Last week we discussed the modern technology that allows theaters to be as big as they are by allowing 512 channels over ethernet, sACN. The biggest flaw of sACN is that the protocol just carries DMX data and will need some sort of converter or gateway to extract the DMX data from the packets and send it to the right place. Devices like this are expensive and might make SsCN not worth it for some people. This week we’ll cover RDM, a protocol that doesn’t need a gateway or any converter and is capable of operating over a standard DMX cable in parallel with standard DMX data. RDM is not meant for controlling lights for a show but is meant to give designers the ability to monitor lights during a show. RDM is mainly used to Identify connected devices, configuring these devices, sending data to those device, and finding problems with those devices. While DMX can only send data from the controller to the light, RDM allows for lights and other RDM capable devices to send status data back. This protocol was first developed by the Entertainment Services and Technology Association (ESTA) and the technical name for RDM is ANSI E1.20. RDM data packets are sent in between DMX data packets and is meant to not disrupt legacy devices that are no RDM compatible. While DMX was originally designed to have two of the pins on the connector reserved for the future, some manufacturers started using those pins for proprietary purposes. Because of this, RDM must work over pins 2 and 3 (the same as DMX) as to not interfere with these proprietary communications. RDM is intended to be sent between DMX packets but because nothing is perfect, there are concerns of data interference between the two protocols. The RDM standard intends to fix this by only having one device transmit at once (except for specific pre-show setup times). This minimizes any chance of collision. This specific pre show time is called discovery where the RDM controller sends out the command and all RDM devices send their data back at the same time and using search algorithms it will resend discovery commands with refined filters based on device IDs and mute devices it’s already found. If the controller needs to send messages quickly, it uses broadcast communication. Because any device can receive these messages, the only messages sent using broadcast is the discovery messages. For every other message send from the controller, Unicast communication is used on a request response pattern. The controller sends the request to the ID of the device and waits for the device to respond. RDM is mainly used to Identify connected devices, sending data to those device, finding problems with those devices, and configuring these devices. RDM is not very compatible with sACN because RDM assumes that the DMX is data is being sent through one universe over DMX cabling where sACN uses multiple channels over ethernet. This makes it impossible for an RDM controller that uses DMX to receive messages sent from a RDM controller on ethernet.
The RDM specifications that were used to help write this piece can be requested at:
http://tsp.esta.org/tsp/documents/published_docs.php
And a forum all about RDM can be found here (where the title draws homage):