DMX Bandwidth Limits and Optimization (Enttec DMX USB Pro MK2)
Dear all,
I have a question that touches both MAX, the DMX protocol and DMX hardware (Enttec dmx usb pro in this case).
I want to create light animation with extremely high speed - specifically turning lights on and off very quickly.
I try to optimize my setup so that it can work as fast and reliable as possible.
I have been doing some tests, but the results sometimes vary - and I am not sure which part of my setup is the bottle neck.
So please excuse the a bit broader scope of the question that exceeds the domain of max programming to a certain degree:
I am wondering:
1) What is the fastet rate that DMX allows, namely at what interval can I send DMX messages out? Are there limitations in the protocol?
2) As for Max object [dmxusbpro] (DMX USB Pro Interface v1.5, © 2005 - 2013 Olaf Matthes).
There are two main paremeters I see here:
The baudrate - where the maximum seems to be 230400.
And the refresh rate, with a maximum of 40. So 40 times a second would mean maximum intervals of 25ms.
It's the question of how to avoid dropouts - when sending the new values not in time.
And: Does it make more sense to send all dmx values at once as one big list, or is it better to send them individually?
3) I couldn't find out if there's a hardware limit to the throughput of the DMX device. Does someone know that?
4) If I'm using for example a metro object to toggle between turning a lamp on and off again - would there be a limit for this as well? There shouldn't right? At least e.g. 10ms intervals should not be a timing problem, correct?
Does somebody know even more efficient hardware / objects to use instead?
Ok, I know these are a lot of questions, and some could perhaps be placed in another forum better, but I am not sure where that would be.
Thanks so much,
all the best,
Frank
Hey Frank!
I will pass along what little I know on this - others here will have much more knowledge. (and accurate terminology : )
1. dunno - I have read the "rate" that DMX can run at, don't remember where or what that number was. (wikipedia?)
If my very fuzzy memory is correct google "artistic License" or some name like that. they are the Artnet creators and there is a lot of info out there.
2. dunno
3. I do not know the specs on your individual device - BUT - I use the Enttec ODEs. They have an onboard processor that takes the instructions and formats the dmx and sends it on - for fastest thruput you must have a device that does the dmx processing ON the device. The lower end units leave that to the CPU, causing a thruput bottleneck when sending big ole huge bucketloads of dmx. (many moving lights with many channels all doing something at once = lag and stutter)
I have used two different (low $) usb devices that did not have this onboard processing and had big hiccups in sending lotsa data to a huge lighting rig, thusly i got the Enttec ODEs and have not had any issues since. The higher dollar USB ones have this chip/processing - dunno about yours
4. dunno
Hope this helps with at least a piece of the puzzle - am curious to what your results are
cheers!
jd
Hi John,
thank you for your thoughts - very helpful.
I also found something on the DMX rate on Wikipedia:
"A maximum-sized packet, which has 512 channels (slots following the start code), takes approximately 23 ms to send, corresponding to a maximum refresh rate of about 44 Hz. For higher refresh rates, packets having fewer than 512 channels can be sent."
So that would mean data can be sent at the highest level of approximately 23ms.
The http://art-net.org.uk/ seems intersting but it seems it needs a win computer to install.
I would be happy to try the Enttec ODE - if it works better the few Dollars are not a problem at all.
Does that work with the [dmxusbpro] object as well, or which one do you use?
If there's a chance to improve the performance with this I'd be happy to do so!
All the best
Frank
Hey Frank!
There are several artnet packages for Max that should talk to the ODEs, Not near my Max machine to tell you which one I use, just put artnet into the Max forums...
I have done only very minimal "does it work?" testing with my ODEs and Max = (yes!)
Most of my dmx stuff revolves around Chamsys, QLC+, and VDMX
The max 44hz refresh rate sounds very familiar - but has been quite a while since I was digging around in the guts of dmx stuff.
Your phrase "but the results sometimes vary" makes me think maybe the interface is possibly not really the issue, look for any network/cpu/usb-hoggin things going on. Flash updates downloading in the background, windows 10 doing whatever it is that it does, things like that. The reasons for slowdowns can be multitudiness, and extremely varied.
Most importantly - post what you've got, the people on the forums here are very helpful, and can be much more helpful when looking at a patch to dissect/troubleshoot.
hope this helps
jd
@Frank Desben
As stated the maximum DMX output rate for a full universe (512 channels) is 44 Hz. However the Enttec DMX USB Pro only allows a refresh rate of up to 40 Hz.
Don't worry about the baud-rate setting for the object. The VCP driver that the Enttec uses ignores this setting.
Sending the values all at once vs. sending individual values makes no difference to the actual DMX output. A DMX signal is simply a constant stream of frames, each of which contains a value for every channel. So the only difference that this could make is with the performance of your Max patch, and I doubt that there would be any significant performance difference between the two.
There's no hardware throughput limitation for a DMX device because there is a direct electrical connection between the 'DMX In' and 'DMX Out/Thru' ports - the signal is not re-transmitted as this would cause a failure on the signal chain if that device lost power.
To be honest, don't worry about any of this unless you look at your output and see a timing problem.
@John Daniel
The issue you raise with processor load on the ODE is not actually entirely correct. The processor load for a computer to drive a serial DMX signal is basically insignificant for any modern computer. The actual issue is that of signal reliability with a continuous DMX output. If the computer is driving the DMX serial port directly (as the Enttec Open DMX USB does) the signal will stop if the computer fails, or if there is any task interruption. The Enttec DMX USB Pro and ODE however, have onboard microcontrollers which consistently produce the DMX output even if the data input from the computer fails.
I do quite some DMX from Max, mostly using the Enttec DMX USB Pro mk1 and a little via Artnet. I haven't spent very much time on this but I have the strong impression that computer controlled DMX output is not steady enough for driving say strobing at or close to the max frequency of 40/44Hz. When we're talking about for example light fades or moving head pans it's no issue if there's a bit of jitter. If you want to do fast strobing jitter and dropouts will be noticeable though.
It's probably a better idea to have the lighting devices control their strobing themselves and send it rate control data over DMX (or other protocol).
I'll gladly be proven wrong if anyone has different experiences!
Thanks for the clarify David!
as I said earlier Frank, others here will have more knowledge and proper terminology : )
I believe the devices i had issues with in the past were the ones mentioned (Enttec Open DMX USB) but it was only when dumping LOTS of dmx really fast... (and not my usual host computer, was a dog loaner laptop with missing keys) - for basic to medium duty mover shows they held up just fine and were quite reliable units. Probably was the computer itself
Would love to see what you are doing when you get further along!
cheers!!
jd
> 4) If I’m using for example a metro object to toggle between turning a lamp on and off again – would there be a limit for this as well? There shouldn’t right? At least e.g. 10ms intervals should not be a timing problem, correct?
Since I 'm working on a nice little setup here I thought I'd give it a try (https://vimeo.com/200077762). I'm using the imp.artnet.controller external with an OXO Netbox 8. The universe I' m testing with has 12 Showtec Compact Par 7 Q4 led spots on it on separate channels. I have the RGBW channels full on and toggle the dimmer channels on/off clocked by a metro. Until 10hz things look steady, above starts glitching. At 20Hz it's very noticeable and very bad at 40hz. It's a much better idea to use the internal strobe function of the spots. They start strobing nicely in sync when receiving the DMX command.
Side note about the OXO Netbox 8: DO NOT BUY THIS THING !!! It 's impossible to figure out how to change the IP address on it. Provided manual and software is very badly translated from Chinese. I resorted to broadcasting the artnet data, which means I better not have much else critical running on this network. Fine in some situations, but definitely not all.
Addendum to that note: I now got config instructions from the manufacturer directly and it can be done. The provided manual is completely erroneous and should be discarded asap.
Dear all,
thanks so much for your valuable input, perhaps to clarify first:
Yes, of course, using the strobe mode of lights results in the best result as far as far as steady frequency is concerned,
but unfortunately syncing complex and fine-grained rhythmical events and to the strobe frequencies (which only have a 256-resolution) only works in a few cases, that's why I am looking at this.
And as I am using on/off of the lights (e.g. master 0/255) the dropouts are very visible when they occur.
"Don’t worry about the baud-rate setting for the object. The VCP driver that the Enttec uses ignores this setting."
Is this really true? I had the feeling increasing the baudrate made it more stable, perhaps only a placebo effect?
@loadmes: Your video / project looks great, has some similarities to what I plan!
What you are describing: That the dropouts start to become more evidient while getting closer to 40Hz is exactly what I experience,
and basically the reason I was posting this thread, in order to see, if there's a work-around.
One thing I was thinking to try:
Use two controllers and use one for all the parameters and another one with just 10 channels used for the masters, perhaps that could make it more reliable if one controller only dealt with a limited amount of channels, as this is supposed to increase performance, correct?
Thanks for you help!
All the best, Frank
It's DTR, not loadmess ;)
I start seeing slight glitches at around 10Hz and by 40Hz it's very apparent. Different hardware, software and OS can yield different results.
Something to consider as well is that given the max transmission rate of 44Hz the theoretical max "signal" frequency is 22Hz. Nyquist. You can't fit a 39Hz pulse in a 44Hz timing grid.
How many and what type of lights do you want to drive? I'm suspecting DMX is not the right protocol if you need it to respond that fast.
I wonder why You guys don't use a Teensy or Arduino for that.
Gives You so many options, for example programming strobe
in arduino sketch, just passing frequency and start / stop from Max,
just to name one simple task...
That's obviously an option but if the number of required outputs surpasses what one microcontroller can provide and you need perfect sync it gets more complicated again. Hence my question to Frank about the number and type of lights.
Sorry, DTR :)
- my mistake !
"frequency is 22Hz. Nyquist. You can’t fit a 39Hz pulse in a 44Hz timing grid."
That is actually a very good point!
I will have to think about what that means for my patching in concrete.
Going through arduino does not seem like a win for me, it would need to go to DMX after that again anayway.
Sorry, I didn't answer the lamp type:
ten moving heads with roughly 25 channels each. DMX-controllable
In that case I think you'll have to work within the limitations of the protocol and hardware.
One thing I do to prevent my DMX stability being influenced by my other processes in Max is separating it as a stand alone app. The generation is done in the general Max patch and the resulting control data sent to the DMX app using jit.net.send or udpsend, depending on the setup. That makes the DMX process have its own thread on the CPU and its own Max scheduler and perhaps help timing performance. I do this for other components of my systems (ie. motion tracking) as well and find it very useful to improve performance.
Besides that you can indeed try 'n keep the channel count low. Not sure how much influence that has on the performance.
@DTR
The generation is done in the general Max patch and the resulting control data sent to the DMX app using jit.net.send or udpsend, depending on the setup. That makes the DMX process have its own thread on the CPU and its own Max scheduler and perhaps help timing performance.
I know, old threat, but I'm curious to this answer.
Is there any performance difference between the send/receive object compared to udpsend/jit.net.send on the same computer between standalones?