E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM Interpretation Questions (http://www.rdmprotocol.org/forums/forumdisplay.php?f=5)
-   -   SC_SUB_MESSAGE values (http://www.rdmprotocol.org/forums/showthread.php?t=32)

Brian Sidebotham July 31st, 2006 08:18 AM

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.

sondericker July 31st, 2006 08:54 AM

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.

Brian Sidebotham July 31st, 2006 09:03 AM

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.

sblair July 31st, 2006 08:55 PM

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.

Brian Sidebotham August 1st, 2006 02:40 AM

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.

prwatE120 August 7th, 2006 05:37 PM

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.


All times are GMT -6. The time now is 11:21 PM.

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