Qu’est-ce que le CAT ?

CAT signifie Computer Aided Transceiver : le pilotage d’un émetteur-récepteur par un ordinateur. Concrètement, l’ordinateur et la radio échangent des ordres sur une liaison série. Le PC peut lire l’état de la radio (fréquence, mode, niveau S-mètre) et lui envoyer des consignes (changer de VFO, régler la puissance, activer le split, déclencher l’émission).

Le terme a été forgé par Yaesu à la fin des années 1980 (on rencontre parfois « Computer Aided Tuning », mais ce n’est pas la dénomination d’origine), puis il s’est généralisé à tous les constructeurs. Aujourd’hui, dès que vous faites du FT8, du contest ou du logbook automatique, c’est le CAT qui travaille en arrière-plan.

À quoi ça sert

Le CAT n’est pas un gadget : il est devenu indispensable dès qu’un logiciel doit connaître ou modifier l’état de la radio.

• Modes numériques : WSJT-X, JTDX, FLDigi ou JS8Call lisent la fréquence et commandent le passage en émission.
• Journal de trafic : Log4OM, CQRLOG ou N1MM+ enregistrent automatiquement fréquence et mode de chaque QSO.
• Concours : le logiciel de contest suit la radio en temps réel et gère le split ou le second VFO.
• Pilotage à distance : la même liaison, transportée sur le réseau, permet d’opérer une station distante.
• Automatismes : commutation d’antenne, pilotage d’un rotor de satellite, correction Doppler, boîtes d’accord.

Comment ça marche

Sous le capot, le CAT est une simple liaison série asynchrone. Les données circulent bit à bit, sans horloge partagée, avec un format que les deux extrémités doivent connaître à l’avance. Le format le plus courant est le 8N1 : 8 bits de données, pas de parité, 1 bit de stop.

Deux paramètres doivent absolument concorder entre le PC et la radio :

• le débit (baud rate) : 4800, 9600, 19200, 38400, 57600 ou 115200 bauds selon les modèles ;
• le protocole : la « langue » dans laquelle les ordres sont formulés, propre à chaque constructeur.

Un mauvais débit ou un mauvais protocole, et le dialogue échoue silencieusement. C’est la cause numéro un des pannes de CAT.

Les grands protocoles

Chaque constructeur a défini son propre jeu de commandes. Trois familles dominent, plus quelques dérivés.

Icom — CI-V

Icom utilise le bus CI-V (Communication Interface V). Sa particularité : un seul fil bidirectionnel à collecteur ouvert, au niveau TTL. Plusieurs appareils peuvent partager le même bus, chacun repéré par une adresse en hexadécimal. L’IC-7300, par exemple, répond par défaut à l’adresse 94h ; le contrôleur (le PC) prend par convention l’adresse E0h.

Une trame CI-V se lit ainsi :

FE FE  94  E0  03  FD
│  │   │   │   │   └─ fin de trame
│  │   │   │   └───── commande (03 = lire la fréquence)
│  │   │   └───────── adresse émetteur (E0 = le PC)
│  │   └───────────── adresse destinataire (94 = IC-7300)
└──┴───────────────── préambule (deux octets FE)

Les données de fréquence sont codées en BCD. Les débits vont historiquement de 1200 à 19200 bauds, et jusqu’à 115200 sur les liaisons USB modernes.

Kenwood — commandes ASCII

Kenwood a choisi des commandes lisibles en clair, terminées par un point-virgule. Les fréquences sont codées sur 11 chiffres en hertz (avec complétion par des zéros à gauche) :

FA00014250000;   règle la fréquence sur 14,250 MHz (11 chiffres)
FA;              interroge la fréquence du VFO A
IF;              renvoie l'état complet de la radio

Ce protocole a l’avantage d’être facile à observer avec un simple terminal série. Il a été si largement adopté qu’il sert aujourd’hui de référence chez d’autres constructeurs.

Yaesu — deux générations

Les anciennes radios (FT-817, FT-857, FT-897) utilisent un protocole binaire : des trames de cinq octets, soit quatre octets de paramètres suivis d’un octet d’instruction. Les modèles récents (FT-991A, FTDX10, FT-710…) ont adopté un jeu de commandes ASCII terminées par un point-virgule, très proche du modèle Kenwood.

Elecraft, FlexRadio et les autres

Beaucoup de constructeurs se sont alignés sur le jeu de commandes Kenwood, souvent en l’étendant. Elecraft (K3, KX3) et FlexRadio en sont les exemples les plus connus. Cette convergence explique pourquoi un même logiciel pilote des radios de marques différentes sans difficulté.

Les liaisons physiques

Le protocole décrit ce qu’on dit ; la liaison physique décrit comment le signal circule. Trois cas se présentent.

RS-232

La liaison série historique, sur prise DB9. Les niveaux logiques sont inversés et élevés : de -3 V à -15 V pour un ‘1’ (Mark) et de +3 V à +15 V pour un ‘0’ (Space). Pour dialoguer avec un microcontrôleur ou une logique moderne, un adaptateur de niveau tel que le composant MAX232 est indispensable. On ne la trouve plus que sur les radios anciennes et les PC de bureau.

TTL

Le niveau logique direct : 0 et 3,3 V, ou 0 et 5 V selon les composants. C’est ce que l’on trouve en sortie des ponts USB-série et sur les bus comme le CI-V. Attention à ne pas mélanger 3,3 V et 5 V sans précaution : la plupart des ponts USB modernes travaillent en 3,3 V, et leurs entrées ne tolèrent pas forcément une ligne à 5 V franc.

USB

C’est aujourd’hui la voie la plus courante. Une puce fait le pont entre l’USB et la liaison série ; elle apparaît alors comme un port COMx sous Windows ou /dev/ttyUSBx sous Linux. Les puces les plus répandues :

• FTDI (FT232) : réputée fiable, mais victime de nombreuses contrefaçons.
• Silicon Labs (CP2102, CP2104, CP2105) : très courante sur les radios et modules récents.
• WCH (CH340, CH341) : bon marché, désormais bien prise en charge.
• Prolific (PL2303) : historique, pilotes parfois délicats sur Windows récent.

Le passage en émission (PTT)

Commander l’émission depuis le PC peut se faire de trois façons, de la plus simple à la plus rustique :

• Par commande CAT : le logiciel envoie l’ordre d’émettre sur la même liaison série (ex: commande TX;). C’est la méthode la plus propre, sans câblage supplémentaire.
• Par ligne matérielle : le logiciel bascule le signal RTS ou DTR du port série (ou du second port COM virtuel), qui commande un transistor ou un optocoupleur fermant le PTT de la radio.
• Par VOX : la radio détecte la présence d’audio et passe seule en émission. Aucun fil de commande, mais un réglage plus délicat.

Un conseil : n’activez pas deux méthodes en même temps. Un PTT par commande CAT qui coexiste avec un PTT sur RTS finit toujours par se contredire.

Couches d’abstraction : Hamlib & Omni-Rig

Se souvenir du protocole exact de chaque radio serait un cauchemar pour les développeurs. Des bibliothèques logicielles permettent d’interfacer n’importe quelle radio avec n’importe quel logiciel.

Hamlib est la référence multiplateforme (Linux, Windows, macOS). Elle masque les centaines de modèles derrière une interface commune. On la pilote en ligne de commande avec rigctl, ou en réseau avec le démon rigctld. De nombreux logiciels (WSJT-X, FLDigi, CQRLOG) s’appuient directement dessus.

# Interroger la fréquence d'une radio via rigctl
rigctl -m 3073 -r /dev/ttyUSB0 -s 115200 f
# -m : numéro de modèle Hamlib (ici IC-7300)
# -r : port série     -s : débit     f : lire la fréquence

Sous Windows, Omni-Rig est extrêmement populaire : il agit comme un serveur CAT centralisé permettant à plusieurs logiciels de partager la même radio simultanément (par exemple, votre journal de trafic et un logiciel de modes numériques) sans conflit de port COM.

Les logiciels qui utilisent le CAT

La liste est longue et couvre tous les usages : WSJT-X et JTDX pour le FT8/FT4, JS8Call pour le JS8, FLDigi pour les modes texte, Log4OM et CQRLOG pour le journal, N1MM+ pour les concours, Ham Radio Deluxe et SDR Console pour le pilotage général. Tous demandent, à la configuration, le même trio d’informations : le port, le débit et le modèle de radio.

Problèmes courants & dépannage

Un test rapide : ouvrez le port dans un terminal série en 8N1 au débit annoncé par la radio. Changez la fréquence sur le poste : vous devez voir des caractères défiler. Si rien n’apparaît, le problème est en amont du logiciel.