View Single Post
Old February 20th, 2008   #1
sblair
Administrator
 
Join Date: Feb 2006
Posts: 430
Send a message via AIM to sblair Send a message via MSN to sblair
Exclamation RDM E1.20 Draft Errata

All,

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.

Thanks!
Scott


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.

http://www.rdmprotocol.org/forums/showthread.php?t=37


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

http://www.rdmprotocol.org/forums/showthread.php?t=66

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.

http://www.rdmprotocol.org/forums/showthread.php?t=65


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 6.2.7.1states 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.”

http://www.rdmprotocol.org/forums/showthread.php?t=75


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.”

http://www.rdmprotocol.org/forums/showthread.php?t=26


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.

http://www.rdmprotocol.org/forums/showthread.php?t=64


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.”

http://www.rdmprotocol.org/forums/showthread.php?t=182


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.”

http://www.rdmprotocol.org/forums/showthread.php?t=67


Appendix B

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

http://www.rdmprotocol.org/forums/showthread.php?t=39


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”



/END of ERRATA/
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote