E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM Interpretation Questions

RDM Interpretation Questions Discussion and questions relating to interpreting and understanding the E1.20 RDM Standard.

Reply
 
Thread Tools Search this Thread Display Modes
Old July 31st, 2006   #1
Brian Sidebotham
Junior Member
 
Join Date: Jul 2006
Posts: 4
Default SC_SUB_MESSAGE values

I have recently discovered that I need to support draft V1 of the protocol in one of our products because there are systems out there with it, and the packet structure is different.

I thought SC_SUB_MESSAGE would be the way of differentiating between different draft standards, however The following values apply:

Draft1 - SC_SUB_MESSAGE = 0x01
Draft2 - SC_SUB_MESSAGE = 0x02
Draft3 - SC_SUB_MESSAGE = 0x01

So draft 1 and 3 have the same sub start code values... is/was this considered a mistake or is this how everyone's RDM packets are being structured?

I don't have the actual release yet, it should be with us today so I can't comment on that yet.
Brian Sidebotham is offline   Reply With Quote
Old July 31st, 2006   #2
sondericker
Banned
 
Join Date: Jun 2006
Posts: 11
Default

I for one am not supporting the draft versions of the protocol in anything I am working on. I can't imagine a compelling reason to do so.
sondericker is offline   Reply With Quote
Old July 31st, 2006   #3
Brian Sidebotham
Junior Member
 
Join Date: Jul 2006
Posts: 4
Default

There are products on the open market today which are only draft compatible. People expect (rightly so) devices to be plugged together and to work, not for both products to be RDM compatible and yet still not work together. This seems like a good enough reason for our product to work in any system available today.
Brian Sidebotham is offline   Reply With Quote
Old July 31st, 2006   #4
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

There was never any intent to differentiate between draft versions or maintain compatability between draft versions. In fact, there were some specific efforts to prevent the proliferation of draft versions, such as not defining a formal RDM Start Code until after the protocol was completed.

The draft versions are completely unsupported and is advised against implementing them as it will likely create opportunity for numerous bugs, rather than just cleanly supporting the Released version. The Message Structure went through numerous changes through the draft versions, as did: Discovery, Messages themselves, timings, message defines, etc..

Seriously, the Released version is available now and the presence of the draft versions in the market place is going to be a fleeting event. Draft versions are not something that should be enshrined at this point.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old August 1st, 2006   #5
Brian Sidebotham
Junior Member
 
Join Date: Jul 2006
Posts: 4
Default

Hi All,

This product is only listening to the network, it is not a controller, and it does not generate its own RDM packets. It is a transparent inline device.

If I were writing a lighting board or some other controller, then I expect to only support the generation of release standard packets. However, as we are only listening to the data I don't see any reason why we shouldn't listen out for all the types of RDM that exist at the moment.

Best Regards,

Brian Sidebotham.
Brian Sidebotham is offline   Reply With Quote
Old August 7th, 2006   #6
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default Restrict support to the Final Standard

I would encourage you to restrict support to the final standard. Thinking that you might be OK with the various drafts discourages your clients from doing the right thing, which is ensuring that all their responders are upgraded to be compatible with the RELEASED standard. Claiming that you support all the drafts (including ones you will NEVER have seen - unless you were on the task group) is likely to end in tears. We have numerous items that respond to one of the drafts - they just happen to work with a different draft to that used by others such as Artistic Licence, and thus will never be compatible, despite any cleverness of your in-line device. The ONLY sensible way forward and ensure any chance of inter-operability would be to upgrade to versions compatible with the published ANSI standard.
prwatE120 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 11:40 AM.


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