Remote Device Management (RDM)

Remote Device Management (RDM) is specified in E1.20. It uses a protocol built on DMX 512 that allows bidirectional communication between a system controller and an attached RDM device using the standard DMX bus. This protocol allows configuration, status monitoring, and management of devices. The standard is officially known as "ANSI E1.20, Remote Device Management Over DMX512 Networks".

Half Duplex Operation

RDM systems provide half-duplex support using the pair of data cables used in DMX. The physical layer is updated by enabling half-duplex communication and requiring a bias network. The pattern of communication using half duplex is:

In RDM, one device is made the master which controls who can transmit to the bus (usually the “DMX USB/Ethernet Interface”).
The master initiates a communications request to a "slave” by addressing the unit and turning-off its own transmit hardware. The master then listens for a response (receive mode).
The slave receiver recognises a control slot, and if addressed it enables its own transmitter. Once data has been sent, slave reverts back to receive mode.
The master then resumes control after reception from slave (or after a timeout).

Start Code

All RDM packets use the Alternate Start Code assigned for use with RDM. Devices that do not support RDM are required to ignore these frames completely.

RDM Unique ID (UID)

RDM provides a way to address individual devices irrespective of their configured DMX base address. This even works when multiple devices have been assigned the same DMX base address.

A manufacturer of a RDM equipment assigns a unique 6 byte RDM ID to each piece of equipment when manufactured. The 6 byte format means there are 281,474,976,710,656 unique UID values available to be assigned. Some of these are reserved for special purposes.

The UID is formatted in the following way:

2B Manufacturer ID + 4B Device ID

The recommended method for representing the UID in text is in hexadecimal format with a colon separating the Manufacturer ID and the Device ID. An example is : mmmm:dddddddd, where mmmm is the Manufacturer ID in hexadecimal and dddddddd is the Device ID in hexadecimal. This forms a "flat" address space. That is, there is no required organisation for the 32-bit Device IDs as long as each equipment is uniquely identified.

Each receiver only responds to messages sent with one of the broadcast addresses or with its own UID, it disregards all other messages.

RDM Broadcast IDs

RDM supports broadcast communication. This uses the RDM broadcast UID, 0x FFFF: FFFF FFFF.

This allows the controller to send an instruction to all devices, or all devices from one manufacturer, 0x mmmm: FFFF FFFF (with a common UID prefix, combining the 2B Manufacturer ID and all one's device ID). Since more than one device may receive a broadcast message, no responses are permitted, except during the Discovery process

RDM Discovery

Discovery is the function that allows a controller to determine the devices attached to the bus using the manufacturer-assigned UID.

Collisions are expected as part of the discovery process. Once all responders have been discovered, the system operates in a collision-free environment by utilizing the UID‘s for addressing messages. While search methods other than a binary search are allowed by the RDM standard, this is the preferred method.

Devices respond to discovery messages (DISC_UNIQUE_BRANCH) unless they have been muted for discovery. The normal discovery process consists of un-muting all devices, and as they are individually discovered, muting each device. The devices must be muted as they are discovered so that they will not respond and create response collisions as the controller attempts to discover other devices.

Discovery Process

Discovery uses a single bit "Discovery Mute Flag" implemented at each receiver. The flag is reset when the device is powered-on or restarted. It can then be set or cleared by the controller. When the controller has set this flag, the device does not respond to any received discovery messages.

A full discovery starts by clearing the Discovery Mute flags in all devices on the DMX/RDM bus. This is done by sending a DISC_UN_MUTE message with the Destination UID set to x FFFF: FFFF FFFF.

The controller clears its own list of previously discovered devices. The controller then sends a broadcast discovery command (RDM DISC_UNIQUE_BRANCH message) to all devices and awaiting a response. This sets the message parameter data to the current UID range ( the branch of the binary search tree, starting with the entire tree and updating this as responses are received).

Any device with a UID greater than or equal to the Lower Bound and less than or equal to the Upper Bound that was transmitted in the Parameter Data area will provide a response message. Numerous collisions are expected. Any response indicates devices within that UID range. No response indicates there are no devices within that branch.

The controller therefore has three possible from sending a discovery message:

If there is no response the controller has discovered there are no nodes with a UID in the current range. It may then decide to examine a different range. When all ranges are explored it knows it has found all the devices.
If there is only one response the controller has discovered that there is only one node with a UID in the current range. The message will have a valid checksum. This node is uniquely identified by reading the UID value from the response message and notes this in a list of devices. It will then attempt to mute the responding device (using a DISC_MUTE message). After a successful mute, the device is no longer allowed to respond to discovery messages, and the controller can then continue to search for other devices (first by re-checking the branch, and then by extending the search).
If there are multiple responders the controller will observe a "collision", but will be unable to identify the responder UIDs. The controller will then refine its search to a smaller range of UIDs using a binary search pattern.

Once all devices has been muted (no responses are received to discovery commands), the discovery process is finished and the controller will now hold a list of all connected devices.

Note: The format of a discovery response message has a number of exceptions to the normal RDM Frame structure to minimize the probability of collisions impacting legacy devices where it colliding responses could otherwise be misinterpreted as a Break followed by a 0x00 Start Code and data.

Note 2: If there is just one response to a discovery message then the controller has found a responder. The responder's UID is recorded (added to a list kept at the controller) and the device is then muted (i.e. has the mute flag set preventing it from responding to further discovery messages). Before muting, the controller may decide to collect data from the device to discover attributes and the profile that is being used. Once the controller has finished working with the responder, it continues the discovery process by extending the addressed range to find any other RDM-enabled devices.

Discovering new devices

The controller needs to periodically perform additional searches to detect changes in the set of devices connected to the bus. Some things it needs to detect include:

Someone may have plugged a new device into the network. It needs to do discover any new devices that were added to the bus after the last discovery process was completed.
Someone may have unplugged a previously connected device from the network. It needs to verify that all the already discovered devices are still connected.
A device may have failed to respond to the discovery because of some other reason. This can be found by restarting the discovery process with all known devices muted.

The controller can detect any new devices that are added to the network by leaving discovered devices muted and sending a DISC_UNIQUE_BRANCH message covering the entire UID range. Only new devices (devices that are not muted) will respond.

Controllers may also wish to periodically un-mute all devices then send individual mute commands to the devices it believes are connected. Following this with a DISC_UNIQUE_BRANCH message covering the entire UID range will detect devices that have been added. This technique will discover devices that were muted (for whatever reason) but that the controller did not know were connected.

Unicast communication

General communication with a specific device occurs using a request-response pattern. The controller sends the request to the device, addressing it by the device's UID.

When a request has been sent, the controller relinquishes control of the DMX bus for a period of time, so that the device can transmit its response. Unicast communication is the only way in which data can be retrieved from a fixture (other than its UID which can be obtained using the discovery mechanism mentioned above).

If the device does not respond within a given period of time, the controller can assume communication has failed, and may retry.

The Get Device Info (DEVICE_INFO) parameter message is used to retrieve a variety of information about the device that is normally required by a controller. This is needed to identify what type of device (e.g. model number, software version, "personality", base address, etc) is to be associated with a specific UID. Subsequent commands sent to the UID will use this stored information to know what parameters are supported and how to interpret the values that have been placed in each parameter.

Other parameters at the device may be retrieved by the controller using "get" messages, or may be changed using "set" messages. E.20 defines a complete set of standard messages and parameters.

Note: Many devices such as moving lights can have different DMX512 "Personalities", i.e. different ways they are configured to operate. Many RDM parameters may be affected by changing personality. Every make and model of intelligent lighting has its control channels allocated in a special order. So, the dimmer may be controlled by the base address + channel #1, pan (horizontal) movement by channel #2, colour by channel # 5 etc. This is specified down by the manufacturer of the fixture and is mapped out and presented in a table format, usually in the User Manual. This mapping of control channels is called the “Fixture Personality” and, using a Fixture Personality file, an intelligent lighting console connects the lighting operator to the correct Attribute and displays the appropriate information.

RDMnet

It is has been possible for some time to send DMX frames over Ethernet (e.g., to a merger). There is now work to enable RDM over Ethernet. The specification is being called E1.33. This will allow an RDM message to be sent to an RDM-enabled merger/splitter by placing it in an Ethernet frame, enabling RDM to scale to large networks with multiple Universes.

It provides standard RDM functions, such as device discovery and configuration of RDM Gateways.