Gaps within the packet

[FishAI]

Hi all,

I have a (possibly theoretical) question:

If the message length, which indicates the slot of the checksum, is greater than the PDL plus 24 bytes, could the packet contain gaps?

Using E1.20 - 6.2.3 as an example:

0 | StartCode | SC_RDM
1 | SubStartCode | SC_SUB_MESSAGE
2 | MessageLength | 26 //Not 25 as given in the example
...
21-22 | PID | STATUS_MESSAGES
23 | Parameter Data Length (PDL) | 1
24 | Parameter Data | STATUS_ERROR
25 | <gap> | 0xff //Example value
26 | Checksum High | Checksum also contains the <gap> value
27 | Checksum Low |

I know such a packet wouldn't make much sense in practice, but is it prohibited by the standard? If so, where is this stated?
Should such a packet be processed if the checksum is still correct?

Thanks!

[sblair]

Alright...

#1. Why would you ever want to do this?
#2. If you have seen another product doing this, please share details so we can try reaching out to them.
#3. Doing this is playing with fire while at the same time running around the wet pavement next to the swimming pool.

Okay, now with that all out of the way... It is going to largely depend on the device implementation if it would accept it or not.

In my implementations it would probably work because I just copy the packet into a buffer, do the offset to validate the checksum and then parse the parameter data to the known format of the message.

I absolutely know other implementations that are very strict and would absolutely reject it. I tend to write more forgiving responders than some people but this is absolutely not something I would intentionally code to allow.

Is this strictly against the standard? Meh. I could argue it from either point of view. I can argue that we have clearly stated the packet format and this is an absolute deviation from it. Have we explicitly stated you can't do this? Not anywhere I can think of off the top of my head. We try to be as explicit as possible and avoid any ambiguities in the standard but there are often only so many ways we can think of telling people not to poke themselves in the eye with a stick.

At the same time there is a school of thought that unless a standard doesn't explicitly say you can't do something than it is allowed. I don't particularly subscribe to that philosophy, but at the same time the entire reason RDM is here today is because 25 years ago I *did* successfully use that exact argument that since DMX512 stated it was an RS485 link and it did NOT say I COULDN'T use it for bidirectional data then it must be allowed. Unbelievably the argument worked (after lots of convincing).

Be careful what you ask for and have a REALLY good reason for doing it. In this case the results are likely to be very mixed and if it does work it is going to be more by accident than intention.

[ericthegeek]

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.

If they 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.