
Le traducteur universel entre votre ordinateur et votre station radio
Vous utilisez WSJT-X, un logiciel de log, un programme de poursuite satellite ou une application de commande à distance ? Il y a de fortes chances que vous ayez déjà utilisé Hamlib, parfois sans même le savoir.
Ce projet libre joue un rôle discret mais essentiel : permettre aux logiciels radioamateurs de communiquer avec des transceivers, des rotors et même certains amplificateurs sans que chaque programme ait à connaître tous les protocoles de tous les constructeurs.
Pourquoi avons-nous besoin de Hamlib ?
Un transceiver moderne peut généralement être commandé depuis un ordinateur par une liaison USB, série, Ethernet, Wi-Fi ou parfois Bluetooth. Le problème est qu’il n’existe pas un langage CAT universel utilisé de manière identique par tous les appareils.
Icom possède notamment son protocole CI-V, tandis que Yaesu, Kenwood, Elecraft et les autres constructeurs utilisent leurs propres commandes et particularités.
Imaginons un logiciel de modes numériques devant supporter plusieurs centaines de radios. Sans intermédiaire, ses développeurs devraient programmer et maintenir séparément le dialogue avec chacune d’elles.
C’est précisément le problème que résout Hamlib.
Logiciel → Hamlib → protocole du constructeur → transceiver
Hamlib fournit aux logiciels une interface commune, puis se charge de traduire leurs demandes dans le langage compris par le matériel sélectionné.

Hamlib, le traducteur de la station
Prenons un exemple simple. Un logiciel souhaite régler le transceiver sur 14,074 MHz.
Pour l’application, l’ordre reste essentiellement : « règle la fréquence sur 14 074 000 Hz ».
Hamlib connaît le modèle de transceiver configuré et son protocole. Son backend, c’est-à-dire le module chargé de gérer cette famille d’appareils, transforme alors la demande en commande appropriée.
Le logiciel n’a donc pas besoin de savoir comment un IC-705, un FT-991A ou un TS-590 réalise cette opération.
C’est toute la force du système : une interface commune côté logiciel et des pilotes spécialisés côté matériel. La liste officielle montre d’ailleurs que Hamlib prend en charge des appareils provenant de très nombreux constructeurs.
Que peut commander Hamlib ?
La fréquence est seulement le début. Selon les possibilités du matériel, Hamlib peut notamment lire ou modifier le mode USB, LSB, CW, FM ou AM, sélectionner les VFO, commander le PTT, gérer le fonctionnement en split ou encore accéder à différents niveaux et réglages.
Mais Hamlib ne s’arrête pas aux transceivers. Le projet propose également des interfaces destinées aux rotors d’antennes et aux amplificateurs.
Toutes les fonctions ne sont évidemment pas disponibles sur tous les équipements. Une commande ne peut être utilisée que si le matériel lui-même la permet et si son protocole est correctement pris en charge.
Du clic de souris jusqu’au transceiver
Prenons maintenant WSJT-X. Lorsque nous sélectionnons une bande, le chemin peut être schématisé ainsi :
WSJT-X
↓
demande une fréquence
↓
Hamlib
↓
traduit la commande
↓
CAT / USB / série / réseau
↓
Transceiver
Dans les paramètres de WSJT-X, nous retrouvons justement le choix du modèle de radio, du port série, de la vitesse de communication et différentes options concernant le PTT et le fonctionnement en split. Le bouton Test CAT permet ensuite de vérifier que le dialogue fonctionne.
Ce qui paraît être une simple sélection dans un menu cache donc toute une chaîne de communication.

rigctl, rigctld, rotctl… qu’est-ce que c’est ?
Hamlib fournit également plusieurs utilitaires dont les noms peuvent sembler mystérieux.
rigctl permet de commander et d’interroger un transceiver, notamment depuis une ligne de commande.
rigctld va plus loin : le « d » signifie daemon. Il fonctionne comme un serveur de commande radio auquel d’autres logiciels peuvent se connecter par le réseau.
Pour les rotors, on retrouve le même principe avec rotctl et rotctld.
Cette architecture devient particulièrement intéressante lorsque plusieurs logiciels doivent accéder à la même radio. La documentation de WSJT-X recommande justement l’utilisation d’un véritable serveur de contrôle tel que rigctld plutôt qu’un simple partage du port série, susceptible de provoquer des collisions entre commandes CAT.
Hamlib dans une station radioamateur
Les applications sont nombreuses.
Avec WSJT-X, le logiciel peut automatiquement positionner le transceiver sur la fréquence FT8 appropriée et commander l’émission.
Un logiciel de log peut récupérer fréquence et mode afin de compléter automatiquement un QSO.
Dans une station satellite, un programme de poursuite peut modifier continuellement la fréquence afin de compenser l’effet Doppler et transmettre parallèlement les positions demandées au contrôleur du rotor.
Enfin, grâce au fonctionnement en réseau, Hamlib trouve naturellement sa place dans une station télécommandée.
Dans tous ces exemples, Hamlib n’effectue ni le décodage FT8, ni le calcul de l’orbite, ni la tenue du carnet de trafic. Il assure la communication entre l’application et le matériel.

Hamlib sait aussi faire tourner les antennes
Le pilotage des rotors est particulièrement intéressant pour les expérimentateurs.
Une station automatisée peut être organisée ainsi :
Logiciel de poursuite → Hamlib → contrôleur → rotor
Le logiciel détermine par exemple qu’une antenne doit être orientée vers un azimut de 135° et une élévation de 28°. Hamlib transmet les informations au contrôleur compatible, qui se charge du mouvement réel des moteurs.
Cela ouvre également la porte aux réalisations personnelles utilisant Arduino, Raspberry Pi ou d’autres microcontrôleurs : plutôt que d’inventer toute l’interface logicielle, le constructeur peut chercher à rendre son contrôleur compatible avec un protocole déjà reconnu.
Et quand cela ne fonctionne pas ?
Hamlib n’est pas magique. Un mauvais modèle de transceiver, un port COM incorrect, une mauvaise vitesse série ou une configuration RTS/DTR inadaptée suffisent à empêcher la communication.
Autre piège classique : deux logiciels tentant de commander directement le même port CAT. Les commandes peuvent alors entrer en collision. L’utilisation d’un serveur comme rigctld constitue une solution beaucoup plus propre lorsque plusieurs applications doivent partager le contrôle d’une radio.
Il faut également garder Hamlib suffisamment à jour : la prise en charge des matériels et de leurs fonctionnalités évolue régulièrement.
Une formidable boîte à outils pour expérimenter
Hamlib devient particulièrement intéressant dès que l’on souhaite dépasser le simple couple ordinateur-transceiver.
PC → Hamlib → réseau → Raspberry Pi ou contrôleur → station
À partir de cette architecture, on peut imaginer une station distante, un rotor automatique, une station satellite, un banc de mesure ou quantité d’autres automatismes.
Et comme Hamlib est un projet libre, il constitue également une excellente base pour les radioamateurs qui aiment comprendre, programmer et construire leurs propres équipements.
Pour aller plus loin
Vous souhaitez approfondir Hamlib ou vérifier si votre matériel est compatible ? Quelques ressources de référence permettent d’aller plus loin :
- Projet officiel Hamlib sur GitHub — code source, versions, documentation et actualités du projet.
- Liste des transceivers compatibles — pour vérifier la prise en charge de votre poste et l’état du backend correspondant.
- Documentation de rigctl — pour découvrir les commandes permettant de piloter directement un transceiver.
- Documentation de rigctld — indispensable pour comprendre le pilotage d’une radio à travers le réseau.
- Guide utilisateur WSJT-X — un excellent exemple d’intégration concrète de Hamlib et du contrôle CAT.
De quoi passer progressivement de la simple utilisation de Hamlib à l’expérimentation et à l’automatisation complète d’une station.
Ce qu’il faut retenir
Hamlib n’est ni un logiciel FT8, ni un carnet de trafic, ni un programme de poursuite satellite. C’est avant tout une couche de communication universelle entre nos logiciels et nos équipements radio.
Il évite aux développeurs de réinventer la commande CAT de chaque appareil et facilite considérablement l’automatisation d’une station.
Vous ne voyez presque jamais Hamlib. Pourtant, il est probablement déjà quelque part dans votre station.