Required handling of sequences of RDM broadcast cmds - E1.20 RDM (Remote Device Management) Protocol Forums

ericthegeek · August 18th, 2011

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.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Is there a minimum required PID list for sub-devices?	p_richart	RDM Interpretation Questions	4	November 7th, 2008 01:04 PM
broadcast Disvovery Mute/Unute	berntd	RDM Interpretation Questions	2	April 8th, 2008 10:07 PM

August 18th, 2011	#2
ericthegeek Task Group Member Join Date: Aug 2008 Posts: 390	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.