Correctly handling ACK_OVERFLOW - E1.20 RDM (Remote Device Management) Protocol Forums

nomis52 · September 5th, 2010

Here's a related problem: The standard states "The responder shall abort a partial transfer of overflow data for a PID when receiving a command
for a different PID before the overflow data transfer is complete."

It says nothing however about what happens if the src UID differs. In multi-controller setups like E1.33 we're going to need to be careful to ensure one of the following:

i) other get/set messages can't be interleaved when an ACK_OVERFLOW sequence is occurring on the DMX side
ii) if interleaving is allowed, the responders need to track the transfer status per src UID and only reset if a different PID is received from the same src UID.

I'll have a guess that no one has designed their responders to handle case ii) so I think we'll have to go with i). This means that gateways are going to have to buffer the entire message.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Switch to Linear Mode Switch to Hybrid Mode Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
ACK_TIMER Handling	ericthegeek	RDM General Implementation Discussion	8	January 20th, 2011 08:15 PM
Command Class / Parameter ID mismatch handling	dangeross	RDM Interpretation Questions	2	April 16th, 2009 01:39 PM

September 5th, 2010	#4
nomis52 Task Group Member Join Date: May 2010 Location: San Franciscio Posts: 57	Here's a related problem: The standard states "The responder shall abort a partial transfer of overflow data for a PID when receiving a command for a different PID before the overflow data transfer is complete." It says nothing however about what happens if the src UID differs. In multi-controller setups like E1.33 we're going to need to be careful to ensure one of the following: i) other get/set messages can't be interleaved when an ACK_OVERFLOW sequence is occurring on the DMX side ii) if interleaving is allowed, the responders need to track the transfer status per src UID and only reset if a different PID is received from the same src UID. I'll have a guess that no one has designed their responders to handle case ii) so I think we'll have to go with i). This means that gateways are going to have to buffer the entire message.