DMX Read/Write per second

[Network_Josh]

Does anybody know how many read/writes per second is the standard for DMX

 

Thanks,

Josh

[Tom Baldwin]

Not quite sure how your question is meant.

DMX (pre the latest revision, at least) is simplex.

The data rata is 250k baud.

 

It's not necessary to transmit all 512 channels in a frame - only those up to the highest channel number in use. If all 512 channels are transmitted with the minimum breaks etc, then a frame rate of 44Hz is achieved - but if you only transmit one channel, you could achieve a terrifyingly high frame rate.

On the other hand, AFAIR the break between frames can be up to a second long, so your refresh rate could be less than 1 Hz...

 

Why do you ask?

[Network_Josh]

There is a company in france who produce their own PCI DMX Boards for use with lightjockey etc.

 

They state that for a card with 1 DMX out it can produce upto 40 read/writes a second and for 3 DMX outs it can produce upto 9 read/writes a second.

 

However - I don;t know if the first itself is a decent figure - does anyone know what a Pearl, or Hog etc are?

[dbuckley]

... but if you only transmit one channel, you could achieve a terrifyingly high frame rate.

Not so - to stop people doing just that there is a minimum break-to-break gap of 1196uS, so about 836 updates/sec worst case.

 

Does that win me today's "sad b'stard" award...?

[jfitzpat]

There are several speeds at issue. The first is the speed of DMX itself.

 

Virtually all upper end control systems send the DMX data itself at the fastest rate the standard allows. That is, about 44 times per second for 512 channels, higher rates for smaller channel counts.

 

We are a PC based system and both our USB based interfaces (1 in 1 out and 1 in 4 out) always transmit at max speed. We also automatically change the number of channels transmitted based on fixture assignments in software. That is, if you use just 32 channels starting at 1, we'll send updates for those channels roughly 700 times per second.

 

There are a number of good reasons to always transmit DMX as fast as the standard allows. For example, DMX is open ended with no error checking in the packets. If you get a single bit error on an intensity or dimming channel, it can be pretty imperceptable if it is only used by the receiver for a 44th of a second. Updating 400-500-600 times a second, you can almost never see it.

 

In other words, transmitting slower doesn't reduce the chances of an communication error occuring, but it does mean that any errors are displayed much longer.

 

The second speed is how fast the controller updates the data being sent via DMX. In other words, with only 32 channels, we send DMX packets at roughly 700 times per second, but the data in the packets does not update at that speed - IE, some adjacent packets are identical. It is still worth refreshing the data as fast as the standard allows to negate communication errors, etc., but the data refresh rate is a compromise between computational overhead and the perception of the human eye.

 

In our worst case, say 16 universes filled with 2,000+ 4 channel pan/tilt fixtures, each running it's own motion generator, and all motion generators 'morphing' shapes in 32 overlapping fades, our minimum data update rate is 30 times per second. That is, we generate new packets, worst case, 30 times per second, then transmit each frame generated as often, and as fast, as the standard allows.

 

We use 30 updates per second as our minimum acceptable 'update rate' because of lasers and media servers. Lower update rates can give perfectly satisfactory results for conventional and intelligent lighting, but video generally updates near the 30 fps mark in the US, so calculating fades, movement, etc. at or above this mark gives you smoother transitions when controlling media servers via DMX than with most existing lighting controllers. Also, our earliest beta tester specializes in 'spectaculars' and one of his specific requests was 'tighter' response on his laser and pyro cues. I can't see the difference, but he was able to immediately identity which system was compiled with a fixed update rate of 24 times per second and one fixed at 30 in a blind test. He may just have above average perception, but even I can see the difference when controlling video.

 

I don't know of anyone who insures an update rate higher than 30. Many upper end consoles seem to update in the 20 to 25 times per second range - though one well known one can drop to update rates as low as 16-17 times per second. At update rates in the 12-14 range, even a simple dimmer fade starts to get a bit 'jerky' to the average eye. This gibes with a fairly widely held industry believe that 15 times per second is a minimum.

 

Using that standard, an update rate of 9 would seem completely worthless for most applications. I hate to jump to conclussions, but not only building something that slow, but then telling users about it might be why this particular manufacturer seems to be in the business of ripping off Martin instead of building their own complete product.

 

We knew that this sort of rip off/clone market is an unavoidable reality. That is why we just bit the bullet and priced very aggressively from the get go, and have continued to press the pricing envelope as we go. But, as someone who has to make a living developing HW and SW it is hard for me to think of 'piggy back pirates' as anything but pond scum.

 

-jjf

Innovate Show Controls

 

Edit: I didn't break out the calculator and figure in the mark and little preamble. Now that I think of it, 32 channels is probably around 600 times per second (sorry - I shouldn't have done 16 x 44 in my head).

[Network_Josh]

Thanks for that

 

Josh

[Tom Baldwin]

... but if you only transmit one channel, you could achieve a terrifyingly high frame rate.

Not so - to stop people doing just that there is a minimum break-to-break gap of 1196uS, so about 836 updates/sec worst case.

 

Does that win me today's "sad b'stard" award...?

Fair cop.

 

Can we agree to define 836 frames/sec as "surprisingly to startlingly fast"?