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
Register FAQ Community Calendar Today's Posts Search

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

 
 
Thread Tools Search this Thread Display Modes
Prev Previous Post   Next Post Next
Old August 18th, 2011   #3
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 390
Default

Quote:
Originally Posted by eldoMS View Post
2. What error to give with a wrong message class value -> format error?
This is a bit of a gray area. It's depends on how you interpret table 6-7.

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:
Originally Posted by eldoMS View Post
3. When the packet data length mismatches with data length -> format error?
I disagree with Scott on this one. A responder needs to be very strict about enforcing the length fields. If the lengths don't match, the packet is almost certainly corrupt, and you should treat it like a checksum error and ignore the packet.

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.
ericthegeek is offline   Reply With Quote
 

Bookmarks


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
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


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


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