|
RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product. |
|
Thread Tools | Search this Thread | Display Modes |
|
August 17th, 2011 | #1 |
Junior Member
Join Date: Aug 2011
Posts: 8
|
Handling incorrect messages
Hello,
I am working on implementing the, hopefully according to the standard, correct actions to be taken on incorrect messages that could be received by a responder. After reading the standard several times I am still left with the following questions on how to do things proper: 1. A message count must be 0x00 as received by a responder. What if a non-zero value is received, this should generate a format error? 2. What error to give with a wrong message class value -> format error? 3. When the packet data length mismatches with data length -> format error? 4. When a PID requested via PARAMETER_DESCRIPTION is not available -> format error or range error? Greetings Marc |
August 17th, 2011 | #2 | ||||
Administrator
|
Quote:
Quote:
Quote:
Quote:
__________________
Scott M. Blair RDM Protocol Forums Admin |
||||
August 18th, 2011 | #3 | ||
Task Group Member
Join Date: Aug 2008
Posts: 375
|
Quote:
Technically, NACK is only allowed for GET_COMMAND_RESPONSE and SET_COMMAND_RESPONSE. It doesn't address whether you can NACK an unknown command class. Scott is correct that if you do decide to NACK it, NR_UNSUPPORTED_COMMAND_CLASS is the correct NACK reason code to use. One quirk of the standard: Per table 6-7 you can never NACK a discovery request. That means if you get an unknown PID with a discovery command class, all you can do is drop it since NACK is not allowed. I'm not sure this was the intended purpose, but that's how it's written. (The original motivation was to ensure that Discover Unique Branch, Mute, and Unmute were always handled immediately). Quote:
There are three lengths in RDM: 1: The "Message Length" Field in the packet. 2: The PDL field in the packet (should be exactly "Message Length" minus 24). 3: The number of bytes you actually receive with your UART (should be "Message Length" plus 2). If all 3 don't match, then some part of the packet has been corrupted in transit. It's common to see this happen. The checksum used in RDM is relatively weak. Because it's an additive checksum, if a 0x00 gets added or dropped from the packet, the checksum won't change. It also can't detect many two-bit errors. That means if a communication error occurs (RF noise, loose connection, UART Error), or a splitter/hub drops one or more bytes, the checksum can't reliably detect it. The only way you have to know if this has happened is to verify that the lengths all match. |
||
August 18th, 2011 | #4 |
Task Group Member
Join Date: May 2010
Location: San Franciscio
Posts: 57
|
I agree with Eric. Responders should be strict in what they accept. Anything else encourages sloppy programming on the controller side.
|
September 1st, 2011 | #5 | |
Task Group Member
Join Date: May 2009
Location: Gothenburg
Posts: 40
|
Quote:
Problem is, that out in the real world the controller is not the piece of equipment that will get the blame if your responder does not work, the user just knows that all other responders he had do work... Hence, the user will blame the responder that does not work. When all responders behave the same way (that is when the standard is no longer open for interpretation), then the controller will get the blame. Compare with the web browser issues... We, who know the details, know that when a site that is W3C compliant that does not show up correctly in IE, but is Webkit based browsers etc, it is IE that is the fault, but the general user does not understand that.
__________________
Michael Karlsson LumenRadio AB |
|
September 1st, 2011 | #6 |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
The matter of how strict a device should be is a philosophical one. It's a matter of strict compliance vs. "I can figure out what they meant to do so I will accept it". I've seen lots of devices that have the wrong PDL for things like the mute Response. They send perfectly valid, properly formatted RDM packets, the PDL:PDATA fields just don't match what's specified for that particular PID.
But from my perspective the length fields are *not* part of the same philosophical debate. Because the checksum is so weak, if the lengths don't match then the packet is corrupt. If you ignore the lengths, Interesting things can happen. Imagine if a 0x00 byte got dropped from a packet such that the checksum ended up in the PDATA fields. |
September 2nd, 2011 | #7 |
Task Group Member
Join Date: May 2009
Location: Gothenburg
Posts: 40
|
I totally agree that if the length does not match, it is something wrong (especially if message length is not consistent with PDL)... But there are just so many things that the responder could cope just fine with. For instance the message count field.
If the message count field is != 0, it is probably because the controller used the same memory buffer for the request as for a response but did not set the field correctly. This should be caught in the tests, not out in the field. If someone have equipment from one manufacturer that ignores this fault in the controller, and then gets a load of moving heads from a manufacturer that drops these packages, I would be surprised if the user in that cased called the controller manufacturer and yelled at them, I rather think they will throw out the equipment they see as "non-working". I'm not saying we should encourage sloppy implementations on the controller side, but we have to keep the real world in mind. And the most important part of the real world: the end user.
__________________
Michael Karlsson LumenRadio AB |
September 2nd, 2011 | #8 |
Administrator
|
As has been said, there is a balance. My own design philosophy is to make it as generally forgiving as possible. This in itself doesn't force non-compliant products to behave better, but it does at least help the end-user accomplish what they need to.
As said, the end-user is unlikely to understand or blame the proper product that is the non-compliant one when they are faced with issues anyway.
__________________
Scott M. Blair RDM Protocol Forums Admin |
Bookmarks |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Correctly handling ACK_OVERFLOW | nomis52 | RDM General Implementation Discussion | 13 | January 29th, 2011 09:25 PM |
ACK_TIMER Handling | ericthegeek | RDM General Implementation Discussion | 8 | January 20th, 2011 08:15 PM |
Command Class / Parameter ID mismatch handling | dangeross | RDM Interpretation Questions | 2 | April 16th, 2009 01:39 PM |