FT8 – Mathematik statt Watt

18.10.2026 Amateurfunk Podcast

Wer wie ich als DL6LG mit einen QRP-Gerät (IC-705 oder X6100) und ein paar Watt FT8 macht, kennt das Gefühl: Aus dem Lautsprecher kommt nur Rauschen, im Wasserfall ist bestenfalls ein Hauch von Strich zu ahnen, und trotzdem steht eine Sekunde später in grüner Schrift ein Rufzeichen aus Übersee auf dem Bildschirm. Irgendwann wollte der Universaldilettant in mir wissen, was da eigentlich passiert. Im Artikel FT8 – Digitaler Flüsterfunk habe ich den Modus aus Sicht des Funkbetriebs vorgestellt. Diesmal geht es Bit für Bit.

Genau das machen wir in diesem Artikel. Wir nehmen die harmlose Nachricht CQ DL6LG JO60, quetschen sie in 77 Bits, packen einen Türsteher und einen Panzer drumherum, verwandeln das Ganze in 79 Töne und schauen zum Schluss zu, wie WSJT-X die Nachricht auf der anderen Seite wieder aus dem Rauschen pult. Kaffee bereitstellen, es wird mathematisch.

Als Landkarte dient die Protokollbeschreibung der Entwickler selbst: The FT4 and FT8 Communication Protocols, erschienen 2020 in der QEX. Wer irgendwo nachprüfen will, ob ich mich verrechnet habe, wird dort fündig.

1 Zeitraster, Modulation und Signalformung

Bevor wir an die Bits gehen, klären wir die Spielregeln: wann gesendet wird, wie die Töne aussehen und warum ein sauberes Signal wichtiger ist als ein lautes.

1.1 Das 15-Sekunden-Raster: die digitale Stechuhr

1.1.1 Sende- und Empfangsintervalle (00, 15, 30, 45 s)

Wer auf Kurzwelle gemütlich über selbstgebaute Antennen plaudern möchte, ist bei FT8 falsch. Das Protokoll von Joe Taylor (K1JT, Physik-Nobelpreisträger 1993) und Steve Franke (K9AN) teilt jede UTC-Minute in vier Zeitschlitze von exakt 15 Sekunden. Sie beginnen bei 00, 15, 30 und 45 Sekunden.

00 s     15 s     30 s     45 s     60 s
├────────┼────────┼────────┼────────┤
│ Even   │ Odd    │ Even   │ Odd    │
│ (1st)  │ (2nd)  │ (1st)  │ (2nd)  │
└────────┴────────┴────────┴────────┘

Gearbeitet wird im Wechselbetrieb: Station A sendet in den geraden Intervallen („Even“ bzw. „1st“, Beginn bei 00 und 30 s), Station B hört zu. In den ungeraden Intervallen („Odd“ bzw. „2nd“, Beginn bei 15 und 45 s) tauschen die beiden die Rollen. Wer versehentlich im selben Intervall sendet wie sein Gegenüber, führt ein Selbstgespräch: Beide brüllen gleichzeitig, keiner hört den anderen.

1.1.2 Was in einem Intervall passiert (0,5 s Vorlauf, 12,64 s Senden, 1,86 s Rest)

Die 15 Sekunden werden nicht von vorn bis hinten durchgesendet. Die innere Choreografie sieht so aus:

$$\text{Intervall} = \text{Vorlauf} + \text{Sendung} + \text{Rest} = 0{,}50\text{ s} + 12{,}64\text{ s} + 1{,}86\text{ s} = 15{,}00\text{ s}$$

Der Vorlauf (0,50 s): Nach dem UTC-Taktstrich wartet die Software eine halbe Sekunde. Das fängt PTT-Umschaltzeiten, Soundkarten-Puffer und kleine Uhrenabweichungen ab.
Die Sendung (12,64 s): Ab Sekunde 0,50 laufen die 79 Tonsymbole durch, jedes 0,160 s lang: 79 × 0,160 s = 12,64 s.
Der Rest (1,86 s): Bei Sekunde 13,14 ist Schluss. Bis zum nächsten Intervall bleiben 15,00 − 13,14 = 1,86 Sekunden. In dieser Zeit muss die Gegenseite decodieren, die Antwort vorbereiten und auf Senden umschalten. Damit das reicht, starten neuere WSJT-X-Versionen einen ersten Decodierdurchgang schon, bevor die Sendung ganz vorbei ist.

1.1.3 Zeitsynchronisation: Ohne genaue Uhr kein QSO

FT8 verlangt von deiner Rechneruhr eine Disziplin, die sie ohne Hilfe nicht hat. Das WSJT-X-Handbuch fordert eine Abweichung von höchstens ±1 Sekunde zu UTC, und auch die FT8-Arbeitsanleitung von Gary Hinson (ZL2iFB) in der deutschen Übersetzung von Ekkehard Körner (DJ5EJ) legt das jedem ans Herz. Der Decoder sucht zwar in einem Fenster von etwa ±2,5 Sekunden nach Signalen (mehr dazu in Kapitel 5), aber je weiter die Uhr daneben liegt, desto mehr Signale rutschen aus dem Raster und desto knapper wird das Zeitfenster für die Antwort. Liegt die Abweichung jenseits von etwa zwei Sekunden, ist Feierabend: WSJT-X decodiert praktisch nichts mehr, und zwar ohne Fehlermeldung. Die Spalte „DT“ in der Decodierliste zeigt dir übrigens, wie weit die Gegenstationen zeitlich von deiner Uhr entfernt liegen. Stehen dort durchweg Werte um +1,5, geht deine Uhr nach.

Im Shack erledigt das NTP (Network Time Protocol) über das Internet. Wer auf dem Gipfel funkt (SOTA) und kein Netz hat, holt sich die Zeit per GPS-Empfänger oder DCF77. Für Linux habe ich mir dafür den GPS-Dilettanten gebaut, der die Uhr mit einer GPS-Maus stellt und nebenbei den Locator für WSJT-X liefert.

Die Bundesnetzagentur interessiert sich übrigens kein bisschen dafür, ob deine Uhr eine Sekunde nachgeht. Ordnungswidrig ist das nicht. Bestraft wirst du trotzdem, und zwar vom Decoder: mit eisernem Schweigen.

1.2 8-GFSK: Töne im Gänsemarsch

1.2.1 Phasenkontinuierlich und gaußgefiltert (BT = 2,0)

FT8 ist eine mehrstufige Frequenzumtastung mit acht Tönen (8-FSK). Würde man zwischen den Tönen hart umschalten, gäbe es Phasensprünge, und die verschmieren das Spektrum mit Nebenaussendungen. Deshalb arbeitet FT8 phasenkontinuierlich (Continuous-Phase FSK, CPFSK): Frequenz und Phase ändern sich stetig, ohne Sprungstellen.

Seit WSJT-X 2.1 geht es noch eleganter. Die rechteckigen Frequenzsprünge werden vor der Phasenintegration durch ein Gauß-Filter geglättet, aus 8-FSK wird 8-GFSK. Die Impulsantwort des Filters:

$$g(t) = \frac{1}{\sqrt{2\pi}\cdot \sigma} \cdot e^{-\frac{t^2}{2\sigma^2}}$$

Das Bandbreite-Zeit-Produkt liegt bei FT8 bei BT = 2,0 (B = −3-dB-Bandbreite des Filters, T = Symboldauer). Das steht so in der Protokollbeschreibung der Entwickler. Aus BT ergibt sich die Breite σ der Glockenkurve:

$$\sigma = \frac{\sqrt{\ln 2}}{2\pi \cdot BT} \cdot T = \frac{0{,}833}{2\pi \cdot 2{,}0} \cdot 0{,}160\text{ s} \approx 10{,}6\text{ ms}$$

Je größer BT, desto schmaler die Glocke und desto weniger wird geglättet. Zum Vergleich: Der kleine Bruder FT4 nutzt BT = 1,0. Wer es noch eiliger hat, findet bei FT2 den nächsten Gang.

Das Gauß-Filter schleift die Ecken der Frequenzsprünge rund. Im Wasserfall sieht man den Unterschied: Das Spektrum fällt außerhalb der Nutzbandbreite deutlich steiler ab, die Nachbarn bekommen weniger ab.

1.2.2 Die Kenngrößen der Modulation

Die physikalischen Parameter greifen ineinander wie die Zinken einer guten Schwalbenschwanzverbindung:

Parameter	Wert	Bedeutung
Anzahl der Töne (M)	8	Ein Symbol trägt log₂(8) = 3 Bits.
Symboldauer (T)	0,160 s (160 ms)	So lange klingt ein Ton.
Symbolrate (Rₛ)	6,25 Baud	Rₛ = 1/T = 1/0,160 s
Tonabstand (Δf)	6,25 Hz	Abstand zwischen benachbarten Tönen, Δf = Rₛ
Modulationsindex (h)	1,0	h = Δf/Rₛ = 6,25 Hz / 6,25 Baud

Weil der Tonabstand genau der Symbolrate entspricht, sind die acht Töne über eine Symboldauer orthogonal. Bei der Fourier-Transformation im Empfänger stören sie sich trotz des winzigen Abstands nicht gegenseitig, und das reicht für die nichtkohärente Demodulation, die WSJT-X verwendet.

1.2.3 50 Hz Bandbreite und die Decodierschwelle von rund −21 dB

Die belegte Bandbreite ergibt sich aus Tonzahl mal Tonabstand:

$$B = M \times \Delta f = 8 \times 6{,}25\text{ Hz} = 50\text{ Hz}$$

Ein SSB-Sprachsignal braucht etwa 2400 Hz. Rein rechnerisch passen also rund 48 FT8-Signale nebeneinander in einen einzigen Telefoniekanal.

Jetzt die Zahl, mit der FT8 auf jeder Party angibt: Bezogen auf eine Referenzbandbreite von 2500 Hz (typische SSB-Filterbreite) decodiert FT8 laut den Entwicklern noch bei einem Signal-Rausch-Abstand von etwa −21 dB im ungestörten Rauschkanal (AWGN). Diese Schwelle erreicht WSJT-X mit einer Kombination aus Block-Detektion und zwei Decodern, Belief Propagation (BP) und Ordered Statistics Decoding (OSD). Die nehmen wir in Kapitel 5 auseinander.

Was heißt das praktisch? −21 dB bedeutet: Im 2500-Hz-Fenster ist die Rauschleistung gut 120-mal größer als die Signalleistung (10^2,1 ≈ 126). Hören kannst du so ein Signal nicht. Selbst geübte Telegrafisten sind bei CW irgendwo um −15 dB am Ende, und zu denen gehöre ich (noch) nicht. Ganz so wundersam ist es aber nicht: Die Signalenergie sitzt in nur 50 Hz, und bezogen auf diese Bandbreite sieht das Verhältnis gleich deutlich freundlicher aus. Die Referenz von 2500 Hz ist eine Konvention, damit man verschiedene Betriebsarten vergleichen kann.

1.3 Soft-Keying: kein Gepolter im Äther

1.3.1 Die Raised-Cosine-Rampe (20 ms)

Auch mit stetiger Phase würde das schlagartige Einschalten der vollen Leistung am Anfang und das Abschalten am Ende Tastklicks erzeugen. Deshalb wird die Hüllkurve A(t) mit einer Raised-Cosine-Rampe sanft hoch- und wieder heruntergefahren:

Die Hüllkurve hat drei Abschnitte. Tₛ steht für die Sendedauer von 12,64 s, τ für die Rampenzeit.

Anstieg, für 0 ≤ t < τ:

$$A(t) = \frac{1}{2} \left[ 1 – \cos\left( \frac{\pi t}{\tau} \right) \right]$$

Volle Leistung, für τ ≤ t ≤ Tₛ − τ:

$$A(t) = 1$$

Abfall, für Tₛ − τ < t ≤ Tₛ:

$$A(t) = \frac{1}{2} \left[ 1 + \cos\left( \frac{\pi \left(t – T_S + \tau\right)}{\tau} \right) \right]$$

Die Rampenzeit τ beträgt 20 ms, also genau ein Achtel einer Symboldauer (T/8).

1.3.2 ALC-Sünden und warum leiser oft besser ist

Hier trifft die saubere Mathematik auf die raue Wirklichkeit der Analogtechnik. FT8 hat eine konstante Hüllkurve, die Endstufe müsste also nicht einmal linear sein. Weil das Signal aber fast immer als NF über die Soundkarte in einen SSB-Transceiver (USB) eingespeist wird, hängt die Sauberkeit an der gesamten Sendekette.

Der Klassiker: Der NF-Pegel aus dem PC wird so weit aufgedreht, bis die Leistungsanzeige des Funkgeräts die volle Nennleistung zeigt. Spätestens dann greift die ALC (Automatic Level Control) ein. Sanft regelt die nicht, sie verzerrt. Die Arbeitsanleitung von ZL2iFB warnt ausdrücklich davor.

Das sauber auf 50 Hz begrenzte FT8-Signal bekommt Geisterlinien und Nebenprodukte, die im Wasserfall der Mitfunker als „Lattenzaun“ auftauchen. Merk dir für die Praxis:

Stell den NF-Pegel so ein, dass die ALC-Anzeige bei null bleibt.
Die Ausgangsleistung regelst du am Leistungsregler des Transceivers, nicht über den NF-Pegel.

Ein sauberes Signal mit weniger Leistung kommt am Ziel besser an als ein verzerrtes mit voller Leistung, und die Nachbarn danken es dir.

Damit kennen wir die Bühne. Jetzt schauen wir uns an, was eigentlich in den 12,64 Sekunden übertragen wird.

2 Quellencodierung und das 77-Bit-Paket

In diesem Kapitel pressen wir unsere Beispielnachricht in genau 77 Bits. Wir schauen uns erst den Aufbau des Pakets an, dann die einzelnen Felder für Rufzeichen, Locator und Freitext, danach die Hash-Tricks für lange Rufzeichen und zum Schluss die Liste aller Nachrichtentypen.

2.1 Warum FT8 über ASCII nur lacht

2.1.1 Das Problem mit 8 Bits pro Zeichen

Wer am PC Text überträgt, nimmt ASCII oder UTF-8: ein Zeichen, ein Byte, acht Bits. CQ DL6LG JO60 hat 13 Zeichen samt Leerzeichen, macht 104 Bits.

Auf Kurzwelle, wo jedes Bit im Rauschen ums Überleben kämpft, ist das Verschwendung. Taylor und Franke haben deshalb radikal entschieden: Bei FT8 wird Text nie Zeichen für Zeichen gesendet. Die ganze Nachricht wird als eine einzige große Zahl betrachtet und verlustfrei in ein Nutzdatenpaket von exakt 77 Bits gepresst.

ASCII:  13 Zeichen × 8 Bits
        = 104 Bits (zu fett)
FT8:    als Zahl gepackt
        =  77 Bits (ein Brikett)

2.1.2 Der Aufbau: Informationsbits und Typkennung (i3, n3)

Die 77 Bits sind ein streng gegliedertes Bitfeld, so beschrieben im QEX-Artikel. Damit der Empfänger weiß, wie er die Bits lesen soll, steckt am Ende eine Typkennung:

Haupttyp i3 (3 Bits): Die letzten drei Bits ergeben acht Grundtypen (0 bis 7). Sie sagen dem Decoder sofort, ob ein Standard-QSO, ein Contest-Austausch oder Freitext kommt.
Untertyp n3 (3 Bits): Beim Typ 0 reicht das nicht, dort gibt es weitere drei Bits für Untertypen (0.0 bis 0.7). Die gehen den Informationsbits ab, deshalb hat zum Beispiel Freitext nur 71 Nutzbits.

2.2 Die Felder im Einzelnen

Die Felder einer FT8-Nachricht tragen kurze Namen nach einem einfachen Schema: Der Buchstabe sagt, was drinsteckt, die Zahl, wie viele Bits das Feld belegt. c28 ist also ein Rufzeichen (call) mit 28 Bits, g15 ein Locator (grid) mit 15 Bits. Hier alle Felder auf einen Blick, die wichtigsten schauen wir uns danach genauer an:

Feld	Bits	Inhalt
`c28`	28	Standard-Rufzeichen, CQ, DE, QRZ oder ein 22-Bit-Hash (2.2.1)
`c58`	58	Sonderrufzeichen mit bis zu 11 Zeichen (2.2.3)
`h10`, `h12`, `h22`	10, 12, 22	Hash eines Rufzeichens (2.3)
`g15`	15	4-stelliger Locator, Rapport, RRR, RR73 oder 73 (2.2.2)
`g25`	25	6-stelliger Locator
`r1`, `p1`	je 1	Rufzeichen trägt ein angehängtes `/R` bzw. `/P`
`R1`	1	„R“ vor dem Rapport (Bestätigung)
`r2`	2	RRR, RR73, 73 oder nichts
`r3`	3	RST-Rapport von 529 bis 599 (Contest)
`r5`	5	Rapport von −30 bis +32 dB in 2-dB-Schritten (DXpedition)
`h1`	1	welches der beiden Rufzeichen als Hash übertragen wird
`c1`	1	das erste Rufzeichen ist „CQ“
`t1`	1	vorangestelltes „TU;“ (Contest)
`s11`	11	Seriennummer (EU VHF Contest)
`s13`	13	Seriennummer oder US-Bundesstaat bzw. kanadische Provinz (RTTY Roundup)
`n4`, `k3`, `S7`	4, 3, 7	ARRL Field Day: Zahl der Sender, Klasse A–F, ARRL/RAC-Sektion
`f71`	71	Freitext mit bis zu 13 Zeichen (2.2.4)
`t71`	71	Telemetrie, 18 Hex-Ziffern
`i3`, `n3`	je 3	Nachrichtentyp und Untertyp (2.1.2)

2.2.1 Das c28-Feld: 28 Bits für ein Rufzeichen

Das Herzstück fast jeder FT8-Nachricht ist das Feld c28. Es belegt 28 Bits und nimmt jedes Standard-Rufzeichen der Welt auf.

Die Normalisierung auf sechs Stellen. Ein Standard-Rufzeichen wird auf sechs Positionen gebracht, und zwar so, dass die Ziffer immer an Position 3 steht. DL6LG passt schon (D, L, 6 …) und wird hinten mit einem Leerzeichen aufgefüllt: DL6LG␣. Bei K1ABC steht die Ziffer an Position 2, also kommt vorne ein Leerzeichen dazu: ␣K1ABC.

Vier Zeichenvorräte. Weil an manchen Positionen nur bestimmte Zeichen erlaubt sind, nutzt jede Position ihren eigenen, möglichst kleinen Zeichenvorrat:

Position	Erlaubte Zeichen	Anzahl	Indizes
1	Leerzeichen, 0–9, A–Z	37	␣ = 0, 0–9 = 1–10, A–Z = 11–36
2	0–9, A–Z	36	0–9 = 0–9, A–Z = 10–35
3	0–9	10	0–9 = 0–9
4, 5, 6	Leerzeichen, A–Z	je 27	␣ = 0, A–Z = 1–26

Damit ergibt sich die Zahl aller bildbaren Standard-Rufzeichen:

$$N_{\text{Calls}} = 37 \times 36 \times 10 \times 27 \times 27 \times 27 = 262.177.560$$

Ein 28-Bit-Register fasst 2²⁸ = 268.435.456 Werte. Alle 262,18 Millionen Rufzeichen passen hinein, und es bleiben 6.257.896 Werte übrig. Diese Reserve liegt am unteren Ende des Wertebereichs (0 bis 268.435.455), die Rufzeichen werden dahinter einsortiert:

Wertebereich	Belegung
0 bis 2	Sondertoken: DE = 0, QRZ = 1, CQ = 2
3 bis 2.063.591	CQ-Varianten (CQ 000–999, CQ A–ZZZZ, z. B. CQ DX, CQ TEST)
2.063.592 bis 6.257.895	22-Bit-Rufzeichen-Hashes (h22)
6.257.896 bis 268.435.455	alle 262.177.560 Standard-Rufzeichen

Das Rechenbeispiel DL6LG. Wir lesen die Indizes aus der Tabelle ab:

Position 1, D: Index 14
Position 2, L: Index 21
Position 3, 6: Index 6
Position 4, L: Index 12
Position 5, G: Index 7
Position 6, Leerzeichen: Index 0

Jetzt das Stellenwertsystem mit gemischten Basen:

$$n = 14 \cdot (36 \cdot 10 \cdot 27^3) + 21 \cdot (10 \cdot 27^3) + 6 \cdot 27^3 + 12 \cdot 27^2 + 7 \cdot 27 + 0$$

Ausgerechnet:

$$n = 99.202.320 + 4.133.430 + 118.098 + 8.748 + 189 + 0 = 103.462.785$$

Und nicht vergessen: Die ersten 6.257.896 Werte sind für Token und Hashes reserviert. Der fertige c28-Wert ist also

$$c_{28} = 103.462.785 + 6.257.896 = \mathbf{109.720.681}$$

Binär auf 28 Bits: 0110 1000 1010 0011 0100 0110 1001

2.2.2 Das g15-Feld: 15 Bits für Locator oder Rapport

Das Feld g15 hat 15 Bits und ist ein schönes Beispiel für Sparsamkeit mit Doppelbelegung.

Der Maidenhead-Locator. Ein vierstelliger Locator besteht aus 18 × 18 Feldern (AA bis RR), die jeweils in 10 × 10 Quadrate (00 bis 99) unterteilt sind. Das macht 18 × 18 × 10 × 10 = 32.400 Möglichkeiten. Ein 15-Bit-Register fasst 2¹⁵ = 32.768 Werte, es bleiben 368 Reservewerte.

Codiert wird wieder als Stellenwertzahl. Für JO60 (J = 9, O = 14, dann die Ziffern 6 und 0):

$$g_{15} = \left( (9 \times 18 + 14) \times 10 + 6 \right) \times 10 + 0 = \mathbf{17.660}$$

Binär auf 15 Bits: 100 0100 1111 1100

Die 368 Reservewerte. Wird kein Locator gesendet, landen dort andere Inhalte:

die Kürzel RRR, RR73 und 73,
der Signalrapport in dB. Codierbar sind ganzzahlige Werte von −50 bis +49 dB, in der Praxis siehst du meist −24 bis +20.

Das vorangestellte „R“ bei einem Rapport wie R-12 steckt übrigens in einem eigenen Bit (R1, siehe 2.4), g15 bleibt davon unberührt.

Die ITU und die Behörden beschreiben in seitenlangen Regelwerken, wie ein ordentliches Funkgespräch abzulaufen hat. FT8 macht es kürzer: Rapport und Abschiedsgruß wandern einfach in dieselbe Schublade, in der sonst die Geokoordinate liegt. Höflicher Smalltalk ist nicht vorgesehen.

2.2.3 Das c58-Feld: 58 Bits für Sonderrufzeichen

Manche Rufzeichen sprengen das Sechs-Zeichen-Korsett, etwa Sonderrufzeichen wie YW18FIFA oder zusammengesetzte Rufzeichen wie PJ4/K1ABC. Dafür gibt es den Nachrichtentyp 4 mit dem Feld c58:

58 Bits nehmen bis zu 11 Zeichen auf. Auch die werden gepackt, nämlich als Zahl zur Basis 38 (Leerzeichen, 0–9, A–Z und /). Das passt: 38¹¹ ≈ 2,39 × 10¹⁷ ist kleiner als 2⁵⁸ ≈ 2,88 × 10¹⁷.
Weil 58 Bits fast das ganze Paket auffressen, bleibt für das zweite Rufzeichen kein Platz. Es fährt als kurzer 12-Bit-Hash (h12) mit.

2.2.4 Das f71-Feld: 71 Bits Freitext

Wer trotz aller Warnungen persönliche Worte wie TNX BOB 73 GL loswerden will, bekommt mit Typ 0.0 das Feld f71:

71 Bits für höchstens 13 Zeichen.
Das Alphabet umfasst 42 Zeichen: 0–9, A–Z, Leerzeichen und + - . / ?.
Pro Zeichen braucht man log₂(42) ≈ 5,39 Bits. Die Probe: 42¹³ ≈ 1,27 × 10²¹ ist kleiner als 2⁷¹ ≈ 2,36 × 10²¹.

Dreizehn Zeichen. Für einen Plausch über die neue Antenne reicht das nicht, für „73“ allemal.

2.3 Hashes: Rufzeichen im Kurzformat

2.3.1 Drei Hash-Längen

Um bei Sonderrufzeichen, im DXpedition-Modus (Fox & Hound) und bei Contest-Formaten Bits zu sparen, rechnet WSJT-X aus einem Rufzeichen einen kurzen Hash. Das Rufzeichen wird dazu als Zahl zur Basis 38 aufgefasst, mit einer festen großen Konstante multipliziert, und von dem Ergebnis bleiben nur die obersten Bits übrig (ein multiplikativer Hash, kein CRC). Je nach Nachrichtentyp sind das unterschiedlich viele:

Hash	Einsatz	Mögliche Werte
h10	DXpedition-Modus (Typ 0.1)	2¹⁰ = 1.024
h12	Sonderrufzeichen (Typ 4 und 5)	2¹² = 4.096
h22	als Rufzeichen-Ersatz im c28-Feld	2²² = 4.194.304

Klartext: "PJ4/K1ABC"
     │
     ▼  multiplikative Hash-Funktion
12-Bit-Hash: Zahl von 0 bis 4095

2.3.2 Kollisionen und die spitzen Klammern

Aus einem Hash lässt sich das Rufzeichen nicht zurückrechnen, und zwei verschiedene Rufzeichen können denselben Hash ergeben (eine Kollision). WSJT-X behilft sich mit einem Gedächtnis:

Hat die Software das vollständige Rufzeichen PJ4/K1ABC schon einmal empfangen, merkt sie sich die Zuordnung zwischen Rufzeichen und Hash.
Kommt später nur der Hash, schlägt sie im Speicher nach.
Ein so rekonstruiertes Rufzeichen erscheint in spitzen Klammern: <PJ4/K1ABC>.
Kennt die Software den Hash nicht, zeigt sie ratlos <...> an.

2.4 Die Nachrichtentypen im Überblick

Gesteuert wird das ganze Baukastensystem über i3 und n3. Die wichtigsten Typen:

Typ (i3.n3)	Zweck	Felder	Beispiel
0.0	Freitext	f71 + n3 + i3	`TNX BOB 73 GL`
0.1	DXpedition (Fox & Hound)	c28 + c28 + h10 + r5 + n3 + i3	`K1ABC RR73; W9XYZ <KH1/KH7Z> -08`
0.3 / 0.4	ARRL Field Day	c28 + c28 + R1 + n4 + k3 + S7 + n3 + i3	`W9XYZ K1ABC R 17B EMA`
0.5	Telemetrie	t71 + n3 + i3	`123456789ABCDEF012`
1	Standard-QSO	c28 + r1 + c28 + r1 + R1 + g15 + i3	`CQ DL6LG JO60`
2	wie Typ 1, mit `/P`	c28 + p1 + c28 + p1 + R1 + g15 + i3	`G4ABC/P PA9XYZ JO22`
3	ARRL RTTY Roundup	t1 + c28 + c28 + R1 + r3 + s13 + i3	`K1ABC W9XYZ 579 WI`
4	Sonderrufzeichen	h12 + c58 + h1 + r2 + c1 + i3	`<W9XYZ> PJ4/K1ABC RRR`
5	EU VHF Contest (6-stelliger Locator, Seriennummer)	h12 + h22 + R1 + r3 + s11 + g25 + i3	`<G4ABC> <PA9XYZ> R 570007 JO22DB`

Wie der DXpedition-Modus Fox & Hound im Betrieb aussieht, zeigt der Vortrag von Jürg Regli (HB9BIN) bei der USKA-Sektion Bern.

Was die Feldkürzel in der Spalte „Felder“ bedeuten, steht in der Tabelle in Abschnitt 2.2.

Nicht jede mögliche Kombination aus i3 und n3 ist belegt. Einige Werte sind frei oder für spätere Erweiterungen reserviert, die Tabelle zeigt die Typen, die dir im Betrieb begegnen.

2.5 Unser Beispiel: die vollständigen 77 Bits für `CQ DL6LG JO60`

Jetzt setzen wir alle Teile für Typ 1 zusammen. Die Reihenfolge ist c28 + r1 + c28 + r1 + R1 + g15 + i3:

Die Probe: 28 + 1 + 28 + 1 + 1 + 15 + 3 = 77. Kein /R, kein „R“ vor einem Rapport, deshalb stehen die drei Einzel-Bits auf null, und i3 = 1 (001) meldet ein Standard-QSO.

Wer das selbst nachrechnen will, ohne Papier zu verbrauchen: James Kelly (VK3JPK) baut die komplette Sendekette in seinen Python-Notebooks nach (Transmit.ipynb), vom Klartext bis zur WAV-Datei.

Diese 77 Bits sind der reine Inhalt. Gegen Rauschen, Fading und Gewitterkrachen sind sie völlig schutzlos. Wie daraus ein sturmfestes Paket von 174 Bits wird, zeigt Kapitel 3.

3 Fehlerschutz mit CRC-14 und LDPC (174, 91)

Zwei Schutzschichten kommen jetzt um unsere 77 Bits: zuerst eine Prüfsumme, die Fehler erkennt, dann ein Code, der Fehler repariert. Am Ende rechnen wir nach, warum mehr Prüfbits als Nutzbits übertragen werden.

3.1 CRC-14: der Türsteher

3.1.1 Die 14-Bit-Prüfsumme

Wer ein Signal mit Magerquark-Leistung durch die Ionosphäre schickt, muss damit rechnen, dass unterwegs Bits umkippen. Aus CQ DL6LG JO60 könnte ohne Schutz beim Empfänger ein Phantasie-Rufzeichen werden, das nie jemand gesendet hat.

Damit so etwas gar nicht erst auf den Bildschirm kommt, bekommen die 77 Nutzbits als ersten Anbau eine 14-Bit-Prüfsumme (Cyclic Redundancy Check, CRC).

|<----------- 91 Bits ----------->|
[ 77 Nutzbits     ][ 14 CRC-Bits ]

Gerechnet wird mit Polynomdivision in Modulo-2-Arithmetik, also im Binärkörper GF(2), wo Addition ein XOR ist und es keinen Übertrag gibt:

Auffüllen: WSJT-X verlängert die 77 Bits mit fünf Nullen auf 82 Bits und rechnet die Prüfsumme über diese 82 Bits. Im Speicher liegen die Bits zwar in einem Puffer von 12 Bytes (96 Bits), gerechnet wird aber nur über die ersten 82. Das ist kein Detail für Erbsenzähler: Jede zusätzliche Null hinten ändert bei einer Polynomdivision das Ergebnis.
Dividieren: Die Bitkette wird als Koeffizientenfolge eines Polynoms aufgefasst und durch das fest vorgegebene Generatorpolynom geteilt:

$$P_{\text{CRC-14}}(x) = x^{14} + x^{13} + x^{10} + x^9 + x^8 + x^6 + x^4 + x^2 + x + 1$$

In Hex heißt das Polynom 0x2757 (siehe QEX-Artikel). Das ist die übliche Schreibweise ohne das führende x¹⁴; mit diesem Term ergibt sich 0x6757. Der 14-Bit-Rest der Division ist die Prüfsumme.

Hängen wir die 14 CRC-Bits an die 77 Nutzbits, haben wir 91 Bits.

3.1.2 Warum ein Türsteher, wenn gleich ein Panzer kommt?

Berechtigte Frage. Gleich folgt eine starke Fehlerkorrektur, wozu dann noch eine Prüfsumme?

Weil der Decoder bei −21 dB am absoluten Limit arbeitet. Gelegentlich findet er im Rauschen ein Bitmuster, das alle Prüfgleichungen der Fehlerkorrektur erfüllt, inhaltlich aber Unsinn ist. Genau hier steht der CRC-14 an der Tür und kontrolliert die Ausweise:

Ein zufälliges Bitmuster erwischt die richtige Prüfsumme nur mit einer Wahrscheinlichkeit von 1 : 2¹⁴ = 1 : 16.384, also rund 0,006 %.
Stimmt die Prüfsumme nicht, fliegt das Paket kommentarlos raus.

Ganz dicht ist die Tür trotzdem nicht. Bei sehr vielen Decodierversuchen pro Intervall rutscht ab und zu ein Falschdecode durch, besonders bei den besonders empfindlichen Verfahren aus Kapitel 5 (OSD und A-priori-Decodierung). Wer FT8 länger macht, hat schon mal ein Rufzeichen aus einem Land gesehen, das es nicht gibt. Selten, aber es kommt vor. WSJT-X markiert deshalb unsichere Decodes mit einem Fragezeichen.

Im Sprachfunk musst du bei Rauschen raten, ob da gerade DL6LG oder DL6HG gerufen hat. Der CRC rät nicht. Ein falsches Bit, und die Nachricht ist weg, ohne Rückfrage und ohne Anhörung.

3.1.3 Wie man so etwas rechnet: Schieberegister und Schleife

In Hardware rechnet man eine CRC mit einem rückgekoppelten Schieberegister (Linear Feedback Shift Register, LFSR): 14 Flip-Flops in Reihe, dazwischen XOR-Gatter an den Stellen, an denen das Polynom eine Eins hat.

Alle 14 Speicherzellen stehen am Anfang auf 0.
Die 82 Bits laufen nacheinander durch das Register, jedes Bit ist ein Takt.
Nach 82 Takten steht in den 14 Zellen die fertige Prüfsumme.

WSJT-X selbst ist Software und bildet genau dieses Verhalten in einer Schleife mit Schiebe- und XOR-Befehlen nach. Das geht für 82 Bits in Mikrosekunden, und da die komplette Nachricht vor dem Senden berechnet wird, spielt die Rechenzeit ohnehin keine Rolle.

3.2 LDPC (174, 91): der Panzer

3.2.1 Generatormatrix und Paritätsbits

Wir haben jetzt 91 Bits (77 Nutzbits + 14 CRC-Bits). Kracht ein Gewitter dazwischen oder säuft das Signal kurz im Fading ab, hilft der Türsteher allein nicht: Er würde das beschädigte Paket nur wegwerfen. Wir brauchen etwas, das kaputte Bits repariert.

Dafür sorgt ein Low-Density Parity-Check Code (LDPC), genauer ein eigens für FT8 entworfener LDPC (174, 91): 91 Bits rein, 174 Bits raus. Der Name verrät das Prinzip: „Low Density“ heißt dünn besetzt. Jedes Bit wird nur von wenigen Prüfgleichungen überwacht, bei FT8 von genau drei, die zugehörige Prüfmatrix besteht also fast nur aus Nullen. Genau das macht die Decodierung in Kapitel 5 so schnell.

Die 83 Paritätsbits entstehen durch eine Matrixmultiplikation im Binärkörper. Die Generatormatrix hat 83 Zeilen und 91 Spalten und ist im WSJT-X-Quellcode als Tabelle hinterlegt. Wer sie sich ansehen will, findet sie zusammen mit der Prüfmatrix im Ordner lib/ft8 in den Dateien, deren Namen mit ldpc_174_91_c beginnen:

$$\mathbf{p} = \mathbf{G} \cdot \mathbf{m} \pmod 2$$

Multiplizieren heißt hier UND-Verknüpfung, Aufaddieren heißt XOR. Heraus kommen 83 Paritätsbits. Weil die 91 Eingangsbits unverändert vorne im Codewort stehen und die Paritätsbits nur hinten angehängt werden, nennt man den Code systematisch. Zusammen ergeben sie das 174-Bit-Codewort.

3.2.2 Paritätsprüfung zum Anfassen: ein Mini-Beispiel

Eine 83 × 91-Matrix füllt jedes Whiteboard. Deshalb zeigen wir das Prinzip an einem Zwerg: dem klassischen Hamming-(7,4)-Code mit 4 Datenbits (D₁ bis D₄) und 3 Prüfbits (P₁ bis P₃). Das ist kein LDPC-Code, aber die Grundidee, nämlich dass jedes Prüfbit über eine XOR-Gleichung mehrere Datenbits überwacht, ist dieselbe.

Senden. Wir wollen 1 0 1 1 schützen und rechnen die Prüfbits aus:

P₁ = D₁ ⊕ D₂ ⊕ D₄ = 1 ⊕ 0 ⊕ 1 = 0
P₂ = D₁ ⊕ D₃ ⊕ D₄ = 1 ⊕ 1 ⊕ 1 = 1
P₃ = D₂ ⊕ D₃ ⊕ D₄ = 0 ⊕ 1 ⊕ 1 = 0

Gesendet wird [ 1 0 1 1 | 0 1 0 ].

Störung. Über dem Atlantik kippt D₁ von 1 auf 0. Beim Empfänger kommt [ 0 0 1 1 | 0 1 0 ] an.

Empfangen. Der Empfänger rechnet die drei Gleichungen stur nach:

D₁ ⊕ D₂ ⊕ D₄ = 0 ⊕ 0 ⊕ 1 = 1, empfangen wurde P₁ = 0. Alarm.
D₁ ⊕ D₃ ⊕ D₄ = 0 ⊕ 1 ⊕ 1 = 0, empfangen wurde P₂ = 1. Alarm.
D₂ ⊕ D₃ ⊕ D₄ = 0 ⊕ 1 ⊕ 1 = 0, empfangen wurde P₃ = 0. Passt.

Gleichungen 1 und 2 schlagen an, Gleichung 3 nicht. Das einzige Bit, das in 1 und 2 vorkommt, in 3 aber nicht, ist D₁. Also wird D₁ zurück auf 1 gesetzt, und die Nachricht ist gerettet, ohne dass der Sender ein Watt mehr aufbringen oder irgendetwas wiederholen musste.

Der echte FT8-Decoder arbeitet raffinierter: Er rechnet mit Wahrscheinlichkeiten statt mit harten Nullen und Einsen und lässt die Gleichungen iterativ miteinander verhandeln. Das schauen wir uns in Kapitel 5 an.

3.2.3 Und wenn ein Prüfbit kaputtgeht?

Dem Decoder ist es egal, welches Bit umkippt. Geprüft wird mit der Paritätsprüfmatrix H der Größe 83 × 174. Ein empfangener Vektor c ist genau dann ein gültiges Codewort, wenn alle 83 Gleichungen null ergeben:

$$\mathbf{H} \cdot \mathbf{c}^T = \mathbf{0} \pmod 2$$

In diesen Gleichungen kommen alle 174 Bits vor, Nutzbits, CRC-Bits und Paritätsbits gleichberechtigt. Wie gesagt steckt jedes Bit in drei der 83 Gleichungen. Ein umgekipptes Paritätsbit lässt also drei Prüfungen anschlagen, und der Decoder repariert es genauso wie ein Nutzbit. Lieblingskinder gibt es nicht.

3.2.4 Mehr Prüfbits als Nutzbits: 97 gegen 77

Zählen wir durch:

Anteil	Bits	Prozent vom Codewort
Nutzdaten	77	44,3 %
CRC-14	14	8,0 %
LDPC-Parität	83	47,7 %
Prüfbits gesamt	97	55,7 %

Nutzdaten 77 Bits: ████████████████
Prüfbits  97 Bits: ████████████████████

Mehr als die Hälfte des Sendedatenstroms ist Kontrollmaterial. Klingt nach Verschwendung, ist aber der Trick, mit dem FT8 so weit unter dem Rauschen arbeiten kann. Das stark überbestimmte Gleichungssystem erlaubt es dem Decoder, auch dann noch das richtige Codewort zu finden, wenn ein erheblicher Teil der Symbole vom Rauschen verfälscht ist.

Anders gesagt: Mathematik ersetzt Sendeleistung. Für eine vergleichbar sichere Verbindung in SSB bräuchtest du grob 20 bis 30 dB mehr Signal, also das Hundert- bis Tausendfache an Leistung. Aus deinen 5 Watt QRP würde dann eine Endstufe, für die du einen Starkstromanschluss im Shack bräuchtest.

Jetzt haben wir 174 sturmfeste Bits. Ein Funkgerät kann mit Bits aber nichts anfangen, es will Töne. Wie aus den Bits Töne werden, zeigt Kapitel 4.

4 Symbole, Gray-Code und Costas-Arrays

In diesem Kapitel übersetzen wir Bits in Töne. Wir fassen die Bits zu Dreiergruppen zusammen, ordnen ihnen mit einem Gray-Code Tonstufen zu, bauen Synchronisationsmuster ein und rechnen am Ende die tatsächlichen NF-Frequenzen aus.

4.1 Aus Bits werden Tonstufen

4.1.1 174 Bits, 58 Dreiergruppen

Jedes Bit als eigenen Ton zu senden, würde ewig dauern. Weil unser 8-GFSK-Modulator acht Töne kennt und 2³ = 8 ist, fasst FT8 die Bits zu Dreiergruppen zusammen:

$$\text{Datensymbole} = \frac{174 \text{ Bits}}{3 \text{ Bits pro Symbol}} = 58$$

174 Codewort-Bits
   │
   ▼  in Dreiergruppen zerlegen
      (000 bis 111)
S₁  S₂  S₃  …  S₅₇  S₅₈
   │
   ▼
58 Datensymbole, je ein Ton 0 bis 7

4.1.2 Gray-Code: Nachbartöne unterscheiden sich in nur einem Bit

Ordnet man die Dreiergruppen einfach nach Binärwert den Tönen zu (000 = Ton 0, 001 = Ton 1 …), erlebt man auf Kurzwelle sein blaues Wunder. Angenommen, der Empfänger liest wegen Fading oder Doppler statt Ton 3 den Nachbarton 4. Binär springt der Wert von 011 auf 100, und damit sind alle drei Bits gleichzeitig falsch, obwohl der Messfehler nur 6,25 Hz betrug.

Die Lösung heißt Gray-Code. Darin unterscheiden sich benachbarte Werte immer in genau einem Bit:

Binär (riskant):
  Ton 3 = 011  →  Ton 4 = 100
  ⇒ 3 Bitfehler

Gray (sicher):
  Ton 3 = 010  →  Ton 4 = 110
  ⇒ 1 Bitfehler

Die Zuordnung in WSJT-X:

Dreiergruppe	Dezimal	Ton	Frequenz
`000`	0	0	f₀
`001`	1	1	f₀ + 6,25 Hz
`011`	3	2	f₀ + 12,50 Hz
`010`	2	3	f₀ + 18,75 Hz
`110`	6	4	f₀ + 25,00 Hz
`100`	4	5	f₀ + 31,25 Hz
`101`	5	6	f₀ + 37,50 Hz
`111`	7	7	f₀ + 43,75 Hz

Verwechselt der Empfänger Ton 4 (110) mit Ton 5 (100), ist nur das mittlere Bit falsch. So einen Einzelkratzer bügelt der LDPC-Decoder nebenbei aus.

4.2 Costas-Arrays: Leuchttürme im Rauschen

4.2.1 Was ein Costas-Array kann

Der beste Decoder nützt nichts, wenn der Empfänger im Rauschen nicht weiß, wann ein Signal anfängt und auf welcher Frequenz es genau liegt. Zwischen Sender und Empfänger gibt es keinen gemeinsamen Takt, und die Quarze zweier Transceiver weichen gern ein paar Hertz voneinander ab.

Taylor und Franke haben dafür in die Werkzeugkiste der Radartechnik gegriffen: Costas-Arrays, benannt nach John P. Costas. Ein Costas-Array ist eine N × N-Anordnung mit genau einem Punkt pro Zeile und Spalte, die so gewählt ist, dass sich das Muster nur an genau einer Stelle mit sich selbst deckt. Verschiebt man es in Zeit oder Frequenz auch nur um einen Schritt, überlappen sich höchstens noch einzelne Punkte. Für den Empfänger heißt das: Es gibt genau eine Position, an der das Muster wirklich passt, und die sticht deutlich heraus.

Im Notebook Background.ipynb von VK3JPK kannst du dieser Eigenschaft beim Rechnen zuschauen. FT8 nutzt ein Costas-Array der Ordnung 7 mit der Tonfolge:

$$\mathbf{S}_{\text{Costas}} = [3, 1, 4, 0, 6, 5, 2]$$

4.2.2 Dreifach eingebaut: Anfang, Mitte, Ende

Ein einziges Synchronisationsmuster am Anfang wäre anfällig: Ein Knacks zur falschen Zeit, und es ist weg. FT8 teilt die 58 Datensymbole deshalb in zwei Hälften zu je 29 und baut das Costas-Muster dreimal ein:

$$7 + 29 + 7 + 29 + 7 = 79 \text{ Symbole}$$

Durch dieses Sandwich kann die Software Zeit und Frequenz auch dann noch bestimmen, wenn Anfang oder Ende der Sendung gestört sind. 21 der 79 Symbole tragen also keine Daten. Ihr einziger Job: gefunden werden.

Früher musstest du dein Rufzeichen regelmäßig selbst nennen, damit man weiß, wer da sendet. FT8 erledigt das nebenbei, denn in fast jeder Nachricht steckt das Rufzeichen. Die Costas-Muster obendrauf, alle 5,76 Sekunden, beantworten eine andere Frage. Die lautet „sendet hier überhaupt jemand?“.

4.3 Vom Symbol zur NF-Frequenz

4.3.1 Die Rechnung

Liegt die Folge aus 79 Symbolen vor (21 Costas-Symbole und 58 Datensymbole), wird jedes Symbol Sₙ (Wert 0 bis 7) in eine Audiofrequenz umgerechnet:

$$f_n = f_0 + S_n \times 6{,}25 \text{ Hz}$$

f₀ ist die Frequenz, die du im Wasserfall anklickst, zum Beispiel 1000 Hz.

Die ersten sieben Töne von CQ DL6LG JO60 bei f₀ = 1000 Hz sind das erste Costas-Array. Die Zeitangaben zählen ab Sendebeginn (also ab Sekunde 0,50 im Intervall):

Symbol	Costas-Ton	Rechnung	Frequenz	Zeit ab Sendebeginn
0	3	1000 Hz + 3 × 6,25 Hz	1018,75 Hz	0,00–0,16 s
1	1	1000 Hz + 1 × 6,25 Hz	1006,25 Hz	0,16–0,32 s
2	4	1000 Hz + 4 × 6,25 Hz	1025,00 Hz	0,32–0,48 s
3	0	1000 Hz + 0 × 6,25 Hz	1000,00 Hz	0,48–0,64 s
4	6	1000 Hz + 6 × 6,25 Hz	1037,50 Hz	0,64–0,80 s
5	5	1000 Hz + 5 × 6,25 Hz	1031,25 Hz	0,80–0,96 s
6	2	1000 Hz + 2 × 6,25 Hz	1012,50 Hz	0,96–1,12 s

Danach folgen die 29 Datensymbole des ersten Datenblocks.

4.3.2 Die Sendung im Zeitraster

Damit schließt sich der Kreis zu Kapitel 1: 79 Symbole à 0,160 s ergeben 12,64 Sekunden. Die NF geht über die Soundkarte an den Transceiver. Ab Sekunde 0,50 wird die Amplitude mit der 20-ms-Rampe hochgefahren, dann laufen die Töne phasenkontinuierlich durch, und um Sekunde 13,14 wird sanft abgeblendet. Ab hier ist der Empfänger dran.

5 Empfang und Decodierung in WSJT-X

Jetzt drehen wir den Spieß um. Wir verfolgen, wie WSJT-X aus 15 Sekunden Rauschen Kandidaten fischt, sie ins Basisband holt, aus den Tönen Bitwahrscheinlichkeiten macht und am Ende mit mehreren Decodern und ein paar cleveren Tricks die Nachricht wiederherstellt.

5.1 Spektralanalyse: die Trüffelsuche

5.1.1 12 kHz Abtastrate und Spektrogramm

Nach dem Intervall liegt im Speicher nur ein rauschendes Audiosignal. Im Lautsprecher klingt das wie eine undichte Dampfheizung. Wie ein FT8-Signal klingt und im Wasserfall aussieht, wenn es stark genug ist, kannst du dir im Signal Identification Wiki anhören. Für WSJT-X beginnt jetzt die eigentliche Arbeit.

12 kHz: Egal, womit die Soundkarte arbeitet, WSJT-X rechnet intern mit 12.000 Abtastwerten pro Sekunde. Ein 15-Sekunden-Puffer enthält damit 15 × 12.000 = 180.000 reelle Abtastwerte.
Spektrogramm: Eine Folge überlappender FFTs überführt das Signal vom Zeit- in den Frequenzbereich. Die Zeitschritte betragen ein Viertel Symboldauer (T/4 = 40 ms, also 25 Spektren pro Sekunde), die Frequenzauflösung 3,125 Hz. Das ist der halbe Tonabstand, so fällt kein Ton durchs Raster.
Rauschgrund: Damit WSJT-X später zu jedem Signal einen Rauschabstand (bezogen auf 2500 Hz) angeben kann, ermittelt die Software die Rauschkurve des Empfängers. Dazu wird das Spektrum in Abschnitte geteilt, in jedem Abschnitt ein niedriges Perzentil der Energie als Rauschwert genommen und eine glatte Kurve hindurchgelegt.

5.1.2 Kandidatensuche mit dem Costas-Muster

Das Spektrogramm verrät noch nicht, wo echte FT8-Signale liegen und wo nur die Schaltnetzteile der Nachbarschaft brummen. Jetzt zahlen sich die Costas-Arrays aus Kapitel 4 aus. Die ganze Empfangskette dieses Kapitels, von der Kandidatensuche bis zum LDPC-Decoder, spielt das Notebook Receive.ipynb von VK3JPK in Python durch.

WSJT-X schiebt das bekannte Costas-Muster schrittweise über den eingestellten NF-Bereich, in Frequenz und in Zeit:

Zeit: Gesucht wird in einem Fenster von etwa ±2,5 Sekunden um den erwarteten Startzeitpunkt. Das fängt Uhrenabweichungen auf beiden Seiten ab.
Korrelation: An jeder Position summiert die Software die Energie an den Stellen, an denen das Costas-Muster einen Ton hätte, für alle drei Arrays.

Wo die Summe deutlich aus dem Rauschen ragt, gibt es einen Kandidaten mit vorläufiger Frequenz f₀ und Zeitversatz DT.

5.1.3 Der Schnelltest

Auf einem vollen Band spuckt die Korrelation schnell über hundert Kandidaten aus. Damit der Rechner nicht an jedem Rauschzipfel die teure Decodierung anwirft, gibt es einen schnellen Vortest: Für die 21 Costas-Symbole wird jeweils der stärkste Ton bestimmt. Nur wenn mindestens 7 der 21 mit dem Sollmuster übereinstimmen, darf der Kandidat weiter. Alle anderen fliegen als Rauschen raus.

5.2 Demodulation: vom Ton zur Bitwahrscheinlichkeit

5.2.1 Ausschneiden und ins Basisband mischen

Hat ein Kandidat den Vortest bestanden, schneidet WSJT-X ihn aus dem Gesamtspektrum heraus:

Gesamtspektrum
   │
   ▼
[ Ausschnitt 62,5 Hz ]
   │
   ▼
[ Tukey-Fenster ]
   │
   ▼
[ Basisband: Ton 0 bei 0 Hz ]

Ausschnitt von 62,5 Hz: Das sind zehn Tonabstände, genug für die acht Töne mit etwas Luft nach unten und oben.
Tukey-Fenster: Damit an den Schnittkanten keine Rechenartefakte entstehen, werden die Ränder des Ausschnitts sanft auf null heruntergezogen.
Mischen ins Basisband: Der Ausschnitt wird so verschoben, dass Ton 0 genau bei 0 Hz liegt. Die übrigen Töne sitzen dann bei 6,25 Hz, 12,50 Hz und so weiter bis 43,75 Hz.
Zurück in den Zeitbereich: Eine inverse FFT liefert ein komplexes Signal mit nur noch 200 Abtastwerten pro Sekunde. Bei 0,160 s Symboldauer sind das genau 32 Abtastwerte pro Symbol.

In diesem schlanken Signal werden Zeit und Frequenz anhand der Costas-Arrays noch einmal fein nachjustiert.

5.2.2 Block-Detektion über mehrere Symbole

Fading und Phasenschwankungen machen Kurzwellensignale unruhig. Wer jeden Ton einzeln auswertet, verliert bei schwachen Signalen schnell den Faden. WSJT-X nutzt deshalb nichtkohärente Block-Detektion über mehrere Symbole:

Statt einzelner Töne werden Blöcke aus 1, 2 und 3 aufeinanderfolgenden Symbolen gemeinsam gegen alle möglichen Tonfolgen getestet.
Bei drei Symbolen und acht Tönen sind das 8³ = 512 Kombinationen.
Ausgewertet wird nur der Betrag der Korrelation, die Phase spielt keine Rolle. Daher „nichtkohärent“.

Laut dem QEX-Artikel bringt das rund ein Dezibel zusätzliche Empfindlichkeit.

5.2.3 Weiche Entscheidungen: Log-Likelihood Ratios

Ein Kardinalfehler einfacher Decoder ist es, sich zu früh festzulegen: Bit ist 0 oder 1, fertig (harte Entscheidung). FT8 behält diese Information und rechnet mit weichen Entscheidungen in Form von Log-Likelihood Ratios (LLR).

Für jede der 174 Bitpositionen j wird ein Wert Lⱼ berechnet. Vereinfacht: der beste Korrelationswert aller Tonfolgen, in denen das Bit 1 ist, minus der beste Wert aller Tonfolgen, in denen es 0 ist:

$$L_j = K \cdot \left( \max_{i: x_j=1} |C_i| – \max_{i: x_j=0} |C_i| \right)$$

So liest sich ein LLR-Wert:

Stark positiv (etwa +5): „Das ist ziemlich sicher eine 1.“
Stark negativ (etwa −5): „Das ist ziemlich sicher eine 0.“
Nahe null: „Hier hat das Rauschen zugeschlagen. Rechne du das bitte aus.“

Diese 174 weichen Werte sind das Futter für den eigentlichen Decoder.

5.3 Decodierung: das große Finale

Der Empfänger hat jetzt 174 verrauschte Wahrscheinlichkeiten und muss daraus die 77 Nutzbits zurückgewinnen. Für jeden Kandidaten probiert WSJT-X dafür nacheinander mehrere Verfahren, und über das ganze Band läuft das in mehreren Durchgängen:

5.3.1 Belief Propagation: die Gleichungen verhandeln

Der erste Decoder ist Belief Propagation (BP), auch Sum-Product-Algorithmus genannt. Er arbeitet auf dem Faktorgraphen des LDPC-Codes: auf der einen Seite 174 Variablenknoten (die Bits), auf der anderen 83 Prüfknoten (die Paritätsgleichungen), verbunden überall dort, wo die Prüfmatrix eine Eins hat.

Die Knoten tauschen in mehreren Runden Nachrichten aus. Ein Prüfknoten meldet sinngemäß: „Laut den anderen Bits in meiner Gleichung solltest du eher eine 1 sein, Bit 5.“ Die Bits aktualisieren daraufhin ihre Einschätzung und schicken sie zurück. Sobald alle 83 Gleichungen erfüllt sind, hat der Decoder ein gültiges Codewort gefunden und hört auf. Klappt das nach einer festen Höchstzahl von Runden nicht, gibt er auf. Bei Signalen mit ordentlichem Rauschabstand ist BP schnell und meistens erfolgreich.

5.3.2 Ordered Statistics Decoding: der Plan B

Scheitert BP, weil das Signal zu schwach ist, kommt der zweite Decoder zum Zug: Ordered Statistics Decoding (OSD).

Sortieren: OSD sortiert die 174 Bits nach dem Betrag ihres LLR-Werts. Die sichersten kommen nach vorn.
Gleichungssystem lösen: Aus den sichersten Bits werden 91 voneinander unabhängige ausgewählt. Per Gauß-Elimination lässt sich daraus ein vollständiges Codewort berechnen.
Probieren: Weil auch unter den „sicheren“ Bits einzelne falsch sein können, kippt OSD versuchsweise einige der am wenigsten sicheren davon um und prüft jeweils, welches Codewort am besten zu den empfangenen Werten passt.

OSD ist rechenintensiver, holt aber noch einmal spürbar Empfindlichkeit heraus. Erst das Gespann aus BP und OSD bringt FT8 auf die rund −21 dB.

5.3.3 A-priori-Decodierung: Wenn das Programm den Satz schon ahnt

Als wäre das nicht genug, nutzt WSJT-X im laufenden QSO ein Verfahren, das man fast als Schummeln bezeichnen könnte: die A-priori-Decodierung (AP).

Angenommen, du hast PA9XYZ angerufen und wartest auf die Antwort. Dann weiß deine Software schon eine Menge:

dein eigenes Rufzeichen (28 Bits),
das Rufzeichen von PA9XYZ (28 Bits),
den erwarteten Nachrichtentyp und einige Einzel-Bits.

|<------------ 77 Bits ------------>|
[ bekannt: gut 60   ][ unbekannt   ]
  beide Rufzeichen,    Rapport,
  Typ, Flags           gut 15 Bits

Diese bekannten Bits setzt der Decoder versuchsweise fest. Statt 77 Bits muss er nur noch den Rest aus dem Nebel ziehen. Das senkt die Decodierschwelle um mehrere Dezibel, und Decodes um −24 dB sind damit möglich. Erwartet die Software eine ganz bestimmte Nachricht wie RR73, ist sogar der komplette Inhalt vorgegeben, und es wird nur noch geprüft, ob das Signal dazu passt.

Der Preis: Wer rät, liegt auch mal daneben. AP-Decodes haben ein etwas höheres Risiko für Falschmeldungen. WSJT-X kennzeichnet sie deshalb in der Decodierliste mit a1, a2 usw. (das Handbuch erklärt die Kürzel) und hängt bei geringer Sicherheit ein Fragezeichen an.

Ehrlich gesagt ist das hochwissenschaftliches Rätselraten: Das Programm errät rund drei Viertel der Nachricht vorab und prüft nur noch, ob der Rest dazupasst. Im Pileup bringt es dir trotzdem die begehrte Bestätigung.

5.3.4 Abziehen und nochmal: subtraktive Mehrfach-Decodierung

Was passiert, wenn zwei Stationen fast auf derselben Frequenz senden und sich im Wasserfall überlappen? Ältere Digimodes lieferten dann Kauderwelsch. WSJT-X arbeitet mit schrittweiser Signalsubtraktion (Successive Interference Cancellation):

Erster Durchgang: Das stärkere Signal A wird decodiert.
Synthese: Aus der decodierten Nachricht wird die Wellenform von A exakt nachgebaut.
Subtraktion: A wird aus dem 15-Sekunden-Puffer herausgerechnet.
Zweiter Durchgang: Das bisher verdeckte, schwächere Signal B wird sichtbar und decodierbar.

Je nach eingestellter Decodiertiefe macht WSJT-X mehrere solcher Durchgänge. So lassen sich oft auch Signale trennen, die sich teilweise überlappen. Ganz zauberhaft ist es nicht: Liegen zwei ähnlich starke Signale exakt aufeinander, hat auch WSJT-X schlechte Karten.

5.3.5 CRC-Prüfung und Entpacken

Hat einer der Decoder ein Codewort gefunden, tritt wieder der CRC-14-Türsteher aus Kapitel 3 auf den Plan:

Die Prüfsumme über die 77 Nutzbits wird neu berechnet.
Stimmt sie mit den empfangenen 14 CRC-Bits überein, ist der Decode gültig.
Entpacken: Die 77 Bits werden mit den umgekehrten Formeln aus Kapitel 2 in Text zurückverwandelt. Aus 109.720.681 wird wieder DL6LG, aus 17.660 wieder JO60.

Kurz nach Ende des Intervalls erscheint dann die Zeile, für die der ganze Aufwand getrieben wurde:

135515 -12  0.4 1000 ~  CQ DL6LG JO60

Uhrzeit (13:55:15 UTC), Rauschabstand (−12 dB), Zeitversatz (0,4 s), NF-Frequenz (1000 Hz), die Tilde ~ als Kennung für FT8 und die Nachricht. Zwölf Sekunden Rauschen, eine Zeile Text. Und ich kann dir sagen: Wenn man einmal weiß, was dahintersteckt, schaut man auf diese grüne Zeile mit deutlich mehr Respekt.

Hier klicken, um den Inhalt von Spotify anzuzeigen.
Erfahre mehr in der Datenschutzerklärung von Spotify (öffnet in neuem Tab).

Inhalt von Spotify immer anzeigen