E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM General Implementation Discussion (http://www.rdmprotocol.org/forums/forumdisplay.php?f=4)
-   -   RDM E1.20 Draft Errata (http://www.rdmprotocol.org/forums/showthread.php?t=253)

sblair February 20th, 2008 09:18 PM

RDM E1.20 Draft Errata

Below are the list of identifed errata for the E1.20 standard and their *proposed* corrections. We will soon begin a Public Review cycle to publish a formalized errata document.

I'm not looking for suggestions to extend or change functionality in RDM at this time, only to identify any open Errata issues that we have missed.

If you are aware of something that should be considered that is not in the following list, pleast post immediately so we can address it.


3.1.2 Table 3-2 Note #3

2.804uS should be 2.804mS.

3.2.1 Responder Packet Timings

The last paragraph references Table 3-2 Line 3. It should reference Table 3-3 Line 1.


6.2.11 Checksum

The following text should be added to this section:

“If the checksum field in the packet does not match the calculated checksum, then the packet shall be discarded and no response sent.”

6.2.11 Table 6-6

In the example:
Slot 1 should be 0x01.
Slot 16 should be 0x01 not 0x00
Slot 24 should be 0x04 not 0xFF.
Slot 25 should be 0x06
Slot 26 should be 0x6A


6.3.3 Acknowledge Timer

The example shows an ACK_TIMER response to a GET: LAMP_STRIKES message. The example incorrectly shows a PDL of 0x04. The PDL should be 0x02. The Parameter Data (PD) section of the message should be 0x0258 rather than 0x00000258 as stated.


9.2.2 Sub-Device All Call

The following text should be added to Section 9.2.2: “Broadcast GET commands sent to the SUB_DEVICE_ALL_CALL Sub-Device ID are not allowed. Any responder receiving a GET command sent to this Sub-Device ID shall respond with a NACK with a NACK Reason Code of NR_SUB_DEVICE_OUT_OF_RANGE.”

All GET messages throughout Section 10 should show the show the Sub-Device GET range stopping at 0xFFFE.

10. (Entire Section) Port ID

Section that the Port ID shall always be in the range of 1-255 for Controller generated messages.

All Get/Set message tables in Section 10 incorrectly show the Port ID range being from 0x00-0xFF. These messages should all show the allowed values for this field in the range from 0x01-0xFF.

10.2.1 Get/Set Communications Status

The following sentence should be added to both the Length Mismatch and Checksum Fail paragraphs:

“Messages sent to an applicable Broadcast address shall also increment this counter.”


10.2.1 Communications Status

Short Message should be re-defined as the following:

“Short Message – This field shall be incremented any time the message terminates (either due to a BREAK or timeout condition occurring) before a complete Destination UID has been received.”

Length Mismatch should be re-defined as the following:

“Length Mismatch - The number of slots received before a BREAK or message timeout condition occurring did not match the Message Length plus the size of the Checksum. This counter shall only be incremented if the Destination UID in the packet matches the Device’s UID.”


10.4.2 Get Parameter Description

The TYPE field in the response for this message incorrectly is associated with a Sensors related table (Table A-12). This field has no meaning and should be filled with 0x00 in the response. Controllers should ignore the contents of this field.


10.7.2 Get/Set Sensor Value

When doing a SET to reset the Sensor values, the response contains the current value for that Sensor. Sending this to Sensor 0xFF is used to reset all Sensors. The response for the Sensor values is currently undefined behavior with Sensor 0xFF.

The following text should be added:

“The Sensor Value fields in the response to a SET Command sent to Sensor 0x0FF shall be ignored by the Controller. There is no requirement on a responder to provide specific values in this response.”


10.7.2 Get/Set Sensor Value

Add the following sentence to: Lowest Detected Value, Highest Detected Value, and Recorded Value:

“If this value is not supported, then this field shall be set to 0x0000.”

All 16-bit and 32-bit Timers/Counters
10.2.1 Communications Status
10.8.1 Device Hours
10.8.2 Lamp Hours
10.8.3 Lamp Strikes
10.8.6 Device Power Cycles

All 16-bit and 32-bit timers/counters should be referenced to explicitly be unsigned values and to not roll over if their value exceeds the max value.

The following phrase should be added to these messages:
“This value for this field shall be unsigned and not roll over when maximum value is reached.”


Appendix B

Add the following text to Appendix B:
“ ‘Slot Label Code’ refers to the Slot ID in Table C-2.”


D.33 Mute

The definition should state that being Muted only stops the device from responding to UNIQ_BRANCH and not any other messages. The following text should be added:

“A device that is “muted” only stops responding to the DISC_UNIQUE_BRANCH message and shall still respond to all other messages”


endoftheworld February 21st, 2008 04:49 PM

ACK_TIMER support requirements
Open for discussion, but just my thoughts

6.3.3 Acknowledge Timer

Though the section describes the ACK_TIMER behaviour in detail, it doesn't outline what exactly constitues the requirements for a Responder to correctly support ACK_TIMER.
From what I understand :-
A Responder should support QUEUED_MESSAGE to effectively have ACK_TIMER responses working. But does this also mean that having QUEUED_MESSAGE in their supported PID's , a Responder Will support ACK_TIMER ?

If not how can a Controller be sure, which device supports ACK_TIMER & which doesn't ?
Then again a Responder might not have QUEUED_MESSAGE in its supported PID's but might still be sending responses with ACK_TIMER ... which shouldn't be allowed in my opinion .

Hope that makes sense

sblair February 25th, 2008 11:28 AM

Yes, that was intentional. There are many different valid implementations and there was not a "one size fits all" approach that worked for everyone.

If you get an ACK_TIMER and the device does not support QUEUED_MESSAGES then you would go back and query the device again after the timer has expired.

It depends on the device as to whether it needs ACK_TIMER or not. There are many implementations where there is no need for ACK_TIMER as the information is immediately available.

A controller shouldn't worry about ACK_TIMER being supported in an end-device unless it gets an ACK_TIMER response.

luiscolo July 7th, 2010 10:40 PM

RDM E1.20 Errata
I'm affraid to make a answered question, but...
is any E1.20 Errata published?
Best regards,

sblair July 7th, 2010 10:44 PM


It is in the final stages of being published and will be available soon. It is currently out for the "final acceptance ballot" vote until the end of this month.

luiscolo November 22nd, 2010 07:29 PM


Originally Posted by sblair (Post 2036)

It is in the final stages of being published and will be available soon. It is currently out for the "final acceptance ballot" vote until the end of this month.

Dear Mr. Scott:
1st of all, thank you for your help across all the forum!
2nd, about the errata, is this available?
I've purchased my E1.20, if available, must I purchase the errata too?
I was browsing the ESTA site and I could not found anything,
thank you again, best regards,

sblair November 22nd, 2010 10:24 PM


Glad to help. We're all here to make the world safe for RDM!

The errata isn't quite published yet. It's a long process. I'm told it hopefully will be available by the end of the year. There will be a free errata document that is a detailed list of all changes that were made for those that have the current version of the standard. I believe to get a full copy of E1.20 that has all the errata implemented in it will require buying the new version.

All times are GMT -6. The time now is 03:07 AM.

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