DMX binding, refresh

Add-ons Bindings
1

Hi,

This discussion is related to my PR #4775 in OH1.

Currently DMX data is only send to the output when at least one channel changed. The following is copied from the PR:

I have incorporated all comments. However, after re-reading E1.11 (DMX 512) and E1.31 (sACN) as well as ArtNet, I come to the conclusion that the “never-refresh-policy” is plain wrong when it comes to standards compliance.

E1.11 states for DMX512 that there is a continous data stream (with a maximum MARK before BREAK of 1s), and defines that longer periods are considered as Data Lost (8.9). The standard does not define how a receiver should behave if that occurs, besides that it should remain operational for at least 60s. So after 60s without signal a standard compliant receiver could even turn off (9.2).

E1.31 defines that if the output is not changing, the last packet should be re-transmitted three times. After that the sender is allowed to pause sending for 800-1000ms (6.6.2).

ArtNet defines that non-changing DMX data should be retransmitted at approximately 4s intervals, but it is recommended for compatibility with sACN to re-transmit after 800-1000ms (chapter ArtDmx, p. 46).

The PR changes the default behaviour to “send always”, which is compatible with all protocols. With a new configuration option this can be changed to suppress repeated transmissions for 800ms or to the current behaviour.

@watou requested your thoughts on this.

Best regards

1 Like
2

Thank you very much, Jan.

For others’ reference, here is the pull request.

3

Just some thoughts:

The reason for suppressing repeated packets is obviously traffic reduction. This should not be a problem for directly connected (rs485) devices.

For OLA in most cases there will be no problem. OLA on the same host sends the traffic over the loopback device and the network will not be affected.

So two remain: the ArtNet and the E1.31/sACN. These are usually connected via Ethernet.

ArtNet uses unicast for small number of receivers and Broadcast for larger numbers. E1.31 uses unicast or multicast. Sending all updates (i.e. all 35ms) may affect the network performance of all devices in the broadcast/multicast (only on switches that do not have proper multicast support). But the packets itself are small (~600 bytes), so single universes are around 30 packets/s, with 18kB/s. This should not be a problem for recent hardware. And with can be reduced to ~1 packet/s with the reduced repetetion option.

Best Regards