# 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](/help/monitor/)).
3. Flex the cable and each connector in turn (see
   [Wiggle the cable](/help/intermittent/#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](/help/intermittent/)).