View Single Post
Old April 13th, 2015   #4
Task Group Member
Join Date: Aug 2008
Posts: 363

You are allowed to ACK_TIMER everything except discovery. In fact, this is how many of the wireless RDM systems work. They can't guarantee that the data will get over-the-air within the 2ms allowed for a response, so they ACK_TIMER everything to give them extra time.

That being said, I would consider this kind of behavior undesirable. Not all controllers implement ACK_TIMER handling, and not all of them implement it the same way. This will hurt your compatibility with some systems out there. It will work perfectly fine with many controllers, but it will fail with some, and be flaky with others.

For controllers that don't implement ACK_TIMER handling properly, it's really a controller problem and should be fixed in the controller, but you're the one who will get the phone call from the user.

Whenever possible, I recommend that you avoid ACK_TIMER except when you absolutely need it. If you can't avoid ACK_TIMER, there are some best practices to follow:

1: When the controller sends GET QUEUED_MESSAGE, return any pending ACK_TIMER fulfillment messages first, before sending unsolicited messages such as a lamp-hour change.

2: Make sure your "Message Count" goes to zero within a reasonable period of time after sending your ACK_TIMER fulfillment messages. Some controllers send a GET QUEUED message until the "Message Count" field reaches zero, but if the count never goes to zero they can get stuck in a loop or time out.

3: Avoid chained ACK_TIMER's if possible. For example, if you've asked for 200ms, but still aren't ready when the GET QUEUED_MESSAGE arrives you can queue up another ACK_TIMER for additional time. This is allowed, but can cause interoperability issues. Better to request the maximum time you'd need the first time rather than using multiple chained delays.

4: Whenever possible, NACK without ACK_TIMER. If you can determine immediately whether a request is valid, NACK it right away rather than ACK_TIMER'ing and subsequently queuing up the NACK.

A random thought: It would be interesting to characterize your OS and see how often it takes longer than 2ms to respond. If it's only 1 or 2 times out of, say, 10,000 packets, you might be better to just drop the request when you can't respond in time and let the controller re-try. I'm not sure if this is the best solution or not, but it's something to consider.

Last edited by ericthegeek; April 13th, 2015 at 11:11 AM.
ericthegeek is offline   Reply With Quote