Émetteur-récepteur HF — écosystème logiciel

Architecture d’intégration avec les logiciels radio

Relier le transceiver aux applications PC sans créer de conflits entre CAT, PTT, audio, journal de trafic et supervision.

CATCommande
Audio USBFlux numériques
PTTAction critique
État réelRetour télémétrique

Chaîne fonctionnelle

TransceiverPort CATAudio USBHamlib/FLRigWSJT-X/N1MMJournal QSOSupervision
Point critique : Deux logiciels ouvrant simultanément le même port CAT provoquent souvent blocages, commandes mélangées ou états incohérents.

Séparer les fonctions

Le CAT transporte fréquence, mode et commandes.

L’audio DATA reste indépendant du volume haut-parleur.

Le PTT doit pouvoir être commandé de façon robuste et revenir en RX en cas de perte.

Éviter les conflits

Un seul logiciel doit être maître du port série lorsqu’aucun serveur CAT n’est utilisé.

Hamlib ou FLRig peut servir d’intermédiaire partagé.

Les applications clientes lisent l’état réel plutôt que conserver leur propre copie.

Supervision

Les erreurs de port, timeouts et changements refusés sont journalisés.

L’état PTT, la puissance et les défauts restent visibles.

Une perte d’application ne doit pas modifier l’état de sécurité.

Repères techniques

Commande demandée ≠ état appliqué
Un seul maître direct par port série
Perte du client → PTT OFF

Contrôles systématiques

  • Un seul maître direct pour chaque port physique.
  • Lire l’état réel après chaque commande critique.
  • Tester les pertes de liaison et reconnexions.
  • Limiter les droits des interfaces réseau.
  • Conserver PTT et protections sous contrôle local.

Procédure recommandée

Lister les logiciels utilisés.
Choisir un maître CAT.
Définir le chemin audio.
Définir le mode PTT.
Configurer les timeouts.
Tester chaque client séparément.
Tester l’usage simultané.
Vérifier le retour RX sur perte.
Validation : les logiciels doivent pouvoir être fermés, redémarrés ou déconnectés sans laisser le transceiver dans un état incohérent.