Help

Corrupt frames: check the line

MCP resource
rdmbench://help/line-faults
Version
0.2.0
Runs on
macOS 15 Sequoia or later, Apple silicon or Intel
Needs
An Enttec DMX USB Pro with its DMX/RDM firmware (major version 2)
Price
Free

Nearly every DMX fault is the cable, the termination or the grounding, not the fixture. A unit arrives on the bench because someone thought it was the fixture, so when the report says its input has been receiving corrupt data, look at the line before opening the unit.

The bench cannot see the line itself. What it reads is the fixture’s own count of bad frames on its DMX input, which only fixtures that keep the count can give. The count is the evidence; the checks below are how to find the cause.

Corrupt RDM frames

The fixture has counted RDM frames on its input that arrived short, the wrong length, or with a bad checksum. The count goes back to when it was last cleared, which may have been at the last venue, so on its own it may be history from the rig. Clear it and watch whether it climbs on the bench cable:

  1. Clear the count with rdmbench-cli clear-comms.
  2. Start monitoring the fixture (see Watch a fixture over time).
  3. Flex the cable and each connector in turn (see Wiggle the cable). Each burst of bad frames shows as corrupt frames on DMX input.

If it stays at zero on a short, terminated bench cable, the fault was on the rig, not in the unit.

DMX packets with errors

Some fixtures also count the ordinary DMX packets (the show data) that arrived with framing errors. That data is what the fixture follows, so these errors are what a desk sees as flicker or jumps.

When the fixture’s RDM count is clean but its DMX count is not, the bench’s own frames cross the same input intact. If both counts date from the same line, suspect the output timing of the desk or splitter that fed it before the cable. A desk that sends a long break, or one stop bit, can upset a receiver that a different desk does not. When both counts are up, suspect the cable, the termination or another device on the line first.

One unit or all of them

When the bench has a report of every unit on the line (Fixture → Scan All Fixtures), it compares their counts:

  • One unit counts errors and the rest are clean: the fault is in the run to that unit. Its cable, its connectors, and the terminator past it if it is the last one.
  • Every unit that keeps a count has errors: the fault is common to all of them, upstream. The termination at the controller end, more than one bias network on the line, or the first cable. Not any one fixture.

Checking the line

In order, with the line as it is when the fault shows:

  1. Terminated at both ends. An RDM line needs a terminator at the far end and termination at the controller. A rig that ran DMX for years and fails with RDM usually has the controller end missing, or doubled.
  2. One bias network. Exactly one device on an RDM line biases it, normally the controller. A second one causes errors.
  3. All three conductors made up. A cut data− (pin 2) or common (pin 1), or the two swapped, often works, intermittently. A wiggle test finds it.
  4. Nothing one-way in line. A splitter, opto or repeater that is not RDM-capable passes DMX and blocks RDM.

With the line unpowered and the cable unplugged at the widget, a meter across pins 2 and 3 checks the termination: open, or more than about 400 Ω, is a missing terminator or a broken wire, and less than about 50 Ω is too many terminators or a short.

Corrupt frames in the monitor

During monitoring, corrupt frames on DMX input and DMX512 packets with errors are these same counts rising between rounds, with the time each rose. That time is what ties a fault to a movement, a load or a cable change (see Chase an intermittent fault).