E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM General Implementation Discussion

RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product.

Reply
 
Thread Tools Search this Thread Display Modes
Old February 20th, 2008   #1
sblair
Administrator
 
Join Date: Feb 2006
Posts: 417
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
Old February 21st, 2008   #2
endoftheworld
Junior Member
 
Join Date: Jul 2006
Posts: 6
Default 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
endoftheworld is offline   Reply With Quote
Old February 25th, 2008   #3
sblair
Administrator
 
Join Date: Feb 2006
Posts: 417
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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
sblair is offline   Reply With Quote
Old July 7th, 2010   #4
luiscolo
Junior Member
 
Join Date: Feb 2010
Posts: 7
Default RDM E1.20 Errata

Hello!
I'm affraid to make a answered question, but...
is any E1.20 Errata published?
Best regards,
Luis
luiscolo is offline   Reply With Quote
Old July 7th, 2010   #5
sblair
Administrator
 
Join Date: Feb 2006
Posts: 417
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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
sblair is offline   Reply With Quote
Old November 22nd, 2010   #6
luiscolo
Junior Member
 
Join Date: Feb 2010
Posts: 7
Default

Quote:
Originally Posted by sblair View Post
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.
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,
Luis
luiscolo is offline   Reply With Quote
Old November 22nd, 2010   #7
sblair
Administrator
 
Join Date: Feb 2006
Posts: 417
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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
sblair is offline   Reply With Quote
Reply

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


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


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