RDMBenchTroubleshooting
What a DMX or RDM symptom usually means, with the section of ANSI E1.68 or the DMX512 Guide each cause comes from, and what an RDM controller on the bench can and cannot see of it.
Two documents say what a DMX512 symptom usually means. ANSI E1.68-2024, Recommended Practice for Compliance and Interoperability in DMX512-A Systems, and the PLASA/USITT Recommended Practice for DMX512 (2nd edition, 2008, “the Guide” below) were written by the people who wrote the protocol, and both are free from their publishers. Neither is protocol. Both are fault finding, written down.
This page is what they say, in my words, with the section or page each cause comes from. The last column is the part that matters at the bench: what an RDM controller can actually see of each cause. For most faults on the cable, the answer is nothing, or only the fixture’s own count of bad frames.
Start with the line
Both documents open the same way: nearly every DMX512 fault is the cable, the termination or the grounding (Guide p. 8 and the fault finding checklist on p. 67; E1.68 §4.3, §5.1). A fixture lands on the bench because somebody thought it was the fixture. Half the job is saying when the evidence points back at the line.
RDMBench does that in two places. A fixture that counts bad frames on
its input gets a line in the report that blames the cable before the
fixture (comms-errors for RDM frames, comms-nsc-errors for DMX
packets; see Corrupt frames: check the line).
And when a unit comes in for a complaint and nothing it reports explains
it, the report says so and names what RDM cannot see (see
Read a fixture’s report).
Flicker
| Symptom | Usual cause | Source | What RDM can see |
|---|---|---|---|
| Flicker that tracks building load (air handling, lifts) | A ground loop: a receiver earthed at a different potential from the transmitter | E1.68 §5.2.8 (note), §5.5.1; Guide p. 34, p. 64 | Nothing directly. The fixture’s error counts, if the noise corrupts frames. |
| Flicker that started when an RDM controller was added to a rig that ran DMX for years | A receiver that ignores the START code and takes RDM frames as levels | E1.68 §5.2.11.2, §5.3.1; Guide p. 26 | Nothing on the flickering unit, which by definition is not answering RDM. Look at what else is on that line. |
| Flicker after the same change | Termination missing at the controller end (RDM needs it at both ends), or doubled | E1.68 §5.2.6; Guide p. 23, p. 104 | The error counts on the units that do answer. |
| Flicker that comes and goes, but mostly works | A cut data− (pin 2) or common (pin 1), or the two swapped: DMX can keep half-working through any of them | Guide p. 67; E1.68 §5.2.4 | The error counts. The Guide’s resistance check (p. 65) finds it with a meter. |
| Flicker with every device floating on its own DC supply, even on a short cable | Common-mode difference between the supplies eating the signal | E1.68 §5.2.7 | The error counts only. |
| Flicker downstream of a “Y” lead or passive splitter | Reflections, and possibly double termination | E1.68 §5.2.5, §5.6.1; Guide p. 28 | The error counts only. |
| Flicker only while levels change; static looks are fine | A marginal signal: noise, a long run, many connections, the wrong cable | E1.68 §5.3.7 | The fixture’s count of bad DMX packets. |
| Errors on channels whose levels are not changing | The receiver miscounting slots, inside the fixture. E1.68’s staircase test (100, 75, 50, 25 and 0 % on consecutive channels) shows it | E1.68 §5.3.6 | Nothing. |
| Flicker or total loss with one particular desk | A transmitter sending one stop bit, or a receiver that accepts one | E1.68 §5.3.2 | The fixture’s count of bad DMX packets. |
| A chain of in-line devices degrades the signal faster than expected | Cascaded slew-rate-limited transceivers | E1.68 §5.2.15 | The error counts only. |
Wrong levels, not flicker
| Symptom | Usual cause | Source | What RDM can see |
|---|---|---|---|
| Full at 0 %, fading out as the level rises | The data pair reversed, on a receiver that does not reject it | E1.68 §5.4.4 | Nothing. RDM is usually dead on that cable too. |
| Answers at address 1 when set to 256, or wrong anywhere above 255 | The receiver handles the address in 8 bits | E1.68 §5.3.3 | Only that the address reads back as set. It is firmware: note the software version. |
| The last channels of the fixture do nothing | Address plus footprint runs past 512, so those channels never get data; RDM may misbehave too | E1.68 §5.3.4 | RDMBench reports it, as an error (config-address-overflow). |
| Does nothing at some valid addresses | A non-compliant receiver, or a non-contiguous addressing mode the manual explains | E1.68 §5.3.5 | The address, the personality and what each channel does: enough to rule out the mode. |
| Changed footprint and trampled its neighbor | A personality change moved the footprint onto the next fixture’s addresses | E1.68 §5.3.4 | RDMBench reports it: the personality and footprint, config-footprint-disagrees when the fixture contradicts itself, and overlapping addresses across a line. |
Dead, or doing its own thing
| Symptom | Usual cause | Source | What RDM can see |
|---|---|---|---|
| Lit with nothing plugged in | The startup setting plays a scene or a level. That is allowed, and documented, and looks like a fault | E1.68 §5.4.6, §5.4.8; E1.37-1 §3.5 | RDMBench reports it (no-signal-output, rated OK). |
| Carries on after the desk is unplugged | The signal-loss setting: hold the last look (the usual default), a scene, or a level after a delay. E1.68 points out that holding forever makes a lost signal impossible to tell from a working rig, and prefers a slow fade | E1.68 §5.4.6, §5.4.7, §7.3.1.1; E1.37-1 §3.4 | RDMBench reports it when the setting puts something out. Holding the last look is not listed. |
| Won’t strike, or re-strikes on every data glitch | A signal-loss setting that sleeps the lamp; E1.68 wants arc lamps to ride through at least 60 seconds | E1.68 §5.4.7 | The signal-loss delay and the lamp settings, where the fixture has them. |
| Goes into signal loss with a long but legal BREAK (5 ms, say), and is fine on another desk | The receiver, which must accept a BREAK from 92 µs to about a second. Swapping desks makes the desk look guilty; it is not | E1.68 §5.4.2 | Perhaps the count of bad DMX packets; otherwise only the symptom. |
| Loses sync at high refresh rates (short packets, up to about 836 Hz) | A receiver that fails minimum-timing packets | E1.68 §5.4.1.2 | The count of bad DMX packets. |
| Unstable with packets 1.25 s or more apart | That gap is signal loss; a receiver that does not treat it so is non-compliant | E1.68 §5.4.1.1 | Nothing. |
| Behaves one way at power-up and another after losing signal | Two separate settings, one for each | E1.68 §6.1.2.2, §5.4.8 | RDMBench reports both when either puts something out. |
| Won’t move, ignores the desk, or stays dark | A shipping lock, a settings lock, a reduced power state, preset playback, burn-in, a capped maximum or a held minimum | E1.37-1 and E1.37-5, not these documents | RDMBench reports each one (see A working fixture that looks broken). |
Who is to blame
The Guide (p. 107) gives a transmitter only five ways to be non-compliant: a bit rate other than 250 kbit/s, a BREAK too short, a mark-after-break too short, too few channels at too high a refresh rate, and not enough drive. If the transmitter is right on all five, a failure is the receiver’s or the wiring’s.
E1.68 §7.4 tabulates the timing a transmitter should use to get along with the most receivers: a BREAK of 176 µs (the minimum is 92), a mark-after-break of 20 to 24 µs (the minimum is 12), and packets padded to 512 slots for about 44 Hz (§7.3.2). That is narrower than the standard allows, because older receivers are known to fall over outside it.
At the bench the transmitter is the Enttec widget, whose timing is fixed and known. That leaves the cable and the fixture as the only suspects, which is why a fixture with clean RDM counts and bad DMX counts points at the cable.
When RDM itself is the symptom
Why a rig that ran DMX for ten years does not work with RDM:
| Symptom | Cause | Source |
|---|---|---|
| Discovery finds nothing, or only some units; responses go missing | No termination at the controller end, or double termination, or a responder that cannot drive its reply back up a long run (worst with a cluster of units at the far end) | E1.68 §5.2.6, §5.5.4, §5.6.1; Guide p. 23 |
| Errors on the RDM line | More than one bias network. There must be exactly one per RDM line, normally the controller’s | Guide pp. 23–24; E1.68 §5.2.12 |
| Works for DMX, dead for RDM, behind a splitter, opto or repeater | An in-line device that only passes data one way; some active loop-throughs block replies too | Guide p. 29, p. 107; E1.68 §5.2.13, §5.2.15 |
| An unterminated line that never bothered a desk and a dimmer rack bothers an RDM device added halfway along | The unterminated line | E1.68 §5.2.11.2 |
| The whole line is disrupted, and removing one device fixes it | A responder that boots transmitting, or transmits out of turn | E1.68 §5.4.9 |
| RDM during a show makes changes visibly late | Expected: RDM takes refresh time from DMX. Turn it off for the show if the update rate matters | Guide p. 58 |
RDMBench retries a branch of discovery that stays silent before it believes it is empty, so one reply lost to a marginal line does not lose the fixture. When nothing is found, see When no fixture is found.
What these documents cannot tell you
- Anything about one manufacturer’s fixtures: no status IDs, no private parameters, nothing like “this model does that”. That comes from manuals, from what the fixture says about itself over RDM, and from units on the bench.
- A way to see most cable faults from the RDM side. A meter (Guide pp. 63–65) and an oscilloscope are the tools. The most a report can say is that the fixture’s own counters saw a bad line, and hand you the checklist.