Förstå FT8-avkodarinställningarna i WSJT-X 3.1 improved

JTDX har länge erbjudit bra förklaringar av hur dess avkodarinställningar fungerar. De guiderna har alltid varit värdefulla eftersom de tydliggör en viktig princip:

Det är grundprincipen.

Men år 2026 har diskussionen förändrats om fokus ligger på prestanda i FT8/FT4.

WSJT-X 3.1 improved är inte längre bara «standard-WSJT-X med några extra funktioner». En betydande mängd praktiskt avkodartänkande — inklusive idéer som känns mycket bekanta för JTDX-användare — har integrerats på ett meningsfullt sätt. Att bara jämföra det med WSJT-X 2.7 eller äldre säger därför inte längre särskilt mycket.

Mer direkt uttryckt: för den genomsnittlige operatören förtjänar WSJT-X 3.1 improved nu att tas på stort allvar som ett förstahandsalternativ.

Att vänta på nästa GA-version av JTDX är naturligtvis en möjlig hållning. Men om prioriteringen är praktisk avkodningsprestanda, tillgängliga funktioner, utvecklingsaktivitet och vad som faktiskt kan installeras och användas i dag, är det mer rationellt att använda det som redan finns och redan fungerar starkt.

Det betyder inte att JTDX saknar en plats. Om någon verkligen föredrar JTDX-gränssnittet är det ett fullt giltigt skäl att fortsätta använda det. Men det är en annan fråga än avkodarkapacitet och praktisk optimering.

Den här artikeln är inte tänkt som ännu en lista med rekommenderade inställningar. Jag vill i stället undersöka en djupare fråga:

Vad betyder FT8-avkodaroptimering egentligen? Och mer specifikt: vad gör inställningen «Decode Start» i WSJT-X 3.1 improved egentligen?

Den praktiska slutsatsen först

Börja med Normal. Prova 3-Stage om CPU:n har tillräcklig marginal. Använd Early om tidsmarginalen är viktigare.

Låt oss börja med den praktiska slutsatsen.

Den viktigaste regeln när FT8-avkodaren ställs in är inte:

«Använd de tyngsta inställningarna som finns.»

Utan:

«Använd de mest aggressiva inställningar som systemet kan slutföra tillförlitligt inom 15-sekunderscykeln.»

Det är ett helt annat sätt att tänka.

Som utgångspunkt är ungefär följande rimligt för många stationer:

Det är inte nödvändigtvis slutinställningen, men det är en stabil startpunkt. Därifrån kan man gå mer aggressivt om CPU:n har marginal. Om man börjar se fördröjning, sen färdigställning eller instabilitet bör man backa.

För Decode Start är en praktisk sammanfattning:

Det är den praktiska sammanfattningen. Men varför inställningen spelar roll är mer intressant än sammanfattningen antyder.

Decode Start är inte bara en preferens för att «börja tidigare eller senare». Den hänger nära samman med hur många steg avkodaren använder, var de ligger i tiden och hur avkodningsarbetet fördelas över FT8-cykeln.

Det är frågans verkliga kärna.

Varför WSJT-X 3.1 improved förtjänar seriös uppmärksamhet nu

För att förstå varför detta är viktigt hjälper det att ta ett steg tillbaka och se helheten.

Under de senaste åren har WSJT-X improved blivit mycket mer än en sidogren med extra alternativ. Det har utvecklats till en praktisk plattform för avkodaridéer från verklig drift, flexibel UI och operatörsinriktade förbättringar.

När man har använt dagens improved-versioner en tid blir en sak tydlig:

den gamla frågan «Hur står detta sig mot standard-WSJT-X 2.7?» är inte längre den mest användbara.

De mer relevanta frågorna är nu:

• Hur bra är WSJT-X 3.1 improved som praktiskt FT8/FT4-verktyg i dag?
• Hur mycket verklighetsbaserat avkodartänkande har byggts in?
• Och hur bör en operatör ställa in det för sin egen station, CPU och sina prioriteringar?

Därför handlar artikeln inte främst om jämförelsetabeller. Den handlar om hur programmet används intelligent.

När diskussionen går från «vilka inställningar finns?» till «hur ska de användas?» måste man fråga vad inställningarna faktiskt betyder inom en FT8-cykel på 15 sekunder.

Varje inställnings roll

«Mer aggressivt» betyder inte automatiskt «bättre»

Innan vi fokuserar på Decode Start är det värt att klargöra hur FT8-avkodarens inställningar i allmänhet bör förstås.

Ett mycket vanligt missförstånd är:

tyngre inställningar måste ge bättre prestanda.

Det låter rimligt, men FT8 fungerar inte så.

Eftersom FT8 arbetar i 15-sekunderscykler handlar det i praktiken om en balans mellan fyra saker:

1. Hur mycket signal man väntar in före avkodning
2. Hur djupt man söker efter kandidatmeddelanden
3. Om allt hinner bli klart i tid
4. Hur många falska avkodningar man är beredd att tolerera

Ur det perspektivet handlar FT8-optimering inte om «maximal kraft», utan om hur begränsad bearbetningstid fördelas.

Det perspektivet förändrar hur varje inställning bör ses.

Antal trådar

För de flesta operatörer är Auto fortfarande den bästa startpunkten. Att bara tvinga fram fler trådar garanterar inte bättre resultat. Operativsystemets schemaläggning, bakgrundslast, kärnornas topologi och systemets helhetsbeteende spelar in.

Antal avkodningspass

Fler pass kan öka chansen att återvinna svagare eller mer tvetydiga signaler, men de kostar CPU-tid. På ett starkt system kan 3 pass vara värda att prova. För många stationer är 2 den mest rimliga standarden. På begränsad hårdvara kan 1 vara säkrare.

Decoder Sensitivity

Den praktiska tolkningen är enkel:

• Minimum är lättare
• Low thresholds är balanserat
• Subpass är mer aggressivt men tyngre

Subpass ger ingen gratis prestanda. Det är extra arbete i utbyte mot möjligheten att återvinna svagare eller svårare signaler.

En kommentar om Fast / Normal / Deep jämfört med Multithreaded FT8 Decoder

Det här är särskilt lätt att missförstå. Eftersom Fast / Normal / Deep visas på samma skärm som Multithreaded FT8 decoder är det naturligt att tro att de bara är olika versioner av samma kontroll. Källkoden visar dock att de är olika typer av inställningar.

Fast / Normal / Deep är först och främst den traditionella inställningen för avkodningsdjup: ett sätt att tala om för avkodaren hur djupt den ska söka. I den konventionella enkeltrådade FT8-vägen är djupet direkt kopplat till hur tung avkodningen blir och hur aggressivt sökningen drivs.

Multithreaded FT8 decoder är däremot en helt annan dimension. Den grundläggande frågan är vilken familj av avkodarmotor som används. I koden hanteras avkodningsdjup och multitrådad FT8 som separata parametrar, inte som två namn på samma sak.

Den viktiga nyansen kommer därefter. När FT8 faktiskt körs med den multitrådade avkodaren aktiverad går programmet in i en särskild MTD-väg i stället för den äldre konventionella FT8-vägen. Där styrs beteendet i praktiken av MTD-specifika inställningar — inte de gamla nivåerna Fast / Normal / Deep:

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

Den mest korrekta tolkningen är därför: Fast / Normal / Deep finns kvar och tillhör fortfarande programmets bredare logik för avkodningsdjup, men i FT8 MTD-drift är det inte den huvudsakliga kontrollen för avkodarens aggressivitet. I praktisk trimning är det de MTD-orienterade inställningarna som verkligen betyder något — särskilt Decoder Sensitivity, Decode Start, Number of decode passes och QSO Rx Frequency Sensitivity.

Om man alltså vill trimma WSJT-X 3.1 improved seriöst för FT8 med den multitrådade avkodaren aktiverad är det bättre att tänka i termer av MTD-specifika beteendekontroller än att anta att Fast / Normal / Deep fortfarande bestämmer avkodarens karaktär. Det gamla djupvärdet finns kvar i designen; det är bara inte längre den viktigaste praktiska hävstången i FT8 MTD-vägen.

QSO Rx Frequency Sensitivity

Det är inte bara en hastighetsinställning. Den påverkar hur aggressivt avkodaren undersöker aktivitet runt QSO-frekvensområdet och närliggande kandidater.

• Low är konservativt
• Medium är balanserat
• High är aggressivt

Som väntat kan större aggressivitet också ge fler tveksamma kandidater och mer avkodningsbrus.

Reduce False Decodes

Det här förtjänar mer uppmärksamhet än det ibland får. Att hitta mer är inte automatiskt bättre om den extra informationen blir allt mindre tillförlitlig. På trånga band och under tvetydiga förhållanden är kontroll av falska avkodningar mycket viktig.

Tillsammans konkurrerar dessa inställningar inte var för sig om vilken som är «starkast». Var och en ger ett annat svar på samma grundfråga:

vad ska avkodaren prioritera inom ett mycket begränsat fönster på 15 sekunder?

Och bland dem är Decode Start ett av de tydligaste och mest avslöjande exemplen.

Huvudfrågan

Vad gör «Decode Start» egentligen?

Det är här ämnet blir riktigt intressant.

I användargränssnittet erbjuder Decode Start fem val:

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

Vid första anblicken ser det ut som en enkel tidskontroll:

börja avkoda tidigare eller senare.

Men det är inte hela bilden.

I den faktiska implementeringen av WSJT-X 3.1 improved hanteras dessa lägen internt som:

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

Under FT8-drift använder programmet värden som m_hsymStop, m_earlyDecode och m_earlyDecode2 för att avgöra när avkodningsstegen ska utlösas.

Det säger oss genast:

För att göra detta lättare att förstå börjar vi med de enklare tre lägena — Early, Normal och Late — och går sedan vidare till de mer avslöjande 2-Stage och 3-Stage.

Early / Normal / Late

De enklare tre lägena först

Låt oss börja med de mest raka alternativen.

När den multitrådade FT8-avkodaren är aktiverad ligger de interna stopppunkterna ungefär vid:

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

I ungefärlig tid motsvarar det:

• Early → cirka 13,8 sekunder
• Normal → cirka 14,1 sekunder
• Late → cirka 14,4 sekunder

Grundbetydelsen är intuitiv:

• Early ger upp lite signalinsamling i utbyte mot större CPU-marginal
• Late väntar längre för att samla något mer information före avkodning
• Normal ligger mitt emellan

Om Decode Start bara bestod av dessa tre lägen skulle det ändå vara en användbar inställning — men inte särskilt ovanlig.

Det som gör funktionen mycket mer intressant är det som följer:

2-Stage och 3-Stage.

Ytterligare teknisk kommentar

Vad 2-Stage och 3-Stage egentligen är

Inte bara «tidigare» eller «senare», utan en stegvis avkodningsstrategi som kombinerar STD och MTD

Ändringsloggen för WSJT-X improved beskriver 2-Stage och 3-Stage som lägen som «intelligent kombinerar båda avkodarna», vilket enligt den ger den bästa FT8-avkodningsprestandan hittills.

Programmet presenterar dem alltså uttryckligen som ett sätt att kombinera den traditionella STD-avkodaren (enkeltrådad) med den nyare MTD-avkodaren (multitrådad).

Det som ändringsloggen inte förklarar är den exakta körordningen eller tidsförhållandet mellan de två. Det blir tydligt först när man tittar på implementeringen.

Då blir det uppenbart att 2-Stage och 3-Stage inte bara är olika starttider. De är flerstegsstrategier för avkodning, och de olika stegen har inte samma roll.

Arbetsfördelningen mellan STD och MTD

Här avser STD den traditionella enkeltrådade FT8-avkodaren. MTD avser den multitrådade FT8-avkodare som introducerades i improved-linjen.

Utifrån implementeringen fungerar steglägena ungefär så här:

• de tidigare stegen använder STD
• det slutliga steget använder MTD

Det är den centrala designidén.

Det bör alltså förstås som en avsiktlig uppdelning mellan:

• en tidigare, lättare och snabbare titt
• och ett senare, mer fullständigt avkodningspass

Det är en mycket viktig skillnad.

En enklare konstruktion hade kunnat vänta till slutet av mottagningsintervallet och sedan göra ett enda tungt avkodningspass. WSJT-X improved gör inte så. I stället görs mellanliggande sökningar efter kandidater före slutsteget, följt av en mer genomgripande avkodning senare.

Det visar att konstruktionen fokuserar på ett centralt problem:

Utvecklarperspektiv: vad STD-förpasset egentligen är till för

Enligt Uwe Risse / DG2YCB är STD-förpasset inte bara en extra preliminär avkodning. Dess viktiga roll är att föra den tidiga avkodningsfördelen från den traditionella STD-avkodaren in i MTD-arbetsflödet.

Under utvecklingen testades flera kombinationer av STD och MTD tillsammans med olika nzhsym-parametrar. Den nuvarande metoden — STD som förpass och MTD som huvudsakligt slutpass — gav de bästa praktiska resultaten.

Det här är en nyckelpunkt. 2-Stage och 3-Stage är inte bara mekanismer för att «köra avkodaren flera gånger». De kombinerar STD:s lätta tidiga avkodning med MTD:s mer fullständiga slutavkodning och utnyttjar därmed den begränsade CPU-tiden i FT8-cykeln på 15 sekunder effektivare.

Uwe noterar också att 2-Stage uppnår omkring 99,5 % av avkodningsutbytet från 3-Stage men kräver betydligt mindre datorkraft. Det förklarar varför 2-Stage är en så stark praktisk rekommendation för de flesta användare, medan 3-Stage förblir maximalprestandaalternativet för mycket snabba datorer.

Vad 2-Stage egentligen betyder

Vid verklig on-air-avkodning består 2-Stage av ett STD-förpass vid nzhsym=41, följt av det slutliga MTD-passet vid nzhsym=49.

Den verkliga sekvensen är alltså:

• STD-förpass @ nzhsym=41 — cirka 11,8 sekunder
• slutligt MTD @ nzhsym=49 — cirka 14,1 sekunder

Nyckelpunkten är att det andra STD-förpasset vid nzhsym=46 inte ingår i 2-Stage vid liveavkodning. Det extra förpasset hör endast till 3-Stage.

2-Stage är alltså ett välbalanserat läge: ett tidigt spaningspass följs av det huvudsakliga MTD-steget vid nzhsym=49.

Eftersom balansen mellan avkodningsutbyte och CPU-kostnad är så god är 2-Stage det läge jag först skulle rekommendera för de flesta användare. Enligt Uwe Risse / DG2YCB ger det omkring 99,5 % av 3-Stage-utbytet med mycket mindre datorkraft. Det är en mycket stark praktisk kompromiss.

Vad 3-Stage egentligen betyder

3-Stage lägger till ett andra STD-förpass vid nzhsym=46 före det slutliga MTD-passet.

Vid verklig on-air-avkodning är sekvensen:

• STD-förpass @ nzhsym=41 — cirka 11,8 sekunder
• STD-förpass @ nzhsym=46 — cirka 13,2 sekunder
• slutligt MTD @ nzhsym=50 — cirka 14,4 sekunder

Så 3-Stage gör först en tidig sonderingspass vid 41, därefter ytterligare en STD-förpass vid 46 och kör slutligen den huvudsakliga MTD-avkodningen vid 50.

Detta gör 3-Stage till det FT8-avkodningsläge med högst prestanda som finns i WSJT-X 3.1 improved.

Här behövs dock en viktig praktisk varning. Den extra avkodningsvinsten med 3-Stage står inte i proportion till den extra CPU-belastningen. Uwe Risse / DG2YCB påpekar att 2-Stage redan når omkring 99,5 % av avkodningsutfallet hos 3-Stage, så den återstående vinsten är liten jämfört med den extra beräkningskraft som krävs.

På svagare datorer kan den extra STD-förpassen vid nzhsym=46 ta för lång tid och i värsta fall störa det avgörande slutliga MTD-steget vid nzhsym=50. Därför bör 3-Stage betraktas som ett high-end-läge: det är det ultimata alternativet för användare med kraftfull hårdvara, men inte automatiskt den bästa rekommendationen för alla.

Det ska förstås som ”STD först, MTD sist” – inte ”MTD först, STD senare”

Detta är en av de punkter som är lättast att missförstå.

Eftersom ändringsloggen säger att 2-Stage och 3-Stage kombinerar STD och MTD kan vissa läsare föreställa sig en modell som denna:

• MTD körs först
• därefter fyller STD i det som MTD missade

Men det är inte vad beteendet vid live-avkodning visar.

Den mer korrekta tolkningen är den motsatta:

• STD gör den tidigare och lättare sonderingspassen eller sonderingspasserna
• MTD gör den slutliga och mer omfattande avkodningen

Vid live-körning är skillnaden:

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

Den skillnaden är viktig. 3-Stage ger högsta möjliga avkodningsprestanda, men 2-Stage är den mer praktiska rekommendationen för de flesta användare eftersom den undviker CPU-kostnaden för den andra STD-förpassen vid nzhsym=46.

Varför använda STD i de tidigare stegen över huvud taget?

Även detta säger mycket.

Om målet bara vore att ”köra avkodaren fler gånger” kunde man vänta sig att programmet körde MTD upprepade gånger i varje steg. Men så fungerar det inte.

En trolig orsak är enkel:

de tidigare stegen är avsedda att vara lätta och snabba.

Vid dessa tidigare tidpunkter är mottagningen ännu inte komplett. Den tillgängliga informationsmängden är fortfarande mindre än i slutsteget. Att köra den tyngsta möjliga avkodningslogiken med full kraft varje gång vore därför inte nödvändigtvis det effektivaste sättet att använda den begränsade CPU-tiden.

I stället använder programmet STD för att snabbt och ekonomiskt titta vid de tidigare tidpunkterna och sparar MTD till den slutliga och mer betydelsefulla passen.

Det är inte bara en implementeringsdetalj. Det speglar en avkodningsfilosofi som passar FT8 mycket väl som en kort, burst-liknande och tidskänslig arbetslast.

Koden antyder också att de tidigare stegen använder något mer begränsad bearbetning än slutsteget. Det stärker bilden av att dessa lägen inte bara är upprepade pass, utan en stegvis process där varje pass har en egen roll.

Kärnan i 2-Stage och 3-Stage är tidsfördelning

I grunden handlar 2-Stage och 3-Stage egentligen om en enda sak:

hur beräkningsarbetet ska fördelas inom en 15-sekunderscykel.

• Ska avkodaren göra en tidigare kontroll?
• Ska den göra ytterligare en kontroll mitt i cykeln?
• Ska den vänta till slutet för det mest kompletta slutliga försöket?

Det är detta de stegvisa lägena avgör.

2-Stage och 3-Stage bör därför inte ses som enkla tidsjusteringar. De förstås bättre som olika sätt att veckla ut FT8-avkodaren över tiden.

Hur bör de tolkas i verklig drift?

Översatt till praktiskt operatörsspråk blir skillnaden mycket konkret.

2-Stage

• bevarar responsiviteten ganska väl
• lägger till en tidigare kontroll
• behåller slutsteget ungefär vid Normal-tidpunkten
• förbättrar återvinningen av kandidater utan att pressa CPU-belastningen till extrem nivå

Med andra ord är det en balanserad stegvis strategi.

3-Stage

• tittar tidigt
• tittar igen mitt i cykeln
• behåller fortfarande en slutlig MTD-pass ungefär vid Late-tidpunkten
• pressar hårdare för att minska missade avkodningar
• men ökar CPU-belastningen i motsvarande grad

3-Stage är alltså det mest ambitiösa och mest aggressiva stegvisa läget som finns.

Om CPU:n har tillräcklig marginal kan det vara mycket attraktivt. Om CPU:n redan ligger nära sina tidsgränser betyder den teoretiska fördelen mindre än att helt enkelt hinna avsluta rent och stabilt.

På den punkten blir innebörden av lägena mycket tydligare:

Ytterligare en viktig punkt

De stegvisa lägena är inte bara ”flera avkodningar”; de tilldelar olika roller till olika steg

Ur ett något bredare perspektiv är det intressanta med 2-Stage och 3-Stage inte bara att avkodning triggas mer än en gång.

Den djupare poängen är att varje steg har en annan roll.

• tidigare steg är lättare och snabbare
• slutsteget är mer komplett
• CPU-arbetet fördelas över cykeln i stället för att förbrukas på en gång

Detta passar FT8 anmärkningsvärt väl.

I princip skulle man kunna vänta till slutet och fatta ett enda slutligt beslut. Men det finns ett verkligt värde i att leta efter återvinningsbara kandidater tidigare och sedan återkomma till problemet senare med mer information och tyngre bearbetning.

Därför handlar förståelsen av de stegvisa lägena inte bara om en enda inställning. Det handlar i själva verket om att förstå vad FT8-optimering betyder.

Praktisk tolkning

Hur bör varje läge faktiskt användas?

Efter all teknisk detalj är det värt att föra diskussionen tillbaka till praktisk drift.

2-Stage

Mycket praktiskt. Det bevarar responsiviteten samtidigt som det gör en tidigare kontroll. Slutsteget ligger inte lika sent som Late och blir därför inte onödigt krävande.

3-Stage

Det mest ambitiösa läget – i positiv mening.

Det tittar tidigt, tittar igen senare och håller ändå kvar en stark slutlig pass. Om det finns CPU-marginal och minskning av missade avkodningar är prioriterad är detta en av de mest intressanta inställningarna i hela panelen.

Early

Detta bör inte avfärdas som enbart ett reservläge för svag CPU. Det är också en mycket rationell stabilitetsstrategi. Om det är viktigare att undvika spill över till nästa cykel än att pressa ut den sista biten signal kan Early vara exakt rätt val.

Normal

Referenspunkten. För de flesta användare bör testningen börja här. Det gör jämförelsen med de andra lägena mycket enklare.

Late

Vänta längre, avkoda senare och fatta slutbeslutet med lite mer information. I teorin kan det hjälpa. I praktiken är det bara användbart om systemet fortfarande hinner avsluta pålitligt.

Sammantaget bör Decode Start-lägena inte förstås som ”personlig smak”. De är bättre att se som olika tidsstrategier.

Så vad är det egentligen vi optimerar?

Inte genomsnittlig prestanda, utan användningen av CPU-tid inom 15-sekunderscykeln

Vid det här laget bör den större principen vara tydlig.

FT8-optimering handlar inte bara om att göra allt ”kraftfullare”.

Det handlar om att avgöra:

• hur länge man ska vänta
• hur ofta man ska titta
• var de lättare passningarna ska göras
• var den tyngre slutliga passen ska göras
• och om hela processen förblir stabil från cykel till cykel

Med andra ord handlar detta om hur CPU-prestandan används, inte bara om hur mycket av den som finns.

Ur det perspektivet är Decode Start en av de viktigaste inställningarna i hela avkodarpanelen. Det som ser ut som ett litet UI-val är i själva verket ett direkt uttryck för tidsstrategi.

Därför är förståelsen av Decode Start mer än en förklaring av en inställning. Det är ett sätt att förstå den bakomliggande filosofin för beräkningsfördelning i FT8.

En mer personlig kommentar

Varför jag skriver detta över huvud taget

Hittills har jag försökt hålla diskussionen generell och teknisk. Men för sammanhangets skull bör jag klargöra min egen position.

Det beror inte på att JTDX saknar värde. Det beror på att programvara också bör bedömas efter vad som faktiskt finns tillgängligt, är tillräckligt moget att prova och är användbart just nu.

Om någon stannar kvar vid JTDX för att de verkligen föredrar dess gränssnitt är det helt förståeligt. Men om frågan gäller dagens avkodningsförmåga och praktiskt driftvärde förtjänar WSJT-X 3.1 improved seriös uppmärksamhet.

Min egen driftfilosofi

Hittills har jag fokuserat på allmänna principer. Men det kan vara nyttigt att förklara vart mitt eget resonemang leder i praktiken.

Min huvudsakliga stationsdator använder en Core i9-9900K. Den detaljen spelar roll – men inte bara för att det är en relativt stark CPU.

Det spelar också roll hur datorn är konfigurerad.

I Windows energialternativ sätter jag minsta processortillstånd till 100 %. Jag väntar alltså inte på att CPU:n ska höja klockfrekvensen efter att avkodningsbelastningen har uppstått. Jag föredrar att den redan kör med hög klockfrekvens, redo och väntande. I mitt fall ligger den i praktiken på 4,7 GHz.

Skälet är enkelt.

FT8-avkodning liknar inte långvarig videorendering där en jämn belastning pågår länge. Det är mycket mer som en kort koncentrerad beräkningsburst som återkommer med förutsägbara intervall.

I en sådan arbetslast är genomsnittlig benchmarkprestanda inte hela historien. Den initiala responsen spelar roll.

Om CPU:n befinner sig i ett lägre energiläge måste systemet:

• upptäcka belastningen
• ändra prestandaläge
• höja klockfrekvenserna
• justera spänningen
• och låta schemaläggaren reagera

Dessa fördröjningar kan vara obetydliga i långvariga arbetslaster. Men i korta och tidskänsliga burstar kan de spela större roll än man tror.

Därför anser jag följande:

Naturligtvis innebär det valet kompromisser.

• högre energiförbrukning
• mer värme
• lägre effektivitet
• mindre elegans ur energisparsynpunkt

Men på en stationsdator anser jag att avkodningsrespons och stabilitet är viktigare än elektrisk prydlighet.

Varför mina egna inställningar medvetet är aggressiva

Därför att 50 MHz är viktigt för mig

Mina inställningar speglar den filosofin ganska tydligt.

• Decoder Sensitivity: Subpass
• QSO Rx Frequency Sensitivity: High
• CPU:n väntar redan vid hög klockfrekvens

Detta är ingen konservativ konfiguration, och jag låtsas inte heller att den är det.

Men det finns ett skäl:

50 MHz betyder mycket för mig.

På 6 meter:

• kan konditionerna ändras snabbt
• kan aktiviteten plötsligt öka
• förekommer svaga och starka signaler ofta samtidigt
• och en kort öppning kan göra missade möjligheter särskilt frustrerande

Därför är jag beredd att använda CPU-resurser för att minska antalet missade avkodningar.

Det är därför jag använder:

• Subpass, för att söka djupare
• High sensitivity, för att vara mer aggressiv i återvinningen av kandidater
• och en energikonfiguration som håller CPU:n redo innan burst-belastningen kommer

Det handlar inte bara om att ”vrida upp allt eftersom mer måste vara bättre”.

Det är en medveten driftstrategi byggd kring:

• fokus på 50 MHz
• tillräcklig CPU-marginal
• betydelsen av snabb respons
• och en vilja att byta effektivitet mot möjligheter

Avslutande tankar

Den verkliga frågan är inte ”Vilket program är rätt?” utan ”Vilken optimeringsfilosofi passar din station?”

Om jag skulle sammanfatta hela diskussionen i en enda mening skulle det vara:

Ur det perspektivet är WSJT-X 3.1 improved en mycket intressant programvara. Inte bara för att den erbjuder fler alternativ, utan för att den ger operatören meningsfull kontroll över avkodarens tidsstrategi.

Och Decode Start är ett av de tydligaste exemplen på det.

2-Stage, 3-Stage, Early, Normal och Late är inte bara kosmetiska etiketter. De representerar olika sätt att fördela avkodningsarbetet över FT8-cykeln.

Och om man tittar närmare på de stegvisa lägena ser man en särskilt elegant idé under ytan:

Och låt mig slutligen säga detta som någon som verkligen uppskattar JTDX:

Om din anknytning till JTDX främst beror på dess gränssnitt är det en sak. Men om din fråga gäller dagens avkodningsförmåga under verkliga trafikförhållanden finns det liten anledning att tveka.