Required handling of sequences of RDM broadcast cmds

[ericthegeek]

The best solution is to make sure your responder can always handle back to back broadcast requests. That means either fully processing the request within 176 us, or saving the request for processing as a background (low priority) task.

Take the common case of an EEPROM write which can take several ms. I keep a copy of the DMX address in both RAM and EEPROM. When the Set DMX Address broadcast request happens, I immediately update the RAM copy, and set a flag that the EEPROM needs to be updated. Then, the lazy loop (low priority task that handles EEPROM writes, display updates, housekeeping, etc.) writes it to EEPROM whenever it gets around to it. If a GET DMX Address comes in before the EEPROM write is finished, it sends the address from RAM because the EEPROM may be busy or out of date.

There's a slight risk that if the system loses power between the request and the end of the EEPROM write that the address change could be lost, but the window is very small (a few ms) and the impact if it does occur is minimal.

If you can't do this, then you may have to drop the request. RDM Broadcasts are not guaranteed to be reliable, so you are allowed to drop the packet. However, this should be avoided if at all possible.

That's really all that a responder can do.


If you're building a controller, it's a good idea to wait 10 to 20ms after sending a broadcast request before you send another broadcast packet. This will allow any poorly implemented responders time to finish processing the previous broadcast.

[nomis52]

This came up at the most recent plugfest. The responder tests now have an additional flag --broadcast_write_delay which you can use to adjust the delay between sending a broadcast set and the next RDM request.

[eldoMS]

Hi Eric

Separate from EE memory writes, which I agree can be handled as you describe, there are other reasons a responder needs more time e.g. when it is a proxy or bridge/gateway device to where the data should be going.

Such a device can indeed store some or even many SET requests but at some point it can lead to an overrun in some practical device, that is the case I meant to be referring to also.

To the standard defining folks:

With regards to the 10 to 20 ms back-off as Eric is suggesting in practice for a controller to handle the overrun issues, are there plans on integrating in the standard a number as a suggested spec for this, or somehow a way informing a controller on responder capabilities on this point?

Leaving this point open and up to implementation can (and probably will) lead to incompatibilities between equipments that in a large part could be prevented by some agreement and future definition on this point.

A related aspect to this is also that the real life figure of 5 to 20 ms is often sufficient to handle these situations while the ACK_TIMER has a granularity of 100 ms. These large time chunks lead to extraordinary long delays that can be reduced a lot by allowing, in addition to the current definition, some finer grained timing.

Very interested to hear your opinions!

Greetings

Marc

[ericthegeek]

Originally Posted by eldoMS

Such a device can indeed store some or even many SET requests but at some point it can lead to an overrun in some practical device, that is the case I meant to be referring to also.

One option when this occurs is for the proxy to queue up a response with a NACK:NR_PROXY_BUFFER_FULL. For example, if you've gotten too many Broadcast SET FACTORY_DEFAULTS, you can queue up a SET_RESPONSE FACTORY_DEFAULTS NACK:NR_PROXY_BUFFER_FULL. This gives the controller a way to know that the proxy has overflowed.

Fortunately, assuming a reasonable buffer size in the proxy, these conditions are unlikely to occur in the real world. The fraction of broadcast packets in most RDM systems is relatively small. It's quite rare to see more than a handful of broadcast requests back-to-back.

I mostly see broadcast used for:
DISCOVER_UNIQUE_BRANCH
UNMUTE
IDENTIFY OFF

The first two are only for discovery, and since proxies handle discovery on behalf of their proxied devices these can be handled immediately in the proxy and don't need to be queued.

You may see a Broadcast IDENTIFY OFF sent 3 or 4 times back-to-back by a controller (to mitigate lost or corrupt packets), but you won't see hundreds at once.

Originally Posted by eldoMS

With regards to the 10 to 20 ms back-off as Eric is suggesting in practice for a controller to handle the overrun issues, are there plans on integrating in the standard a number as a suggested spec for this, or somehow a way informing a controller on responder capabilities on this point?

The is really an implementation-specific decision. A wired proxy may need 10ms, but a wireless proxy could require 100ms or more. Whatever value got written into the standard, some would say it's too long, and some too short.

Anyone who's designing a controller that makes heavy use of broadcast packets will need to consider the real-world behavior of proxies. Fortunately, other than test equipment, this kind behavior is very rare.