What update rate does wireless support?

[charles59]

My understanding is with DMX I can send updates to the lights every 25 msec if needed.  Does the wireless support this same rate?  I have some Lynx Expresses which work great wired. But when I run wireless, it appears that some of my transitions are "lagging" are having data dropped.  I know many here use a slower update rate, but I would like to know what the wireless actually supports.

[rrowan]

I would guess 50ms. I don't have wireless but it seems the speed RJ supports

Cheers

Rick R.

[lineman]

I have sequences at 10 MS and 25 and 50 I do not have any RGB or smartstrings but I have no problem with dropped data make sure you transmitter is up high and have a clear line of sight

[rm357]

It takes about 23ms to transmit the maximum size DMX packet, which corresponds to about 44Hz.

If you need a higher refresh rate, you can send fewer channels, but I don't know if the lynx dongle supports that... For reference, your DVD/Bluray/Cable/Satellite/Over the air TV is really only 30 frames per second (60 half frames if running interlaced mode and only 24 frames if HDTV in cinema mode...).

For Christmas lights, most people consider 50ms (20Hz) as fast enough.

RM

[charles59]

For Christmas lights, most people consider 50ms (20Hz) as fast enough.

RM

yea, I understand most here use slower refresh.  For me, to get the shimmer effects, and ramps that I want, I have found 25 ms to be effective.  I have not found the wireless to work well for me (it seem very laggy).  And this was a test in my backyard, so the distance, etc wasn't a factor.  That was why I wanted to check on the rate it supported, before I went into more investigation.  As I knew many update at slower rates, I wanted to check what the wireless was rated at.  If it really can support 25ms updates for 512 channels, then I have more investigation to find out why it seems to not be able to keep up.

[charles59]

I have sequences at 10 MS and 25 and 50 I do not have any RGB or smartstrings but I have no problem with dropped data make sure you transmitter is up high and have a clear line of sight

This confuses me, as DMX for 512channels can only support around 25 msec.  I don't understand how you can actually do 10 msec.

[jnealand]

What software are you using?  There are known problems with some software sending data straight out of the sequencer, but work fine when used with the scheduler.  Or in some cases with LSP folks are exporting to a LOR format and playing the sequence using xlights which give them better results.  I'm not the person to explain this but it has been documented in several threads.

[charles59]

Let me restate my problem.  It works fine if I am using wired DMX to my Lynx expresses.  There is no issues, and all works fine.

If I take the same output, and use the wireless for the lynx dongle, that is when I see the issue.  Now, I was trying to understand if the fact that I do have channel changes every 25 msec be why I am seeing an issue when others have not (as I know many plan on slower rates, such as 50 msec). Or does the wireless actually keep up with data dmx packets at the full spec, and then I have to do further investigation.

This is purely a wireless versus no wireless question.

[Dennis Cherry]

Let me restate my problem.  It works fine if I am using wired DMX to my Lynx expresses.  There is no issues, and all works fine.

If I take the same output, and use the wireless for the lynx dongle, that is when I see the issue.  Now, I was trying to understand if the fact that I do have channel changes every 25 msec be why I am seeing an issue when others have not (as I know many plan on slower rates, such as 50 msec). Or does the wireless actually keep up with data dmx packets at the full spec, and then I have to do further investigation.

This is purely a wireless versus no wireless question.

I had that problem last year and the answer is maximum 56K, the 115K needed will not make a difference to the wireless.

[rm357]

This confuses me, as DMX for 512channels can only support around 25 msec.  I don't understand how you can actually do 10 msec.

I don't know if the dongle supports this, but the DMX definition allows "short" packets. For example, if you were to send only 90  channels, you could do 10ms updates.

I'm pretty sure with the dongle, your actual baud rate setting is ignored (although 8 data bits probably is). The driver is a serial com port emulator, but the actual data is sent via USB. I don't know how RJ's design works, but the data transfer from the USB module to the PIC in the dongle appears to be a parallel data connection... If it were a true serial output, the data would be dumped into a buffer and the baud rate would be programmmed into the hardware that outputs the serial data.


RM

[charles59]

Thanks for the answers. 

I understand that one can not do a full dmx univerise on the transmission (just up to the channel number of the highest channel one is changing).  However, I do believe the lynx Donlge always puts out a full 512 channels regardless.


I am not taking about a serial baud rate to the dongle.  I don't write to the dongle as a serial device.  But I do present to the dongle new data about every 25 msec (thus a rate). And I do provide a complete 512 channels worth of data.

So I am not worried about the rate (in terms of a serial device) of writing to the dongle.  THat is constant, and a new data set is presented every 25 msec.


What I am noticing, is that if I put the data stream over wireless to the lynx express, I don't see some of my updates  (yet I do if I I am wired).  So I am wondering it he wireless transmission can actually keep up with the dmx rate of change (if the transmission over wireless is slower, then data would overwrite itself or be "dropped"), which is what I am seeing.

Dennis, I believe your statement of 56K was for the actual wireless transmission, which would seem to correspond what I am seeing.  So effectively, if you use the wireless, your refresh/update rates for channel changes is restricted (if you plan to actually see them).  This is what I am observing, and that seems to make sense).  I wish that had been noted for the wireless if this is all correct, for that can directly influence the usefulness of the wireless for a particular situation.

[rimist]

Rrowan -
Since this issue came up in the past and again now, I think it should be added to the wiki, probably on the transmitter. I would have added it, but didn't see an obvious place, and want to be consistent with other articles with similar information.
My initial thought was to put it at the bottom of the notices section, but that seemed to disrupt the flow. I think perhaps an addendum section with operation notes might be better.
I'll leave it to your judgement if and where the info goes.

- Rimist

Sent from my HTC Glacier using Tapatalk

[rrowan]

I probably should not post this but…

Lets think about this for a moment.

Wireless is ALWAYS slower then wired. While recent advances in wireless has made it better it still not up to the 1 gigabit of wired networks. Then add on top of that the units RJ had available (keep affordable) to him to make a wireless system is not on par with the latest wireless system. Also you made also wonder why the Pixelnet is not wireless at this moment and what is coming out is NOT sending a Pixelnet universe but sync timing. So none of this should be a shock to anyone.

Just something to think about

Rick R.

Santa's flame proof suit is on

[rrowan]

FYI

From RJ's Original post about Wireless, You are not allowed to view links. Register or Login

I am far enough along on this project I felt it was time to put some info out on it.

I am beta testing and working the bugs out of the wireless DMX project. It appears as it will be a successful project and I hope to run all wireless DMX in the show this year.

So far testing has the range at in excess of 1000 ft from my home with the transmitter inside on the workbench.

It also appears that 512 channels at 50ms will work fine.

The transmitter unit appears as if it will run about $55 (maybe less) without a case.

The Reciever that outputs the DMX looks like it will run about $30 without a case.

Both units are really really small.

The recievers put out all 512 channels of the dmx universe and there is no limit to how many recievers you can use.

So it uses one transmitter and how ever many of recievers. Put one where every you do not wish to run cat5.

Think of the Recievers as DMX dongles with out USB cables. they work the same way they make dmx but do not need to be connected to the computer.

They will have RJ45 outputs just like the dongle but no USB jacks so they will retrofit to all the current DMX equipment on DLA.

There is a new Plugin for vixen that I created to make this all work and it just drops in the plugin folder of vixen and then you change you seqence to use it instead of the enttec DMX plugin to use the wireless system.

I can not say when it will be ready for public release but I can say I expect to be using it in the show this year as a beta test. If testing in the coming months go well it may be made availiable for a few beta testers for this year and most likely fully released after xmas and the real testing has completed if all works well as I expect.

Hope this fills in some of the holes.

RJ

Rick R.

[charles59]

I wish I had seen that post about the 50 msec from RJ.  Although my indication is it seems a tad greater then that. 

As for "...thinking about it for second", I did before I posted or used it.   I know something may be slower, but one doesn't know if it it won't meet spec, or how much slower.   So, "in thinking" about it, I  wondered what it was rated for.  That seemed like a reasonable thing to know. Just like in other things you mentioned, knowing something is slower, but having no idea how much slower so one can determine if it is useable for your use doesn't help much. Having the fact that 50 msec in the wiki as a note would be a good thing, I think for others and new users (versus searching through all old posts).  I wasn't complaining about the fact it was slower. I wanted to know what it did support.