RDM: how a console finds fixtures where brute force is impossible

A moving head hangs in the grid. Its address is wrong. It is twelve metres up, the ladder is at the other end of the hall, and the run-through is in forty minutes.

RDM was invented for exactly this situation.

Bidirectional DMX on a one-way bus

RDM (standard ANSI E1.20) adds a return channel to DMX512 without changing the cable or the connectors. The trick is that the line stays half-duplex: exactly one party talks at a time.

The controller sends a packet marked as RDM (a different start code), addresses it to a specific fixture and then shuts up, releasing the bus. The fixture answers into that window — a few milliseconds all told — after which the controller returns to normal DMX transmission.

Two practical consequences follow immediately.

First, DMX is paused during the exchange. Otherwise the next frame would slice through the window in which the fixture is answering. On stage this is invisible — fixtures hold their last received value and are not going anywhere — but polling the line in the middle of a number is still a bad idea.

Second, RDM is far more demanding of line quality than one-way DMX. Broadcasting forgives reflections: you send the same thing forty times a second, and a corrupted frame simply disappears. A fixture's reply arrives once, and if a reflection from an unterminated line end ate it, that fixture does not exist as far as you are concerned. A terminator at the end of the line is mandatory for RDM, not "recommended, as they taught at college".

The search problem: 281 trillion addresses

Every RDM fixture has a UID — a 48-bit identifier: 16 bits of manufacturer number and 32 bits of device number. That is 2⁴⁸ ≈ 281 trillion combinations.

The controller does not know in advance what is hanging on the line. It cannot ask "everyone identify yourselves": the fixtures would answer simultaneously, their signals would add up on the shared pair, and the controller would receive garbage.

Brute-forcing 281 trillion addresses is, obviously, also out.

Binary search over collisions

The standard solves this elegantly. The controller asks not "who are you" but "is anybody in the UID range from A to B", and listens to what happens.

There are exactly three outcomes:

• Silence. Nobody in that range — strike it out entirely.
• A clean answer. Exactly one fixture replied, we hear it and record it. Then we send it MUTE: "be quiet, you've been found". It stops answering broadcast questions and no longer interferes.
• A collision. Several replied and their signals merged into mush. The value can't be read, but the very fact that something happened is information. Split the range in half and ask about each half separately.

Classic binary search: every step halves the space, and any given fixture is reached in at most 48 steps instead of trillions. Mute what you found, repeat, until the whole line goes quiet.

The subtlety the whole construction rests on: silence and collision must be distinguishable. If an implementation confuses "nobody there" with "three answered at once", the search will either miss half the fixtures or loop forever. We have dedicated tests for this on a virtual line where collisions are faked deliberately — because on real hardware that bug surfaces at the least convenient moment.

The reply to a broadcast question is, incidentally, deliberately redundant: bytes travel in pairs with inversion plus a checksum, so the receiver can tell a corrupted answer from someone else's. That is the standard fighting to make a collision honestly look like a collision.

Why it doesn't work on a cheap dongle

Here comes the unpleasant part about interfaces that cost twenty euros.

USB-DMX comes in two breeds. Open DMX is literally a USB-UART (FT232, CH340, CP210x chips) plus an RS-485 transceiver. The frame timing, BREAK included, is generated by the computer itself, toggling the line through the driver. There is no receiver at all: the device can only transmit.

Enttec Pro and compatibles are a microcontroller that accepts "here is a frame, send it" from the computer and forms the timing itself. And it can listen to the line, passing what it receives back over USB.

RDM requires receiving answers in a window a few milliseconds long. On Open DMX there is nothing to receive with — not "it works badly", but physically nothing. No firmware, no driver and no software version will change that.

So Flux Lights in Open DMX mode says plainly that RDM is unavailable, rather than pretending to poll the line.

If RDM matters to you, look at this when buying. The price difference pays for itself on the first get-in where you didn't have to climb the truss.

The network route: the node did it for you

There is a second route where none of the above concerns you.

An Art-Net node can do RDM on its own outputs. It has already walked its line, already run the binary search and holds a ready table of fixtures. The console just has to ask for it.

No binary search is needed, and there is no reason to pause DMX — the node owns the line, not us. One subtlety: before requesting the table you have to ask for a refresh, otherwise you get the previous one, where fixtures that have since been unplugged are still listed as alive.

So if you have a network rig, RDM comes almost for free — the only question is whether your node supports it.

What to do with it in practice

Discovery gives you model, manufacturer, channel footprint and current address. After that:

Addressing from the console. The scenario from the top of this article.

Identify — the fixture starts flashing. Irreplaceable when the patch holds twelve identical heads and you need to know which one is number three.

Personality — the fixture's mode. The same head can occupy 14 channels in basic mode and 32 in extended; that is switched remotely too.

Sensors — temperature, voltage, hours of operation. Read on demand rather than by constant polling: keeping the line busy for a thermometer is a questionable trade. But walking the temperatures before handover and finding the head running ten degrees hotter than its neighbours is a good habit.