E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM General Implementation Discussion

RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product.

Reply
 
Thread Tools Search this Thread Display Modes
Old April 12th, 2015   #1
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default 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
berntd is offline   Reply With Quote
Old April 12th, 2015   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old April 12th, 2015   #3
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

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
berntd is offline   Reply With Quote
Old April 13th, 2015   #4
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

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
Reply

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -6. The time now is 01:03 PM.


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