Flickering or Erratic Behavior and RDM
The information in this post is provided to assist in troubleshooting. Perform work at your own risk. ENSURE ANY POWER FROM DEVICES HAS BEEN DISCONNECTED BEFORE SERVICING ANY EQUIPMENT. If you do not feel comfortable performing the work, please contact us or your local service center. Be aware that ETC and its Affiliates are not responsible for any damage or injury caused by service of our products by anyone other than us or our authorized service providers, and such damage is excluded from the product’s warranty.
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.