De FT8-decoderinstellingen in WSJT-X 3.1 improved begrijpen

JTDX biedt al lange tijd nuttige uitleg over de werking van zijn decoderinstellingen. Die uitleg is altijd waardevol geweest, omdat zij één belangrijk punt zeer duidelijk maakt:

Dat is het kernprincipe.

Maar in 2026 is het gesprek veranderd als uw focus ligt op prestaties bij FT8/FT4.

WSJT-X 3.1 improved is niet langer slechts «standaard WSJT-X met een paar extra functies». Een aanzienlijk deel van praktisch decoderdenken — inclusief ideeën die JTDX-gebruikers zeer bekend zullen voorkomen — is er betekenisvol in verwerkt. Een losse vergelijking met WSJT-X 2.7 of ouder is daardoor eerlijk gezegd niet meer bijzonder informatief.

Korter gezegd: voor de gemiddelde operator verdient WSJT-X 3.1 improved het nu om zeer serieus als eerste keuze te worden overwogen.

Wachten op de volgende GA-versie van JTDX is uiteraard een mogelijke houding. Maar als praktische decoderprestaties, beschikbare functies, ontwikkelactiviteit en wat u vandaag daadwerkelijk kunt installeren en gebruiken vooropstaan, is het rationeler om te benutten wat er nu al is en al sterk presteert.

Dit betekent niet dat JTDX geen plaats meer heeft. Wie sterk aan de JTDX-interface gehecht is, heeft een volkomen geldige reden om erbij te blijven. Maar dat is een andere vraag dan decodercapaciteit en praktische optimalisatie.

Dit artikel is niet bedoeld als nog een lijst met aanbevolen instellingen. Ik wil juist een diepere vraag onderzoeken:

Wat betekent FT8-decoderoptimalisatie eigenlijk? En specifieker: wat doet de instelling «Decode Start» in WSJT-X 3.1 improved werkelijk?

Eerst de praktische conclusie

Begin met Normal. Probeer 3-Stage als uw CPU voldoende reserve heeft. Gebruik Early als timingmarge belangrijker is.

Laten we beginnen met de praktische conclusie.

De belangrijkste regel bij het afstellen van de FT8-decoder is niet:

«Gebruik de zwaarste beschikbare instellingen.»

Maar:

«Gebruik de agressiefste instellingen die uw systeem binnen de 15-seconden-cyclus betrouwbaar kan afronden.»

Dat is een heel andere manier van denken.

Als uitgangspunt is voor veel stations ongeveer het volgende verstandig:

Dat is niet per se het eindantwoord, maar wel een solide startpunt. Van daaruit kunt u agressiever gaan als de CPU reserve heeft. Ziet u vertraging, te late voltooiing of instabiliteit, dan doet u een stap terug.

Voor Decode Start is de praktische samenvatting:

Dat is de praktische samenvatting. Maar waarom deze instelling belangrijk is, is interessanter dan de samenvatting alleen doet vermoeden.

Decode Start is niet alleen een voorkeur voor «eerder of later beginnen». Het hangt nauw samen met het aantal decoderfasen, waar die fasen in de tijd liggen en hoe de decode-inspanning over de FT8-cyclus wordt verdeeld.

Dat is de echte kern van de zaak.

Waarom WSJT-X 3.1 improved nu serieuze aandacht verdient

Om te begrijpen waarom dit belangrijk is, helpt het om een stap terug te doen en naar het grotere geheel te kijken.

In de afgelopen jaren is WSJT-X improved veel meer geworden dan een zijtak met extra opties. Het is uitgegroeid tot een praktisch platform voor decoderideeën uit de echte wereld, UI-flexibiliteit en verbeteringen die op werkelijk gebruik zijn gericht.

Wie enige tijd met de huidige improved-builds werkt, merkt al snel één ding:

de oude vraag «Hoe verhoudt dit zich tot standaard WSJT-X 2.7?» is niet langer de nuttigste.

De relevantere vragen zijn nu:

• Hoe goed is WSJT-X 3.1 improved vandaag als praktisch FT8/FT4-programma?
• Hoeveel praktische decoderervaring is erin verwerkt?
• En hoe moet een operator het afstellen voor zijn eigen station, CPU en operationele prioriteiten?

Daarom gaat dit artikel niet in de eerste plaats over vergelijkingstabellen. Het gaat erom de software intelligent te gebruiken.

En zodra de discussie verschuift van «welke instellingen bestaan er?» naar «hoe moeten ze worden gebruikt?», moeten we vragen wat die instellingen werkelijk betekenen binnen een FT8-cyclus van 15 seconden.

De rol van elke instelling

«Agressiever» betekent niet automatisch «beter»

Voordat we Decode Start bekijken, is het nuttig om eerst duidelijk te maken hoe FT8-decoderinstellingen in het algemeen moeten worden begrepen.

Een veelvoorkomend misverstand is:

zwaardere instellingen moeten betere prestaties betekenen.

Dat klinkt aannemelijk, maar zo werkt FT8 niet.

Omdat FT8 in cycli van 15 seconden werkt, draait het werkelijk om een evenwicht tussen vier zaken:

1. Hoeveel signaal u afwacht vóór het decoderen
2. Hoe diep u naar kandidaatberichten zoekt
3. Of alles op tijd klaar is
4. Hoeveel valse decodes u bereid bent te accepteren

Zo bekeken gaat FT8-optimalisatie niet om «maximaal vermogen», maar om de verdeling van beperkte verwerkingstijd.

Dat perspectief verandert hoe elke instelling moet worden bekeken.

Aantal threads

Voor de meeste operators blijft Auto het beste uitgangspunt. Meer threads forceren garandeert geen beter resultaat. OS-scheduling, achtergrondbelasting, core-topologie en het totale systeemgedrag spelen allemaal mee.

Aantal decode-passes

Meer passes kunnen de kans vergroten om zwakkere of ambiguë signalen te herstellen, maar kosten ook CPU-tijd. Op een krachtig systeem kunnen 3 passes de moeite waard zijn. Voor veel stations is 2 de verstandigste standaard. Op beperkte hardware kan 1 veiliger zijn.

Decoder Sensitivity

De praktische interpretatie is eenvoudig:

• Minimum is lichter
• Low thresholds is gebalanceerd
• Subpass is agressiever, maar zwaarder

Subpass levert geen gratis prestaties. Het is extra werk in ruil voor de kans om zwakkere of moeilijkere signalen terug te vinden.

Een opmerking over Fast / Normal / Deep tegenover Multithreaded FT8 Decoder

Dit onderdeel is bijzonder gemakkelijk verkeerd te begrijpen. Omdat Fast / Normal / Deep op hetzelfde scherm staat als Multithreaded FT8 decoder, ligt het voor de hand te denken dat het varianten van dezelfde bediening zijn. De broncode laat echter zien dat het verschillende soorten instellingen zijn.

Fast / Normal / Deep is om te beginnen de traditionele instelling voor decode-diepte: een manier om aan te geven hoe diep de decoder moet zoeken. In het conventionele enkel-thread FT8-pad is deze diepte direct gekoppeld aan de rekenbelasting en agressiviteit van de zoekactie.

Multithreaded FT8 decoder is daarentegen een geheel andere dimensie. De fundamentele vraag is welke familie van decoderengine wordt gebruikt. In de code worden decode-diepte en multithreaded FT8 als afzonderlijke parameters behandeld, niet als twee namen voor hetzelfde.

Dan volgt de belangrijke nuance. Wanneer FT8 werkelijk met de multithreaded decoder actief draait, gebruikt het programma een speciaal MTD-pad in plaats van de oudere conventionele FT8-route. In dat pad bepalen de MTD-specifieke instellingen het gedrag — niet de oude Fast / Normal / Deep-niveaus:

• Decoder Sensitivity
• Decode Start
• Number of decode passes
• QSO Rx Frequency Sensitivity

De nauwkeurigste manier om ernaar te kijken is dus: Fast / Normal / Deep bestaat nog steeds en behoort nog steeds tot de bredere decode-dieptelogica, maar in FT8 MTD-bedrijf is het niet de primaire knop die bepaalt hoe agressief de decoder werkt. Bij praktisch afstellen zijn vooral de MTD-gerichte instellingen belangrijk — Decoder Sensitivity, Decode Start, Number of decode passes en QSO Rx Frequency Sensitivity.

Met andere woorden: wie WSJT-X 3.1 improved serieus voor FT8 wil afstellen met de multithreaded decoder ingeschakeld, kan beter denken in termen van MTD-specifieke gedragsinstellingen dan aannemen dat Fast / Normal / Deep nog steeds het karakter van de decoder bepaalt. De oude diepte-instelling blijft onderdeel van het ontwerp, maar is binnen het FT8 MTD-pad niet meer de belangrijkste praktische hefboom.

QSO Rx Frequency Sensitivity

Dit is niet alleen een snelheidsinstelling. Het beïnvloedt hoe agressief de decoder activiteit rond de QSO-gerelateerde frequentieregio en nabijgelegen kandidaten onderzoekt.

• Low is conservatief
• Medium is gebalanceerd
• High is agressief

Zoals te verwachten kan meer agressiviteit ook meer twijfelachtige kandidaten en meer decode-ruis opleveren.

Reduce False Decodes

Dit verdient meer aandacht dan het soms krijgt. Meer vinden is niet automatisch beter wanneer de extra uitvoer steeds minder betrouwbaar wordt. Op drukke banden en onder ambiguë omstandigheden is beheersing van valse decodes zeer belangrijk.

Samen concurreren deze instellingen niet afzonderlijk om te bepalen welke «het sterkst» is. Elk geeft een ander antwoord op dezelfde onderliggende vraag:

wat moet de decoder binnen een zeer beperkte periode van 15 seconden prioriteit geven?

En van al deze instellingen is Decode Start een van de duidelijkste en meest onthullende voorbeelden.

De hoofdvraag

Wat doet «Decode Start» werkelijk?

Hier wordt het onderwerp echt interessant.

In de gebruikersinterface biedt Decode Start vijf keuzes:

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

Op het eerste gezicht lijkt dit een eenvoudige timingregeling:

eerder of later beginnen met decoderen.

Maar dat is niet het hele verhaal.

In de werkelijke implementatie van WSJT-X 3.1 improved worden deze modi intern behandeld als:

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

Tijdens FT8-bedrijf gebruikt het programma waarden zoals m_hsymStop, m_earlyDecode en m_earlyDecode2 om te bepalen wanneer decodefasen worden geactiveerd.

Dat vertelt ons meteen:

Om dit makkelijker te begrijpen beginnen we met de eenvoudigere drie modi — Early, Normal en Late — en gaan daarna naar de meer onthullende 2-Stage- en 3-Stage-modi.

Early / Normal / Late

Eerst de drie eenvoudigere modi

Laten we beginnen met de meest rechttoe-rechtaan opties.

Met de multithreaded FT8-decoder ingeschakeld liggen de interne stoppunten ongeveer op:

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

In ruwe tijdstermen komt dat ongeveer overeen met:

• Early → circa 13,8 seconden
• Normal → circa 14,1 seconden
• Late → circa 14,4 seconden

De basisbetekenis is intuïtief:

• Early levert wat signaalverzameling in voor meer CPU-marge
• Late wacht langer om iets meer informatie te verzamelen vóór het decoderen
• Normal zit ertussenin

Als Decode Start alleen uit deze drie modi bestond, zou het nog steeds nuttig zijn — maar niet bijzonder ongewoon.

Wat de functie veel interessanter maakt, is wat daarna komt:

2-Stage en 3-Stage.

Aanvullende technische noot

Wat 2-Stage en 3-Stage werkelijk zijn

Niet alleen «eerder» of «later», maar een gefaseerde decoderstrategie die STD en MTD combineert

De changelog van WSJT-X improved beschrijft 2-Stage en 3-Stage als modi die «beide decoders intelligent combineren», met volgens de changelog de beste FT8-decodeprestaties tot nu toe.

Met andere woorden: de software presenteert ze expliciet als een manier om de traditionele STD-decoder (single-threaded) te combineren met de nieuwere MTD-decoder (multithreaded).

Wat de changelog niet uitlegt, is de exacte uitvoeringsvolgorde of de timingrelatie tussen beide. Dat wordt pas duidelijk wanneer naar de implementatie wordt gekeken.

Dan blijkt dat 2-Stage en 3-Stage niet slechts verschillende starttijden zijn. Het zijn meerfasige decoderstrategieën, en de verschillende fasen hebben niet allemaal dezelfde rol.

De taakverdeling tussen STD en MTD

STD staat hier voor de traditionele single-threaded FT8-decoder. MTD staat voor de multithreaded FT8-decoder die in de improved-lijn is geïntroduceerd.

Op basis van de implementatie werken de gefaseerde modi grofweg zo:

• de eerdere fasen gebruiken STD
• de laatste fase gebruikt MTD

Dat is het centrale ontwerpidee.

Het kan dus het best worden begrepen als een bewuste scheiding tussen:

• een eerdere, lichtere en snellere blik
• en een latere, completere decode-pass

Dat is een zeer belangrijk onderscheid.

Een eenvoudiger ontwerp zou kunnen wachten tot het einde van het ontvangstinterval en dan één zware decode-pass uitvoeren. WSJT-X improved doet dat niet. Het voert tussentijdse zoekacties naar kandidaten uit vóór de laatste fase en voltooit later een grondigere decode.

Daarmee wordt duidelijk dat het ontwerp sterk focust op één centraal probleem:

Ontwikkelaarsperspectief: waar de STD-voorpass werkelijk voor dient

Volgens Uwe Risse / DG2YCB is de STD-voorpass niet slechts een extra voorlopige decode. De belangrijke rol ervan is dat het voordeel van vroeg decoderen van de traditionele STD-decoder in de MTD-werkwijze wordt gebracht.

Tijdens de ontwikkeling zijn verschillende combinaties van STD en MTD getest, samen met verschillende nzhsym-parameters. De huidige aanpak — STD als voorpass en MTD als belangrijkste eindpass — leverde de beste praktische resultaten op.

Dit is een kernpunt. 2-Stage en 3-Stage zijn niet simpelweg mechanismen om «de decoder meer dan één keer te draaien». Ze combineren het lichte vroege decodegedrag van STD met de completere einddecodekracht van MTD en benutten zo de beperkte CPU-tijd binnen de FT8-cyclus van 15 seconden efficiënter.

Uwe merkt ook op dat 2-Stage ongeveer 99,5% van de decode-opbrengst van 3-Stage haalt en veel minder rekenkracht vraagt. Dat verklaart waarom 2-Stage voor de meeste gebruikers zo’n sterke praktische aanbeveling is, terwijl 3-Stage de maximale-prestatiemodus voor zeer snelle computers blijft.

Wat 2-Stage werkelijk betekent

Bij live on-air decodering bestaat 2-Stage uit één STD-voorpass op nzhsym=41, gevolgd door de laatste MTD-decodepass op nzhsym=49.

De werkelijke volgorde is dus:

• STD-voorpass @ nzhsym=41 — ongeveer 11,8 seconden
• laatste MTD @ nzhsym=49 — ongeveer 14,1 seconden

Het belangrijke punt is dat de tweede STD-voorpass op nzhsym=46 geen onderdeel is van 2-Stage bij live decodering. Die extra voorpass hoort uitsluitend bij 3-Stage.

2-Stage is dus een goed gebalanceerde modus: één vroege verkenningspass, gevolgd door de belangrijkste MTD-decode bij nzhsym=49.

Omdat de balans tussen decode-opbrengst en CPU-kosten zo goed is, zou ik 2-Stage als eerste aan de meeste gebruikers aanbevelen. Volgens Uwe Risse / DG2YCB haalt het ongeveer 99,5% van de opbrengst van 3-Stage met veel minder rekenkracht. Dat maakt het een zeer sterk praktisch compromis.

Wat 3-Stage werkelijk betekent

3-Stage voegt een tweede STD-voorpass op nzhsym=46 toe vóór de laatste MTD-decodepass.

Bij live on-air decodering is de volgorde:

• STD-voorpass @ nzhsym=41 — ongeveer 11,8 seconden
• STD-voorpass @ nzhsym=46 — ongeveer 13,2 seconden
• laatste MTD @ nzhsym=50 — ongeveer 14,4 seconden

3-Stage voert dus eerst een vroege verkenning uit op 41, daarna nog een STD-voorpass op 46 en ten slotte de hoofd-MTD-decodering op 50.

Daarmee is 3-Stage de FT8-decodemodus met de hoogste prestaties die in WSJT-X 3.1 improved beschikbaar is.

Er is echter een belangrijke praktische waarschuwing. De extra decodewinst van 3-Stage is niet evenredig met het extra CPU-gebruik. Uwe Risse / DG2YCB merkt op dat 2-Stage al ongeveer 99,5% van de decode-opbrengst van 3-Stage haalt, zodat de resterende winst klein is in verhouding tot de extra benodigde rekenkracht.

Op zwakkere computers kan de extra STD-voorpass op nzhsym=46 te veel tijd kosten en in het slechtste geval de uiterst belangrijke laatste MTD-decodestap op nzhsym=50 hinderen. Daarom moet 3-Stage als een high-endmodus worden gezien: de ultieme optie voor krachtige hardware, maar niet automatisch de beste aanbeveling voor iedereen.

Begrijp het als «eerst STD, MTD als laatste», niet «eerst MTD, daarna STD»

Dit is een van de gemakkelijkst verkeerd te begrijpen punten.

Omdat de changelog zegt dat 2-Stage en 3-Stage STD en MTD combineren, kunnen lezers zich een model als dit voorstellen:

• MTD draait eerst
• daarna vult STD aan wat MTD heeft gemist

Maar dat is niet wat het live decodegedrag laat zien.

De nauwkeurigere interpretatie is precies andersom:

• STD voert de eerdere, lichtere verkenningspass of -passes uit
• MTD voert de laatste, zwaardere decode uit

Bij live gebruik is het onderscheid:

• 2-Stage: STD @41 → laatste MTD @49
• 3-Stage: STD @41 → STD @46 → laatste MTD @50

Dat onderscheid is belangrijk. 3-Stage biedt de hoogst mogelijke decodeprestaties, maar 2-Stage is voor de meeste gebruikers praktischer omdat het de extra CPU-kosten van de tweede STD-voorpass op nzhsym=46 vermijdt.

Waarom STD überhaupt in de eerdere fasen gebruiken?

Ook dit is veelzeggend.

Als het doel alleen zou zijn «de decoder vaker draaien», dan zou je verwachten dat MTD in elke fase herhaaldelijk wordt uitgevoerd. Dat gebeurt niet.

De waarschijnlijke reden is eenvoudig:

de eerdere fasen moeten licht en snel zijn.

Op die vroege momenten is de ontvangst nog niet compleet. Er is minder informatie beschikbaar dan in de laatste fase. Iedere keer de zwaarste decode-logica op volle kracht gebruiken zou niet noodzakelijk de efficiëntste besteding van beperkte CPU-tijd zijn.

Daarom gebruikt de software STD om op de eerdere punten snel en zuinig te kijken, en bewaart MTD voor de laatste en belangrijkere pass.

Dat is niet slechts een implementatiedetail. Het weerspiegelt een decoderfilosofie die uitstekend past bij FT8 als korte, burst-achtige en timinggevoelige workload.

De code suggereert bovendien dat de eerdere fasen iets beperkter worden verwerkt dan de laatste fase. Dat ondersteunt opnieuw het idee dat dit niet zomaar herhaalde passes zijn, maar een gefaseerde voortgang waarin elke pass een andere rol heeft.

De essentie van 2-Stage en 3-Stage is tijdtoewijzing

Uiteindelijk draaien 2-Stage en 3-Stage om één ding:

hoe rekeninspanning binnen een cyclus van 15 seconden wordt verdeeld.

• Moet de decoder eerder kijken?
• Moet hij halverwege nog eens kijken?
• Moet hij tot het einde wachten voor de meest complete eindpoging?

Dat is wat de gefaseerde modi beslissen.

2-Stage en 3-Stage moeten dus niet als simpele timingaanpassingen worden gezien. Ze zijn beter te begrijpen als verschillende manieren om de FT8-decoder in de tijd uit te rollen.

Hoe moeten ze in werkelijk gebruik worden geïnterpreteerd?

In operationele termen wordt het onderscheid heel praktisch.

2-Stage

• behoudt de responsiviteit redelijk goed
• voegt een eerdere blik toe
• houdt de laatste fase rond Normal-timing
• verbetert kandidaatdetectie zonder de CPU-belasting tot het uiterste te drijven

Met andere woorden: een gebalanceerde gefaseerde strategie.

3-Stage

• kijkt vroeg
• kijkt halverwege opnieuw
• behoudt nog steeds een laatste MTD-pass rond Late-timing
• gaat verder in het verminderen van gemiste decodes
• maar verhoogt de CPU-belasting overeenkomstig

3-Stage is daarmee de ambitieuste en agressiefste gefaseerde modus.

Als de CPU voldoende reserve heeft kan dit zeer aantrekkelijk zijn. Zit de CPU al dicht bij zijn timinggrenzen, dan is het theoretische voordeel minder belangrijk dan het proces gewoon schoon afronden.

Op dat punt wordt de betekenis van deze modi veel duidelijker:

Nog een belangrijk punt

De gefaseerde modi zijn niet alleen «meerdere decodes»; ze geven verschillende fasen verschillende rollen

Van iets grotere afstand bekeken is het interessante aan 2-Stage en 3-Stage niet alleen dat ze de decoder meer dan één keer activeren.

Het diepere punt is dat elke fase een andere rol speelt.

• de eerdere fasen zijn lichter en sneller
• de laatste fase is completer
• de CPU-inspanning wordt over de cyclus verdeeld in plaats van in één keer verbruikt

Dat past opmerkelijk goed bij FT8.

In principe zou je tot het einde kunnen wachten en één laatste beslissing nemen. Maar het heeft echte waarde om eerder herstelbare kandidaten te zoeken en het probleem later opnieuw te bekijken met meer informatie en zwaardere verwerking.

Daarom gaat het begrijpen van de gefaseerde modi niet alleen om één instelling. Het gaat eigenlijk om begrijpen wat FT8-optimalisatie zelf betekent.

Praktische interpretatie

Hoe moet elke modus in de praktijk worden gebruikt?

Na alle technische details is het nuttig om terug te keren naar operationele taal.

2-Stage

Zeer praktisch. Het behoudt de responsiviteit en kijkt toch eerder. De laatste fase ligt niet zo laat als Late, waardoor de belasting niet onnodig hoog wordt.

3-Stage

De ambitieuste modus — in positieve zin.

Hij kijkt vroeg, kijkt later nog eens en houdt toch een krachtige eindpass. Als er voldoende CPU-reserve is en minder gemiste decodes prioriteit hebben, is dit een van de interessantste instellingen van het hele paneel.

Early

Dit moet niet worden afgedaan als alleen een noodoplossing voor een zwakke CPU. Het is ook een rationele stabiliteitsstrategie. Als voorkomen dat verwerking in de volgende cyclus doorloopt belangrijker is dan het laatste beetje signaal eruit halen, kan Early precies goed zijn.

Normal

Het referentiepunt. Voor de meeste gebruikers moeten tests hier beginnen. Het maakt vergelijking met de andere modi veel eenvoudiger.

Late

Wacht langer, decodeer later en neem de eindbeslissing met iets meer informatie. Theoretisch kan dat helpen; praktisch is het alleen nuttig als het systeem nog steeds betrouwbaar op tijd klaar is.

Gezamenlijk moeten de Decode Start-modi niet als «persoonlijke smaak» worden gezien. Het zijn beter verschillende timingstrategieën.

Wat optimaliseren we dan eigenlijk?

Niet gemiddelde prestaties, maar het gebruik van CPU-tijd binnen de cyclus van 15 seconden

Op dit punt moet het bredere principe duidelijk zijn.

FT8-optimalisatie draait niet simpelweg om alles «krachtiger» maken.

Het gaat om beslissen:

• hoe lang te wachten
• hoe vaak te kijken
• waar lichtere passes te doen
• waar de zwaardere eindpass te doen
• en of het hele proces van cyclus tot cyclus stabiel blijft

Met andere woorden: het gaat om hoe CPU-prestaties worden gebruikt, niet alleen hoeveel ervan beschikbaar is.

Vanuit dat perspectief is Decode Start een van de belangrijkste instellingen in het hele decoderpaneel. Wat een kleine UI-optie lijkt, is in werkelijkheid een directe uitdrukking van tijdstrategie.

Daarom is Decode Start begrijpen meer dan alleen een instelling uitleggen. Het helpt de onderliggende filosofie van rekenallocatie in FT8 te begrijpen.

Een persoonlijkere noot

Waarom ik dit eigenlijk schrijf

Tot nu toe heb ik geprobeerd de discussie algemeen en technisch te houden. Voor de context moet ik mijn eigen positie echter duidelijk maken.

Niet omdat JTDX geen waarde heeft, maar omdat software ook moet worden beoordeeld op wat praktisch beschikbaar, voldoende volwassen om te testen en nu bruikbaar is.

Als iemand bij JTDX blijft omdat hij de interface echt prefereert, is dat volledig begrijpelijk. Maar als de vraag gaat over huidige decodercapaciteit en praktische operationele waarde, verdient WSJT-X 3.1 improved serieuze aandacht.

Mijn eigen bedieningsfilosofie

Tot nu toe heb ik algemene principes besproken. Het kan nuttig zijn uit te leggen waar mijn eigen denken in de praktijk toe leidt.

Mijn belangrijkste station-PC gebruikt een Core i9-9900K. Dat detail is belangrijk, maar niet alleen omdat het een relatief krachtige CPU is.

Ook de configuratie van de machine is belangrijk.

In de energie-instellingen van Windows zet ik de minimale processorstatus op 100%. Ik wacht dus niet tot de CPU de kloksnelheid verhoogt nadat de decodebelasting verschijnt. Ik heb hem liever al op hoge kloksnelheid, klaar en wachtend. In mijn geval staat hij effectief op 4,7 GHz.

De reden is eenvoudig.

FT8-decodering lijkt niet op langdurige videorendering met een constante belasting. Het lijkt veel meer op een korte uitbarsting van geconcentreerd werk, die op voorspelbare momenten terugkomt.

Bij zo’n workload vertelt gemiddelde benchmarkprestatie niet het hele verhaal. De eerste respons telt.

Als de CPU in een energiezuinige toestand staat, moet het systeem:

• de belasting detecteren
• van prestatietoestand veranderen
• de klok verhogen
• de spanning aanpassen
• en de scheduler laten reageren

Die vertragingen zijn bij langdurige workloads mogelijk onbelangrijk, maar bij korte timinggevoelige bursts kunnen ze meer uitmaken dan men verwacht.

Daarom geloof ik dit:

Uiteraard heeft die keuze nadelen.

• hoger energieverbruik
• meer warmte
• lagere efficiëntie
• minder elegant vanuit energiebesparing

Maar op een station-PC vind ik decoderrespons en stabiliteit belangrijker dan elektrische zuinigheid.

Waarom mijn eigen instellingen bewust agressief zijn

Omdat 50 MHz voor mij belangrijk is

Mijn instellingen weerspiegelen die filosofie vrij duidelijk.

• Decoder Sensitivity: Subpass
• QSO Rx Frequency Sensitivity: High
• CPU staat al klaar op hoge kloksnelheid

Dit is geen conservatieve configuratie, en ik doe niet alsof.

Maar daar is een reden voor:

50 MHz betekent veel voor mij.

Op 6 meter:

• kunnen omstandigheden snel veranderen
• kan activiteit plotseling toenemen
• bestaan zwakke en sterke signalen vaak naast elkaar
• en kan een korte opening gemiste kansen extra frustrerend maken

Daarom ben ik bereid CPU-resources te gebruiken om gemiste decodes te beperken.

Daarom gebruik ik:

• Subpass, om dieper te zoeken
• High sensitivity, om agressiever kandidaten te herstellen
• en een energieconfiguratie die de CPU gereed houdt voordat de burstbelasting aankomt

Dit is niet simpelweg «alles omhoog omdat meer beter moet zijn».

Het is een bewuste operationele strategie rond:

• nadruk op 50 MHz
• voldoende CPU-reserve
• het belang van reactiesnelheid
• en bereidheid efficiëntie in te ruilen voor kansen

Slotgedachten

De echte vraag is niet «Welk programma heeft gelijk?», maar «Welke afstelfilosofie past bij uw station?»

Als ik deze hele discussie tot één zin moest terugbrengen, zou het deze zijn:

Vanuit dat perspectief is WSJT-X 3.1 improved zeer interessante software. Niet alleen omdat het meer opties biedt, maar omdat het de operator betekenisvolle controle geeft over de timingstrategie van de decoder.

En Decode Start is daarvan een van de duidelijkste voorbeelden.

2-Stage, 3-Stage, Early, Normal en Late zijn niet alleen cosmetische labels. Ze vertegenwoordigen verschillende manieren om decode-inspanning over de FT8-cyclus te verdelen.

Wie de gefaseerde modi nauwkeuriger bekijkt, ziet daaronder een bijzonder elegant idee:

Tot slot wil ik dit zeggen als iemand die JTDX oprecht waardeert:

Als uw voorkeur voor JTDX vooral om de interface draait, is dat één ding. Maar als uw zorg de huidige decodercapaciteit onder echte operationele omstandigheden is, is er weinig reden om te aarzelen.