|
RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product. |
|
Thread Tools | Search this Thread | Display Modes |
|
February 20th, 2008 | #1 |
Administrator
|
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 |
February 21st, 2008 | #2 |
Junior Member
Join Date: Jul 2006
Posts: 6
|
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 |
February 25th, 2008 | #3 |
Administrator
|
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.
__________________
Scott M. Blair RDM Protocol Forums Admin |
July 7th, 2010 | #4 |
Junior Member
Join Date: Feb 2010
Posts: 7
|
RDM E1.20 Errata
Hello!
I'm affraid to make a answered question, but... is any E1.20 Errata published? Best regards, Luis |
July 7th, 2010 | #5 |
Administrator
|
Luis,
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.
__________________
Scott M. Blair RDM Protocol Forums Admin |
November 22nd, 2010 | #6 | |
Junior Member
Join Date: Feb 2010
Posts: 7
|
Quote:
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, Luis |
|
November 22nd, 2010 | #7 |
Administrator
|
Luis,
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.
__________________
Scott M. Blair RDM Protocol Forums Admin |
Bookmarks |
|
|