Digital Modes and GridTracker fr

Modes numériques : WSJT-X, GridTracker et OpsLog ensemble

🇬🇧 Digital Modes and GridTracker

Faire tourner WSJT-X (ou JTDX, ou MSHV) avec GridTracker et OpsLog en même temps, c'est la station numérique normale, et c'est la configuration qui marche le plus souvent à moitié : les décodages arrivent un jour et pas le lendemain, sans que rien n'ait changé.

Il y a une cause et un remède. La cause est l'unicast ; le remède est le multicast.

---

L'unicast et le multicast, en une minute

WSJT-X ne connaît pas OpsLog. Il envoie un flux de messages UDP — chaque décodage, l'indicatif DX que tu travailles, chaque QSO que tu enregistres — vers une adresse et un port que tu lui donnes. Tout le reste n'est qu'écoute.

L'unicast est un message adressé à un seul endroit : 127.0.0.1:2237.

Une lettre, une boîte aux lettres. Si deux logiciels surveillent la même boîte, c'est le système d'exploitation qui décide lequel reçoit la lettre — et il décide d'après l'ordre de démarrage, pas d'après ce que tu veux. Voilà pourquoi ça marche après un redémarrage et pas après le suivant.

Le multicast est un message adressé à un groupe : 239.255.0.1:2237.

Une émission de radio. Chaque logiciel qui s'est accordé sur le groupe reçoit sa propre copie. Pas de concurrence, pas d'ordre, pas de hasard.

Le multicast est ce que WSJT-X propose exactement pour cette raison, et c'est ce que tu veux dès que plus d'un logiciel écoute ton décodeur.

À quoi ça ressemble quand ça va de travers

Deux démarrages de la même station, à une heure d'intervalle, sans rien changer dans aucun réglage :

06:43  autostart: GridTracker2 — already_running
06:43  udp: [Decodium] listening on unicast :2237
       … pas un décodage de toute la matinée, alors que WSJT-X tournait et loguait
          des QSO

10:30  udp: [Decodium] listening on unicast :2237
10:30  autostart: GridTracker2 — launched
10:30  udp: emit udp:dx_call "JK2TTP" (mode=FT4 freq=21140000)
       … des décodages du début à la fin

Le matin, GridTracker tenait déjà le port 2237 quand OpsLog a démarré. Dans la seconde session, OpsLog y est arrivé le premier. Mêmes logiciels, mêmes réglages, et la seule différence est qui a démarré le premier.

---

La configuration qui marche

Choisis un groupe et un port et donne la même paire à chaque logiciel. 239.255.0.1 port 2237 est le choix habituel.

WSJT-X

File → Settings → Reporting, encadré UDP Server :

Champ	Valeur
UDP Server	239.255.0.1
UDP Server port number	2237
Outgoing interfaces	coche ton adaptateur LAN/Wi-Fi et le loopback
Accept UDP requests	✔ coché

Outgoing interfaces compte et s'oublie facilement, dans les deux sens : avec seulement l'adaptateur LAN coché, les logiciels du même PC peuvent ne jamais voir le trafic — et avec seulement le loopback coché, rien ne quitte jamais la machine. Coche les deux.

Sur un autre PC du réseau

C'est à ça que sert le multicast, et ça fonctionne : pointe l'OpsLog de la seconde machine sur le même groupe et le même port, et sa ligne entrante reçoit les mêmes décodages. OpsLog se lie à 0.0.0.0 et rejoint le groupe sur chaque interface active et capable de multicast, et le journal dit combien il en a obtenu :

udp: [WSJT-X] listening on multicast 239.255.0.1:2237 on 2 interface(s)

Quatre choses décident si ça arrive :

• Les interfaces sortantes de l'émetteur doivent inclure l'adaptateur LAN, comme ci-dessus. Le loopback seul ne quitte jamais le PC qui fait tourner WSJT-X.
• Le même sous-réseau. Le multicast ne traverse pas un routeur à moins qu'il ne soit configuré pour le porter, ce que ne fait pas un routeur domestique.
• Le pare-feu du PC récepteur doit laisser OpsLog recevoir de l'UDP sur ce port.
• Le câble vaut mieux que le Wi-Fi. Les points d'accès gèrent le multicast de façon inégale, et c'est la raison habituelle pour laquelle ça marche sur une machine et pas sur une autre avec des réglages identiques.

Ce qui traverse, ce sont les décodages et la journalisation. Tout ce qui agit sur la radio ne voyage pas avec : le second OpsLog n'a pas de poste à moins que tu lui en donnes un — le port CAT partagé est en 127.0.0.1, local par définition. Pour une station dont la radio est sur l'autre machine, voir Station distante.

Accept UDP requests est ce qui permet à OpsLog de répondre à une station pour toi et d'effacer l'indicatif DX. Sans lui, OpsLog entend tout mais ne peut que regarder.

JTDX

Même endroit, mêmes valeurs — JTDX garde l'onglet Reporting de WSJT-X.

MSHV

Options → Settings → Reporting (protocole WSJT-X), même adresse et même port.

GridTracker

Settings → WSJT-X / UDP : adresse 239.255.0.1, port 2237, multicast activé. GridTracker rejoint alors le groupe comme tout le monde au lieu de posséder le port.

OpsLog

Réglages → Connexions → Ajouter :

Champ	Valeur
Sens	Entrant
Service	WSJT-X / JTDX / MSHV
Port	2237
Multicast	✔ coché
Groupe	239.255.0.1

Enregistre. Le journal devrait dire :

udp: [WSJT-X] listening on multicast 239.255.0.1:2237 on 2 interface(s) (service=wsjt)

---

L'erreur à éviter : 127.0.0.1 dans la case du groupe

Un groupe multicast est une adresse entre 224.0.0.0 et 239.255.255.255. Rien d'autre ne peut être rejoint.

127.0.0.1 est le loopback — une adresse unicast ordinaire — et c'est une chose très compréhensible à taper, parce que c'est ce que veut tous les autres champs de tous les autres logiciels. Mais une ligne cochée Multicast avec 127.0.0.1 dans la case du groupe ne peut rien rejoindre, et échouait avec un message Windows qui ne nommait rien de ce que tu avais tapé :

udp: [Wsjtx] join 127.0.0.1 on Wi-Fi 2: setsockopt: the requested address is not
     valid in its context
udp: start "Wsjtx" failed: couldn't join multicast 127.0.0.1 on any interface

OpsLog écoute désormais en unicast à la place et le dit, donc la ligne fonctionne quand même — mais si tu voulais du multicast, mets un vrai groupe.

Règle simple : si l'adresse commence par 127., 192.168. ou 10., décoche Multicast.

---

S'il faut rester en unicast

Parfois le multicast n'est pas possible — un vieux logiciel, un réseau verrouillé. Alors un seul logiciel peut écouter sur le port, et les autres sont alimentés par lui.

OpsLog peut être celui qui les alimente. Ajoute une ligne sortante Relayer le flux WSJT-X (Réglages → Connexions) et il réémet chaque datagramme qu'il reçoit, octet pour octet, là où tu le pointes :

WSJT-X ──unicast 2237──▶ OpsLog ──relais──▶ GridTracker (2238)

Règle GridTracker pour écouter sur 2238 au lieu de 2237 et plus rien n'est en concurrence. Pointe le relais sur le port de l'autre logiciel, jamais sur l'un de ceux d'OpsLog — cela réinjecterait le flux dans lui-même, et le relais refuse plutôt que de le laisser faire.

Ça marche aussi dans l'autre sens, si tu préfères que GridTracker possède le port : GridTracker transmet vers un port différent et OpsLog y prend une ligne entrante. Les deux ordres conviennent. La seule configuration qui ne marche jamais de façon fiable, c'est deux logiciels sur un même port unicast.

---

Vérifier

1. Réglages → Connexions — la ligne est activée et son port correspond.
2. Aide → Journal de l'application — l'une de ces deux lignes apparaît au démarrage :
   • listening on multicast 239.255.0.1:2237 on N interface(s) ✔
   • listening on unicast :2237 — acceptable seulement si rien d'autre n'y écoute
3. Accorde-toi sur une fréquence FT8 chargée. En moins d'une minute le journal se remplit de :

   udp: emit udp:dx_call "F5ABC" (mode=FT8 freq=14074000)
   

4. Rien du tout ? Dans l'ordre : l'adresse du serveur UDP de WSJT-X est-elle le même groupe ; Outgoing interfaces inclut-il le loopback ; un autre logiciel tient-il le port ; le pare-feu Windows bloque-t-il OpsLog.

Ce n'est pas la même chose : rigctld: sharing CAT on port 2237 dans le journal, c'est le partage du CAT en TCP d'OpsLog pour les clients Hamlib. Les ports TCP et UDP sont distincts — cela n'entre pas en conflit avec l'écouteur UDP, aussi semblables que les numéros paraissent.

---

L'appel automatique

Réglages → DXHunter → Appel automatique. OpsLog répond tout seul à la meilleure station à l'antenne, sans que tu cliques. Ceci met ton émetteur en l'air sans te demander.

Il répond à une station à la fois, jamais par-dessus un QSO déjà en cours, et il abandonne de lui-même :

Frein	Défaut
Appels avant d'abandonner	7
… si l'indicatif est sur ta watchlist	15
Ses propres périodes d'émission sans décodage de la station	3
Séries par station	3
Repos entre les séries, en périodes de la station	1
Maintenu sur une station, quoi que disent les compteurs	4 minutes

Chaque décision est écrite dans le journal de l'application avec sa raison, et Stop l'interrompt immédiatement.

N'appeler que ceux-là : un ou plusieurs indicatifs, ou un par ligne avec des jokers (4S7*, */P), et rien d'autre n'est appelé. Une station surveillée est appelée avant les critères ci-dessous. Laisse vide pour appeler ce dont le log a besoin.

Répondre en milieu d'échange ne fonctionne qu'avec MSHV — WSJT-X et JTDX jettent cette réponse sans l'émettre. Cela te met dans la liste des appelants de la station au lieu d'attendre un CQ, comme on travaille un pile-up à la main.

Quelle station il choisit

Par ordre de priorité :

1. Tout indicatif de ta watchlist — et parmi ceux-là, la même échelle que ci-dessous.
2. Une nouvelle entité DXCC
3. Une nouvelle bande pour l'entité
4. Un nouveau mode pour l'entité
5. Un nouveau créneau (bande + mode jamais travaillés ensemble)

Un vrai besoin passe avant un besoin qui n'existe que parce qu'une QSL n'est jamais arrivée. Une station qui t'appelle est appelée quoi que le journal en pense. Une station en plein QSO avec quelqu'un d'autre n'est jamais appelée — elle ne peut pas répondre.

Les filtres pilotent l'émetteur

Avec N'appeler que ce que la liste des décodages affiche coché — c'est le cas par défaut — les filtres au-dessus de la liste des décodages FT s'appliquent aussi à l'appel automatique : CQ seulement, LoTW seulement, les pastilles de nouvelles catégories, les continents, le seuil de report et la case de recherche. Une station filtrée hors de l'écran n'est pas appelée. Avec la liste des décodages fermée, l'appel automatique est désarmé purement et simplement.

Quand rien n'est appelé

Coche Journaliser chaque décision. Cela écrit une ligne par période dans le journal de l'application : ce qui était à l'antenne, pourquoi chaque station a été refusée, et ce qui a été décidé. C'est une ligne toutes les quinze secondes, donc laisse-le coupé le reste du temps.

« Est-ce qu'il m'entend ? » — le panneau PSK Reporter

À côté des décodages FT, un panneau répond à la question que tu te poses réellement en appelant une station : est-ce qu'il me décode, tout simplement ?

Active l'analyse PSK Reporter dans Réglages → DXHunter. Le panneau suit alors la station que tu travailles — un clic sur un décodage, ou l'indicatif DX que le logiciel numérique annonce — et montre :

• les reports sur toi reçus dans les dix dernières minutes. Le flux est vivant même quand les compteurs sont à zéro, et c'est ainsi qu'on distingue « personne ne m'entend » de « rien n'est connecté ».
• son pile-up : les stations uniques que lui a décodées ces deux dernières minutes. C'est ce qu'on peut approcher de plus près de la file dans laquelle tu appelles — les stations qu'il a décodées avant sont probablement passées à autre chose.
• qui il entend près de chez toi, pour distinguer un chemin mort d'un chemin encombré.
• les appelants : les stations de tes propres décodages qui l'appellent, avec, entre parenthèses, combien d'entre elles il a décodées — ce sont celles qui lui parviennent vraiment.
• où sa bande passante est libre, pour choisir un décalage qui ne soit pas sur le dos de quelqu'un d'autre.

Chaque ligne se lit décodée par lui il y a N secondes à D dB, et son décalage est l'endroit où le signal est tombé dans sa bande passante, pas forcément là où la station appelait.

Sur la carte FT, le même flux marque les stations qui rapportent tes propres émissions par des losanges, à côté de ce que tu décodes. Il ne surveille qu'un seul topic — ton indicatif — donc cela ne coûte presque rien.

Uniquement la bande sur laquelle tu es : change de bande et les marques de celle que tu quittes disparaissent, puisqu'elles répondent sur une bande où la radio n'est plus. Reviens dessus et les rapports encore dans la fenêtre de quinze minutes sont de nouveau là. Sans CAT, donc sans bande à comparer, tous les rapports sont affichés.

Chase New — ce qui est à l'antenne près de chez toi

Un panneau qui liste les stations décodées près de chez toi qui sont nouvelles par rapport à ton journal : nouvelle entité, bande, mode, créneau, préfixe ou carré. Modes numériques seulement, puisqu'il est construit sur le flux PSK Reporter.

Les bandes ici ne décident que de ce que le panneau liste — pas de ce que ta station sait travailler, qui reste Modes et bandes et s'applique en dessous. Une bande décochée ici est écartée dès son arrivée : elle cesse de prendre une place dans la liste.

Quand un carré est-il encore NEW ?

Le périmètre du carré décide quand un carré cesse de compter comme nouveau, et plus c'est étroit, plus il y a de carrés à chasser :

Périmètre	Exigence
par bande et mode exact	le plus exigeant
par bande, tout mode numérique	entre les deux
toute bande, tout mode numérique	le moins exigeant

Chasser aussi les non confirmés garde un carré recherché jusqu'à ce qu'une confirmation QSL, LoTW ou eQSL arrive — d'ici là il manque toujours au diplôme, quoi que dise le journal.

---

Apparenté

• Connexions — chaque ligne entrante et sortante, et ce que fait chaque service
• Bases du log — ce qui se passe quand un QSO arrive de WSJT-X
• Dépannage — où vit le journal