RDM Responder Tests and background DMX

[ericthegeek]

Originally Posted by ericthegeek

In older versions of DMX (USITT DMX512) you could send variable length packets. I don't remember if E1.11 disallows that or not, but it's always been a bad practice.

I finally had a chance to pull out my copy of E1.11-2008. In section 8.5.1 it says:

"Once a controller is configured for a particular application, all NULL START Code packets should have the same number of slots."

Now, that's a "should", not a "shall", so variable length NSC packets don't strictly violate the standard. Still, it's a *very* bad practice.

[Arjan]

alvangee : I just ran a RDM Responder test with 128 DMX slots in between. DMX Frame rate = 20.

I have two Raspberry Pi's which are acting as an Enttec DMX USB Pro. One is set in Mode 2, and one is set in Mode 3 (OLA RDM Sniffer compatible).

And one Raspberry Pi as a RDM Responder.

I have uploaded the output of the sniffer here :
https://drive.google.com/file/d/0B0Q...ew?usp=sharing

When you do a grep DMX 128" Sniffer.log then you will see that the DMX data is correctly outputted by the host and widget.

When you look at the sniffer monitor https://picasaweb.google.com/lh/phot...eat=directlink
then you see statistics where the break-to-break time is 25000 us


- Arjan