Connections fr

Connexions

🇬🇧 Connections

Réglages → Connexions, c'est là qu'OpsLog dialogue avec les autres logiciels et avec du matériel sur le réseau : ce qu'il écoute, ce qu'il envoie, et les messages que tu écris toi-même.

Cela s'appelait UDP jusqu'à ce qu'un second transport apparaisse — une ligne peut désormais envoyer une requête HTTP GET au lieu d'un datagramme, ce que comprennent la plupart des commutateurs d'antennes faits maison.

Chaque ligne a un nom, un sens, un type de service, un port et un interrupteur. Tout ce qui est envoyé et reçu est écrit dans le journal de l'application, donc une ligne qui ne fonctionne pas se diagnostique au lieu de se deviner — voir Dépannage pour savoir où vit le journal.

---

En entrée — ce qu'OpsLog écoute

Service	Qui l'envoie	Usage
WSJT-X / JTDX / MSHV	ces logiciels, port 2237	Journaliser leurs QSO automatiquement, suivre l'indicatif DX travaillé, et afficher leurs décodages. Le multicast est normal ici.
ADIF en UDP	JTAlert, GridTracker, FLDIGI	Un enregistrement ADIF texte par QSO journalisé.
N1MM Logger+	N1MM	Son enregistrement de contact en XML.
Indicatif distant	DXHunter et similaires	Un indicatif — et éventuellement une fréquence et un mode — à charger dans le formulaire et sur lequel s'accorder.

Multicast ou unicast ?

WSJT-X et MSHV diffusent normalement vers un groupe multicast (239.255.0.1 en général) pour que plusieurs logiciels les entendent à la fois. Coche Multicast et donne le groupe. Un logiciel qui n'envoie qu'à une seule adresse n'a besoin que d'unicast — laisse la case décochée.

Si tu fais aussi tourner GridTracker, ou quoi que ce soit d'autre qui écoute ton décodeur, lis d'abord Modes numériques et GridTracker : deux logiciels sur un même port unicast fonctionnent ou non selon lequel a démarré le premier, et c'est la cause habituelle du « les décodages arrivaient hier et plus aujourd'hui ».

Un groupe multicast est une adresse entre 224.0.0.0 et 239.255.255.255. 127.0.0.1 n'en est pas une — une ligne cochée Multicast avec une adresse de loopback ou de LAN dans la case du groupe écoute en unicast à la place, et le dit dans le journal.

Ne mets pas une ligne entrante et une ligne sortante sur le même port. OpsLog reçoit alors ses propres messages, et ce qu'il publie peut lui revenir comme une commande. Il le dit dans le journal quand il repère la configuration : « X émet sur le port 2241 et Y y écoute — OpsLog y recevra ses propres messages ; donne un autre port à l'une des deux. »

---

En sortie — ce qu'OpsLog envoie

Service	Format	Déclenché par
Message ADIF	un enregistrement ADIF simple	chaque QSO journalisé
QSO journalisé WSJT-X	le même ADIF emballé dans un datagramme WSJT-X	chaque QSO journalisé
Relayer le flux WSJT-X	chaque datagramme reçu, octet pour octet	à l'arrivée
Fréquence PstRotator	<PST><FREQUENCY>	changement de fréquence
N1MM RadioInfo	le XML RadioInfo de N1MM	changement de fréquence ou de mode
Message personnalisé	ce que tu écris	un déclencheur que tu choisis

Relayer le flux WSJT-X

WSJT-X, JTDX et MSHV n'envoient chacun qu'à une seule adresse. Sans relais, il faut choisir entre OpsLog et JTAlert / GridTracker, pas les deux.

Cette ligne réémet chaque datagramme reçu par une ligne WSJT-X entrante, octet pour octet, vers un autre logiciel — pour qu'OpsLog cesse d'être la raison pour laquelle tu ne peux pas faire tourner les deux ensemble :

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

Pointe-la sur le port de l'autre logiciel. La pointer sur l'un des ports d'écoute d'OpsLog réinjecterait le flux dans lui-même à l'infini ; le relais refuse et le dit dans le journal plutôt que de noyer le réseau.

Rien n'est ajouté aux datagrammes — pas d'en-tête d'origine. Certains relais du terrain en préfixent un (127.0.0.1:2237|), ce qui est exactement le genre de chose pour laquelle OpsLog a dû écrire du code afin d'y survivre côté réception ; le transmettre en aval serait répéter cette erreur.

Si tous les logiciels concernés savent faire du multicast, préfère-le : chacun reçoit sa propre copie et aucun relais n'est nécessaire. Voir Modes numériques et GridTracker.

PstRotator : quel tracker choisir

Pour la ligne fréquence PstRotator, règle le tracker de PstRotatorAz sur DXLog.net — c'est le format qu'OpsLog envoie, et son port par défaut est 12040. La ligne N1MM RadioInfo est lue par le tracker N1MM de PstRotator, et par bien d'autres outils. Les deux marchent ; choisis-en un et règle le tracker correspondant.

Colorer la fenêtre du décodeur

OpsLog peut colorer les indicatifs dans la fenêtre Band Activity de WSJT-X ou de JTDX, d'après ton journal : une station de la watchlist, un nouveau DXCC, une nouvelle bande pour son entité, un nouvel état américain. C'est appliqué en direct à l'arrivée des décodages, et les couleurs sont à toi de choisir (Connexions → coloration).

Laquelle pour un autre carnet ?

Si un carnet annonce qu'il accepte « WSJT-X UDP », c'est la ligne QSO journalisé WSJT-X qu'il veut — il écoute sur l'interface WSJT-X et jette silencieusement un enregistrement ADIF nu. Logger32 est le cas habituel. Un carnet qui documente un écouteur ADIF simple veut la ligne Message ADIF à la place. Ce sont deux lignes parce que ce sont deux choses différentes sur le réseau ; active celle que ton carnet demande, pas les deux, sinon le QSO arrive en double.

---

Messages personnalisés

Le cas général : tu choisis quand cela part, ce que cela dit, et comment cela sort. C'est ainsi qu'un commutateur d'antennes fait maison, un boîtier de relais ou un serveur domotique apprend ce que fait la station.

1. Choisis le déclencheur

Déclencheur	Se déclenche quand
QSO journalisé	un contact est enregistré
Changement de bande	la radio change de bande — ou, sur une station sans CAT, le sélecteur de bande du bandeau de saisie
Commande de rotor	on demande à l'antenne de tourner (boussole, boutons SP/LP, clic sur un spot)
Recherche terminée	une recherche dans un annuaire répond

2. Écris le message

Tout ce qui est entre {accolades} est remplacé. Ce qui est disponible dépend du déclencheur :

Déclencheur	Variables
QSO journalisé	{call} {band} {band_m} {mode} {grid} {name} {country} {rst_s} {rst_r} {comment} {date} {time} {freq_hz} {freq_mhz} {dxcc}
Changement de bande	{band} {band_m} {mode} {freq_hz} {freq_mhz}
Commande de rotor	{az} {el} {path} (SP, LP ou vide)
Recherche terminée	{call} {name} {grid} {country} {qth} {state} {dxcc}

{band} donne 20m ; {band_m} donne juste 20, parce qu'un commutateur d'antennes veut généralement le nombre et rien d'autre.

3. Choisis le transport

• UDP — un datagramme vers une adresse et un port. Tu choisis la fin de ligne.
• URL — une requête HTTP GET. Les valeurs sont encodées pour l'URL automatiquement. Les identifiants peuvent s'écrire dedans sous la forme http://user:pass@hôte/… ; ils sont stockés exactement tels que tapés, donc réserve cela à ton propre réseau.

Pour un commutateur d'antennes ou une carte de relais, Station Control → relais est le meilleur outil : il tient l'état, relit les cartes au démarrage, et ne recommute pas chaque fois que tu bouges à l'intérieur d'une bande. Un commutateur fait maison s'y déclare en type Relais HTTP — voir Amplis et commutateurs. Les messages personnalisés sont pour tout ce qui n'est pas un relais.

Exemples

Commuter un commutateur d'antennes à chaque changement de bande, en HTTP :

Déclencheur : Changement de bande
Transport   : URL
URL         : http://192.168.1.50/set?band={band_m}

20 m → http://192.168.1.50/set?band=20

Dire à un afficheur de rotor où va l'antenne :

Déclencheur : Commande de rotor
Transport   : UDP  →  192.168.1.77:8100
Message     : <AZIMUT>{az}</AZIMUT><PATH>{path}</PATH>

Annoncer chaque QSO à un tableau de bord de shack :

Déclencheur : QSO journalisé
Transport   : URL
URL         : http://homeassistant.local:8123/api/webhook/qso?call={call}&band={band}&mode={mode}

Les identifiants dans une URL sont envoyés tels que tapés — c'est prévu pour un réseau local. Les mots de passe sont masqués dans le journal, pour qu'un fichier de journal puisse être partagé sans risque.

Quand un changement de bande est un changement de bande

Le déclencheur « changement de bande » suit la radio, parce qu'un commutateur d'antennes doit suivre la radio et non ce qui est tapé. Changer de bande dans le bandeau pilote la radio, la radio annonce la nouvelle bande, et le déclencheur part de là.

Sur une station dont OpsLog ne pilote pas la radio, il n'y a rien qui revienne, donc le sélecteur de bande lui-même compte comme le changement de bande. Le verrou 🔒 sur la bande ou la fréquence le supprime : un verrou signifie que la saisie est volontairement découplée de la radio, et rien ne doit bouger pour un contact enregistré depuis l'année dernière.

---

Diagnostiquer une ligne qui ne fait rien

Le journal nomme chaque message. Dans l'ordre, vérifie :

1. La ligne est-elle activée ? La liste le montre.
2. udp: Reload done — N server(s) running au démarrage, et une ligne cfg id=… name=… dir=… service=… port=… par entrée. Une ligne qui n'a pas démarré est listée avec son erreur.
3. En sortie : udp: [NOM] sent N bytes to ADRESSE (service) pour un datagramme, ou l'URL pour une ligne HTTP.
4. Un message qui se rend vide est sauté et le journal le dit — en général une variable que le déclencheur ne fournit pas.
5. a QSO was logged but no outbound "ADIF message" row is enabled — la réponse au « pourquoi mon autre carnet ne reçoit rien ».

Voir aussi : Amplis et commutateurs pour les cartes de relais et leur contrôle automatique, et Cluster DX et spots pour les sources de spots.