FT8-Decoder-Einstellungen verstehen
in WSJT-X 3.1 improved

JTDX hat schon lange hilfreiche Erklärungen dazu angeboten, wie seine Decoder-Einstellungen funktionieren. Diese Leitfäden waren stets wertvoll, weil sie einen wichtigen Punkt sehr deutlich machen:

Das ist das zentrale Prinzip.

Aber im Jahr 2026, wenn der Fokus auf Leistung beim FT8/FT4-Betrieb liegt, hat sich die Diskussion verändert.

WSJT-X 3.1 improved ist nicht mehr bloß „Standard-WSJT-X mit ein paar zusätzlichen Funktionen.“ Eine beträchtliche Menge an praxisorientierten Decoder-Konzepten — einschließlich Ideen, die JTDX-Nutzern sehr vertraut vorkommen werden — wurde hier sinnvoll integriert. Zu diesem Zeitpunkt ist ein beiläufiger Vergleich mit WSJT-X 2.7 oder älteren Versionen ehrlich gesagt nicht mehr sehr aufschlussreich.

Um es noch direkter zu sagen: Für den durchschnittlichen Funker sollte WSJT-X 3.1 improved heute sehr ernsthaft als erste Wahl betrachtet werden.

Auf das nächste GA-Release von JTDX zu warten ist natürlich eine mögliche Haltung. Aber wenn die Priorität praktische Decoder-Leistung, verfügbare Funktionen, Update-Aktivität und das ist, was man heute tatsächlich installieren und nutzen kann, dann ist es der rationalere Weg, das zu nutzen, was bereits vorhanden und bereits leistungsfähig ist.

Das bedeutet nicht, dass JTDX keinen Platz hat. Wer der JTDX-Oberfläche eng verbunden ist, hat dafür einen vollkommen nachvollziehbaren Grund. Aber das ist eine andere Frage als Decoder-Leistungsfähigkeit und praktische Optimierung.

Dieser Artikel soll nicht einfach eine weitere Liste empfohlener Einstellungen sein. Stattdessen möchte ich eine tiefere Frage untersuchen:

Was bedeutet FT8-Decoder-Optimierung eigentlich?
Und konkreter: Was bewirkt die „Decode Start“-Einstellung in WSJT-X 3.1 improved wirklich?

Das praktische Fazit vorweg

Beginnen Sie mit Normal. Probieren Sie 3-Stage, wenn Ihre CPU-Reserven ausreichen. Nutzen Sie Early, wenn Zeitreserve wichtiger ist.

Lassen Sie mich mit dem praktischen Fazit beginnen.

Die wichtigste Regel beim FT8-Decoder-Tuning lautet nicht:

„Verwenden Sie die rechenintensivsten verfügbaren Einstellungen.“

Sondern:

„Verwenden Sie die aggressivsten Einstellungen, die Ihr System innerhalb des 15-Sekunden-Zyklus zuverlässig beenden kann.“

Das ist eine völlig andere Denkweise.

Als Ausgangspunkt ist für viele Stationen etwa Folgendes sinnvoll:

Das ist nicht unbedingt die endgültige Antwort, aber ein solider Ausgangspunkt. Von dort aus können Sie aggressiver vorgehen, wenn Ihre CPU Kapazitätsreserven hat. Wenn Sie Verzögerungen, spätes Beenden oder Instabilität bemerken, gehen Sie einen Schritt zurück.

Was Decode Start betrifft, eine praktische Zusammenfassung:

Das ist die praktische Zusammenfassung. Aber der Grund, warum diese Einstellung wichtig ist, ist interessanter als die Zusammenfassung allein vermuten lässt.

Decode Start ist nicht bloß eine „früher oder später starten“-Präferenz. Es ist eng damit verbunden, wie viele Stufen der Decoder verwendet, wo diese Stufen zeitlich platziert sind und wie der Dekodieraufwand über den FT8-Zyklus verteilt wird.

Das ist der eigentliche Kern der Sache.

Warum WSJT-X 3.1 improved jetzt ernsthafte Beachtung verdient

Um zu verstehen, warum das wichtig ist, hilft es, einen Schritt zurückzutreten und das große Bild zu betrachten.

In den letzten Jahren ist WSJT-X improved weit mehr als ein Seitenzweig mit zusätzlichen Optionen geworden. Es hat sich zu einer praktischen Plattform für reale Decoder-Ideen, UI-Flexibilität und betriebsorientierte Verbesserungen entwickelt.

Wenn man Zeit mit aktuellen improved-Builds verbringt, wird eines offensichtlich:

Die alte Frage „Wie schneidet das im Vergleich zu Standard-WSJT-X 2.7 ab?“ ist nicht mehr die nützlichste.

Die relevanteren Fragen lauten jetzt:

• Wie gut ist WSJT-X 3.1 improved heute als praktisches FT8/FT4-Betriebswerkzeug?
• Inwieweit wurden dabei realistische Decoder-Konzepte berücksichtigt?
• Und wie sollte ein Funkamateur es für seine eigene Station, CPU und Betriebsprioriäten einstellen?

Deshalb geht es in diesem Artikel nicht primär um Vergleichstabellen. Es geht darum, die Software intelligent zu nutzen.

Und sobald die Diskussion von „welche Einstellungen gibt es?“ zu „wie sollten sie verwendet werden?“ wechselt, wird es notwendig, zu fragen, was diese Einstellungen tatsächlich bedeuten innerhalb eines 15-Sekunden-FT8-Zyklus.

Die Rolle jeder Einstellung

„Aggressiver“ bedeutet nicht automatisch „besser“

Bevor wir uns auf Decode Start konzentrieren, lohnt es sich zu klären, wie FT8-Decoder-Einstellungen im Allgemeinen verstanden werden sollten.

Ein sehr häufiges Missverständnis ist folgendes:

Rechenintensivere Einstellungen müssen bessere Leistung bedeuten.

Das klingt plausibel, aber FT8 funktioniert so nicht.

Da FT8 in 15-Sekunden-Zyklen läuft, kommt es wirklich auf eine Balance zwischen vier Dingen an:

1. Wie viel Signal Sie vor dem Dekodieren abwarten
2. Wie tief Sie nach Kandidatennachrichten suchen
3. Ob die Decodierung rechtzeitig abgeschlossen wird
4. Wie viele Falschdecodierungen Sie zu tolerieren bereit sind

So betrachtet geht es bei der FT8-Optimierung nicht um „maximale Leistung.“ Es geht darum, begrenzte Rechenzeit sinnvoll aufzuteilen.

Diese Perspektive verändert den Blick auf jede einzelne Einstellung.

Anzahl der Threads

Für die meisten Funkamateure ist Auto immer noch der beste Ausgangspunkt. Mehr Threads zu erzwingen garantiert kein besseres Ergebnis. OS-Scheduling, Hintergrundlast, Core-Topologie und das allgemeine Systemverhalten spielen alle eine Rolle.

Anzahl der Dekodierdurchläufe

Mehr Durchläufe können die Chance erhöhen, schwächere oder mehrdeutigere Signale zu decodieren. Aber sie kosten auch CPU-Zeit. Wenn Ihr System leistungsstark ist, können 3 Durchläufe sinnvoll sein. Für viele Stationen ist 2 die vernünftigste Standardeinstellung. Bei begrenzter Hardware kann 1 die sicherere Wahl sein.

Decoder-Empfindlichkeit

Eine praktische Lesart ist unkompliziert:

• Minimum ist schneller
• Low thresholds ist ausgewogen
• Subpass ist aggressiver, aber CPU-intensiver

Subpass ist keine kostenlose Leistungssteigerung. Es bedeutet zusätzliche Arbeit für die CPU, um schwächere oder schwierigere Signale empfangen zu können.

Hinweis zu Fast / Normal / Deep und dem Multithreaded FT8-Decoder

Das ist ein Teil, der besonders leicht missverstanden wird. Da Fast / Normal / Deep in der selben Dropdown-Liste wie der Multithreaded FT8-Decoder erscheint, liegt es nahe anzunehmen, dass es sich nur um verschiedene Einstellungen desselben Reglers handelt. Aber der Quellcode legt nahe, dass sie nicht dieselbe Art von Einstellung sind.

Zunächst ist Fast / Normal / Deep die traditionelle Dekodiertiefe-Einstellung: Mit anderen Worten, eine Möglichkeit, dem Decoder mitzuteilen, wie tief er suchen soll. Im herkömmlichen Single-Threaded FT8-Dekodierpfad ist diese Tiefeneinstellung direkt damit verbunden, wie rechenintensiv die Dekodierung wird und wie aggressiv die Suche verfolgt wird.

Der Multithreaded FT8-Decoder hingegen ist eine völlig andere Sache. Es ist grundsätzlich eine Frage, welche Decoder-Engine-Familie verwendet wird. Im Code werden Dekodiertiefe und Multithreaded FT8 als separate Parameter behandelt, nicht als zwei Namen für dieselbe Sache.

Die wichtige Nuance folgt jetzt. Wenn FT8 tatsächlich mit aktiviertem Multithreaded-Decoder läuft, so tritt das Programm in einen dedizierten MTD-Pfad ein, anstatt den älteren herkömmlichen FT8-Dekodierpfad zu nutzen. In diesem Pfad sind die Einstellungen, die das Decoder-Verhalten wirklich steuern, die MTD-spezifischen — nicht die alten Fast / Normal / Deep-Stufen:

• Decoder-Empfindlichkeit
• Decode Start
• Anzahl der Dekodierdurchläufe
• QSO Rx Frequenzempfindlichkeit

Die genaueste Art, darüber nachzudenken, ist also: Fast / Normal / Deep existiert weiterhin und gehört nach wie vor zur allgemeinen Dekodiertiefe-Logik des Programms, aber im FT8-MTD-Betrieb ist es nicht der primäre Regler, der bestimmt, wie aggressiv der Decoder sich verhält. Beim praktischen Tuning sind die wirklich wichtigen Regler die MTD-orientierten — insbesondere Decoder-Empfindlichkeit, Decode Start, Anzahl der Dekodierdurchläufe und QSO Rx Frequenzempfindlichkeit.

Mit anderen Worten: Wenn Sie WSJT-X 3.1 improved für FT8 mit aktiviertem Multithreaded-Decoder ernsthaft optimieren möchten, ist es besser, in Begriffen von MTD-spezifischen Verhaltensreglern zu denken, anstatt davon auszugehen, dass die Einstellungen Fast / Normal / Deep weiterhin den Decoder-Charakter maßgeblich bestimmen. Die alte Tiefeneinstellung ist immer noch Teil des Designs; sie ist einfach nicht mehr der wichtigste praktische Hebel, sobald man sich im FT8 MTD-Pfad befindet.

QSO Rx Frequenzempfindlichkeit

Das ist nicht bloß eine Geschwindigkeitseinstellung. Es beeinflusst, wie aggressiv der Decoder die Aktivität rund um den QSO-bezogenen Frequenzbereich und nahe Kandidaten untersucht.

• Low ist konservativ
• Medium ist ausgewogen
• High ist aggressiv

Und wie erwartet kann größere Aggressivität auch mehr fragwürdige Kandidaten und mehr Dekodierungsrauschen bringen.

Falschdecodierungen reduzieren

Dieser Punkt verdient mehr Aufmerksamkeit, als ihm oft zuteilwird. Mehr zu finden ist nicht automatisch besser, wenn die zusätzlichen Ergebnisse zunehmend unzuverlässig werden. Auf überfüllten Bändern und unter mehrdeutigen Bedingungen ist die Kontrolle von Falsch­deco­dierungen sehr wichtig.

Zusammengenommen konkurrieren diese Einstellungen nicht isoliert darum, welche „stärker“ ist. Jede von ihnen drückt eine andere Antwort auf dieselbe zugrunde liegende Frage aus:

Was sollte der Decoder innerhalb eines sehr begrenzten 15-Sekunden-Fensters priorisieren?

Und unter allen ist Decode Start eines der klarsten und aufschlussreichsten Beispiele.

Die Hauptfrage

Was bewirkt „Decode Start“ wirklich?

Hier wird es wirklich interessant.

In der Benutzeroberfläche bietet Decode Start fünf Optionen:

• 2-Stage
• 3-Stage
• Early
• Normal
• Late

Auf den ersten Blick sieht das wie eine einfache Timing-Steuerung aus:

Beginne mit der Dekodierung früher, oder beginne mit der Dekodierung später.

Aber das ist nicht die ganze Geschichte.

Betrachtet man die tatsächliche WSJT-X 3.1 improved-Implementierung, werden diese Modi intern als Folgendes behandelt:

• 0 = 2-Stage
• 1 = 3-Stage
• 2 = Early
• 3 = Normal
• 4 = Late

Und während des FT8-Betriebs verwendet das Programm Werte wie m_hsymStop, m_earlyDecode, and m_earlyDecode2 um zu bestimmen, wann Dekodierstufen ausgelöst werden.

Das zeigt uns sofort:

Zur besseren Übersicht beginnen wir mit den drei einfacheren Modi — Early, Normal und Late — bevor wir zu den aufschlussreicheren 2-Stage- und 3-Stage-Modi übergehen.

Early / Normal / Late

Zuerst die einfacheren drei Modi

Fangen wir mit den einfacheren Optionen an.

Wenn der Multithreaded FT8-Decoder aktiviert ist, liegen die internen Stopppunkte ungefähr bei:

• Early → 48
• Normal → 49
• Late → 50

Zeitlich ausgedrückt entspricht das ungefähr:

• Early → etwa 13,8 Sekunden
• Normal → etwa 14,1 Sekunden
• Late → etwa 14,4 Sekunden

Die grundlegende Bedeutung ist intuitiv:

• Early gibt etwas Signalsammlung auf für mehr CPU-Spielraum
• Late wartet länger, um etwas mehr Information vor dem Dekodieren zu sammeln
• Normal liegt in der Mitte

Wenn Decode Start nur aus diesen drei Modi bestünde, wäre es immer noch eine nützliche Einstellung — aber keine besonders ungewöhnliche.

Was das Feature viel interessanter macht, ist das, was als nächstes kommt:

2-Stage und 3-Stage.

Zusätzliche technische Anmerkung

Was 2-Stage und 3-Stage wirklich sind

Nicht bloß „früher“ oder „später“, sondern eine stufenweise Dekodierungsstrategie, die STD und MTD kombiniert

Das WSJT-X improved-Änderungsprotokoll beschreibt die 2-Stage- und 3-Stage-Modi als solche, die „beide Decoder intelligent kombinieren“. Dadurch ist es der bisher beste FT8-Dekodierer.

Mit anderen Worten präsentiert die Software sie explizit als eine Möglichkeit, den traditionellen STD-Decoder (Single-Threaded) und den neueren MTD-Decoder (Multithreaded) zu kombi­nieren.

Was das Änderungsprotokoll nicht erklärt, ist die genaue Ausführungsreihenfolge oder die Timing-Beziehung zwischen den beiden. Das wird erst klar, wenn man sich die Implemen­tierung ansieht.

Und einmal gesehen, wird offensichtlich, dass 2-Stage und 3-Stage nicht bloß unterschiedliche Startzeiten sind. Sie sind mehrstufige Dekodierungsstrategien, und die verschiedenen Stufen spielen nicht alle dieselbe Rolle.

Die Arbeitsteilung zwischen STD und MTD

Hier bezieht sich STD auf den traditionellen Single-Threaded FT8-Decoder. MTD bezieht sich auf den Multithreaded FT8-Decoder, der in der improved-Linie eingeführt wurde.

Betrachtet man die Implementierung, funktionieren die Stufenmodi ungefähr so:

• frühe Stufen verwenden STD
• die letzte Stufe verwendet MTD

Das ist die zentrale Design-Idee.

Mit anderen Worten ist das am besten als bewusste Trennung zwischen zu verstehen:

• einer frühen, einfacheren, schnelleren Decodierung
• und einem späteren, vollständigen Dekodierdurchlauf

Das ist eine sehr wichtige Unterscheidung.

Ein einfacheres Design hätte bis zum Ende des Empfangsintervalls gewartet und dann einen rechenintensiven Dekodierdurchlauf durchgeführt. WSJT-X improved macht das nicht. Stattdessen führt es zwischenzeitliche Kandidatensuchen vor der letzten Stufe durch und nimmt die endgültige Dekodierung erst später vor.

Das macht deutlich, dass das Design einem zentralen Problem große Aufmerksamkeit widmet:

Entwicklerperspektive: Wozu die STD-Vordekodierung wirklich dient

Laut Uwe Risse / DG2YCB ist diese STD-Vordekodierung nicht einfach nur ein zusätzlicher vorbereitender Dekodierdurchlauf. Seine wichtige Aufgabe besteht darin, den aus dem traditionellen STD-Decoder bekannten Vorteil des frühen Dekodierens auch in den MTD-Arbeitsablauf zu bringen.

Während der Entwicklung wurden verschiedene Kombinationen von STD und MTD sowie unterschiedliche nzhsym-Parameter ausprobiert. Die heutige Lösung — STD als Vordekodierung und MTD als finaler Hauptdurchlauf — lieferte dabei die besten praktischen Ergebnisse.

Das ist ein zentraler Punkt. 2-Stage und 3-Stage sind nicht einfach Mechanismen, um „den Decoder mehrfach laufen zu lassen“. Sie verbinden das leichte, frühe Dekodierverhalten von STD mit der vollständigeren finalen Dekodierleistung von MTD und nutzen so die knappe CPU-Zeit innerhalb des 15-Sekunden-FT8-Zyklus effektiver.

Uwe weist außerdem darauf hin, dass 2-Stage etwa 99,5 % der Dekodierausbeute von 3-Stage erreicht, dafür aber deutlich weniger Rechenleistung benötigt. Das erklärt, warum 2-Stage für die meisten Anwender die starke praktische Empfehlung ist, während 3-Stage die maximale Leistungsoption für sehr schnelle Rechner bleibt.

Was 2-Stage wirklich bedeutet

Hier ist eine wichtige Klarstellung nötig, weil der Name leicht zu falschen Annahmen führen kann. Beim Live-Dekodieren ist 2-Stage tatsächlich eine zweistufige Struktur.

Die Live-Sequenz ist:

1. eine frühe STD-Vordekodierung bei nzhsym=41
2. ein finaler MTD-Durchlauf bei nzhsym=49

Zeitlich ausgedrückt entspricht das ungefähr:

• STD-Vordekodierung: etwa 11,8 Sekunden
• finaler MTD-Durchlauf: etwa 14,1 Sekunden

Der entscheidende Punkt ist: Die zweite STD-Vordekodierung bei nzhsym=46 gehört nicht zu 2-Stage. Dieser zusätzliche Vorlauf wird nur bei 3-Stage ausgeführt.

2-Stage ist daher am besten als ausgewogener Modus zu verstehen: Es gibt eine frühe, leichte STD-Vordekodierung und danach die eigentliche finale MTD-Dekodierung bei Normal-ähnlichem Timing.

Das ist kein „bis zum Ende warten und alles auf einen einzigen Dekodierdurchlauf setzen“-Modus. Aber es ist auch nicht so rechenintensiv wie 3-Stage. Gerade deshalb ist 2-Stage für viele Anwender die praxisnähere Empfehlung. Laut Uwe Risse / DG2YCB erreicht 2-Stage etwa 99,5 % der Dekodierausbeute von 3-Stage, benötigt aber deutlich weniger Rechenleistung. Damit ist es ein sehr starker praktischer Kompromiss.

Dieses Design hat eine sehr klare praktische Bedeutung.

FT8 ist ein 15-Sekunden-Modus, und die verfügbare Verarbeitungszeit innerhalb jedes Zyklus ist begrenzt. Es kann deshalb sinnvoll sein, bereits vor dem finalen Moment einen frühen Kandidaten-Scan durchzuführen, ohne dabei so viel CPU-Zeit zu verbrauchen, dass die wichtige finale MTD-Dekodierung gefährdet wird.

Aus diesem Grund ist 2-Stage am besten als sehr praktischer Betriebsmodus für Situationen zu verstehen, in denen man möchte:

• bessere Reaktionsfähigkeit
• begrenzte zusätzliche CPU-Auslastung
• und eine geringere Chance, wiederherstellbare Signale zu verpassen

Was 3-Stage wirklich bedeutet

3-Stage erweitert 2-Stage um einen zusätzlichen STD-Vorlauf bei nzhsym=46 und verschiebt den finalen MTD-Durchlauf auf nzhsym=50.

Beim Live-Dekodieren lautet die Sequenz:

1. eine frühe STD-Vordekodierung bei nzhsym=41
2. eine zweite STD-Vordekodierung bei nzhsym=46
3. ein finaler MTD-Durchlauf bei nzhsym=50

Das ungefähre Timing ist:

• Stufe 1: etwa 11,8 Sekunden
• Stufe 2: etwa 13,2 Sekunden
• finaler MTD-Durchlauf: etwa 14,4 Sekunden

Im Vergleich zu 2-Stage fügt 3-Stage also tatsächlich einen zweiten STD-Vorlauf bei 46 hinzu und wartet bis 50, bevor der finale MTD-Durchlauf gestartet wird.

Die Absicht ist sehr deutlich:

• frühzeitig nach dem suchen, was bereits gefunden werden kann
• erneut suchen, wenn sich mehr Signal angesammelt hat
• dann die vollständige abschließende Dekodierung mit MTD am Ende durchführen

In diesem Sinne ist 3-Stage der ehrgeizigste Stufenmodus im Set. Er bietet die höchste FT8-Dekodierleistung, die WSJT-X 3.1 improved bereitstellen kann.

Allerdings ist dieser zusätzliche Gewinn nicht proportional zur zusätzlichen CPU-Last. Laut Uwe Risse / DG2YCB erreicht 2-Stage bereits etwa 99,5 % der Dekodierausbeute von 3-Stage. Der verbleibende Zusatzgewinn ist also klein im Vergleich zu der deutlich höheren benötigten Rechenleistung.

Auf schwächeren Rechnern kann der zusätzliche STD-Vorlauf bei nzhsym=46 zu lange dauern. Im ungünstigsten Fall ist er nicht rechtzeitig abgeschlossen, sodass der wichtigste finale MTD-Durchlauf bei nzhsym=50 nicht mehr ausgeführt werden kann. Deshalb ist 3-Stage vor allem ein Modus für leistungsstarke Rechner. Wer genügend CPU-Reserve hat, bekommt damit die maximale FT8-Dekodierleistung. Für die meisten Anwender ist 2-Stage jedoch der bessere Kompromiss aus Dekodierausbeute und CPU-Kosten.

Es sollte als „STD → MTD“ beziehungsweise „STD → STD → MTD“ verstanden werden, nicht als „MTD → STD“

Das ist einer der am leichtesten misszuverstehenden Punkte.

Da das Änderungsprotokoll besagt, dass 2-Stage und 3-Stage STD und MTD kombinieren, könnten sich einige Leser ein Modell wie dieses vorstellen:

• MTD läuft zuerst
• dann füllt STD auf, was MTD verpasst hat

Aber das ist nicht, was die Implementierung nahelegt.

Die genauere Interpretation ist die entgegengesetzte:

• STD führt die früheren, schnelleren Dekodierungen durch
• MTD führt die abschließende, komplexeren Dekodierung durch

Diese Unterscheidung ist wichtig.

Stellt man sich „MTD zuerst, STD später“ vor, klingt die Beziehung wie ein Rückfall- oder Reparaturschritt. Was der Code stattdessen nahelegt, ist ein viel eleganteres Modell:

• die schnellere Arbeit früher
• die schwerere Arbeit später

Das ist nicht nur eine Frage der Decoder-Reihenfolge. Es spiegelt eine sehr bewusste und sehr vernünftige Zeitverteilungsstrategie wider.

Warum überhaupt STD in den früheren Stufen verwenden?

Auch das ist aufschlussreich.

Wäre das Ziel einfach „den Decoder öfter ausführen“, würde man erwarten, dass die Software MTD wiederholt in jeder Stufe ausführt. Aber das ist nicht, was sie tut.

Ein wahrscheinlicher Grund ist unkompliziert:

Die früheren Stufen sollen einfach und schnell sein.

Zu diesen früheren Zeitpunkten ist der Empfang noch nicht abgeschlossen. Die verfügbare Informationsmenge ist noch geringer als sie in der letzten Stufe sein wird. Die komplexeste Dekodierlogik jedes Mal mit voller Stärke auszuführen, wäre nicht unbedingt die effizienteste Nutzung begrenzter CPU-Zeit.

Stattdessen verwendet die Software STD, um früher schnell und wirtschaftlich zu dekodieren, und spart MTD für den abschließenden und folgenreicheren Pass auf.

Das ist mehr als nur ein Implementierungsdetail. Es spiegelt eine Dekodierphilosophie wider, die sehr gut zu FT8 passt, da es sich dabei um eine kurze, stoßartige und zeitkritische Arbeitslast handelt.

Der Code legt auch nahe, dass frühere Stufen im Vergleich zur letzten Stufe eine etwas einge­schränkte Verarbeitung verwenden, was die Idee weiter unterstützt, dass diese Modi nicht nur wiederholte Durchläufe sind, sondern eine gestufte Progression, in der jeder Durchlauf eine andere Rolle hat.

Das Wesentliche von 2-Stage und 3-Stage ist die Zeitverteilung

Im Kern geht es bei 2-Stage und 3-Stage wirklich um eine Sache:

wie Rechenaufwand innerhalb eines 15-Sekunden-Zyklus zugeteilt wird.

• Sollte der Decoder früher dekodieren?
• Sollte er in der Mitte noch einmal dekodieren?
• Sollte er bis zum Ende warten, um den vollständigsten abschließenden Versuch zu unternehmen?

Das ist es, was die Stufenmodi entscheiden.

2-Stage und 3-Stage sollten also nicht als einfache Timing-Anpassungen betrachtet werden. Sie sind besser zu verstehen als verschiedene Arten, den FT8-Decoder über die Zeit zu entfalten.

Wie sollten sie im tatsächlichen Betrieb interpretiert werden?

In die Praxis umgesetzt, erweist sich diese Unterscheidung als sehr nützlich.

2-Stage

• erhält die Reaktionsfähigkeit recht gut
• fügt einen früheren Blick hinzu
• hält die letzte Stufe um das Normal-Timing
• verbessert die Wiederherstellung von Kandidaten ohne die CPU-Last auf Extreme zu treiben

Mit anderen Worten, es ist eine ausgewogene Stufenstrategie.

3-Stage

• dekodiert früh
• dekodiert erneut in der Mitte
• behält dennoch einen abschließenden MTD-Durchlauf zu einem Zeitpunkt gegen Ende bei
• setzt stärker auf die Reduzierung von Dekodierungsfehlern
• erhöht aber die CPU-Last entsprechend

3-Stage ist also der ehrgeizigste und aggressivste verfügbare Stufenmodus.

Wenn die CPU ausreichende Reserven hat, kann das äußerst attraktiv sein. Wenn die CPU jedoch bereits nahe an ihren Timing-Grenzen ist, dann zählt der theoretische Vorteil weniger als einfach sauber abzuschließen.

An diesem Punkt wird die Bedeutung dieser Modi viel klarer:

Noch ein wichtiger Punkt

Die Stufenmodi sind nicht nur „mehrfache Dekodierungen“; sie weisen verschiedenen Stufen unterschiedliche Rollen zu

Was 2-Stage und 3-Stage aus einer etwas weiteren Perspektive betrachtet so interessant macht, ist nicht bloß die Tatsache, dass sie die Dekodierung mehr als einmal auslösen.

Der tiefere Punkt ist, dass jede Stufe eine andere Rolle spielt.

• frühere Stufen sind einfacher und schneller
• die letzte Stufe ist umfassender
• CPU-Aufwand wird über den Zyklus verteilt, anstatt auf einmal aufgewendet zu werden

Das passt bemerkenswert gut zu FT8.

Im Prinzip könnte man bis zum Ende warten und dann eine einzige Entscheidung treffen. Aber es hat echten Wert, früher nach wiederherstellbaren Kandidaten zu suchen, dann das Problem später mit mehr Informationen und besserer Verarbeitung erneut anzugehen.

Deshalb geht es beim Verstehen der Stufenmodi nicht nur darum, eine Einstellung zu verstehen. Es geht wirklich darum, was FT8-Optimierung selbst bedeutet.

Praktische Interpretation

Wie sollte jeder Modus tatsächlich verwendet werden?

Nach den technischen Einzelheiten lohnt sich ein Blick auf die praktische Betriebsebene.

2-Stage

Sehr praktisch. Es erhält die Reaktionsfähigkeit und dekodiert dennoch früher. Die letzte Stufe ist nicht so spät wie Late, vermeidet also unnötig anspruchsvoll zu werden.

3-Stage

Der ehrgeizigste Modus — im guten Sinne.

Es dekodiert früh, dekodiert später erneut und hält dennoch an einem starken abschließenden Pass fest. Wenn CPU-Reserven vorhanden sind und die Reduzierung verpasster Dekodierungen Priorität hat, ist das eine der interessantesten Einstellungen im gesamten Panel.

Early

Das sollte nicht bloß als schwacher CPU-Rückfall abgetan werden. Es ist auch eine sehr rationale Stabilitätsstrategie. Wenn das Vermeiden von Überlauf in den nächsten Zyklus wichtiger ist als das Herausziehen jedes letzten Signalbits, kann Early genau die richtige Wahl sein.

Normal

Der Referenzpunkt. Für die meisten Benutzer sollte das Testen hier beginnen. Es erleichtert den Vergleich mit den anderen Modi erheblich.

Late

Länger warten, später dekodieren und die endgültige Entscheidung mit etwas mehr Informationen treffen. In der Theorie kann das helfen. In der Praxis ist es nur nützlich, wenn das System noch zuverlässig abschließt.

Zusammengenommen sollten die Decode Start-Modi nicht als „persönlicher Geschmack“ verstanden werden. Sie sind besser als verschiedene Zeitstrategien zu betrachten.

Was optimieren wir wirklich?

Nicht durchschnittliche Leistung, sondern die Nutzung der CPU-Zeit innerhalb des 15-Sekunden-Zyklus

An diesem Punkt sollte das größere Prinzip klar sein.

FT8-Optimierung geht nicht einfach darum, Dinge „leistungsfähiger“ zu machen.

Es gilt zu entscheiden:

• wie lange zu warten
• wie oft zu dekodieren
• wo schnellere Durchläufe zu machen sind
• wo der komplexe abschließende Durchlauf zu machen ist
• und ob der gesamte Prozess von Zyklus zu Zyklus stabil bleibt

Mit anderen Worten geht es wirklich darum, wie CPU-Leistung genutzt wird, nicht nur wie viel davon vorhanden ist.

Aus dieser Perspektive ist Decode Start eine der wichtigsten Einstellungen im gesamten Decoder-Panel. Was wie eine kleine UI-Option aussieht, ist in Wirklichkeit ein direkter Ausdruck von Zeitstrategie.

Aus diesem Grund geht es beim Verständnis von „Decode Start” um mehr als nur die Erklärung dieser Einstellungen. Es ist ein Ansatz, um die zugrunde liegende Philosophie der Rechenressourcenverteilung in FT8 zu verstehen.

Eine persönlichere Anmerkung

Warum ich das überhaupt schreibe

Bis zu diesem Punkt habe ich versucht, die Diskussion allgemein und technisch zu halten. Aber für den Kontext sollte ich meine eigene Position klarmachen.

Das liegt nicht daran, dass JTDX keinen Wert hat. Es liegt daran, dass Software auch danach beurteilt werden sollte, was praktisch verfügbar, reif genug zum Testen und jetzt nützlich ist.

Wenn jemand bei JTDX bleibt, weil er die Oberfläche wirklich bevorzugt, ist das völlig verständlich. Aber wenn es um heutige Decoder-Fähigkeit und praktischen Betriebswert geht, verdient WSJT-X 3.1 improved ernsthafte Aufmerksamkeit.

Meine eigene Betriebsphilosophie

Bisher habe ich mich auf allgemeine Prinzipien beschränkt. Aber es könnte nützlich sein zu erklären, wohin mein eigenes Denken in der Praxis führt.

Mein Haupt-PC verwendet einen Core i9-9900K. Dieses Detail ist wichtig — jedoch nicht allein deshalb, weil es eine vergleichsweise leistungsstarke CPU ist.

Entscheidend ist darüber hinaus, wie die Maschine konfiguriert ist.

In den Windows-Energieeinstellungen setze ich den minimalen Prozessorlast auf 100%. Mit anderen Worten, ich warte nicht darauf, dass die CPU die Taktrate nach dem Auftreten der Dekodierarbeitslast erhöht. Ich bevorzuge es, wenn sie bereits mit hoher Taktrate läuft — bereit und wartend. In meinem Fall läuft sie effektiv bei 4,7 GHz.

Der Grund ist einfach.

FT8-Dekodierung ist nicht wie langfristiges Video-Rendering, wo eine stetige Last über längere Zeiträume läuft. Sie ähnelt vielmehr einem kurzen, intensiven Arbeitsschub, der in vorhersehbaren Abständen wiederholt wird.

Bei dieser Art von Arbeitslast ist die durchschnittliche Benchmark-Leistung nicht die ganze Geschichte. Die initiale Reaktion zählt.

Wenn die CPU in einem niedrigeren Energiezustand sitzt, muss das System:

• die Last erkennen
• den Leistungszustand ändern
• Taktrate erhöhen
• Spannung anpassen
• und den Scheduler reagieren lassen

Diese Verzögerungen mögen bei langfristigen Arbeitslasten unbedeutend sein. Aber bei kurzen, zeitempfindlichen Arbeitsschüben können sie wichtiger sein, als die Leute erwarten.

Deshalb bin ich der Überzeugung:

Natürlich bringt diese Wahl Kompromisse mit sich.

• höherer Stromverbrauch
• mehr Wärme
• geringere Effizienz
• weniger Eleganz aus Energiesparsicht

Aber bei einem Stations-PC betrachte ich Dekodier-Reaktionsfähigkeit und Stabilität als wichtiger als elektrische „Aufgeräumtheit“.

Warum meine eigenen Einstellungen bewusst aggressiv sind

Weil 50 MHz mir wichtig ist

Meine Einstellungen spiegeln diese Philosophie ziemlich deutlich wider.

• Decoder Sensitivity: Subpass
• QSO Rx Frequency Sensitivity: High
• CPU bereits mit hoher Taktrate wartend

Das ist kein konservatives Setup, und ich tue nicht so, als wäre es das.

Aber es gibt einen Grund dafür:

50 MHz ist mir sehr wichtig.

Auf dem 6-Meter-Band:

• können sich die Bedingungen schnell ändern
• kann die Aktivität plötzlich ansteigen
• koexistieren oft schwache und starke Signale
• und eine kurze Öffnung kann verpasste Möglichkeiten besonders frustrierend machen

Deshalb bin ich bereit, CPU-Ressourcen aufzuwenden, um verpasste Dekodierungen zu reduzieren.

Deshalb verwende ich:

• Subpass, um tiefer zu suchen
• High-Empfindlichkeit, um aggressiver bei der Kandidatenerholung zu sein
• und eine Energiekonfiguration, die die CPU bereit hält, bevor die Burst-Auslastung einsetzt

Das ist nicht einfach „alles aufdrehen, weil mehr besser sein muss.“

Es ist eine bewusste Betriebsstrategie, aufgebaut auf:

• Betonung von 50 MHz
• ausreichend CPU-Reserven
• Wichtigkeit der Reaktionsgeschwindigkeit
• der Bereitschaft, Effizienz gegen Opportunität einzutauschen

Abschließende Gedanken

Die eigentliche Frage ist nicht „Welches Programm ist richtig?“, sondern „Welche Abstimmungs-Philosophie passt zu Ihrer Station?“

Wenn sich diese gesamte Abhandlung auf einen einzigen Satz verdichten ließe, wäre es dieser:

Aus dieser Perspektive betrachtet ist WSJT-X 3.1 improved ein sehr interessantes Stück Software. Nicht weil es bloß mehr Optionen bietet, sondern weil es dem Funkamateur eine sinnvolle Kontrolle über die Decoder-Zeitstrategie gibt.

Und Decode Start ist eines der deutlichsten Beispiele dafür.

2-Stage, 3-Stage, Early, Normal und Late sind nicht nur kosmetische Bezeichnungen. Sie repräsentieren verschiedene Arten, den Dekodieraufwand über den FT8-Zyklus zu verteilen.

Und wenn man die Stufenmodi genauer betrachtet, kann man darunter eine besonders elegante Idee erkennen:

Und abschließend möchte ich dies als jemand sagen, der JTDX aufrichtig schätzt:

Wenn Ihre Verbundenheit mit JTDX in seiner Oberfläche verwurzelt ist, ist das eine Sache. Aber wenn Ihre Sorge der heutigen Decoder-Fähigkeit unter realen Betriebsbedingungen gilt, gibt es wenig Grund zum Zögern.