Capire le impostazioni del decoder FT8 in WSJT-X 3.1 improved

JTDX offre da tempo spiegazioni utili sul funzionamento delle sue impostazioni di decodifica. Quelle guide sono sempre state preziose, perché rendono molto chiaro un punto fondamentale:

Questo è il principio chiave.

Ma nel 2026, se il vostro obiettivo è la prestazione operativa in FT8/FT4, il quadro è cambiato.

WSJT-X 3.1 improved non è più semplicemente «WSJT-X standard con qualche funzione in più». Una quantità sostanziale di idee pratiche sulla decodifica — comprese idee molto familiari agli utenti JTDX — vi è stata integrata in modo significativo. A questo punto, confrontarlo superficialmente con WSJT-X 2.7 o versioni precedenti non è più particolarmente informativo.

Detto in modo più diretto: per l’operatore medio, WSJT-X 3.1 improved merita ormai di essere considerato seriamente come una scelta di prima fascia.

Aspettare la prossima versione GA di JTDX è naturalmente una scelta possibile. Ma se le priorità sono prestazioni pratiche del decoder, funzioni disponibili, attività di sviluppo e ciò che si può davvero installare e usare oggi, la strada più razionale è sfruttare ciò che è già disponibile ed è già valido.

Questo non significa affatto che JTDX non abbia più un ruolo. Se qualcuno è molto legato all’interfaccia JTDX, è un motivo perfettamente valido per continuare a usarlo. Ma è una questione diversa dalle capacità di decodifica e dall’ottimizzazione pratica.

Questo articolo non vuole essere l’ennesimo elenco di impostazioni consigliate. Voglio invece esaminare una domanda più profonda:

Che cosa significa davvero ottimizzare il decoder FT8? E, più precisamente, cosa fa realmente l’impostazione «Decode Start» in WSJT-X 3.1 improved?

Prima la conclusione pratica

Partite da Normal. Provate 3-Stage se avete margine di CPU. Usate Early se la riserva temporale è più importante.

Cominciamo dalla conclusione pratica.

La regola più importante nel tuning del decoder FT8 non è:

«Usare le impostazioni più pesanti disponibili.»

È invece:

«Usare le impostazioni più aggressive che il sistema riesce a completare in modo affidabile entro il ciclo di 15 secondi.»

È un modo di pensare molto diverso.

Come base, una configurazione simile alla seguente è ragionevole per molte stazioni:

Non è necessariamente la risposta definitiva, ma è un ottimo punto di partenza. Da lì potete spostarvi verso impostazioni più aggressive se la CPU ha margine. Se compaiono ritardi, completamenti troppo tardivi o instabilità, fate un passo indietro.

Per Decode Start, in sintesi pratica:

Questa è la sintesi pratica. Ma il motivo per cui questa impostazione conta è più interessante della sintesi stessa.

Decode Start non è semplicemente una preferenza per «iniziare prima o dopo». È strettamente legato a quanti stadi usa il decoder, a dove tali stadi sono collocati nel tempo e a come lo sforzo di decodifica viene distribuito nel ciclo FT8.

Questo è il vero cuore della questione.

Perché WSJT-X 3.1 improved merita oggi seria attenzione

Per capire perché tutto ciò conta, è utile fare un passo indietro e guardare il quadro generale.

Negli ultimi anni WSJT-X improved è diventato molto più di un ramo laterale con opzioni aggiuntive. Si è evoluto in una piattaforma pratica per idee di decodifica nate dall’uso reale, flessibilità dell’interfaccia e miglioramenti orientati all’operatività.

Dopo aver usato per un po’ le build improved attuali, una cosa diventa evidente:

la vecchia domanda «Come si confronta con WSJT-X 2.7 standard?» non è più la più utile.

Le domande più pertinenti oggi sono:

• Quanto è valido WSJT-X 3.1 improved come strumento pratico FT8/FT4 oggi?
• Quanta esperienza reale di decodifica è stata incorporata nel programma?
• E come dovrebbe un operatore regolarlo in funzione della propria stazione, CPU e priorità operative?

Per questo l’articolo non riguarda principalmente tabelle comparative. Riguarda il modo di usare il software in maniera intelligente.

E quando la discussione passa da «quali impostazioni esistono?» a «come vanno usate?», diventa necessario chiedersi che cosa significhino davvero all’interno di un ciclo FT8 di 15 secondi.

Il ruolo di ogni impostazione

«Più aggressivo» non significa automaticamente «migliore»

Prima di concentrarci su Decode Start, vale la pena chiarire come interpretare in generale le impostazioni del decoder FT8.

Un equivoco molto comune è questo:

impostazioni più pesanti devono significare prestazioni migliori.

Sembra plausibile, ma l’FT8 non funziona così.

Poiché l’FT8 lavora in cicli di 15 secondi, ciò che conta davvero è l’equilibrio tra quattro fattori:

1. Quanto segnale si aspetta prima di decodificare
2. Quanto in profondità si cercano i messaggi candidati
3. Se tutto il processo termina in tempo
4. Quanti falsi decode si è disposti a tollerare

Vista così, l’ottimizzazione FT8 non riguarda la «massima potenza». Riguarda il modo in cui si assegna un tempo di elaborazione limitato.

Questa prospettiva cambia il modo in cui ogni impostazione va considerata.

Numero di thread

Per la maggior parte degli operatori, Auto rimane il miglior punto di partenza. Forzare semplicemente più thread non garantisce un risultato migliore. Contano lo scheduling del sistema operativo, il carico in background, la topologia dei core e il comportamento complessivo del sistema.

Numero di passaggi di decodifica

Più passaggi possono aumentare la possibilità di recuperare segnali più deboli o ambigui, ma costano anche tempo CPU. Su un sistema potente, 3 passaggi possono valere la pena. Per molte stazioni, 2 è il valore predefinito più sensato. Su hardware limitato, 1 può essere la scelta più sicura.

Decoder Sensitivity

La lettura pratica è semplice:

• Minimum è più leggero
• Low thresholds è equilibrato
• Subpass è più aggressivo, ma più pesante

Subpass non offre prestazioni gratuite. È lavoro aggiuntivo in cambio della possibilità di recuperare segnali più deboli o difficili.

Nota su Fast / Normal / Deep rispetto al Multithreaded FT8 Decoder

Questa è una parte particolarmente facile da fraintendere. Poiché Fast / Normal / Deep compare nella stessa schermata di Multithreaded FT8 decoder, è naturale supporre che siano semplicemente varianti dello stesso controllo. Il sorgente suggerisce invece che siano tipi di impostazione diversi.

Prima di tutto, Fast / Normal / Deep è la tradizionale impostazione della profondità di decodifica: indica cioè al decoder quanto in profondità cercare. Nel percorso FT8 convenzionale monothread, questa profondità è direttamente legata al peso del decode e all’aggressività della ricerca.

Multithreaded FT8 decoder, invece, appartiene a un asse completamente diverso. La questione fondamentale è quale famiglia di motore di decodifica viene usata. Nel codice, profondità di decodifica e FT8 multithread sono parametri separati, non due nomi per la stessa cosa.

La sfumatura importante viene subito dopo. Quando FT8 opera realmente con il decoder multithread abilitato, il programma entra in un percorso MTD dedicato invece del vecchio percorso FT8 convenzionale. In quel percorso, le impostazioni che controllano davvero il comportamento sono quelle specifiche MTD — non i vecchi livelli Fast / Normal / Deep:

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

Il modo più preciso di interpretarlo è quindi questo: Fast / Normal / Deep esiste ancora e resta parte della logica generale di profondità di decodifica del programma, ma nel funzionamento FT8 MTD non è la manopola principale che determina quanto aggressivamente si comporta il decoder. Nel tuning pratico, i controlli davvero importanti sono quelli orientati al MTD — soprattutto Decoder Sensitivity, Decode Start, Number of decode passes e QSO Rx Frequency Sensitivity.

In altre parole, se volete regolare seriamente WSJT-X 3.1 improved per FT8 con il decoder multithread attivo, è meglio ragionare in termini di controlli specifici del comportamento MTD anziché assumere che Fast / Normal / Deep resti il principale fattore che determina il carattere del decoder. La vecchia profondità fa ancora parte del progetto; semplicemente non è più la leva pratica più importante una volta entrati nel percorso FT8 MTD.

QSO Rx Frequency Sensitivity

Non è semplicemente un’impostazione di velocità. Influenza quanto aggressivamente il decoder esamina l’attività attorno alla regione di frequenza del QSO e i candidati vicini.

• Low è conservativo
• Medium è equilibrato
• High è aggressivo

Come previsto, una maggiore aggressività può anche produrre più candidati dubbi e più rumore di decodifica.

Reduce False Decodes

Questa funzione merita più attenzione di quanta ne riceva talvolta. Trovare di più non è automaticamente meglio se i risultati aggiuntivi diventano sempre meno affidabili. Su bande affollate e in condizioni ambigue, il controllo dei falsi decode conta molto.

Considerate insieme, queste impostazioni non competono isolatamente per vedere quale sia la «più forte». Ognuna esprime una risposta diversa alla stessa domanda di fondo:

dentro una finestra molto limitata di 15 secondi, che cosa dovrebbe privilegiare il decoder?

E tra tutte, Decode Start è uno degli esempi più chiari e rivelatori.

La domanda principale

Cosa fa realmente «Decode Start»?

È qui che l’argomento diventa davvero interessante.

Nell’interfaccia utente, Decode Start offre cinque scelte:

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

A prima vista sembra un semplice controllo temporale:

iniziare a decodificare prima oppure più tardi.

Ma non è tutta la storia.

Osservando l’implementazione reale di WSJT-X 3.1 improved, questi modi sono gestiti internamente come:

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

Durante il funzionamento FT8, il programma usa valori come m_hsymStop, m_earlyDecode e m_earlyDecode2 per determinare quando vengono attivati gli stadi di decodifica.

Questo ci dice immediatamente una cosa:

Per rendere tutto più chiaro, iniziamo dai tre modi più semplici — Early, Normal e Late — e poi passiamo ai più rivelatori 2-Stage e 3-Stage.

Early / Normal / Late

Prima i tre modi più semplici

Cominciamo dalle opzioni più immediate.

Con il decoder FT8 multithread abilitato, i punti di arresto interni sono approssimativamente:

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

In termini di tempo, corrispondono approssimativamente a:

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

Il significato di base è intuitivo:

• Early rinuncia a un po’ di raccolta del segnale in cambio di maggiore margine CPU
• Late aspetta più a lungo per raccogliere un po’ più di informazione prima del decode
• Normal si colloca nel mezzo

Se Decode Start fosse composto soltanto da questi tre modi, sarebbe comunque un’impostazione utile — ma non particolarmente insolita.

A rendere la funzione molto più interessante è ciò che viene dopo:

2-Stage e 3-Stage.

Nota tecnica aggiuntiva

Cosa sono realmente 2-Stage e 3-Stage

Non semplicemente «prima» o «dopo», ma una strategia di decodifica a stadi che combina STD e MTD

Il change log di WSJT-X improved descrive 2-Stage e 3-Stage come modalità che «combinano intelligentemente entrambi i decoder», ottenendo quella che definisce la migliore prestazione di decodifica FT8 finora.

In altre parole, il software li presenta esplicitamente come un modo per combinare il decoder tradizionale STD (monothread) e il più recente MTD (multithread).

Ciò che il change log non spiega è l’ordine esatto di esecuzione né la relazione temporale tra i due. Questo diventa chiaro solo osservando l’implementazione.

A quel punto è evidente che 2-Stage e 3-Stage non sono semplicemente tempi di avvio differenti. Sono strategie di decodifica multistadio, e i diversi stadi non svolgono tutti lo stesso ruolo.

La divisione dei compiti tra STD e MTD

Qui STD indica il decoder FT8 tradizionale monothread. MTD indica il decoder FT8 multithread introdotto nella linea improved.

Osservando l’implementazione, i modi a stadi funzionano grosso modo così:

• gli stadi iniziali usano STD
• lo stadio finale usa MTD

Questa è l’idea progettuale fondamentale.

In altre parole, va inteso come una separazione deliberata tra:

• un controllo iniziale, più leggero e veloce
• e un passaggio di decodifica successivo e più completo

È una distinzione molto importante.

Un progetto più semplice potrebbe aspettare la fine dell’intervallo di ricezione e poi eseguire un unico decode pesante. WSJT-X improved non lo fa. Esegue invece ricerche intermedie dei candidati prima dello stadio finale e completa poi un decode più approfondito.

Questo rende chiaro che il progetto presta particolare attenzione a un problema centrale:

Prospettiva dello sviluppatore: a cosa serve davvero il pre-passaggio STD

Secondo Uwe Risse / DG2YCB, il pre-passaggio STD non è semplicemente un decode preliminare aggiuntivo. Il suo ruolo importante è portare nel flusso MTD il vantaggio del decode precoce noto dal decoder STD tradizionale.

Durante lo sviluppo sono state provate varie combinazioni di STD e MTD insieme a differenti parametri nzhsym. L’approccio attuale — STD come pre-passaggio e MTD come passaggio finale principale — ha dato i migliori risultati pratici.

Questo è un punto chiave. 2-Stage e 3-Stage non sono semplicemente meccanismi per «eseguire il decoder più di una volta». Sono progettati per combinare il comportamento leggero e precoce di STD con la maggiore potenza del decode finale MTD, usando più efficacemente il tempo CPU limitato del ciclo FT8 di 15 secondi.

Uwe osserva inoltre che 2-Stage raggiunge circa il 99,5% della resa di 3-Stage richiedendo molta meno potenza di calcolo. Questo spiega perché 2-Stage sia una raccomandazione pratica così forte per la maggior parte degli utenti, mentre 3-Stage resta l’opzione di massime prestazioni per i computer più veloci.

Cosa significa realmente 2-Stage

Nel decode reale on-air, 2-Stage consiste in un pre-passaggio STD a nzhsym=41, seguito dal passaggio MTD finale a nzhsym=49.

La sequenza reale è quindi:

• pre-passaggio STD @ nzhsym=41 — circa 11,8 secondi
• MTD finale @ nzhsym=49 — circa 14,1 secondi

Il punto fondamentale è che il secondo pre-passaggio STD a nzhsym=46 non fa parte di 2-Stage nel decode reale. Quel passaggio aggiuntivo appartiene solo a 3-Stage.

In altre parole, 2-Stage è ben bilanciato: effettua una prima ricognizione precoce e conclude con il passaggio MTD principale a nzhsym=49.

Poiché l’equilibrio fra resa di decodifica e costo CPU è così favorevole, 2-Stage è il modo che consiglierei per primo alla maggior parte degli utenti. Secondo Uwe Risse / DG2YCB raggiunge circa il 99,5% della resa di 3-Stage richiedendo molta meno potenza di calcolo. È quindi un compromesso pratico molto valido.

Cosa significa realmente 3-Stage

3-Stage aggiunge un secondo pre-passaggio STD a nzhsym=46 prima del passaggio MTD finale.

Nel decode reale on-air, la sequenza è:

• pre-passaggio STD @ nzhsym=41 — circa 11,8 secondi
• pre-passaggio STD @ nzhsym=46 — circa 13,2 secondi
• MTD finale @ nzhsym=50 — circa 14,4 secondi

3-Stage esegue quindi prima una ricognizione a 41, poi un ulteriore pre-passaggio STD a 46 e infine il passaggio MTD principale a 50.

Questo rende 3-Stage la modalità di decodifica FT8 con le prestazioni più elevate disponibile in WSJT-X 3.1 improved.

Serve però un’importante avvertenza pratica. Il guadagno aggiuntivo di 3-Stage non è proporzionale all’aumento dell’uso della CPU. Uwe Risse / DG2YCB osserva che 2-Stage raggiunge già circa il 99,5% della resa di 3-Stage, quindi il guadagno residuo è piccolo rispetto alla potenza di calcolo aggiuntiva richiesta.

Su computer meno potenti, il pre-passaggio STD aggiuntivo a nzhsym=46 può consumare troppo tempo e, nel peggiore dei casi, interferire con il fondamentale passaggio MTD finale a nzhsym=50. Per questo 3-Stage va considerato una modalità di fascia alta: è l’opzione estrema per chi dispone di hardware potente, ma non è automaticamente la raccomandazione migliore per tutti.

Va inteso come «prima STD, MTD alla fine», non «prima MTD, poi STD»

È uno dei punti più facili da fraintendere.

Poiché il change log afferma che 2-Stage e 3-Stage combinano STD e MTD, alcuni lettori potrebbero immaginare un modello di questo tipo:

• MTD viene eseguito per primo
• poi STD completa ciò che MTD non ha decodificato

Ma il comportamento reale on-air non indica questo.

L’interpretazione più corretta è l’opposto:

• STD effettua il passaggio o i passaggi di ricognizione iniziali e più leggeri
• MTD esegue il decode finale e più approfondito

In uso reale, la distinzione è:

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

La distinzione è importante. 3-Stage offre la massima prestazione di decodifica possibile, ma 2-Stage è la raccomandazione più pratica per la maggior parte degli utenti perché evita il costo CPU del secondo pre-passaggio STD a nzhsym=46.

Perché usare STD negli stadi iniziali?

Anche questo è rivelatore.

Se l’obiettivo fosse semplicemente «eseguire più volte il decoder», ci si potrebbe aspettare che il software esegua MTD ripetutamente in ogni stadio. Ma non è così.

La ragione probabile è semplice:

gli stadi iniziali devono essere leggeri e veloci.

In quei momenti iniziali la ricezione non è ancora completa. La quantità di informazioni disponibili è inferiore a quella dello stadio finale. Eseguire ogni volta a piena potenza la logica di decodifica più pesante non sarebbe necessariamente l’uso più efficiente del limitato tempo CPU.

Il software usa quindi STD per controllare rapidamente ed economicamente i punti iniziali e riserva MTD al passaggio finale, più importante.

Non è un semplice dettaglio implementativo. Riflette una filosofia di decodifica estremamente adatta all’FT8 come carico breve, a raffica e sensibile al timing.

Il codice suggerisce inoltre che gli stadi iniziali usano un’elaborazione più vincolata rispetto allo stadio finale, rafforzando l’idea che queste modalità non siano semplici passaggi ripetuti, ma una progressione a stadi in cui ogni passaggio ha un ruolo diverso.

L’essenza di 2-Stage e 3-Stage è l’allocazione del tempo

In fondo, 2-Stage e 3-Stage riguardano davvero una sola cosa:

come distribuire lo sforzo di calcolo all’interno di un ciclo di 15 secondi.

• Il decoder dovrebbe dare un’occhiata prima?
• Dovrebbe effettuare un ulteriore controllo a metà ciclo?
• Dovrebbe aspettare fino alla fine per il tentativo finale più completo?

È questo che decidono le modalità a stadi.

2-Stage e 3-Stage non vanno quindi considerati semplici regolazioni temporali. È meglio interpretarli come modi differenti di distribuire nel tempo il decoder FT8.

Come interpretarli nell’uso reale?

Tradotta in termini operativi, la distinzione diventa molto concreta.

2-Stage

• mantiene abbastanza bene la reattività
• aggiunge un controllo più precoce
• mantiene lo stadio finale vicino al timing Normal
• migliora il recupero dei candidati senza portare il carico CPU agli estremi

In altre parole, è una strategia a stadi equilibrata.

3-Stage

• controlla presto
• controlla di nuovo a metà
• mantiene comunque un passaggio MTD finale vicino al timing Late
• spinge più forte per ridurre i decode mancati
• ma aumenta di conseguenza il carico CPU

3-Stage è quindi la modalità a stadi più ambiziosa e aggressiva disponibile.

Se la CPU ha margine sufficiente può essere estremamente interessante. Se invece è già vicina ai propri limiti temporali, il vantaggio teorico conta meno del semplice fatto di terminare il processo in modo pulito.

A questo punto il significato di queste modalità diventa molto più chiaro:

Un altro punto importante

Le modalità a stadi non sono soltanto «decode multipli»: assegnano ruoli diversi ai diversi stadi

Da una prospettiva più ampia, ciò che rende 2-Stage e 3-Stage così interessanti non è soltanto il fatto che attivino il decode più di una volta.

Il punto più profondo è che ogni stadio svolge un ruolo diverso.

• gli stadi iniziali sono più leggeri e veloci
• lo stadio finale è più completo
• lo sforzo CPU è distribuito lungo il ciclo invece di essere speso tutto in una volta

Questo si adatta molto bene all’FT8.

In linea di principio si potrebbe aspettare la fine e prendere una sola decisione finale. Ma c’è un valore reale nel cercare prima i candidati recuperabili e poi riesaminare il problema più tardi con più informazioni e un’elaborazione più approfondita.

Per questo capire le modalità a stadi non significa soltanto capire una singola impostazione. Significa davvero capire che cosa sia l’ottimizzazione FT8.

Interpretazione pratica

Come va usata concretamente ogni modalità?

Dopo tutti i dettagli tecnici, vale la pena tornare al linguaggio operativo.

2-Stage

Molto pratico. Mantiene la reattività pur effettuando un controllo precoce. Lo stadio finale non arriva tardi come Late, evitando così di diventare inutilmente oneroso.

3-Stage

La modalità più ambiziosa — in senso positivo.

Controlla presto, ricontrolla più tardi e mantiene comunque un forte passaggio finale. Se c’è margine CPU e ridurre i decode mancati è una priorità, è una delle impostazioni più interessanti dell’intero pannello.

Early

Non va liquidato come semplice soluzione di ripiego per CPU deboli. È anche una strategia di stabilità molto razionale. Se evitare di sconfinare nel ciclo successivo è più importante che estrarre l’ultimo frammento di segnale, Early può essere esattamente la scelta giusta.

Normal

Il punto di riferimento. Per la maggior parte degli utenti, i test dovrebbero iniziare qui. Rende molto più semplice il confronto con gli altri modi.

Late

Aspetta più a lungo, decodifica più tardi e prende la decisione finale con un po’ più d’informazione. In teoria può aiutare; in pratica è utile solo se il sistema continua a terminare in modo affidabile.

Nel complesso, i modi Decode Start non vanno interpretati come una questione di «gusto personale». È meglio considerarli diverse strategie temporali.

Quindi, che cosa stiamo realmente ottimizzando?

Non le prestazioni medie, ma l’uso del tempo CPU all’interno del ciclo di 15 secondi

A questo punto il principio generale dovrebbe essere chiaro.

Ottimizzare l’FT8 non significa semplicemente rendere tutto «più potente».

Significa decidere:

• quanto aspettare
• con quale frequenza controllare
• dove effettuare i passaggi più leggeri
• dove effettuare il passaggio finale più pesante
• e se l’intero processo rimane stabile da un ciclo all’altro

In altre parole, la questione è come vengono usate le prestazioni della CPU, non soltanto quante prestazioni esistono.

Da questa prospettiva, Decode Start è una delle impostazioni più importanti dell’intero pannello del decoder. Quella che sembra una piccola opzione dell’interfaccia è in realtà un’espressione diretta della strategia temporale.

Per questo comprendere Decode Start è più che spiegare un’impostazione: è un modo per capire la filosofia di fondo dell’allocazione computazionale nell’FT8.

Una nota più personale

Perché sto scrivendo tutto questo

Fin qui ho cercato di mantenere la discussione generale e tecnica. Ma per dare il giusto contesto devo chiarire la mia posizione personale.

Non perché JTDX non abbia valore, ma perché il software va giudicato anche per ciò che è concretamente disponibile, abbastanza maturo da essere provato e utile adesso.

Se qualcuno resta con JTDX perché ne preferisce davvero l’interfaccia, è assolutamente comprensibile. Ma se la domanda riguarda capacità di decodifica attuali e valore operativo pratico, WSJT-X 3.1 improved merita seria attenzione.

La mia filosofia operativa

Fin qui mi sono concentrato sui principi generali. Può però essere utile spiegare dove mi porta concretamente il mio modo di pensare.

Il mio PC principale usa un Core i9-9900K. Il dettaglio conta, ma non soltanto perché è una CPU relativamente potente.

Conta anche il modo in cui la macchina è configurata.

Nelle impostazioni di alimentazione di Windows imposto al 100% lo stato minimo del processore. In altre parole, non aspetto che la CPU aumenti la frequenza dopo l’arrivo del carico di decodifica: preferisco che sia già ad alta frequenza, pronta. Nel mio caso rimane di fatto a 4,7 GHz.

Il motivo è semplice.

Il decode FT8 non assomiglia a un rendering video prolungato con un carico costante per molto tempo. È molto più simile a una breve raffica di lavoro concentrato, ripetuta a intervalli prevedibili.

In quel tipo di carico, la prestazione media nei benchmark non racconta tutta la storia. Conta la risposta iniziale.

Se la CPU si trova in uno stato a basso consumo, il sistema deve:

• rilevare il carico
• cambiare stato prestazionale
• aumentare la frequenza
• regolare la tensione
• e lasciare reagire lo scheduler

Questi ritardi possono essere trascurabili nei carichi prolungati, ma in brevi raffiche sensibili al timing possono contare più di quanto si pensi.

Ecco perché penso questo:

Naturalmente questa scelta comporta compromessi.

• maggiore consumo energetico
• più calore
• minore efficienza
• meno eleganza dal punto di vista del risparmio energetico

Ma su un PC di stazione considero reattività e stabilità del decode più importanti dell’efficienza elettrica.

Perché le mie impostazioni sono volutamente aggressive

Perché i 50 MHz per me contano

Le mie impostazioni riflettono piuttosto chiaramente questa filosofia.

• Decoder Sensitivity: Subpass
• QSO Rx Frequency Sensitivity: High
• CPU già pronta ad alta frequenza

Non è una configurazione conservativa e non fingo che lo sia.

Ma c’è un motivo:

i 50 MHz per me contano moltissimo.

Sui 6 metri:

• le condizioni possono cambiare rapidamente
• l’attività può aumentare all’improvviso
• segnali deboli e forti spesso coesistono
• e una breve apertura può rendere particolarmente frustranti le occasioni mancate

Per questo sono disposto a spendere risorse CPU per ridurre i decode mancati.

Ecco perché uso:

• Subpass, per cercare più in profondità
• sensibilità High, per essere più aggressivo nel recupero dei candidati
• e una configurazione di alimentazione che mantiene la CPU pronta prima dell’arrivo del carico a raffica

Non significa semplicemente «alzare tutto perché di più deve essere meglio».

È una strategia operativa deliberata costruita attorno a:

• priorità ai 50 MHz
• margine CPU sufficiente
• importanza della velocità di risposta
• e disponibilità a sacrificare efficienza in cambio di opportunità

Considerazioni finali

La vera domanda non è «Quale programma ha ragione?», ma «Quale filosofia di tuning si adatta alla vostra stazione?»

Se dovessi ridurre l’intera discussione a una sola frase, sarebbe questa:

Vista da questa prospettiva, WSJT-X 3.1 improved è un software molto interessante. Non semplicemente perché offre più opzioni, ma perché dà all’operatore un controllo significativo sulla strategia temporale del decoder.

E Decode Start è uno degli esempi più chiari.

2-Stage, 3-Stage, Early, Normal e Late non sono semplici etichette. Rappresentano modi diversi di distribuire lo sforzo di decodifica lungo il ciclo FT8.

E osservando più da vicino i modi a stadi si vede un’idea particolarmente elegante:

Infine, lasciatemi dire questo da persona che apprezza davvero JTDX:

Se il legame con JTDX nasce dalla sua interfaccia, è una cosa. Ma se la preoccupazione è la capacità di decodifica odierna in condizioni operative reali, ci sono pochi motivi per esitare.