E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM Interpretation Questions

RDM Interpretation Questions Discussion and questions relating to interpreting and understanding the E1.20 RDM Standard.

Reply
 
Thread Tools Search this Thread Display Modes
Old April 16th, 2009   #1
dangeross
Junior Member
 
Join Date: Feb 2009
Posts: 13
Question Command Class / Parameter ID mismatch handling

What is the consensus on how a responder should handle and respond to a Command Class CC data and Parameter ID PID data mismatch. As an example if the CC data is DISCOVERY_COMMAND and the PID data is DEVICE_INFO assuming it is not a broadcast address should the responder ignore the command and do nothing or respond with a NACK and if a NACK response is called for should the NACK reason code be NR_UNKNOWN_PID meaning that the CC Command Class takes precendence over the PID Parameter ID or should the NACK reason code be NR_UNSUPPORTED_COMMAND_CLASS which would mean that the PID Parameter ID takes precedence over the CC Command Class.
I am assuming that if the address is a broadcast address that I should just ignore the packet and wait for a valid packet.
dangeross is offline   Reply With Quote
Old April 16th, 2009   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

To be strictly compliant with the example you've given, I think you have to drop the packet and not respond.

Table 6-7 explicitly dis-allows NACKs is response to a Discovery, and according to section 6.3.4:

"The response RESPONSE_TYPE_NACK_REASON shall only be used in conjunction with the
Command Classes GET_COMMAND_RESPONSE & SET_COMMAND_RESPONSE."

This has always bugged me about how NACK_REASON is defined. If you get some unknown PID, say 0x56, if you strictly follow the standard you can't respond and must drop the packet.

A controller should probably be able to handle the case where an oddball CC gets NACK'd though, just in case.
ericthegeek is offline   Reply With Quote
Old April 16th, 2009   #3
sblair
Administrator
 
Join Date: Feb 2006
Posts: 413
Send a message via AIM to sblair Send a message via MSN to sblair
Default

A good implementation of a controller should be able to handle the NACK without falling over but strictly speaking as Eric mentioned NACK's were disallowed for that CC.

It mainly had to do with the fact that if you had NACK's (or ACK_TIMER) on any of the well-defined PID's in the Discovery CC it would completely break discovery. The odd-ball PID under the wrong CC was less of a concern at the time.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair 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

Similar Threads
Thread Thread Starter Forum Replies Last Post
ACK_TIMER Handling ericthegeek RDM General Implementation Discussion 8 January 20th, 2011 08:15 PM


All times are GMT -6. The time now is 04:18 PM.


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