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.

 
 
Thread Tools Search this Thread Display Modes
Prev Previous Post   Next Post Next
Old June 24th, 2024   #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
 

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 07:35 AM.


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