Daniel – F6FLU

Introduction

Basé sur la documentation JTdx avec de Log4OM : Working with JT applications

Les applications basées sur JT (Joe Taylor) utilisent un protocole de message UDP spécial pour partager des informations avec les auditeurs.

L’un de ces messages est :

– les appels actuellement décodés,

un autre est :

– le contact enregistré lorsque vous enregistrez un QSO dans le programme JT.

Il existe de nombreux autres messages contenant diverses informations (données) partagées par les différentes applications.
Une fois configuré pour lire (recevoir) les messages via UDP, Log4OM recherche le message ‘QSO’ à enregistrer.

Note importante :

Lorsqu’une application envoie un message UDP (et non un message de diffusion/multidiffusion) en tant que JTDX ou WSJT-X, ce message est « capturé » par la première application qui lit les données UDP à partir du réseau exposé, aucune autre application ne le verra .

Une fois que le message a été capturé par la première application, il n’est plus disponible pour d’autres logiciels , comme si vous mettiez un billet de dix dollars par terre dans un supermarché ; la première personne le remarque et récupère les 10 USD, ne laissant rien à trouver à aucun autre acheteur du supermarché !

Log4OM, Gridtracker, JTAlert et d’autres applications qui écoutent un message UDP de JTAlert sont en concurrence pour recevoir le message en premier.

Cela signifie que parfois JTAlert peut recevoir le message en premier, parfois GT, parfois Log4OM.

Ce n’est pas un bon comportement car si Log4om « capture » un message qui intéresse JTAlert, alors JTAlert ne recevra pas les informations.

De la même manière, si GRIDTRACKER ‘Capture’ un message QSO, Log4Om ne pourra pas l’enregistrer.

C’est pourquoi, lors de la configuration de plusieurs applications JT, UNE SEULE APPLICATION DOIT ÊTRE CONFIGURÉE POUR UTILISER LES MESSAGES JT UDP, et cette application doit prendre en charge la REDIFFUSION des informations pertinentes vers d’autres applications qui attendent les informations.

Cette documentation a été adaptée par F6FLU car je pense que dans la version originale il manque quelques précisions.
En tous cas « ma » version est fonctionnelle, c’est à dire qu’en utilisant mes réglages, vous n’aurez pas de soucis tout devrait fonctionner correctement

Omnirig

Omnirig est un « multiplexeur de données » ; c’est à dire qu’il permet à plusieurs applications de se connecter à un même port.
Il existe bien sûr des logiciels qui permettent la même chose mais c’est Omnirig qui est le plus utilisé

C’est bien sûr un logiciel gratuit

Il est donc INDISPENSABLE de lire ma rubrique « Omnirig » AVANT de continuer plus loin avec ce mode FT8

==> Omnirig

Paramètre CAT dans Log4OM et JTDX

CAT Log4OM

Le premier paramètre à modifier est bien sûr dans Log4OM pour lui dire d’utiliser « Omnirig »

Pour cela on va dans les settings / Program Configuration

Dans le bandeau gauche on sélectionne « Cat Interface » et dans l’onglet « Settings / Cat Engine » on sélectionne « Omnirig »

CAT JTDX

Le second paramètre est donc de dire à JTDX d’utiliser également Omnirig

Ici on a le choix d’utiliser soit le RIG1 ou le RIG2

JTDX vers Log4OM direct

Dans ce scénario, Log4OM est le seul récepteur UDP, Log4OM reçoit le QSO directement en utilisant le JT UDP PROTOCOL qui contient les données QSO enregistrées.

Ici j’utilise JTDX mais avec WSJT c’est la même chose …

Cas 1 : JT Message

C’est ce fonctionnement qui est préconisé

Synoptique

Donc dans JTDX on donne le port #2237 (qui est utilisé par défaut avec Log4OM) mais on peut utiliser un autre port sans aucun problème. (Moi j’utilise le port #2235)
Log4OM a changé son système de connexion de port UDP mais visiblement c’est toujours le cas avec cette nouvelle version de Log4OM

Réglage JTDX

Donc dans cette fenêtre on met :

– 127.0.0.1 dans le champ « UDP Server »

– 2235 dans le champ « UDP Sever port number »

et on coche les 3 cases à côté : « Accept UDP requests », « Notify on accepted UDP request », Accepted UDP request restores window »

on coche également juste en dessous :

– « Enable sending logged QSO ADIF data » et « Prevent spotting messages with the unconfirmed callsigns via UDP » (pas obligé pour cette dernière option)

Bien sûr on coche également en haut à gauche, l’option « Prompt me to log QSO » ce qui permet à JTDX d’afficher la fenêtre de Log afin de la valider (ou de la modifier avant de valider)

Réglages Log4OM

Dans ce cas on utilise le message JT via UDP, ce qui est préconisé, mais il est possible d’envoyer la trame via un message ADIF (ce qui était le cas avant mais qui n’est pas préconisé)

Ici dans la documentation on voit bien qu’ils préconise le port #2237 et commemoi j’utilise le port #2235 j’ai donc changé ce numéro de port dans cette fenêtre

Daniel – F6FLU

Cas 2 : Message ADIF

Bien que non recommandé dans cette configuration, l’utilisateur peut vouloir utiliser un message ADIF spécifique pour se connecter.

Ne créez pas en plus une connexion JT comme vu précédemment

car dans ce cas Log4OM va recevoir 2 fois la trame ce qui va entrainer une surcharge dans Log4OM.

En effet le QSO ne sera pas enregistré 2 fois car Log4OM vérifie qu’il n’y ai pas de doublons, mais il y aura beaucoup d’erreurs d’enregistrées dans le journal de Log4OM

Réglages JTDX :

Réglages Log4OM

Remarques

JT Message

ADIF Message

Vous pouvez remarquer que les 2 options ne permettent pas tout à fait la même chose.

Mais par défaut je suggère de valider les 4 options dans ces 2 cas.

Nous verrons également le fonctionnement du Locator à la fin de cet article

JTDX => JTAlert => Log4OM

On peut bien sûr utiliser Gridtracker au lieu de JTAlert, ce qui est décrit plus loin

Synoptique

Ici j’utilise bien ADIF from GT/JTalert car j’utilise JTAlert et

si on utilise une connexion JT Message le QSO ne sera pas loggé par Log4OM

Même si Log4OM émet un warning cette configuration fonctionne très bien

En fait Log4OM émet un warning car j’ai coché le case « Update Gridsquare » et nous allons détailler pourquoi.

Ce qu'il faut comprendre

JTDX et JTALERT fonctionnent ensemble.

Si vous lancez JTAlert tout seul par exemple et bien il va vous afficher une erreur disant qu’il attend JTDX.

Cela signifie que le port utilisé dans JTDX n’a pas d’importance, c’est à dire que JTAlert va lire le port utilisé par JTDX et va donc se connecter sur ce port.

Vous remarquerez que moi j’utilise comme adresse dans JTDX 239.255.0.1 et non 127.0.0.1, c’est à dire que je suis en mode Broadcast et non Unicast (voir mon article sur le sujet : Unicast ou Broadcast).

Cela signifie qu’au lieu d’envoyer la trame uniquement en local (127.0.0.1) je demande à JTDX d’envoyer cette trame sur tout le réseau ; ce qui évite les problèmes décrits précédemment (c’est à dire que seul le premier logiciel récupère la trame et pas les autres) .

En broadcast la trame est envoyée sur tout le réseau et n’importe quelle application connectée sur ce même réseau peut récupérer la trame.

Dans mon cas j’utilise 1 PC ET 1 Macintosh, ces 2 appareils sont connectés sur le même réseau.

JTAlert est lancé sur le PC et GridTracker est lancé sur le Macintosh ET les 2 peuvent voir la trame.

Bien sûr c’est valable également avec 1 seul PC, si on lance JTAlert ET Gridtracker sur le même PC ET que JTDX envoie la trame en broadcast et bien les 2 applications JTAlert ET Gridtracker pourront utiliser cette même trame.

Dans la documentation de JTAlert il est dit d’utiliser une adresse comprise entre 224.0.0.1 à 224.0.0.255 ou une adresse comprise entre 239.255.0.1 à 239.255.255.255. Ici la plage 244… ne fonctionne pas alors j’ai pris une adresse dans la plage 239…

Réglages JTDX

Donc dans les réglages de JTDX je lui dit d’envoyer la trame en Broadcast sur le port #2237 (c’est arbitraire vous pouvez prendre le port que vous voulez)

Réglages JTAlert

Dans JTALERT il faut régler 2 paramètres.

1) En premier dans le menu de gauche , sélectionnez le paramètre Logging / Log4OM V2

On valide « Enable Log4OM V2 Logging »

On valide « Send WSJT-X Call to Log4OM »

Dans la partie « UDP Connections » on met comme adresse 127.0.0.1, on met par exemple 2235 comme port pour le ADIF-MESSAGE et on met par exemple 2241 pour le port de controle

Dans la partie « LogType » on valide « Use SQLite File Log)

Dans la partie SQLite Log on lui donne le chemin pour aller lier le fichier Log de Log4OM. En fait JTAlert va aller lire le Log de Log4OM et donc va être en mesure de vous dire si il reçoit un nouveau DX un nouveau prefixe un nouveau locator etc… suivant vos demandes de vos alertes

2) dans la partie gauche on sélectionne le paramètre « Applications / WSJT-X / JTDX »

on coche comme montré sur cette copie d’écran et on valide l’option « Resend WSJT-X UPD packets » avec comme adresse IP 127.0.0.1 et comme port 1240

Comme on le voit sur le synoptique :

JTDX envoie la trame sur le port 2237 détecté automatiquement par JTAlert qui reçoit donc cette trame

Ensuite avec nos réglages on dit à JTAlert de renvoyer cette trame sur le port 2235, on lui dit également qu’on utilisera le port 2241 comme port de controle et qu’on utilisera le port 1240 pour renvoyer la trame (ce port est utilisé automatiquement par Log4OM)

Il reste donc à configurer Log4om pour que tout ce petit monde fonctionne correctement

Réglages Log4OM

Comme nous venons de le décrire, JTDX a envoyé sa trame sur le port 2237 en Broadcast, ensuite JTAlert récupère cette trame et la renvoie sur le port 2235

Il faut donc dire à Log4OM qu’il va recevoir la trame sur ce port 2235

On crée donc une connexion sur le port 2235, ici j’ai coché toutes les options car je les utilise

Il faut également préciser à Log4OM d’utiliser le port 2241 comme port de remote control, cela se passe dans le menu Connections en sélectionnant le dernier onglet « Remote Control »

Et voilà la boucle est bouclée. Normalement tout devrait fonctionner

Je n’ai pas testé toutes les possibilités, il est tout à fait possible de faire autrement mais en faisant exactement comme décrit ici, vous êtes déjà sûr que cela fonctionne et donc ces réglages peuvent servir de base pour démarrer avec JTDX et JRAlert.
Nhésitez pas à me faire des retours suivant votre expérience ; rien n’est figé…

JTDX ==> Gridtracker ==> Log4om

Au lieu d’utiliser JTAlert on peut utiliser Gridtracker

C’est cette combinaison que j’utilise.

Synoptique

Cette combinaison permet donc d’utiliser GridTracker qui permet d’exploiter beaucoup plus facilement les QSOs à faire

En effet Gridtracker va lire votre fichier de Log (wsjt_log.adi) et donc va vous proposer les contacts qu’il faudrait réaliser pour améliorer votre Log. Par exemple il va vous monter quels sont les calls ayant un nouveau Locator pour vous ou un nouveau prefixe ou une nouvelle zone CQ ou ITU etc … suivant vos réglages.

Mais tout ça fait partie de l’utilisation du logiciel et donc c’est un autre sujet

Astuces / Remarques

Transmission du NOM

Lorsque l’on valide un QSO dans JTdx une fenêtre apparaît avec un certains nombre de renseignements donnés par JTdx

JTdx remplit tous les champs dont il connait la valeur

Donc les champs comme « Grid » ; « Name » sont renseignés ou non ; mais ces champs sont transmis à Log4OM

Prenons l’exemple du champ « Name »

Dans cet exemple ce champ n’est pas renseigné donc JTDX ne transmet rien

Par contre Log4om voyant que ce champ est vide, va aller chercher ce nom sur QRZ.com (ou sur un autre site suivant les réglages dans Log4OM) et si il trouve ce nom et bien il va renseigner ce champ « Nom » dans le Log

JTdx-Log4OM en direct (JTMessage)

Dans ce cas Log4OM prend bien en compte les différents champs envoyés par JTdx SAUF le nom

Donc si dans la trame de JTdx vous mettez un nom et bien Log4OM ne va pas en tenir compte et ira chercher le nom sur QRZ.com

Par contre le QSO sera bien loggé

Cela est dû au fait que dans le type de connexion on a coché « Use External Data » donc Log4om va aller chercher les infos qu’il lui manque dans ses connexions externes que l’on a validé dans les paramètres de Log4om (QRZ.com par défaut)

Si on décoche cette option « Use External Data » Log4OM ne modifie rien et prend bien en compte le nom donné dans la trame JTdx

Transmission du Locator

Le locator est toujours sur 4 caractères dans JTdx alors que si l’on va chercher les informations sur QRZ.com par exemple on a souvent le locator renseigné sur 6 Caractères

Locator renseigné dans JTdx

Si le locator est renseigné dans JTdx (4 caractères) alors JTdx envoie cette trame vers Log4OM et Log4OM ne change rien ; donc le locator dans le Log sera renseigné avec celui envoyé par JTDX sur 4 caractères même si Log4OM trouve un autre Locator correspondant au call (via QRZ.com)

Cela est normal, si un correspondant fais un CQ avec un Locator mais que dans QRZ.com cela n’est pas mis à jour, Log4OM prendra celui donné par JTdx qui est quand même le plus fiable

Dans tous les cas, si un champ est renseigné dans la trame JTDX, Log4OM ne modifie rien

Conseils

L’astuce consiste à supprimer le contenu des champs « Grid » et « Name » dans la trame de JTdx

et dans ce cas, comme ces champs sont vides, Log4OM ira chercher le contenu sur QRZ.com et mettra à jour dans le Log.

Bien sûr AVANT il faut bien vérifier que les 4 caractères donnés par JTDX correspondent bien aux 4 premiers caractères du Locator proposé par Log4OM, sinon on garde le Locator proposé par JTdx comme décrit auparavant

Cela est dû au fait d’avoir validé la case « Use External Data » dans la connexion utilisée dans Log4OM ; si cette case n’est pas cochée alors Log4OM n’ira pas chercher des infos à l’extérieur mais utilisera juste les infos contenues dans la trame envoyée par JTdx.