E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM Interpretation Questions

RDM Interpretation Questions Discussion and questions relating to interpreting and understanding the E1.20 RDM Standard.

Reply
 
Thread Tools Search this Thread Display Modes
Old 2 Weeks Ago   #1
FishAI
Junior Member
 
Join Date: Jul 2019
Posts: 8
Default Gaps within the packet

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:
Code:
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!
FishAI is offline   Reply With Quote
Old 2 Weeks Ago   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 436
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old 2 Weeks Ago   #3
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 376
Default

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

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

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
Responder Packet Timing issue berntd RDM Timing Discussion 10 May 27th, 2015 12:40 AM
3.2.1 Responder Packet Timings prwatE120 RDM Timing Discussion 6 May 23rd, 2009 08:32 AM
Packet Captures? jhuntington RDM General Implementation Discussion 0 March 4th, 2007 07:19 PM


All times are GMT -6. The time now is 09:36 AM.


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