E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM Interpretation Questions (http://www.rdmprotocol.org/forums/forumdisplay.php?f=5)
-   -   Command Class / Parameter ID mismatch handling (http://www.rdmprotocol.org/forums/showthread.php?t=1008)

dangeross April 16th, 2009 01:18 AM

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.

ericthegeek April 16th, 2009 10:00 AM

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

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.

sblair April 16th, 2009 01:39 PM

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.

All times are GMT -6. The time now is 11:53 AM.

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