Comprendre les réglages du décodeur FT8 dans WSJT-X 3.1 improved

JTDX propose depuis longtemps des explications utiles sur le fonctionnement de ses réglages de décodeur. Ces guides ont toujours été précieux, car ils mettent très clairement en évidence un point essentiel :

C’est le principe fondamental.

Mais en 2026, si votre priorité est la performance en FT8/FT4, la discussion a changé.

WSJT-X 3.1 improved n’est plus simplement « WSJT-X standard avec quelques fonctions supplémentaires ». Une part importante de la réflexion pratique autour du décodage — y compris des idées très familières aux utilisateurs de JTDX — y a été intégrée de manière significative. À ce stade, le comparer sommairement à WSJT-X 2.7 ou à des versions antérieures n’est, franchement, plus très instructif.

Pour le dire plus directement : pour l’opérateur moyen, WSJT-X 3.1 improved mérite désormais d’être considéré très sérieusement comme un choix de premier plan.

Attendre la prochaine version GA de JTDX est bien sûr une position possible. Mais si vos priorités sont les performances réelles du décodeur, les fonctions disponibles, l’activité de développement et ce que vous pouvez réellement installer et utiliser aujourd’hui, il est plus rationnel d’exploiter ce qui existe déjà et fonctionne déjà très bien.

Cela ne signifie nullement que JTDX n’a plus sa place. Si quelqu’un est profondément attaché à l’interface de JTDX, c’est une raison parfaitement valable de continuer à l’utiliser. Mais c’est une question différente de celle des capacités de décodage et de l’optimisation pratique.

Cet article ne cherche pas à être une simple liste supplémentaire de réglages recommandés. Je souhaite plutôt examiner une question plus profonde :

Que signifie réellement optimiser le décodeur FT8 ? Et plus précisément, que fait vraiment le réglage « Decode Start » dans WSJT-X 3.1 improved ?

La conclusion pratique d’abord

Commencez par Normal. Essayez 3-Stage si votre processeur dispose d’une marge suffisante. Utilisez Early si la marge temporelle est plus importante.

Commençons par la conclusion pratique.

La règle la plus importante pour régler le décodeur FT8 n’est pas :

« Utiliser les réglages les plus lourds disponibles. »

Elle est plutôt :

« Utiliser les réglages les plus agressifs que votre système peut terminer de façon fiable dans le cycle de 15 secondes. »

C’est une façon de penser très différente.

Comme point de départ, une configuration du type suivant est raisonnable pour de nombreuses stations :

Ce n’est pas nécessairement la configuration finale, mais c’est un excellent point de départ. Ensuite, vous pouvez aller vers des réglages plus agressifs si votre processeur dispose de marge. Si vous observez du retard, des traitements qui finissent trop tard ou de l’instabilité, revenez en arrière.

Concernant Decode Start, voici un résumé pratique :

Voilà pour le résumé pratique. Mais la raison pour laquelle ce réglage est important est plus intéressante que le résumé lui-même.

Decode Start n’est pas simplement une préférence pour « commencer plus tôt ou plus tard ». Il est étroitement lié au nombre d’étapes utilisées par le décodeur, à leur position dans le temps et à la manière dont l’effort de décodage est réparti sur le cycle FT8.

C’est là le véritable cœur du sujet.

Pourquoi WSJT-X 3.1 improved mérite aujourd’hui une attention sérieuse

Pour comprendre pourquoi cela compte, il est utile de prendre du recul et d’observer la situation dans son ensemble.

Au cours des dernières années, WSJT-X improved est devenu bien plus qu’une branche parallèle enrichie de quelques options. Il a évolué vers une plate-forme pratique intégrant des idées de décodage issues du terrain, une interface plus flexible et des améliorations orientées exploitation.

Dès que l’on passe du temps avec les versions improved actuelles, une chose devient évidente :

l’ancienne question « Comment cela se compare-t-il à WSJT-X 2.7 standard ? » n’est plus la plus utile.

Les questions réellement pertinentes sont désormais :

• Quelle est aujourd’hui la qualité de WSJT-X 3.1 improved comme outil pratique d’exploitation FT8/FT4 ?
• Quelle part de réflexion issue de l’exploitation réelle a été intégrée au décodeur ?
• Et comment un opérateur doit-il le régler en fonction de sa station, de son processeur et de ses priorités ?

C’est pourquoi cet article ne porte pas principalement sur des tableaux comparatifs. Il porte sur la manière d’utiliser intelligemment le logiciel.

Et dès que la discussion passe de « quels réglages existent ? » à « comment faut-il les utiliser ? », il devient nécessaire de demander ce que ces réglages signifient réellement à l’intérieur d’un cycle FT8 de 15 secondes.

Le rôle de chaque réglage

« Plus agressif » ne signifie pas automatiquement « meilleur »

Avant de nous concentrer sur Decode Start, il vaut la peine de préciser comment les réglages du décodeur FT8 doivent être compris de manière générale.

Une idée fausse très répandue est la suivante :

des réglages plus lourds doivent forcément donner de meilleures performances.

Cela semble plausible, mais le FT8 ne fonctionne pas ainsi.

Comme le FT8 fonctionne par cycles de 15 secondes, ce qui compte réellement est l’équilibre entre quatre éléments :

1. La quantité de signal que l’on attend avant de décoder
2. La profondeur de recherche des messages candidats
3. Le fait que l’ensemble du traitement se termine à temps
4. Le nombre de faux décodages que l’on est prêt à tolérer

Vu sous cet angle, optimiser le FT8 ne consiste pas à rechercher la « puissance maximale ». Il s’agit de répartir un temps de traitement limité.

Cette perspective change la manière dont chaque réglage doit être envisagé.

Nombre de threads

Pour la plupart des opérateurs, Auto reste le meilleur point de départ. Imposer davantage de threads ne garantit pas un meilleur résultat. L’ordonnancement du système d’exploitation, la charge en arrière-plan, la topologie des cœurs et le comportement global de la machine jouent tous un rôle.

Nombre de passes de décodage

Davantage de passes peut augmenter les chances de récupérer des signaux plus faibles ou plus ambigus, mais cela coûte aussi du temps processeur. Si votre système est puissant, 3 passes peuvent être intéressantes. Pour beaucoup de stations, 2 constitue le meilleur réglage par défaut. Sur un matériel limité, 1 peut être le choix le plus sûr.

Decoder Sensitivity

Une lecture pratique est simple :

• Minimum est plus léger
• Low thresholds est équilibré
• Subpass est plus agressif, mais plus lourd

Subpass n’offre pas des performances gratuites. C’est du travail supplémentaire en échange de la possibilité de récupérer des signaux plus faibles ou plus difficiles.

À propos de Fast / Normal / Deep par rapport au Multithreaded FT8 Decoder

C’est un point particulièrement facile à mal comprendre. Comme Fast / Normal / Deep apparaît sur le même écran que Multithreaded FT8 decoder, il est naturel de supposer qu’il s’agit simplement de variantes d’un même réglage. Le code source indique pourtant qu’il ne s’agit pas du même type de paramètre.

Tout d’abord, Fast / Normal / Deep est le réglage traditionnel de profondeur de décodage : autrement dit, il indique au décodeur jusqu’où pousser la recherche. Dans le chemin FT8 classique monothread, cette profondeur est directement liée à la charge de calcul et à l’agressivité de la recherche.

Multithreaded FT8 decoder, en revanche, correspond à un tout autre axe. La question fondamentale est de savoir quelle famille de moteur de décodage est utilisée. Dans le code, la profondeur de décodage et le FT8 multithread sont traités comme des paramètres distincts, et non comme deux noms pour une même fonction.

La nuance importante vient ensuite. Lorsque FT8 fonctionne réellement avec le décodeur multithread activé, le programme emprunte un chemin MTD dédié plutôt que l’ancien chemin FT8 conventionnel. Dans ce chemin, les réglages qui pilotent réellement le comportement du décodeur sont ceux propres au MTD — plutôt que les anciens niveaux Fast / Normal / Deep :

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

La manière la plus exacte de le comprendre est donc la suivante : Fast / Normal / Deep existe toujours et reste intégré à la logique générale de profondeur de décodage du programme, mais en fonctionnement FT8 MTD ce n’est plus le réglage principal qui définit l’agressivité du décodeur. En pratique, les commandes réellement déterminantes sont celles orientées MTD — en particulier Decoder Sensitivity, Decode Start, Number of decode passes et QSO Rx Frequency Sensitivity.

Autrement dit, si vous cherchez à régler sérieusement WSJT-X 3.1 improved pour le FT8 avec le décodeur multithread activé, il vaut mieux raisonner en termes de commandes propres au comportement MTD plutôt que de supposer que Fast / Normal / Deep reste le facteur principal définissant le caractère du décodeur. L’ancien réglage de profondeur fait toujours partie de la conception ; il n’est simplement plus le levier pratique le plus important une fois dans le chemin FT8 MTD.

QSO Rx Frequency Sensitivity

Ce n’est pas seulement un réglage de vitesse. Il influence l’agressivité avec laquelle le décodeur examine l’activité autour de la zone de fréquence liée au QSO et les candidats voisins.

• Low est conservateur
• Medium est équilibré
• High est agressif

Comme on peut s’y attendre, une plus grande agressivité peut aussi produire davantage de candidats douteux et davantage de bruit de décodage.

Reduce False Decodes

Ce réglage mérite plus d’attention qu’il n’en reçoit parfois. Trouver davantage de décodages n’est pas automatiquement préférable si les résultats supplémentaires deviennent de moins en moins fiables. Sur les bandes chargées et dans les situations ambiguës, la maîtrise des faux décodages est très importante.

Pris ensemble, ces réglages ne sont pas en concurrence isolée pour déterminer lequel est le « plus puissant ». Chacun apporte une réponse différente à la même question de fond :

dans une fenêtre très limitée de 15 secondes, que doit privilégier le décodeur ?

Et parmi tous ces réglages, Decode Start est l’un des exemples les plus clairs et les plus révélateurs.

La question principale

Que fait réellement « Decode Start » ?

C’est ici que le sujet devient vraiment intéressant.

Dans l’interface utilisateur, Decode Start propose cinq choix :

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

À première vue, cela ressemble à une simple commande temporelle :

commencer à décoder plus tôt ou plus tard.

Mais ce n’est pas toute l’histoire.

En examinant l’implémentation réelle de WSJT-X 3.1 improved, ces modes sont traités en interne comme suit :

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

Pendant le fonctionnement FT8, le programme utilise des valeurs telles que m_hsymStop, m_earlyDecode et m_earlyDecode2 pour déterminer le moment où les différentes étapes de décodage sont déclenchées.

Cela nous indique immédiatement ceci :

Pour rendre cela plus facile à comprendre, commençons par les trois modes les plus simples — Early, Normal et Late — puis passons aux modes plus révélateurs 2-Stage et 3-Stage.

Early / Normal / Late

Commençons par les trois modes les plus simples

Commençons par les options les plus directes.

Lorsque le décodeur FT8 multithread est activé, les points d’arrêt internes sont approximativement :

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

En termes de chronologie approximative, cela correspond à :

• Early → environ 13,8 secondes
• Normal → environ 14,1 secondes
• Late → environ 14,4 secondes

Le sens général est intuitif :

• Early abandonne un peu de collecte de signal en échange d’une plus grande marge processeur
• Late attend plus longtemps afin de recueillir un peu plus d’informations avant le décodage
• Normal se situe entre les deux

Si Decode Start ne comportait que ces trois modes, ce serait déjà un réglage utile — mais pas particulièrement inhabituel.

Ce qui rend cette fonction beaucoup plus intéressante est ce qui vient ensuite :

2-Stage et 3-Stage.

Note technique complémentaire

Ce que sont réellement 2-Stage et 3-Stage

Pas seulement « plus tôt » ou « plus tard », mais une stratégie de décodage par étapes combinant STD et MTD

Le journal des modifications de WSJT-X improved décrit les modes 2-Stage et 3-Stage comme des modes qui « combinent intelligemment les deux décodeurs », ce qui conduit, selon lui, aux meilleures performances de décodage FT8 obtenues à ce jour.

Autrement dit, le logiciel les présente explicitement comme une manière de combiner le décodeur traditionnel STD (monothread) et le nouveau décodeur MTD (multithread).

Ce que le journal des modifications n’explique pas, c’est l’ordre exact d’exécution ni la relation temporelle entre les deux. Cela ne devient clair qu’en examinant l’implémentation.

Et une fois qu’on le fait, il devient évident que 2-Stage et 3-Stage ne correspondent pas simplement à des instants de démarrage différents. Ce sont des stratégies de décodage multi-étapes, et toutes les étapes n’ont pas le même rôle.

La répartition des rôles entre STD et MTD

Ici, STD désigne le décodeur FT8 traditionnel monothread. MTD désigne le décodeur FT8 multithread introduit dans la branche improved.

En observant l’implémentation, les modes par étapes fonctionnent approximativement ainsi :

• les premières étapes utilisent STD
• l’étape finale utilise MTD

C’est l’idée centrale de la conception.

Autrement dit, il faut comprendre cela comme une séparation volontaire entre :

• un examen plus précoce, plus léger et plus rapide
• et une passe de décodage plus tardive et plus complète

Cette distinction est très importante.

Une conception plus simple pourrait attendre la fin de l’intervalle de réception puis effectuer une seule passe de décodage lourde. WSJT-X improved ne fait pas cela. Il effectue au contraire des recherches intermédiaires de candidats avant l’étape finale, puis réalise plus tard un décodage plus approfondi.

Cela montre clairement que la conception s’attache à un problème central :

Point de vue du développeur : à quoi sert réellement la pré-passe STD

Selon Uwe Risse / DG2YCB, la pré-passe STD n’est pas simplement un décodage préliminaire supplémentaire. Son rôle important est d’apporter dans le flux MTD l’avantage du décodage précoce connu avec le décodeur STD traditionnel.

Pendant le développement, plusieurs combinaisons de STD et MTD ont été testées, ainsi que différents paramètres nzhsym. L’approche actuelle — STD comme pré-passe et MTD comme passe finale principale — a produit les meilleurs résultats pratiques.

C’est un point essentiel. 2-Stage et 3-Stage ne sont pas de simples mécanismes permettant de « lancer le décodeur plusieurs fois ». Ils sont conçus pour combiner le comportement de décodage précoce et léger de STD avec la puissance de décodage finale plus complète de MTD, afin d’utiliser plus efficacement le temps processeur limité du cycle FT8 de 15 secondes.

Uwe indique également que 2-Stage atteint environ 99,5 % du rendement de décodage de 3-Stage tout en demandant beaucoup moins de puissance de calcul. Cela explique pourquoi 2-Stage constitue une recommandation pratique si forte pour la plupart des utilisateurs, tandis que 3-Stage reste l’option de performances maximales pour les ordinateurs très rapides.

Ce que signifie réellement 2-Stage

En décodage réel sur l’air, 2-Stage se compose d’une pré-passe STD à nzhsym=41, suivie de la passe de décodage MTD finale à nzhsym=49.

La séquence réelle est donc :

• pré-passe STD @ nzhsym=41 — environ 11,8 secondes
• MTD finale @ nzhsym=49 — environ 14,1 secondes

Le point essentiel est que la seconde pré-passe STD à nzhsym=46 ne fait pas partie de 2-Stage en décodage réel. Cette pré-passe supplémentaire appartient uniquement à 3-Stage.

Autrement dit, 2-Stage est un mode bien équilibré : il effectue une première reconnaissance précoce, puis se termine par l’étape principale de décodage MTD à nzhsym=49.

Grâce à son excellent équilibre entre rendement de décodage et coût processeur, 2-Stage est le mode que je recommanderais d’abord à la plupart des utilisateurs. Selon Uwe Risse / DG2YCB, il atteint environ 99,5 % du rendement de 3-Stage tout en demandant beaucoup moins de puissance de calcul. C’est donc un compromis pratique particulièrement solide.

Ce que signifie réellement 3-Stage

3-Stage ajoute une seconde pré-passe STD à nzhsym=46 avant la passe de décodage MTD finale.

En décodage réel sur l’air, la séquence est :

• pré-passe STD @ nzhsym=41 — environ 11,8 secondes
• pré-passe STD @ nzhsym=46 — environ 13,2 secondes
• MTD finale @ nzhsym=50 — environ 14,4 secondes

3-Stage effectue donc d’abord une reconnaissance précoce à 41, puis une seconde pré-passe STD à 46, et lance enfin le décodage MTD principal à 50.

Cela fait de 3-Stage le mode de décodage FT8 offrant les performances maximales dans WSJT-X 3.1 improved.

Il faut toutefois ajouter un avertissement pratique important. Le gain supplémentaire de 3-Stage n’est pas proportionnel à l’augmentation de la charge processeur. Uwe Risse / DG2YCB souligne que 2-Stage atteint déjà environ 99,5 % du rendement de décodage de 3-Stage ; le gain restant est donc faible par rapport à la puissance de calcul supplémentaire nécessaire.

Sur les ordinateurs moins puissants, la pré-passe STD supplémentaire à nzhsym=46 peut consommer trop de temps et, dans le pire des cas, perturber l’étape MTD finale essentielle à nzhsym=50. C’est pourquoi 3-Stage doit être considéré comme un mode haut de gamme : c’est l’option ultime pour les utilisateurs disposant d’un matériel puissant, mais ce n’est pas automatiquement la meilleure recommandation pour tout le monde.

Il faut le comprendre comme « STD d’abord, MTD à la fin », et non « MTD d’abord, STD ensuite »

C’est l’un des points les plus faciles à mal interpréter.

Comme le journal des modifications indique que 2-Stage et 3-Stage combinent STD et MTD, certains lecteurs peuvent imaginer un modèle de ce type :

• MTD s’exécute d’abord
• puis STD complète ce que MTD n’a pas décodé

Mais ce n’est pas ce qu’indique le comportement réel de décodage.

L’interprétation correcte est plutôt l’inverse :

• STD effectue la ou les passes de reconnaissance précoces et légères
• MTD effectue le décodage final, plus approfondi

En exploitation réelle, la distinction est la suivante :

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

Cette distinction est importante. 3-Stage offre les performances de décodage maximales possibles, mais 2-Stage est la recommandation la plus pratique pour la plupart des utilisateurs car il évite le coût processeur supplémentaire de la seconde pré-passe STD à nzhsym=46.

Pourquoi utiliser STD dans les premières étapes ?

Cela aussi est révélateur.

Si l’objectif était simplement de « lancer le décodeur plus souvent », on pourrait s’attendre à ce que le logiciel exécute MTD à chaque étape. Ce n’est pourtant pas ce qu’il fait.

La raison probable est simple :

les premières étapes doivent rester légères et rapides.

À ces instants précoces, la réception n’est pas encore terminée. La quantité d’informations disponible est inférieure à celle de l’étape finale. Exécuter à pleine puissance la logique de décodage la plus lourde à chaque fois ne serait pas forcément l’utilisation la plus efficace d’un temps processeur limité.

Le logiciel utilise donc STD pour examiner rapidement et économiquement les premiers instants, puis réserve MTD à la passe finale, plus déterminante.

Ce n’est pas un simple détail d’implémentation. Cela reflète une philosophie de décodage particulièrement adaptée au FT8, charge courte, impulsionnelle et très sensible au temps.

Le code suggère aussi que les premières étapes utilisent un traitement un peu plus contraint que l’étape finale, ce qui renforce encore l’idée que ces modes ne sont pas de simples passes répétées, mais une progression par étapes dans laquelle chaque passe possède un rôle différent.

L’essence de 2-Stage et 3-Stage est l’allocation du temps

Au fond, 2-Stage et 3-Stage portent réellement sur une seule question :

comment répartir l’effort de calcul à l’intérieur d’un cycle de 15 secondes.

• Le décodeur doit-il examiner plus tôt ?
• Doit-il effectuer un examen supplémentaire au milieu du cycle ?
• Doit-il attendre la fin pour tenter le décodage final le plus complet ?

C’est précisément ce que décident les modes par étapes.

2-Stage et 3-Stage ne doivent donc pas être considérés comme de simples ajustements temporels. Il vaut mieux les comprendre comme différentes façons de déployer le décodeur FT8 dans le temps.

Comment les interpréter en exploitation réelle ?

Traduit en termes d’exploitation, la distinction devient très concrète.

2-Stage

• préserve assez bien la réactivité
• ajoute un examen plus précoce
• maintient l’étape finale autour du timing Normal
• améliore la récupération des candidats sans pousser la charge processeur à l’extrême

Autrement dit, il s’agit d’une stratégie par étapes équilibrée.

3-Stage

• examine tôt
• examine à nouveau au milieu
• conserve encore une passe MTD finale proche du timing Late
• pousse plus loin la réduction des décodages manqués
• mais augmente en conséquence la charge processeur

3-Stage est donc le mode par étapes le plus ambitieux et le plus agressif disponible.

Si le processeur dispose d’une marge suffisante, il peut être extrêmement intéressant. Si le processeur est déjà proche de ses limites temporelles, l’avantage théorique compte moins que le fait de terminer proprement le traitement.

À ce stade, le sens de ces modes devient beaucoup plus clair :

Encore un point important

Les modes par étapes ne sont pas simplement des « décodages multiples » ; ils attribuent des rôles différents aux différentes étapes

Avec un peu de recul, ce qui rend 2-Stage et 3-Stage si intéressants n’est pas seulement le fait qu’ils déclenchent le décodage plusieurs fois.

Le point plus profond est que chaque étape joue un rôle différent.

• les premières étapes sont plus légères et plus rapides
• l’étape finale est plus complète
• l’effort processeur est réparti sur le cycle au lieu d’être dépensé en une seule fois

Cela convient remarquablement bien au FT8.

On pourrait, en principe, attendre la fin et prendre une seule décision finale. Mais il est réellement utile de rechercher plus tôt les candidats récupérables, puis de réexaminer le problème plus tard avec davantage d’informations et un traitement plus approfondi.

C’est pourquoi comprendre les modes par étapes ne consiste pas seulement à comprendre un réglage. Il s’agit en réalité de comprendre ce que signifie l’optimisation FT8 elle-même.

Interprétation pratique

Comment utiliser concrètement chaque mode ?

Après tous ces détails techniques, il est utile de revenir à un langage d’exploitation plus concret.

2-Stage

Très pratique. Il préserve la réactivité tout en effectuant un examen précoce. L’étape finale n’est pas aussi tardive que Late, ce qui évite une charge inutilement élevée.

3-Stage

Le mode le plus ambitieux — au bon sens du terme.

Il examine tôt, recommence plus tard et conserve encore une passe finale puissante. Si le processeur dispose de marge et si la réduction des décodages manqués est prioritaire, c’est l’un des réglages les plus intéressants de tout le panneau.

Early

Il ne faut pas le réduire à une solution de repli pour processeur faible. C’est aussi une stratégie de stabilité parfaitement rationnelle. Si éviter le débordement sur le cycle suivant importe davantage que d’extraire le dernier fragment de signal, Early peut être exactement le bon choix.

Normal

Le point de référence. Pour la plupart des utilisateurs, les essais devraient commencer ici. Cela facilite beaucoup la comparaison avec les autres modes.

Late

Attendez plus longtemps, décodez plus tard et prenez la décision finale avec un peu plus d’informations. En théorie, cela peut aider. En pratique, ce n’est utile que si le système termine encore le traitement de manière fiable.

Pris ensemble, les modes Decode Start ne doivent pas être considérés comme une question de « préférence personnelle ». Il vaut mieux les voir comme différentes stratégies temporelles.

Alors, qu’optimisons-nous réellement ?

Pas la performance moyenne, mais l’utilisation du temps CPU à l’intérieur du cycle de 15 secondes

À ce stade, le principe général devrait être clair.

Optimiser le FT8 ne consiste pas simplement à rendre les choses « plus puissantes ».

Il s’agit de décider :

• combien de temps attendre
• à quelle fréquence examiner
• où effectuer les passes plus légères
• où effectuer la passe finale la plus lourde
• et si l’ensemble du processus reste stable d’un cycle à l’autre

Autrement dit, il s’agit réellement de la manière dont les performances du processeur sont utilisées, et pas seulement de la quantité de puissance disponible.

De ce point de vue, Decode Start est l’un des réglages les plus importants de tout le panneau du décodeur. Ce qui ressemble à une petite option d’interface est en réalité l’expression directe d’une stratégie temporelle.

Pour cette raison, comprendre Decode Start va au-delà de l’explication d’un réglage. C’est une façon de comprendre la philosophie sous-jacente de l’allocation des ressources de calcul en FT8.

Une note plus personnelle

Pourquoi j’écris tout cela

Jusqu’ici, j’ai essayé de conserver une approche générale et technique. Mais pour donner le contexte, je dois préciser ma propre position.

Ce n’est pas parce que JTDX manquerait de valeur. C’est parce qu’un logiciel doit aussi être jugé sur ce qui est concrètement disponible, suffisamment mûr pour être testé et réellement utile maintenant.

Si quelqu’un reste sur JTDX parce qu’il préfère sincèrement son interface, cela se comprend parfaitement. Mais si la question porte sur les capacités actuelles du décodeur et la valeur pratique en exploitation, WSJT-X 3.1 improved mérite une attention sérieuse.

Ma propre philosophie d’exploitation

Jusqu’ici, je me suis concentré sur des principes généraux. Il peut toutefois être utile d’expliquer où cette réflexion me conduit concrètement.

Mon PC principal d’exploitation utilise un Core i9-9900K. Ce détail compte — mais pas seulement parce qu’il s’agit d’un processeur relativement puissant.

La manière dont la machine est configurée compte également.

Dans les paramètres d’alimentation de Windows, je règle l’état minimal du processeur à 100 %. Autrement dit, je n’attends pas que le processeur augmente sa fréquence après l’apparition de la charge de décodage. Je préfère qu’il fonctionne déjà à haute fréquence, prêt et en attente. Dans mon cas, il reste effectivement autour de 4,7 GHz.

La raison est simple.

Le décodage FT8 ne ressemble pas à un rendu vidéo de longue durée où une charge constante s’exécute pendant longtemps. Il ressemble davantage à une courte rafale de travail concentré, répétée à des intervalles prévisibles.

Dans ce type de charge, les performances moyennes d’un benchmark ne racontent pas toute l’histoire. La réactivité initiale compte.

Si le processeur se trouve dans un état basse consommation, le système doit alors :

• détecter la charge
• changer d’état de performance
• augmenter la fréquence
• ajuster la tension
• et laisser l’ordonnanceur réagir

Ces délais peuvent être négligeables dans les charges longues. Mais dans de courtes rafales sensibles au timing, ils peuvent compter davantage qu’on ne l’imagine.

C’est pourquoi je pense ceci :

Bien sûr, ce choix implique des compromis.

• consommation électrique plus élevée
• davantage de chaleur
• rendement énergétique inférieur
• moins d’élégance du point de vue des économies d’énergie

Mais sur le PC d’une station radio, je considère la réactivité et la stabilité du décodage plus importantes que l’optimisation énergétique.

Pourquoi mes propres réglages sont volontairement agressifs

Parce que le 50 MHz compte beaucoup pour moi

Mes réglages reflètent assez clairement cette philosophie.

• Decoder Sensitivity : Subpass
• QSO Rx Frequency Sensitivity : High
• CPU déjà prêt à haute fréquence

Ce n’est pas une configuration conservatrice, et je ne prétends pas le contraire.

Mais il y a une raison :

le 50 MHz compte énormément pour moi.

Sur 6 mètres :

• les conditions peuvent changer rapidement
• l’activité peut augmenter soudainement
• les signaux faibles et forts coexistent souvent
• et une ouverture brève peut rendre les occasions manquées particulièrement frustrantes

C’est pourquoi je suis prêt à consacrer des ressources CPU afin de réduire les décodages manqués.

Voilà pourquoi j’utilise :

• Subpass, pour rechercher plus en profondeur
• la sensibilité High, pour être plus agressif dans la récupération des candidats
• et une configuration d’alimentation qui maintient le processeur prêt avant l’arrivée de la charge en rafale

Il ne s’agit pas simplement de « tout mettre au maximum parce que plus doit forcément être mieux ».

C’est une stratégie d’exploitation délibérée fondée sur :

• l’importance accordée au 50 MHz
• une marge CPU suffisante
• l’importance de la vitesse de réaction
• et la volonté d’échanger de l’efficacité contre des opportunités

Conclusion

La vraie question n’est pas « Quel programme a raison ? », mais « Quelle philosophie de réglage convient à votre station ? »

Si je devais résumer toute cette discussion en une seule phrase, ce serait celle-ci :

Vu sous cet angle, WSJT-X 3.1 improved est un logiciel particulièrement intéressant. Non pas simplement parce qu’il offre davantage d’options, mais parce qu’il donne à l’opérateur un contrôle réel sur la stratégie temporelle du décodeur.

Et Decode Start en est l’un des exemples les plus clairs.

2-Stage, 3-Stage, Early, Normal et Late ne sont pas de simples étiquettes cosmétiques. Ils représentent différentes manières de répartir l’effort de décodage sur le cycle FT8.

En examinant plus attentivement les modes par étapes, on découvre derrière eux une idée particulièrement élégante :

Enfin, permettez-moi de le dire en tant que personne qui apprécie sincèrement JTDX :

Si votre attachement à JTDX vient de son interface, c’est une chose. Mais si votre préoccupation est la capacité actuelle du décodeur dans des conditions réelles d’exploitation, il y a peu de raisons d’hésiter.