E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDMnet (BSR E1.33) Draft Standard General Discussion (http://www.rdmprotocol.org/forums/forumdisplay.php?f=20)
-   -   Next Question on Discovery (http://www.rdmprotocol.org/forums/showthread.php?t=1111)

owaits August 30th, 2011 12:08 PM

Next Question on Discovery
I have read through the draft many times to answer this question as well as the RDM standard but still have no answer to this question. I am sure I must be missing something.

How do you discover RDM devices that are on the DMX network and connected to a gateway that supports E1.33?

I am clear on how to use SLP to discover devices on the sACN network and I think I also know how to send messages to RDM devices when I know their ID but how do I get a list of IDs for devices connected to the ports of the gateway?

I should also point out that I purposfully have not read section 7 of the RDM standard on Discovery because it says to ignore this in section 1.3 of E1.33.

sblair August 30th, 2011 12:15 PM

You can force an initiation of discovery to occur for the ports on the gateway by using the INITIATE_DISCOVERY PID in this document. The Gateways are intended to all operate as RDM Proxy devices from E1.20. So following that, you can use the E1.20 Proxy Management messages to get a list of the UID's that the gateway has discovered.

owaits August 30th, 2011 12:25 PM

I had wondered whether it had something to do with proxies but then I read this line in the RDM standard which threw me.


All devices represented by a Proxy are discovered using the standard methods of Discovery described in Section 7.
Section 7 refers to discovery which is not part of E1.33.

The RDM spec also seems to say that only managed proxies support


A proxy itself may be discoverable as an RDM device, and may optionally support the Proxy
Management commands which may be used by a controller to reduce the complexity of
Discovery in a large system. A proxy with such capabilities is known as a managed proxy.
Thank you for your response it makes it much clearer now. I will think of something to write in my review form on this.

ericthegeek August 30th, 2011 12:29 PM

RDM Packets with the Discovery Command Class are never sent over the E1.33 network.

Each E1.33 device that acts as a gateway to a RS485 DMX/RDM link is responsible for performing discovery on the RS485 links that are plugged into the gateway. The gateway discovers the responders, mutes them, and tracks as devices are added and removed.

The E1.33 controller then uses the GET PROXIED_DEVICE_COUNT and GET PROXIED_DEVICES PIDs from E1.20 to get the list of devices that are attached to each gateway.

The "BINDING_CONTROL_FIELDS" PID was added to E1.33 as a way to get the information that's normally contained in the Mute Response (bootloader flag, Binding UID, etc).

owaits August 30th, 2011 12:36 PM

Thanks, makes sense now.

Another related question is whether you should send the start discovery command and then wait a period of time before requesting the device list or poll the device for queued messages. If you poll then should you poll continuously (what interval?) or just for some period after starting the discovery.

ericthegeek August 30th, 2011 01:11 PM

In E1.20, the details of how and when to do discovery are left up to the implementer. Some RDM controllers do constant ongoing discovery, others do discovery only at startup or when requested by the user.

The same applies to E1.33: It's implementation specific.

I suspect many controllers will send the INITIATE_DISCOVERY PID when they startup, then poll the "Discovery State" field to know when it's complete. But this is not required.

Polling intervals are also implementation specific. Some will get a device list once and use it forever, others will poll every few seconds. It's a matter of what best fits the target market.

All times are GMT -6. The time now is 10:32 PM.

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