Manchester-Code

Digitale Leitungscodierung, bei der die Information in einem garantierten Flankenwechsel zur Bitzellenmitte steckt — auf Kosten der doppelten Bandbreite gegenüber NRZ.

Der Manchester-Code ist eine Leitungscodierung (Line Code): Er verändert nicht die Nutzdaten selbst, sondern nur deren physikalische Repräsentation auf der Übertragungsstrecke. Benannt ist er nach der University of Manchester, wo das Verfahren in den 1940er-Jahren für die Speicherung auf Trommelspeichern früher Computer (u. a. Manchester Mark 1) entwickelt wurde. Der entscheidende Unterschied zu einfachen Codes wie NRZ (Non-Return-to-Zero): Bei NRZ steht der Pegel für den Bitwert (High = 1, Low = 0), beim Manchester-Code steht stattdessen die Richtung des Flankenwechsels in der Mitte jeder Bitzelle für den Bitwert — der absolute Pegel allein ist bedeutungslos.

Manchester-Codierung

1. Kodierregel

Jede Bitzelle der Dauer $T$ wird in zwei Hälften zu je $T/2$ geteilt. Nach der gebräuchlichen G. E.-Thomas-Konvention:

Logische 0: erste Hälfte Low, zweite Hälfte High → Flanke Low → High in Zellenmitte
Logische 1: erste Hälfte High, zweite Hälfte Low → Flanke High → Low in Zellenmitte

Zwei gespiegelte Konventionen sind in Gebrauch: Die G. E.-Thomas-Konvention (oben) und die in IEEE 802.3 benutzte Variante ordnen die Flankenrichtungen genau umgekehrt den Bitwerten zu. Beide Varianten teilen dieselbe Kerneigenschaft — garantiert eine Flanke pro Bitzellenmitte — unterscheiden sich aber in der Zuordnung Flankenrichtung↔Bitwert. Sender und Empfänger müssen sich auf dieselbe Konvention einigen; ein Verwechseln der beiden invertiert sämtliche empfangenen Bits.

Wichtig: Der Wert eines Bits hängt nur von der Flankenrichtung ab, nicht vom Anfangspegel der Zelle. Der Anfangspegel jeder Zelle wird durch den Endpegel der vorherigen Zelle festgelegt — sind zwei aufeinanderfolgende Bits gleich, muss zusätzlich zur garantierten Mittenflanke auch am Zellenrand eine (informationslose) Flanke auftreten, um den Pegel für die nächste Mittenflanke zurückzusetzen.

Simulator: Taktsignal, NRZ und Manchester im Vergleich

Eine frei wählbare Bitfolge wird gleichzeitig als Bitzellentakt, als einfaches NRZ-Signal (Pegel = Bitwert) und als Manchester-Signal dargestellt. Die grünen Pfeile markieren die garantierte Flanke in jeder Bitzellenmitte — ihre Richtung trägt die Information, nicht der Pegel davor oder danach. Zwischen den beiden Konventionen umschalten, um den in Abschnitt 1 beschriebenen Unterschied direkt an der Kurve zu sehen: Bei gleicher Bitfolge ist das Manchester-Signal bei IEEE 802.3 exakt invertiert gegenüber G. E. Thomas.

Bitfolge (nur 0 und 1):

Konvention:

2. Warum Flankenwechsel Taktrückgewinnung ermöglichen

Bei NRZ trägt eine lange Folge identischer Bits (z. B. 000000…) keinerlei Flankeninformation — der Empfänger hat nichts, woran er seinen Bit-Takt nachjustieren könnte, und driftet ohne separate Taktleitung auseinander. Der Manchester-Code garantiert dagegen mindestens eine Flanke pro Bitzelle, unabhängig vom übertragenen Bitmuster. Ein Phasenregelkreis (siehe Phase Locked Loop) im Empfänger kann sich damit fortlaufend auf diese Flanken synchronisieren, ohne dass eine separate Taktleitung oder ein regelmäßiges Trainingssignal nötig wäre — der Code ist selbsttaktend.

3. Gleichstromfreiheit

Jede einzelne Bitzelle besteht aus exakt einer Hälfte High und einer Hälfte Low, unabhängig vom übertragenen Bitwert. Der Gleichanteil (Mittelwert) des Signals ist damit über jede beliebige Bitzelle hinweg exakt null — nicht nur im statistischen Mittel über viele Bits, sondern deterministisch für jedes einzelne Bit. Das ist relevant für Übertragungsstrecken mit galvanischer Trennung (Transformatoren, AC-gekoppelte Leitungen), die keinen Gleichanteil übertragen können, ohne das Signal zu verzerren.

4. Bandbreitenbedarf

Für eine Folge identischer Bits (Worst Case für Manchester, da hier zusätzlich zur Mittenflanke auch am Zellenrand eine Flanke auftritt) liegt die dominante Frequenzkomponente exakt bei 1000 Hz = R. Für eine alternierende Bitfolge (Worst Case für NRZ) liegt sie bei 500 Hz = R/2 — sowohl beim NRZ-Signal als auch beim Manchester-Signal mit alternierenden Bits.

Der Vergleich zeigt den Kern des Bandbreiten-Nachteils: Das ungünstigste NRZ-Bitmuster (alternierend) erzeugt eine höchste Frequenzkomponente von $R/2$. Das ungünstigste Manchester-Bitmuster (beliebige lange Folge gleicher Bits — beim NRZ der harmloseste Fall überhaupt) erzeugt dagegen eine höchste Frequenzkomponente von $R$ — doppelt so hoch. Für dieselbe Datenrate $R$ braucht der Manchester-Code deshalb ungefähr die doppelte Übertragungsbandbreite gegenüber NRZ.

Bitmuster	NRZ: höchste Frequenzkomponente	Manchester: höchste Frequenzkomponente
alternierend (`0101…`)	$R/2$ (Worst Case für NRZ)	$R/2$
konstant (`0000…` oder `1111…`)	$0$ Hz (kein Wechsel)	$R$ (Worst Case für Manchester)

5. Verwandtes Verfahren: Differential Manchester Encoding

Eine wichtige Variante kodiert den Bitwert nicht über die Richtung der Mittenflanke, sondern über das Vorhandensein oder Fehlen einer Flanke am Zellenrand (die Mittenflanke bleibt in jeder Zelle als Taktreferenz erhalten, unabhängig vom Bitwert):

Logische 0: Flankenwechsel am Zellenanfang
Logische 1: kein Flankenwechsel am Zellenanfang (Pegel setzt sich fort)

Der entscheidende Vorteil: Differential Manchester ist polaritätsunabhängig — vertauscht man die beiden Leitungsadern (oder invertiert das Signal), bleibt die Kodierung trotzdem korrekt entschlüsselbar, da nur Änderungen relativ zum vorherigen Pegel ausgewertet werden, nicht der absolute Pegel selbst. Dieses Verfahren kam u. a. bei Token Ring (IEEE 802.5) zum Einsatz.

Simulator: Differential Manchester Encoding

Die orangen Marker am Zellenrand zeigen die informationstragende Flanke — sie erscheint nur bei einer 0, bei einer 1 setzt sich der Pegel unverändert fort. Die grünen Pfeile in der Zellenmitte markieren die reine Taktflanke, die unabhängig vom Bitwert in jeder Zelle auftritt. Anders als beim klassischen Manchester-Code oben trägt hier also nicht die Mittenflanke die Information, sondern das Vorhandensein der Randflanke.

Bitfolge (nur 0 und 1):

Randflanke vorhanden → Bit 0 Randflanke fehlt → Bit 1 Mittenflanke (immer, taktgebend)

6. Praktischer Einsatz

2400-Baud-Packet-Radio (Manchester-FSK): Neben dem verbreiteten 1200-Baud-AFSK-Packet (Bell-202-Töne, kein Manchester-Code) gibt es G3RUH-kompatible 2400-Baud-Modems — etwa das YAM-Modem —, die mit Manchester-kodiertem FSK arbeiten. Der Grund ist derselbe wie bei 802.3-Ethernet: garantierte Taktrückgewinnung ohne separate Taktleitung, hier zwischen TNC und Funkgerät.

Klassisches Ethernet (10 Mbit/s): 10BASE5, 10BASE2 und 10BASE-T kodieren auf der physikalischen Schicht mit Manchester-Code — die Selbsttaktung erlaubt den Verzicht auf eine separate Taktleitung im Kabel. Spätere, schnellere Ethernet-Standards (100BASE-TX u. a.) verwenden stattdessen bandbreiteneffizientere Verfahren (4B5B/MLT-3), da der doppelte Bandbreitenbedarf bei höheren Datenraten zunehmend ins Gewicht fällt.

Niederfrequente RFID-Systeme (125 kHz): Viele einfache RFID-Tag-Protokolle in diesem Frequenzbereich nutzen Manchester- oder Differential-Manchester-Codierung für die Rückantwort des Tags, da die Selbsttaktung ohne zusätzliche Referenzleitung besonders für passive, energiearme Tags vorteilhaft ist.

Historische Massenspeicher: Trommel- und frühe Magnetplattenspeicher nutzten Manchester-ähnliche Codierungen, um Bittakt und Nutzdaten gemeinsam auf einer einzigen Spur unterzubringen, ohne separate Taktspur.

7. Grenzen

Doppelter Bandbreitenbedarf gegenüber NRZ bei gleicher Datenrate (siehe Abschnitt 4) — für hohe Datenraten zunehmend unattraktiv gegenüber bandbreiteneffizienteren Leitungscodes.
Höhere Flankenrate bedeutet auch höhere Anforderungen an die analoge Bandbreite der Übertragungsstrecke (Kabel, Transformatoren, Treiberstufen).
Konventionsabhängigkeit: Wie in Abschnitt 1 beschrieben, invertiert eine falsch angenommene Konvention (G. E. Thomas vs. IEEE 802.3) sämtliche empfangenen Bits — ein reines Definitionsproblem, kein technischer Mangel, aber eine häufige Fehlerquelle bei der Implementierung.