E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM General Implementation Discussion (http://www.rdmprotocol.org/forums/forumdisplay.php?f=4)
-   -   What is the genral opinion about using ACK_TIMER for... (http://www.rdmprotocol.org/forums/showthread.php?t=1227)

berntd April 12th, 2015 09:20 PM

What is the genral opinion about using ACK_TIMER for...
 
Hi

We have a new device application which does not use a real time OS.
Our software guru has told me that he want to use the ACK_TIMER reply to every single rdm command (not discovery).
Once the command has then travelled through the OS and a reply is available, the reply will become a QUED_MESSAGE

The spec does not forbid this but what is the general opinon on this?

Regards
Bernt

sblair April 12th, 2015 09:57 PM

It is allowed to do this, but obviously not preferred. Make sure you pay attention to all the messages where ACK_TIMER is not allowed.

Also, for any message that is ACK_TIMER I would make sure to have it cached for a reasonable amount of time in case the controller comes back asking for it again rather than collecting it with QUEUED_MESSAGE.

berntd April 12th, 2015 11:08 PM

Yes, understood.

My understanding is that only discovery messages are not alowed ACK_TIMER.

I don't think they (software guru) meant that the ACK_TIMER will be very long. It is just that he can't meet the realtime responce requirements so he might need maybe a ms or 2.

Regards
Bernt

ericthegeek April 13th, 2015 10:34 AM

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.


All times are GMT -6. The time now is 12:14 PM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2020, vBulletin Solutions, Inc.