View Single Post
Old October 14th, 2008   #3
Task Group Member
Join Date: Aug 2008
Posts: 369

The way I read the document is that a responder that wants to use ACK_TIMER has to support queued messages. If a responder can't support queued messages, then it can't use ACK_TIMER.

Still, there are devices out there that don't do this, so to some extent we're stuck with this behavior. Since it's not defined in the standard, is there a generic way to handle this? What I'd really like to avoid is a situation where the controller has to keep a table of specific device types and how they handle ACK_TIMER.

The worst case is a device that claims to support queued messages, but uses ACK_OVERFLOW style handling of ACK_OVERFLOW. In that case, you have to:

Send Get Lamp Hours
Wait for the timeout
Send get queued messages until you drain everything in the queue.
Determine the device did not queue the appropriate response
Send Get Lamp Hours Again
Wait for the timeout again
Send Get Lamp Hours a third time
Read the response

This is very cumbersome.

I don’t mind the TTL style handling you mention, but I’m afraid adding that to the RDM standard would be outside the scope of the current errata document.

At a minimum, I'd like to document the behaviors that are out there in a public forum. This will help everyone.
ericthegeek is offline   Reply With Quote