Skip to main content

 

Electronic Theatre Controls Inc

Flickering or Erratic Behavior and RDM

 

Every now and then, a report will come in from a site where fixtures are flickering or twitching on a DMX run from a gateway or console DMX port. After troubleshooting, turning off RDM at the gateway or local console port resolves the issue.

This generally leaves lingering questions (or assumptions) – Was RDM the issue? If not, what’s actually going on?

For devices that do not speak RDM

The problem isn’t often an issue at all with the RDM protocol. Instead, the issue typically rests in a fixture’s response to RDM packets. According to the DMX standard alone, all DMX packets must begin with a null start code (0x00). If packets start with something else, they should be ignored. RDM builds on top of the DMX standard and passes its data on an alternate start code (0xCC). The theory is then that any DMX device that does not speak RDM will simply ignore packets with any alternate start code.

Even without a console connected, a Net3 DMX/RDM gateway will send periodic RDM Discovery packets, looking for RDM capable devices on the line. Devices that are not compliant may attempt to read this information as regular DMX and respond erratically. By disabling RDM at the gateway, we ensure that the gateway does not send any RDM traffic, including discovery.

There are other possibilities that should be considered, however, if the devices do claim to handle RDM.

For devices that claim to speak RDM

RDM has more stringent infrastructure requirements. Just like DMX, RDM requires an end-of-line termination. Also like DMX, RDM does not tolerate ‘Y’s in the cable.

However, RDM requires that the DMX source (in the RDM world, also known as an RDM controller) have termination at the beginning of the line. It also requires that splitters be RDM compatible, as the protocol is now bi-directional. Most DMX splitters were designed for one-way communication.

Other possible causes include timing issues. All devices may be correctly ignoring or processing the relevant packets, but if a device does not operate within the specified timing parameters, it may cause data collisions on the line that can be misinterpreted or even distort the regular DMX data. This is something that would need to be solved in the particular RDM device’s firmware.

In a mixed system

A system that has a mix of DMX-only and RDM devices that shows issues, it is helpful to start narrowing down the problem. Typically, the issues will be something mentioned above. Separating devices into an RDM capable line and a DMX only line often is a great start.

 

  • Was this article helpful?