RDM Implementation Requirements - E1.20 RDM (Remote Device Management) Protocol Forums

RobbG · January 21st, 2015

Hi there,

I'm in the process of designing a new implementation of RDM responder functionality but there's one thing that I can't seem to find anywhere. What's the maximum possible length of any single RDM packet going to be? There doesn't seem to be much mention of it in the standard and I'm aware that there may not be one set but having to compensate for the possibility of receiving Megabytes long packets over RDM is quite difficult on an embedded platform.

Thanks in advance,

// Robb

ericthegeek · February 18th, 2015

257 bytes.

The maximum packet size is determined by the "Message Length" field that is an 8 bit value between 24 and 255. This length includes the Startcode, but does not include the checksum.

Adding a 2-byte checksum to the 255 maximum for the "Message Length" field gives you 257 bytes. You will never see a megabyte long packet.

See E1.20-2010 section 6.2.3 for details.

Any individual packet will be 257 bytes max, but responders can generate an arbitrary number of ACK-Overflow responses to return data of any size by breaking it into smaller chunks. Due to practical constraints, responders should limit ACK-Overflow sequences to a few packets, I typically say 5 or 6 maximum. That's because any error in the ACK-Overflow sequence (lost or corrupt packet) effectively requires the controller to start over from the beginning.

From the responder's point of view, it only has to implement ACK-Overflow if it needs it. Most responders don't need to use the feature.

Controllers on the other hand need to aware that responders may generate long ACK-Overflow sequences.

January 21st, 2015	#1
RobbG Junior Member Join Date: Jan 2015 Posts: 3	RDM Implementation Requirements Hi there, I'm in the process of designing a new implementation of RDM responder functionality but there's one thing that I can't seem to find anywhere. What's the maximum possible length of any single RDM packet going to be? There doesn't seem to be much mention of it in the standard and I'm aware that there may not be one set but having to compensate for the possibility of receiving Megabytes long packets over RDM is quite difficult on an embedded platform. Thanks in advance, // Robb

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
RDM software/implementation	austen	RDM User Discussion	5	April 4th, 2013 12:02 AM
Electrical Safety requirements for DMX / RDM lines	R.Schladör	RDM Physical Layer/Hardware Discussion	1	November 18th, 2010 11:56 AM
Partial RDM implementation?	svanciel	RDM General Implementation Discussion	7	November 7th, 2008 08:19 AM
Master Fader accross Rdm implementation Question	berntd	RDM General Implementation Discussion	1	May 9th, 2008 01:12 AM
Welcome to the RDM General Implementation Discussion Forum	sblair	RDM General Implementation Discussion	0	May 31st, 2006 11:38 PM

February 18th, 2015	#2
ericthegeek Task Group Member Join Date: Aug 2008 Posts: 379	257 bytes. The maximum packet size is determined by the "Message Length" field that is an 8 bit value between 24 and 255. This length includes the Startcode, but does not include the checksum. Adding a 2-byte checksum to the 255 maximum for the "Message Length" field gives you 257 bytes. You will never see a megabyte long packet. See E1.20-2010 section 6.2.3 for details. Any individual packet will be 257 bytes max, but responders can generate an arbitrary number of ACK-Overflow responses to return data of any size by breaking it into smaller chunks. Due to practical constraints, responders should limit ACK-Overflow sequences to a few packets, I typically say 5 or 6 maximum. That's because any error in the ACK-Overflow sequence (lost or corrupt packet) effectively requires the controller to start over from the beginning. From the responder's point of view, it only has to implement ACK-Overflow if it needs it. Most responders don't need to use the feature. Controllers on the other hand need to aware that responders may generate long ACK-Overflow sequences.