Handling incorrect messages - E1.20 RDM (Remote Device Management) Protocol Forums

ericthegeek · September 1st, 2011

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.

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

September 1st, 2011	#6
ericthegeek Task Group Member Join Date: Aug 2008 Posts: 390	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.