Field trial · 7.074 & 18.100 MHz FT8

Decodium out-decoded JTDX and WSJT-X in every round

Four decoders, one shared antenna feed, four rounds over 70 minutes. Decodium came out ahead every single time — by 27% to 66%, depending on the app and the five minutes of band noise the round happened to catch.

+27–53%vs JTDX, across 4 rounds
+31–66%vs WSJT-X, across 4 rounds
133cycles logged, 4 rounds
Live cycle comparison · avg. decodes / 15s cycle, Rounds 1–4 Replayed from trial data
Decodium38.2 / cycle avg.
0decoded
JTDX26.7 / cycle avg.
0decoded
WSJT-X24.8 / cycle avg.
0decoded
MSHV3.2 / cycle avg.
0decoded
Same shared antenna feed, same 15-second FT8 cycle — averaged from the four rounds on 7.074 MHz above. Not a live feed: it replays the averages already published in this article's own tables, one 15-second cycle at a time.

When a weak signal gets decoded, it is the software doing it, not the radio. Four FT8 decoders — Decodium 1.0.611, JTDX 2.2.159, WSJT-X 3.2.0 and MSHV 2.76.5 — were pointed at the same antenna and the same audio feed on 7.074 MHz, and left to decode the same air for 70 minutes. Nothing about the antenna, the radio, or the band changed between them: whatever difference showed up came from the decoding software alone.

Method

All four applications ran at the same time against one shared soundcard input. For every 15-second cycle, the decoded message text logged by each app was pulled from its own ALL.TXT, de-duplicated, and compared as a set of unique messages — not as a raw line count, since Decodium's own log writes each decode twice (a known quirk, collapsed out before counting).

Four rounds ran over roughly 70 minutes: a baseline round with every app on its stock settings, then three rounds after JTDX, WSJT-X and MSHV were each raised to the deepest search settings this trial could find in their configuration files. Decodium's settings were never touched, at any point. The fourth round was taken 40 minutes after the second, specifically to see whether the margin would settle down with time.

Round 1 · Baseline settings01:16–01:21 UTC · 22 cycles
ApplicationDecodesPer cyclevs Decodium
Decodium89640.7
JTDX61628.0+45.5%
WSJT-X54124.6+65.6%
MSHV462.1+1839%
Round 2 · Deep-search settings raised01:41–01:47 UTC · 27 cycles
ApplicationDecodesPer cyclevs Decodium
Decodium85031.5
JTDX66824.7+27.2%
WSJT-X65024.1+30.8%
MSHV782.9+989%
Round 3 · Same settings, longer window01:51–02:01 UTC · 41 cycles
ApplicationDecodesPer cyclevs Decodium
Decodium152637.2
JTDX104225.4+46.4%
WSJT-X96523.5+58.1%
MSHV1393.4+998%
Round 4 · Same settings, 40 minutes later02:13–02:23 UTC · 43 cycles
ApplicationDecodesPer cyclevs Decodium
Decodium187243.5
JTDX122428.5+52.9%
WSJT-X116727.1+60.4%
MSHV1844.3+917%

Decodium's own count moved with the band, not with anything on its side: 40.7, then 31.5, then 37.2, then 43.5 decodes per cycle, with nothing ever changed in its settings. Round 2's narrower margin looks less like an effect of raising the competitors' settings and more like a quieter five minutes on the band — and Round 4, forty minutes later under the same settings, produced the widest JTDX margin of the night. The lead never settled to one number.

What changed between Round 1 and Round 2

Every other app's own configuration file, edited with the app closed and reopened to confirm the change survived. Decodium was left untouched throughout.

JTDX

Aggressive1 → 5
FT8Sensitivity2 → 3
NFT8Cycles1 → 3

NDepth was already at 3 (max). Aggressive and NFT8Cycles were raised to match WSJT-X's own values — the only evidence available for their ceiling.

WSJT-X

MultithreadedFT8decoderfalse → true

FT8AP, Aggressive (5), NDepth (3), FT8Sensitivity (3) and NFT8Cycles (3) were already at their apparent maximum once the app had written its live settings back to disk on a clean close.

MSHV

deep_search_decode (FT8)0 → 1

dec_depth and ap_decode were already at 3 and 1 for FT8. Deep search was the one relevant knob found off. MSHV runs elevated on this machine and had to be closed and relaunched by the operator.

A later check — 18.100 MHz, midday

A different band and a different time of day, run hours after the four rounds above, included specifically to answer one question: has MSHV caught up? It is not comparable in absolute terms to Rounds 1–4.

All four on 18.100 MHz, JTDX back after a restart12:41–12:45 UTC · 18 cycles
ApplicationDecodesPer cyclevs Decodium
Decodium95553.1
MSHV60533.6+57.9%
WSJT-X58832.7+62.4%
JTDX55931.1+70.8%

Decodium's lead held, same as every round the night before. The real change is further down the table: MSHV is no longer the outlier. It edged out both WSJT-X (+2.9%) and the just-restarted JTDX (+8.2%), sanity-checked by message overlap with Decodium (36 of 43 MSHV messages in a sample cycle matched exactly). Three apps now sit within 9% of each other — only Decodium stands apart, by more than 55% over all three.

An earlier attempt at this same check (12:23–12:33 UTC) had to be discarded: JTDX's own log had gone silent at 10:42 UTC and stayed at zero for almost two hours despite the process staying alive — a stall, not a reception result. It was restarted before the run above.

The limits of this test

!One shared feed, not four receivers. All four decoders read the same soundcard input, so this measures decoding software on identical audio, not four independent radios.
!The margin moved with band conditions, not just settings. Decodium's own count swung from 40.7 to 31.5 to 37.2 to 43.5 decodes/cycle with nothing changed on its side.
!JTDX's Hint option was on throughout, which lets it guess callsigns from history and should inflate its count if anything — working against Decodium's margin, not for it.
!WSJT-X logged 0.000 MHz after a restart (a CAT re-sync issue), confirmed by message-text overlap with Decodium to still be decoding live 7.074 MHz audio — a logging label, not a reception problem.
!MSHV did not climb steadily through the night (2.1 → 2.9 → 3.4 → 4.3 → back to 2.7 on a fifth, unlisted overnight check) — it oscillates like the others, on a much lower scale, right up until the 18.100 MHz daytime check.
!JTDX stalled for almost two hours before the 18.100 MHz check — its process stayed alive but its own log wrote zero lines between 10:42 and 12:41 UTC. Restarted, it resumed decoding normally.

Verdict

Decodium held a positive, repeatable lead over both JTDX and WSJT-X in all four rounds, even after those two were raised to the deepest search settings this trial could find. The size of that lead did not settle: +27% to +53% against JTDX, +31% to +66% against WSJT-X, depending on which few minutes of band noise the window happened to catch. Round 4 — run specifically to test whether the narrower Round 2 margin would hold — instead produced the widest JTDX margin of the night, which argues against a genuine settling effect from the settings change.

133 cycles across four rounds is enough to say the lead is real; it is not enough to quote a single number with confidence. A longer trial — thirty minutes to an hour in one continuous run, ideally spanning a full band opening — is the next step before treating any one figure as the answer.

fastldpc, Decodium's own LDPC decoder, is a separate piece of work already documented at ft2.it/fastldpc; this shootout measures the full decoding chain end to end, not one component in isolation.

73 de Martino IU8LMC


Versione italiana
Prova sul campo · FT8 7.074 e 18.100 MHz

Decodium ha decodificato più di JTDX e WSJT-X in ogni round

Quattro decodificatori, un solo feed d'antenna condiviso, quattro round in 70 minuti. Decodium è arrivato davanti ogni singola volta — dal 27% al 66% in più, a seconda dell'app e dei cinque minuti di rumore di banda toccati in sorte a ciascun round.

+27–53%su JTDX, in 4 round
+31–66%su WSJT-X, in 4 round
133cicli registrati, 4 round
Confronto dei cicli, in diretta · decodifiche medie / ciclo da 15s, Round 1–4 Riprodotto dai dati della prova
Decodium38,2 / ciclo medio
0decodificati
JTDX26,7 / ciclo medio
0decodificati
WSJT-X24,8 / ciclo medio
0decodificati
MSHV3,2 / ciclo medio
0decodificati
Stesso feed d'antenna condiviso, stesso ciclo FT8 da 15 secondi — media dei quattro round sui 7.074 MHz qui sopra. Non è un flusso live: ripropone le medie già pubblicate nelle tabelle di questo articolo, un ciclo da 15 secondi alla volta.

Quando un segnale debole viene decodificato, è il software a farlo, non la radio. Quattro decodificatori FT8 — Decodium 1.0.611, JTDX 2.2.159, WSJT-X 3.2.0 e MSHV 2.76.5 — sono stati puntati sulla stessa antenna e sullo stesso feed audio a 7.074 MHz, e lasciati a decodificare la stessa aria per 70 minuti. Niente è cambiato fra loro nell'antenna, nella radio o nella banda: qualunque differenza sia emersa viene dal solo software di decodifica.

Metodo

Tutte e quattro le applicazioni hanno girato insieme sullo stesso ingresso audio della scheda. Per ogni ciclo da 15 secondi, il testo dei messaggi decodificati da ciascuna app è stato estratto dal proprio ALL.TXT, deduplicato e confrontato come insieme di messaggi unici — non come semplice conteggio di righe, perché il log di Decodium scrive ogni decodifica due volte (un vizio noto, eliminato prima del conteggio).

Quattro round in circa 70 minuti: un round di base con ogni app alle impostazioni di fabbrica, poi tre round dopo aver portato JTDX, WSJT-X e MSHV alle impostazioni di ricerca più profonda reperibili nei rispettivi file di configurazione. Le impostazioni di Decodium non sono mai state toccate, in nessun momento. Il quarto round è stato preso 40 minuti dopo il secondo, apposta per vedere se il margine si sarebbe assestato col tempo.

Round 1 · Impostazioni di base01:16–01:21 UTC · 22 cicli
ApplicazioneDecodifichePer ciclovs Decodium
Decodium89640,7
JTDX61628,0+45,5%
WSJT-X54124,6+65,6%
MSHV462,1+1839%
Round 2 · Impostazioni di ricerca profonda01:41–01:47 UTC · 27 cicli
ApplicazioneDecodifichePer ciclovs Decodium
Decodium85031,5
JTDX66824,7+27,2%
WSJT-X65024,1+30,8%
MSHV782,9+989%
Round 3 · Stesse impostazioni, finestra più lunga01:51–02:01 UTC · 41 cicli
ApplicazioneDecodifichePer ciclovs Decodium
Decodium152637,2
JTDX104225,4+46,4%
WSJT-X96523,5+58,1%
MSHV1393,4+998%
Round 4 · Stesse impostazioni, 40 minuti dopo02:13–02:23 UTC · 43 cicli
ApplicazioneDecodifichePer ciclovs Decodium
Decodium187243,5
JTDX122428,5+52,9%
WSJT-X116727,1+60,4%
MSHV1844,3+917%

Il conteggio di Decodium si è mosso con la banda, non per cause sue: 40,7, poi 31,5, poi 37,2, poi 43,5 decodifiche per ciclo, senza mai toccare le sue impostazioni. Il margine più stretto del Round 2 sembra meno un effetto delle impostazioni alzate sui concorrenti e più cinque minuti più tranquilli in banda — e il Round 4, quaranta minuti dopo con le stesse impostazioni, ha prodotto il margine più ampio della notte su JTDX. Il margine non si è mai assestato su un numero solo.

Cosa è cambiato tra il Round 1 e il Round 2

Il file di configurazione di ogni altra app, modificato con l'app chiusa e riaperta per verificare che il cambiamento fosse sopravvissuto. Decodium è rimasto intoccato per tutto il tempo.

JTDX

Aggressive1 → 5
FT8Sensitivity2 → 3
NFT8Cycles1 → 3

NDepth era già a 3 (il massimo). Aggressive e NFT8Cycles sono stati alzati per uguagliare i valori di WSJT-X, l'unico riferimento disponibile per il loro tetto.

WSJT-X

MultithreadedFT8decoderfalse → true

FT8AP, Aggressive (5), NDepth (3), FT8Sensitivity (3) e NFT8Cycles (3) erano già al massimo apparente, una volta che l'app aveva scritto le sue impostazioni live su disco con una chiusura pulita.

MSHV

deep_search_decode (FT8)0 → 1

dec_depth e ap_decode erano già a 3 e 1 per FT8. Deep search era l'unica leva rilevante trovata spenta. MSHV gira con privilegi elevati su questa macchina ed è dovuto essere chiuso e rilanciato dall'operatore.

Un controllo successivo, 18.100 MHz, mezzogiorno

Una banda diversa e un'ora diversa del giorno, effettuato ore dopo i quattro round precedenti, incluso apposta per rispondere a una domanda: MSHV ha recuperato terreno? Non è confrontabile in termini assoluti con i Round 1–4.

Tutte e quattro su 18.100 MHz, JTDX di nuovo dopo un riavvio12:41–12:45 UTC · 18 cicli
ApplicazioneDecodifichePer ciclovs Decodium
Decodium95553,1
MSHV60533,6+57,9%
WSJT-X58832,7+62,4%
JTDX55931,1+70,8%

Il vantaggio di Decodium ha tenuto, come in ogni round della notte precedente. Il vero cambiamento è più in basso nella tabella: MSHV non è più il fuori scala. Ha superato sia WSJT-X (+2,9%) sia il JTDX appena riavviato (+8,2%), verificato con la sovrapposizione dei messaggi con Decodium (36 messaggi MSHV su 43 combaciano esattamente in un ciclo campione). Tre app ora stanno entro il 9% l'una dall'altra, solo Decodium resta a parte, per oltre il 55% su tutte e tre.

Un primo tentativo dello stesso controllo (12:23–12:33 UTC) è stato scartato: il log di JTDX era rimasto muto dalle 10:42 UTC e a zero per quasi due ore, nonostante il processo restasse attivo, uno stallo, non un risultato di ricezione. È stato riavviato prima del giro qui sopra.

I limiti di questa prova

!Un solo feed condiviso, non quattro ricevitori. Tutti e quattro i decodificatori leggono lo stesso ingresso della scheda audio: questo misura il software di decodifica su audio identico, non quattro radio indipendenti.
!Il margine si è mosso con le condizioni di banda, non solo con le impostazioni. Il conteggio di Decodium è oscillato da 40,7 a 31,5 a 37,2 a 43,5 decodifiche al ciclo senza cambiare nulla dal suo lato.
!L'opzione Hint di JTDX era attiva per tutta la prova, e permette di indovinare i nominativi dalla cronologia: dovrebbe gonfiare il suo conteggio, se mai, giocando contro il margine di Decodium, non a favore.
!WSJT-X ha registrato 0.000 MHz dopo un riavvio, un problema di risincronizzazione CAT, confermato dalla sovrapposizione col testo dei messaggi di Decodium a essere comunque in decodifica live sui 7.074 MHz: un'etichetta di log, non un problema di ricezione.
!MSHV non è salito in modo costante nel corso della notte (2,1 poi 2,9 poi 3,4 poi 4,3 poi di nuovo 2,7 in un quinto controllo notturno non elencato): oscilla come gli altri, su una scala molto più bassa, fino al controllo diurno sui 18.100 MHz.
!JTDX si è bloccato per quasi due ore prima del controllo sui 18.100 MHz: il processo restava attivo ma il suo log non ha scritto righe fra le 10:42 e le 12:41 UTC. Riavviato, ha ripreso a decodificare normalmente.

Verdetto

Decodium ha mantenuto un vantaggio positivo e ripetibile su JTDX e WSJT-X in tutti e quattro i round, anche dopo che i due sono stati portati alle impostazioni di ricerca più profonda reperibili in questa prova. L'ampiezza di quel vantaggio non si è assestata: dal +27% al +53% su JTDX, dal +31% al +66% su WSJT-X, a seconda dei pochi minuti di rumore di banda catturati dalla finestra. Il Round 4, effettuato apposta per verificare se il margine più stretto del Round 2 avrebbe tenuto, ha invece prodotto il margine più ampio della notte su JTDX: un risultato che va contro un vero effetto di assestamento dovuto al cambio di impostazioni.

133 cicli in quattro round bastano per dire che il vantaggio è reale; non bastano per citare un singolo numero con sicurezza. Una prova più lunga, da trenta minuti a un'ora in un'unica sessione continua, idealmente per l'intera durata di un'apertura di banda, è il prossimo passo prima di trattare una singola cifra come la risposta.

fastldpc, il decodificatore LDPC di Decodium, è un lavoro a parte già documentato su ft2.it/fastldpc; questo shootout misura l'intera catena di decodifica, non un solo componente isolato.

73 de Martino IU8LMC