How a one gets down a wire
A receiver has no clock of its own. It has a voltage that changes, and from that alone it has to work out where each bit begins, what each bit is, and whether any of it survived the journey. Everything on this page follows from that one problem.
The problem
A wire carries voltage, not bits
The obvious scheme is the naive one: high is a one, low is a zero. It is called NRZ, non-return-to-zero, and it fails for a reason that is easy to miss — send a long run of the same value and nothing on the wire changes for a long time. The receiver, which is timing itself from the transitions it sees, has nothing to time from and slowly drifts out of step. By the time the run ends it has miscounted.
So a line code has two jobs at once: carry the data, and guarantee enough transitions that a receiver can keep its clock locked. Every scheme below is a different bargain about how much bandwidth to spend on that guarantee.
Before any of that
One wire at a time beats many wires at once, past a certain speed
A wire carries voltage, and the last section asked how a one gets onto it. There is a prior question: how many wires should there be at all.
A parallel bus sends many bits at once, one per wire, and relies on every wire arriving in step. GPIB, SCSI, PATA, the old Centronics printer port, even VGA’s separate red, green, blue and sync lines are parallel in spirit. It is simple while the clock is slow. Push the clock up and the wires stop matching each other: propagation delays differ, so bits that left together arrive apart. That is skew, and crosstalk between neighbouring conductors gets worse as you add more of them, not better.
A serial link sends one bit at a time down far fewer conductors, usually a single differential pair per lane. There is no wire-to-wire alignment to keep because there is only one wire, so the entire skew problem disappears and the clock can go enormously higher. That is the trade, and it is why almost everything fast is serial: USB, SATA, PCIe, Ethernet, DMX512 on RS-485, and the TMDS lanes inside HDMI and DisplayPort. Several fast serial lanes beat one wide slow parallel bus once you are past a few tens of megahertz.
All four should land together. The orange wire is running the same distance slower — that gap between wires is skew, and it only gets worse as you push the clock higher or add more wires.
No wire-to-wire alignment to keep — there's only one lane, so nothing can drift relative to anything else. That's the trade: fewer conductors, much higher clock, no skew budget to manage.
The famous one
Why Manchester puts a transition in every bit
Manchester coding takes the guarantee to its logical conclusion: every single bit has a transition in the middle of it. A one is a change one way, a zero is a change the other way. Which direction means which depends on the convention and both are in use, which has confused people since the 1970s.
The receiver now cannot lose the clock, because there is an edge in the middle of every bit whatever the data does. That is a very strong guarantee, and it is bought with bandwidth: the signal changes twice as often as the data rate, so you need twice the bandwidth for the same throughput.
It was the coding of original 10 Mbit/s Ethernet, and it lives on wherever a receiver has to lock on quickly with no separate clock line and bandwidth is cheap — RFID and contactless cards, some infrared remotes, DALI lighting control, and plenty of short-range radio links.
The alternatives spend less. 4B/5B and 8b/10b map each group of data bits to a slightly longer group chosen so that long runs are impossible — 25% and 20% overhead respectively, rather than 100%. 64b/66b, used at 10 Gbit/s and above, gets that overhead down to about 3% by scrambling instead of substituting.
The one on a show
DMX has no line code at all — it has a break
DMX is asynchronous serial over RS-485, and it solves the clock problem in the oldest way there is: both ends agree in advance on the bit rate — 250 kbit/s — and every byte carries its own start and stop bits so the receiver can re-synchronise at the start of each one.
What marks the beginning of a whole packet is a deliberate violation. The line is held low for far longer than any legal byte could be — the break — followed by a mark after break, and then a start code. Nothing in normal data can look like that, which is exactly why it works as a frame marker.
This is worth knowing because the failures follow from it directly. A break that is too short and a receiver misses the start of the packet. A source that sends packets slightly too fast and a fixture with a slow input drops frames. And the whole scheme has no error checking whatsoever: a corrupted DMX value is simply used. That is the deal — 44 packets a second, no verification, and the next packet along fixes it. See DMX on the wire for what happens electrically.
Verification
Four bargains between cost and catching
Once bits arrive, something has to decide whether to believe them. There are four broad approaches and they are not interchangeable.
| Scheme | What it does | What it costs and catches |
|---|---|---|
| Parity | One extra bit making the number of ones odd or even. | One bit of overhead. Catches any odd number of flipped bits and misses every even number. Cheap, weak, and still used inside serial links. |
| Checksum | Add up the data and send the total. Recompute it at the far end and compare. | Cheap and easy, and blind to errors that cancel out — swap two bytes and the sum is identical. This is what UDP and IP headers use. |
| CRC | Treat the data as a big polynomial, divide by a fixed one, send the remainder. | A little more arithmetic and vastly stronger: it catches all burst errors up to the length of the CRC and nearly everything else. This is what Ethernet puts on every frame. |
| FEC | Send enough structured redundancy that the receiver can rebuild the missing parts. | Real bandwidth — but it repairs rather than reports. Reed–Solomon is the classic; it is why a QR code with a hole in it still scans, and why satellite links work at all. |
Layer four
TCP and UDP, and why show protocols choose UDP
IP gets a packet to an address. Layer 4 decides what happens when that goes wrong, and there are essentially two answers.
TCP establishes a connection, numbers every byte, acknowledges what arrived, and retransmits what did not. Data comes out the far end complete and in order, guaranteed. The cost is time: a lost packet stalls everything behind it until the retransmission arrives, because TCP will not hand over byte 400 before byte 399. That is head-of-line blocking, and it is the right trade for a file and the wrong one for a stage.
UDP sends a datagram and forgets it. No connection, no acknowledgement, no retransmission, no ordering. Packets can arrive late, out of order, twice, or never, and the application deals with it.
That sounds worse and for live control it is much better, for one reason: a retransmitted lighting level is worthless. By the time it arrives, two newer values have already been sent. There is no point spending latency to recover data that is already obsolete. So sACN, Art-Net, Dante's audio, PTP, OSC and almost everything else in this index run over UDP and simply send the next value.
TCP still shows up where completeness matters more than latency: configuration, file transfer, RDM-over-IP style management, web interfaces, and anything you would rather have arrive late than wrong.
- UDP does not mean unreliable in practice. On a properly designed switched network with headroom, loss is close to zero. UDP means the protocol does not promise, which is a different claim.
- Multicast is UDP only. There is no such thing as multicast TCP, because there is nobody to acknowledge. That is why IGMP snooping matters so much.
- A TCP control channel on a show network is fine and can still bite. A management session retransmitting hard can consume the same bandwidth your streams need.
- Ethernet already CRCs every frame. A corrupted frame is dropped by the switch before your protocol ever sees it — which means your protocol's losses are usually congestion, not corruption.
Standing back
The same three questions, at every layer
Whether you are looking at a voltage on a wire, a byte in a serial frame, or a datagram on a network, the questions are identical.
How does the receiver know where this begins? A transition, a start bit, a break, a header. How does it know what it says? A voltage level, a code group, a field layout. How does it know it is true? A parity bit, a checksum, a CRC, or nothing at all — and "nothing at all" is a legitimate answer when the next value is 23 milliseconds away.
Every protocol in the index is a set of answers to those three. Reading it that way makes an unfamiliar one much less unfamiliar.
Wireshark will show you the layer-4 headers, the checksums and the retransmissions on any of the protocols above, and it is free. Point it at a show network with sACN running and the theory stops being theory.
2 questions on the mechanism rather than the trivia. Nothing is scored and you can answer again — the explanation under a wrong answer is the point of it.
-
1A live video stream loses a packet. Why is error correction more useful than error detection here?
-
Right. Detection tells you something is wrong, and the usual remedy is retransmission. On a live stream the retransmitted packet arrives after the moment it was needed, so the data has to carry its own repair.
-
It finds them perfectly well. The problem is what you can do about it in the time available.
-
It is generally slower and more expensive. It is chosen despite that.
-
The opposite — correction sends redundant data and costs more.
-
-
2DMX512 has no line code. How does a receiver know where a packet starts?
-
DMX is two data conductors and a shield. There is no separate clock.
-
That would drift, and a receiver joining mid-stream would never sync.
-
The start code exists but comes after the framing. Something has to mark the frame boundary first.
-
Right. The break is longer than any legal character, so it cannot be mistaken for data. That is the framing, and it is why DMX needs no line code.
-
Answers are kept in this browser on this device. Nothing is sent anywhere.
- What is Manchester coding?
- Checksum or CRC?
- Why UDP and not TCP?
Where to go next
These pages are a chain rather than a library — the next one along usually answers the question this one raised.
Everything on this page, in the index
Each of these has its own entry with sources, ports, gotchas and an open gap where a field is missing.