Bienvenue sur le Site du Radio-Club F5KEE de Viry-Châtillon (91 – Essonne)!

Chers(es) visiteurs(ses) et passionnés(es) de radio et de sciences,

Le Radio-Club F5KEE vous accueille à la Maison des Associations de Viry-Châtillon, au cœur de l’Essonne. Dans ce lieu ouvert et convivial, nous réunissons toutes celles et ceux qui partagent la curiosité des sciences, des techniques et des communications sans fil.

Le radioamateurisme, c’est bien plus qu’un simple hobby :
c’est une passion universelle, où l’on apprend à dialoguer avec le monde entier, à construire ses propres antennes et équipements, à explorer la propagation des ondes, mais aussi à découvrir les technologies numériques et les satellites.

À qui s’adresse le radio-club ?

Le F5KEE s’adresse à tous les publics :

  • les curieux qui veulent découvrir ce qu’est la radio et comment on peut communiquer sans Internet,

  • les jeunes et étudiants attirés par la technique, l’électronique ou l’aéronautique,

  • les futurs radioamateurs qui souhaitent préparer la licence,

  • les opérateurs confirmés qui veulent partager leurs expériences, expérimenter ou participer à des contests,

  • et plus largement, toute personne désireuse d’apprendre, de pratiquer et d’échanger dans un cadre associatif.

Que fait-on au F5KEE ?

Nos activités sont variées et adaptées à tous les niveaux :

  • Découverte et formation : initiation aux bases de la radio, aide à la préparation de la licence radioamateur.

  • Pratique du trafic : contacts en phonie, en CW (morse), en modes numériques (FT8, …), via satellites ou encore à travers le monde en HF.

  • Expérimentations techniques : réalisation et essais d’antennes, utilisation du SDR, projets autour de l’Arduino ou d’interfaces numériques.

  • Activités collectives : organisation de démonstrations publiques, projets éducatifs en lien avec les écoles ou évènements internationaux (ARISS, QO-100, etc.).

  • Vie de club : échanges, entraide, convivialité et partage de connaissances dans une ambiance amicale.

Pourquoi nous rejoindre ?

Adhérer au Radio-Club F5KEE, c’est rejoindre une communauté dynamique et passionnée, c’est apprendre en pratiquant, c’est aussi trouver un lieu où la curiosité technique et la convivialité se conjuguent au quotidien.

C’est également l’occasion d’acquérir des bases solides en électricité et en électronique, compétences précieuses pour comprendre le fonctionnement des équipements mais aussi pour, pourquoi pas, préparer un futur métier dans les domaines techniques, scientifiques ou industriels.

Que vous soyez simple curieux, débutant ou opérateur chevronné, poussez la porte de la Maison des Associations de Viry-Châtillon : F5KEE vous accueille et vous invite à découvrir le monde fascinant du radioamateurisme.

L’équipe du Radio-Club F5KEE de Viry-Châtillon

Construire un émetteur QRP minimaliste en 2026 : que peut-on apprendre avec quelques composants ? (Tuna Tin 2)

Banniere Tina Tin 2

Aujourd’hui, un transceiver SDR peut embarquer des millions de transistors, des convertisseurs rapides et un puissant processeur de signal. Impressionnant… mais pas forcément idéal pour comprendre comment naît réellement un signal radio.

Pour cela, revenons en 1976 avec un montage devenu mythique : le Tuna Tin 2, un véritable émetteur CW pour la bande des 40 mètres construit avec… deux transistors et une poignée de composants.

Une boîte de thon devenue célèbre

Le Tuna Tin 2 fut imaginé par Doug DeMaw, W1CER puis W1FB, alors membre de l’équipe technique de l’ARRL. Son montage paraît dans QST en mai 1976 : un petit émetteur QRP installé sur une boîte de conserve métallique.

Le principe est remarquablement simple :

Quartz → oscillateur → amplificateur RF → filtre passe-bas → antenne

tuna tin

Architecture simplifiée du Tuna Tin 2.

Deux transistors 2N2222 suffisent. Le premier génère le signal HF, le second fournit la puissance nécessaire à l’antenne.

Premier miracle : fabriquer du 7 MHz avec du continu

Une alimentation de 12 V ne produit évidemment aucune HF. C’est le premier transistor qui transforme cette énergie continue en oscillation.

Un quartz 40 m est placé dans la boucle de réaction de l’oscillateur. Grâce à sa très forte sélectivité, il impose pratiquement la fréquence d’émission.

C’est une première leçon fondamentale : l’énergie vient de l’alimentation, mais le quartz détermine la fréquence.

Et contrairement à un VFO, il n’y a quasiment rien à régler.

Deuxième transistor : passer des milliwatts aux centaines de milliwatts

Le signal produit par l’oscillateur est encore trop faible pour être envoyé directement vers l’antenne.

Le deuxième 2N2222 fonctionne donc comme amplificateur RF. Une réalisation typique fournit environ un demi-watt.

Cela paraît dérisoire. Pourtant :

    \[500\ \mathrm{mW}=0,5\ \mathrm{W}\approx27\ \mathrm{dBm}\]

Sur une charge fictive de 50 Ω, on peut même retrouver la puissance avec :

    \[P=\frac{V_{\mathrm{RMS}}^2}{R}\]

Le Tuna Tin devient ainsi un excellent petit laboratoire de mesure RF.

Le composant essentiel : le filtre de sortie

Un transistor ne produit pas une sinusoïde parfaite. En plus de notre fondamentale vers 7 MHz apparaissent des harmoniques, notamment vers 14, 21 ou 28 MHz.

Effet du filtre passe-bas du Tuna Tin 2.

D’où le réseau LC placé en sortie : le filtre passe-bas.

Il laisse passer le 7 MHz tout en atténuant fortement les fréquences supérieures. Les versions modernisées du Tuna Tin 2 conservent naturellement ce principe.

Voilà une excellente expérience : observer le signal avant et après filtrage avec un analyseur de spectre.

Un émetteur simple ne doit jamais devenir un émetteur sale !

Et peut-on vraiment communiquer avec 500 mW ?

Absolument.

Le QRP démontre justement que la puissance ne fait pas tout. Une bonne antenne, peu de pertes dans le coaxial, un correspondant attentif et une propagation favorable peuvent permettre des liaisons étonnamment lointaines.

Le Tuna Tin 2 original a même inspiré des défis QRP et des réalisations ayant obtenu le Worked All States avec environ un demi-watt.

Sur 40 mètres, le plan de bande IARU Région 1 prévoit 7000 à 7040 kHz pour la CW, avec 7030 kHz comme centre d’activité QRP CW.

Construire un Tuna Tin 2 en 2026 ?

C’est justement là que l’expérience devient intéressante.

Deux 2N2222A, quelques résistances et condensateurs, un quartz, quelques inductances, un filtre passe-bas, une alimentation et une prise BNC suffisent pour retrouver les fondamentaux d’un véritable émetteur.

Mais aujourd’hui, nous pouvons ajouter quelque chose dont Doug DeMaw ne disposait pas aussi facilement en 1976 : nos instruments de mesure modernes.

La démarche devient alors :

Construire → brancher une charge fictive 50 Ω → mesurer la fréquence → mesurer la puissance → observer les harmoniques → vérifier le filtrage → seulement ensuite connecter l’antenne.

Le Tuna Tin 2 ne remplacera évidemment pas votre transceiver moderne. Mais pour comprendre ce qui se passe réellement entre 12 volts et une antenne, deux transistors peuvent parfois en apprendre beaucoup plus qu’un SDR à 2 000 €.

Liens et ressources utiles

Pour ceux qui souhaitent aller plus loin, retrouver le schéma du Tuna Tin 2 ou envisager sa construction, voici une sélection de ressources intéressantes :

  • Tuna Tin 2 original — QST, mai 1976 : l’article de Doug DeMaw, W1FB, « Build a Tuna Tin 2 », pp. 14–16, est la publication qui a lancé ce petit émetteur devenu un classique du QRP. L’ARRL confirme également que le montage original figurait en couverture de ce numéro.
    ARRL — histoire du Tuna Tin 2
  • Une adaptation avec des composants plus modernes : Doug Hendricks, KI6DS, explique comment le circuit historique a été adapté afin d’utiliser des composants plus faciles à trouver. C’est une excellente ressource pour qui souhaite réellement reconstruire le montage.
    The Tuna Tin 2 Transmitter — KI6DS
  • Schéma détaillé du Tuna Tin 2 : cette version « 35th Anniversary » montre clairement les deux 2N2222A, l’oscillateur à quartz, l’amplificateur, les valeurs des composants et surtout le filtre passe-bas de sortie. Le document indique également plusieurs tensions utiles pour le dépannage.
    QRPme — schéma Tuna Tin 2 35th Anniversary
  • Manuel de construction NJQRP : probablement la ressource la plus intéressante pour passer de la théorie à la pratique. On y trouve schéma, implantation des composants, câblage, transformateurs et procédure de mesure.
    NJQRP — Tuna Tin 2 Assembly Manual
  • Plan de bande IARU Région 1 : sur 40 mètres, la plage 7000–7040 kHz est prévue pour la CW et 7030 kHz constitue le centre d’activité QRP CW. Attention : il s’agit d’un centre d’activité, pas d’une fréquence réservée.
    IARU Région 1 — HF Band Plan
  • Réglementation radioamateur française : l’ANFR rassemble sur cette page les textes concernant les bandes attribuées, les conditions d’utilisation des installations radioamateurs et les principales références réglementaires françaises.
    ANFR — cadre juridique radioamateur

Après la HF, RADE : l’IA pourrait-elle révolutionner nos talkies VHF/UHF ?

RADE en VHF/UHF

Nous avons déjà évoqué sur F5KEE RADE (Radio Autoencoder) et les résultats étonnants obtenus en HF. Mais les chercheurs du projet FreeDV explorent maintenant un autre terrain qui concerne directement beaucoup plus de radioamateurs au quotidien : nos communications VHF et UHF.

Et si, après avoir transformé la manière de transmettre de la voix en HF, l’intelligence artificielle pouvait un jour se retrouver dans nos talkies ?

De la FM au numérique… puis à l’IA

Sur VHF/UHF, la bonne vieille FM analogique reste remarquablement efficace. À ses côtés sont apparus plusieurs systèmes numériques : D-Star, DMR, C4FM, puis plus récemment M17, protocole ouvert utilisant Codec 2.

Malgré leurs différences, ces systèmes reposent généralement sur une architecture assez classique :

voix → vocodeur → correction d’erreurs → modulation → radio

Chaque bloc accomplit une fonction bien définie.

Avec RADE-BBFM, pour RADE over Baseband FM, les chercheurs de FreeDV proposent une approche radicalement différente : utiliser l’apprentissage automatique pour remplacer une grande partie de cette chaîne de traitement traditionnelle.

RADE-BBFM : une IA derrière la FM

L’idée est astucieuse car il n’est pas nécessaire de réinventer toute la partie radio.

RADE-BBFM conserve une architecture Baseband FM (BBFM) que l’on retrouve dans de nombreuses radios VHF/UHF. Ce sont principalement le traitement de la parole et la protection contre les erreurs qui sont remplacés par un autoencodeur neuronal entraîné pour fonctionner directement avec les imperfections du canal radio.

On pourrait résumer très simplement la chaîne :

Micro → encodeur neuronal RADE → FM → canal radio → décodeur neuronal RADE → haut-parleur

L’IA apprend donc non seulement à représenter efficacement la parole, mais également à la reconstruire lorsqu’elle a été dégradée par le bruit, l’affaiblissement ou les évanouissements du signal.

C’est là que RADE devient particulièrement intéressant.

Et cela fonctionne déjà sur de vraies radios UHF

Nous ne sommes plus uniquement devant une simulation informatique.

David Rowe et Tibor Bece ont publié en 2025 leurs travaux dans RADE for Land Mobile Radio: A Neural Codec for Transmission of Speech over Baseband FM Radio Channels. Ils y décrivent notamment une démonstration utilisant des radios UHF du commerce.

Les essais et simulations montrent une qualité vocale supérieure à la FM analogique dans certaines conditions difficiles, notamment en présence de fading. FreeDV présente également des comparaisons audio entre FM analogique, D-Star et RADE.

Plus intéressant encore : des modèles ont été testés sur des canaux simulant un véhicule se déplaçant à 30, 60 et 120 km/h, avec des résultats encourageants même lorsque les conditions diffèrent de celles utilisées pour l’apprentissage.

Alors, bientôt RADE dans nos talkies ?

Pas encore.

L’un des principaux obstacles reste la puissance de calcul et la mémoire nécessaires. Les protocoles actuels ont été conçus pour fonctionner sur des processeurs embarqués modestes, tandis qu’un réseau neuronal demande davantage de ressources. FreeDV souligne cependant que les besoins de RADE restent très inférieurs aux capacités d’un smartphone moderne, et des essais ont déjà été réalisés sur des processeurs embarqués.

L’évolution des microprocesseurs et accélérateurs dédiés à l’IA pourrait donc rapidement changer la donne.

Et si le premier talkie « IA » venait des radioamateurs ?

C’est peut-être finalement la partie la plus enthousiasmante.

RADE-BBFM est développé en open source et FreeDV fournit le code permettant aux expérimentateurs avancés de reproduire les travaux.

Le monde radioamateur dispose parallèlement de projets ouverts comme M17, qui démontrent qu’il est possible de développer nos propres systèmes de radiocommunication numérique.

Il devient alors tentant d’imaginer un futur portatif SDR capable de charger différents modes par logiciel, parmi lesquels un mode vocal neuronal particulièrement robuste.

Un processeur suffisamment puissant, un émetteur-récepteur VHF/UHF ouvert, RADE-BBFM et quelques radioamateurs motivés… Le premier véritable talkie utilisant l’IA ne viendra peut-être pas d’un grand constructeur.

Et si notre prochain projet de construction commençait justement ici ?

Liens et ressources utiles

Votre NanoVNA sait faire beaucoup plus que mesurer le ROS : 10 expériences RF à essayer

Banniere NanoVNA

Pour beaucoup de radioamateurs, le NanoVNA est devenu l’instrument que l’on sort lorsqu’une antenne refuse obstinément d’afficher un ROS convenable. On branche le coaxial sur CH0, on cherche le minimum de ROS et l’appareil retourne dans son tiroir. C’est dommage, car nous n’utilisons alors qu’une petite partie de ses possibilités.

Un NanoVNA est avant tout un analyseur de réseau vectoriel. Il ne mesure pas seulement combien d’énergie revient vers l’émetteur : il mesure également l’amplitude et la phase des signaux. Il peut ainsi nous renseigner sur l’impédance d’une antenne, les pertes d’un câble, la réponse d’un filtre ou encore nous aider à localiser un défaut dans une ligne coaxiale.

Deux paramètres vont nous accompagner dans les expériences suivantes :

  • S11 mesure ce qui est réfléchi vers le port CH0 ;
  • S21 mesure ce qui est transmis de CH0 vers CH1.

Mesurer S11 et S21 avec un NanoVNA

Les deux mesures fondamentales du NanoVNA : S11 analyse le signal réfléchi par l’antenne ou la charge sur CH0, tandis que S21 mesure la transmission d’un signal de CH0 vers CH1 à travers un câble, un filtre ou un autre dispositif RF.

Avec seulement quelques câbles, adaptateurs et composants, notre petit NanoVNA peut donc devenir un véritable laboratoire RF de poche. Voici dix expériences pour le découvrir.

Avant de commencer : calibrez !
Une mesure n’est valable que si le NanoVNA a été correctement calibré sur la plage de fréquences utilisée. Pour les mesures en réflexion, on utilise les références OPEN, SHORT et LOAD. Pour les mesures de transmission entre CH0 et CH1, on ajoute notamment THRU. La calibration doit idéalement être réalisée au niveau du connecteur où commencera réellement le dispositif à mesurer.

1. Trouver la vraie fréquence de résonance d’une antenne

Première expérience : oublions quelques instants le ROS.

Branchez une antenne sur CH0 et affichez simultanément le ROS et l’abaque de Smith. Placez ensuite un marqueur autour de la fréquence où l’antenne semble résonner.

Le NanoVNA permet de lire son impédance sous la forme :

    \[Z=R+jX\]

avec R, la partie résistive, et X, la partie réactive.

À la résonance, nous recherchons surtout :

    \[X \approx 0\]

Une antenne peut donc parfaitement être résonante avec une impédance de 35 Ω, 70 Ω ou 100 Ω. Son ROS ne sera alors pas égal à 1 sur une ligne de 50 Ω.

C’est une distinction essentielle :

résonance et adaptation d’impédance ne sont pas la même chose.

Le NanoVNA permet justement de voir les deux phénomènes séparément, là où un simple ROS-mètre ne nous donne qu’une partie de l’histoire.

2. Mesurer la longueur d’un câble coaxial

Le NanoVNA peut également nous renseigner sur ce qui se passe le long d’un câble. Pour cela, il exploite ses mesures fréquentielles et les transforme dans le domaine temporel : c’est le principe utilisé par la fonction TDR (Time Domain Reflectometry).

Branchez sur CH0 un câble coaxial dont l’autre extrémité reste ouverte. Après calibration, effectuez un balayage sur une plage de fréquences suffisamment large puis affichez la représentation temporelle, directement sur les modèles qui le permettent ou avec un logiciel comme NanoVNA-Saver.

Le signal parcourt le câble, rencontre son extrémité ouverte et revient vers le NanoVNA. Le délai mesuré correspond donc à un aller-retour.

En connaissant la vitesse de propagation dans le câble, le logiciel peut convertir ce délai en distance et ainsi estimer sa longueur.

C’est une façon étonnamment simple de mesurer un coaxial de plusieurs mètres… sans dérouler le mètre ruban !

3. Déterminer le facteur de vélocité d’un coaxial

La vitesse d’une onde RF dans un câble coaxial est inférieure à celle de la lumière. Elle dépend principalement du diélectrique situé entre l’âme et le blindage.

On définit le facteur de vélocité, ou VF, par :

    \[VF=\frac{v}{c}\]

où (v) est la vitesse de propagation dans le câble et (c) la vitesse de la lumière.

Prenons maintenant un câble dont nous connaissons précisément la longueur physique. En mesurant son délai de propagation avec le NanoVNA, nous pouvons calculer sa vitesse réelle, puis en déduire son facteur de vélocité.

L’expérience devient particulièrement intéressante en comparant plusieurs câbles : un RG-58 à diélectrique plein, un câble à mousse ou encore un coaxial faible perte.

On constate alors directement que deux câbles de même longueur physique n’ont pas nécessairement la même longueur électrique.

Ce paramètre devient essentiel dès que le coaxial participe au fonctionnement du circuit : ligne quart d’onde, stub d’adaptation, transformateur d’impédance, phasage d’antennes, etc.

4. Localiser un défaut dans un câble avec le TDR

Voici probablement l’une des expériences les plus spectaculaires à réaliser avec un NanoVNA.

Prenez un câble coaxial de plusieurs mètres et observez sa réponse dans le domaine temporel. Une discontinuité d’impédance provoque une réflexion : le NanoVNA peut donc indiquer à quelle distance elle se trouve.

Essayez successivement :

  • une extrémité ouverte ;
  • un court-circuit ;
  • un raccord coaxial ;
  • un connecteur mal monté ;
  • ou, sur un vieux câble, une zone réellement endommagée.

Chaque anomalie produit une signature différente.

Le principe est exactement celui d’un radar miniature : le NanoVNA observe le temps nécessaire pour que la réflexion revienne vers lui. Connaissant la vitesse de propagation dans le câble, il peut en déduire la position du défaut.

Un point mérite cependant d’être retenu : la précision dépend notamment de la largeur du balayage fréquentiel, de la calibration et du facteur de vélocité renseigné.

Le NanoVNA ne remplace donc pas toujours un véritable réflectomètre professionnel, mais il permet déjà de répondre à une question extrêmement utile dans une station radioamateur :

« Mon coaxial est défectueux… mais à combien de mètres du shack ? »

VNA mode temporel

En mode temporel, le NanoVNA transforme les réflexions mesurées dans le coaxial en informations de distance. Une rupture, un court-circuit ou une variation d’impédance peut ainsi être localisé le long du câble.

5. Mesurer les pertes réelles d’un câble coaxial

Après S11, passons à S21, c’est-à-dire à ce qui traverse réellement un dispositif.

Reliez CH0 à une extrémité du câble et CH1 à l’autre extrémité, puis affichez la courbe LOGMAG en dB. Après une calibration THRU correcte, la valeur mesurée correspond directement à la perte d’insertion du câble.

Un câble parfait donnerait 0 dB. En pratique, on lira par exemple :

    \[S21=-1,2\ \text{dB}\]

Cela signifie que le câble atténue le signal de 1,2 dB sur la fréquence considérée.

L’expérience devient très instructive en comparant plusieurs longueurs ou plusieurs types de coaxiaux. On voit immédiatement que les pertes augmentent avec la fréquence et qu’un câble acceptable sur 7 MHz peut devenir beaucoup moins intéressant sur 432 MHz ou 1,3 GHz.

6. Tracer la courbe d’un filtre

Le NanoVNA peut également devenir un petit analyseur de filtres.

Branchez simplement :

CH0 → filtre → CH1

Puis balayez une plage de fréquences suffisamment large autour de la zone qui vous intéresse.

Avec S21 LOGMAG, on visualise directement :

  • la bande passante ;
  • les fréquences de coupure ;
  • la perte d’insertion ;
  • l’atténuation hors bande ;
  • et la pente du filtre.

Essayez par exemple un filtre passe-bas destiné au 14 MHz. Dans sa bande utile, la courbe doit rester proche de 0 dB, puis chuter rapidement au-delà de la fréquence de coupure.

On peut même afficher simultanément la phase afin de mieux comprendre le comportement du filtre autour de sa transition.

C’est une excellente façon de vérifier un filtre construit soi-même avant de le placer entre un émetteur et son antenne.

7. Observer la résonance d’un circuit LC

Pour cette expérience, réalisons un circuit composé simplement d’une self L et d’un condensateur C.

Sa fréquence théorique de résonance est :

    \[f_0=\frac{1}{2\pi\sqrt{LC}}\]

Prenons par exemple :

    \[L=1\ \mu H\]

et

    \[C=100\ pF\]

La résonance théorique se situe alors autour de :

    \[f_0 \approx 15,9\ MHz\]

Connectez le circuit au NanoVNA et balayez quelques MHz autour de cette fréquence.

Vous constaterez probablement que la valeur mesurée n’est pas exactement 15,9 MHz. Pourquoi ?

Parce que dans le monde réel, les composants possèdent des tolérances, des pertes, des capacités parasites et même une inductance parasite pour le condensateur.

C’est justement tout l’intérêt de l’expérience : le NanoVNA permet de voir la différence entre le composant idéal de nos formules et le circuit RF réellement posé sur l’établi.

Observer la résonance d’un circuit LC

Trois applications de S21 avec le NanoVNA : mesurer les pertes d’un câble coaxial, tracer la réponse en fréquence d’un filtre et observer la résonance d’un circuit LC. Dans chaque cas, le dispositif à tester est inséré entre CH0 et CH1.

8. Mesurer une self ou un condensateur inconnu

Le NanoVNA peut aussi devenir un petit instrument de caractérisation de composants.

En mesurant l’impédance complexe d’un composant sur CH0, nous obtenons :

    \[Z=R+jX\]

Pour une inductance, la réactance permet d’estimer :

    \[L=\frac{X_L}{2\pi f}\]

et pour un condensateur :

    \[C=\frac{1}{2\pi f|X_C|}\]

Essayez avec une self ou un condensateur dont vous connaissez déjà la valeur, puis comparez mesure et marquage.

Encore plus intéressant : augmentez progressivement la fréquence. Le composant finit par s’éloigner de son modèle idéal à cause de ses éléments parasites et peut même atteindre sa fréquence d’auto-résonance.

9. Tester réellement un choke ou un balun

Voilà une expérience particulièrement utile pour l’amateur qui construit ses antennes.

Bobinez quelques spires de coaxial sur une ferrite et mesurez son comportement sur plusieurs bandes. On peut ainsi étudier l’impédance de mode commun du choke et observer comment elle évolue avec la fréquence.

L’expérience permet surtout de comprendre qu’un choke n’est pas simplement « bon » ou « mauvais ».

Un montage très efficace sur 7 MHz peut l’être beaucoup moins sur 28 MHz. Le résultat dépend du matériau de la ferrite, de ses dimensions, du nombre de spires et de la façon dont elles sont bobinées.

Le NanoVNA devient alors particulièrement intéressant pour comparer plusieurs constructions avant d’installer le choke au pied d’une antenne.

10. Voir un coaxial transformer une impédance

Terminons par une expérience qui peut sembler presque magique.

Connectez sur CH0 une longueur de coaxial terminée successivement par un circuit ouvert puis un court-circuit, et observez son impédance sur l’abaque de Smith en faisant varier la fréquence.

La ligne ne se comporte plus comme un simple morceau de câble.

Lorsque sa longueur électrique approche :

    \[L=\frac{\lambda}{4}\]

une ligne quart d’onde transforme les impédances. Pour une ligne sans pertes :

    \[Z_{in}=\frac{Z_0^2}{Z_L}\]

Ainsi, à exactement λ/4, une charge très faible est transformée en impédance très élevée et, inversement, une charge très élevée en impédance très faible.

Sur l’abaque de Smith, c’est spectaculaire : lorsque la fréquence varie, le point d’impédance tourne autour de l’abaque.

Nous venons d’observer directement le principe utilisé dans les stubs, transformateurs quart d’onde et de nombreux systèmes d’adaptation RF.

Le coaxial n’est donc plus seulement le câble qui transporte notre HF : sa longueur électrique peut devenir une partie intégrante du circuit.

Liens et ressources utiles

Envie de reproduire ces expériences ou d’aller plus loin avec votre NanoVNA ? Quelques ressources permettent d’exploiter beaucoup plus facilement S11, S21, l’abaque de Smith et le domaine temporel.

  • NanoVNA-Saver — Probablement le complément logiciel le plus intéressant. Il permet d’afficher S11 et S21 sous différentes formes (Smith, LogMag, phase, VSWR), d’effectuer des balayages comportant davantage de points, d’analyser des filtres, d’exporter des fichiers Touchstone et surtout d’utiliser une fonction TDR pour mesurer et examiner les câbles.
  • Téléchargement de NanoVNA-Saver — Les versions disponibles pour les différents systèmes se trouvent directement dans la rubrique Releases du projet.
  • Calibration du NanoVNA — Une lecture indispensable avant de rechercher de la précision. La procédure SOLT — Short, Open, Load, Through — permet de définir correctement le plan de référence et de compenser les erreurs introduites par les connecteurs, adaptateurs et câbles de mesure.

Conseil F5KEE : avec un VNA, une belle courbe n’est pas nécessairement une bonne mesure. Avant toute expérience, vérifiez la plage de fréquences et surtout la calibration au niveau où commence réellement le dispositif à tester.

GNU Radio 4 : pourquoi cette nouvelle génération pourrait changer nos SDR

Banniere GNU Radio 4

GNU Radio 4 : une nouvelle architecture pour nos SDR

Pour beaucoup de radioamateurs, GNU Radio est devenu l’un des outils incontournables du monde SDR. Il permet de construire virtuellement un récepteur, un démodulateur ou un analyseur de signaux simplement en assemblant des blocs de traitement.

Le principe est assez simple :

Antenne → SDR → échantillons I/Q → traitement numérique → audio ou données

Un bloc peut réaliser un filtrage, un changement de fréquence, une démodulation FM, un décodage numérique ou encore afficher un spectre. En reliant ces blocs, on constitue ce que GNU Radio appelle un flowgraph.

Cette approche permet aujourd’hui de réaliser des systèmes étonnamment complexes avec un simple ordinateur et un récepteur RTL-SDR, HackRF, PlutoSDR ou LimeSDR.

Alors pourquoi vouloir tout changer ?

GNU Radio 4 n’est pas simplement GNU Radio 3.11

C’est probablement le premier point à comprendre : GNU Radio 4 n’est pas une évolution ordinaire de GNU Radio 3.

Les développeurs parlent eux-mêmes d’une nouvelle fondation destinée au traitement numérique du signal moderne. GNU Radio 4 a d’ailleurs atteint son premier stade Release Candidate (RC1) en mars 2026. À ce stade, l’architecture centrale et le modèle d’exécution sont considérés comme suffisamment stabilisés pour préparer l’écosystème à la future version définitive.

Une grande partie du travail concerne quelque chose que l’utilisateur ne voit pratiquement jamais : le moteur qui fait fonctionner les blocs.

Pour comprendre son importance, imaginons une petite chaîne SDR :

SDR → filtre → AGC → démodulateur → filtre audio → haut-parleur

Chaque bloc reçoit des échantillons, effectue son calcul puis transmet les résultats au suivant.

GNU Radio doit donc constamment décider quel bloc doit travailler, quand il doit travailler et quelles données doivent lui être fournies.

C’est le rôle du scheduler, ou ordonnanceur.

GNU4 scheduler

 

Le scheduler : le chef d’orchestre invisible

Dans GNU Radio 3.x, le moteur d’exécution repose historiquement sur un fonctionnement largement basé sur un thread par bloc. Cette solution a longtemps donné d’excellents résultats, mais elle n’est pas forcément optimale pour toutes les architectures modernes.

Imaginez maintenant un flowgraph contenant 40 ou 50 blocs.

Créer et coordonner autant de traitements peut finir par représenter une charge non négligeable, particulièrement lorsque certains blocs n’effectuent que des opérations très rapides.

GNU Radio 4 change profondément cette philosophie.

Le scheduler : le chef d’orchestre invisible

GNU Radio 3.x et GNU Radio 4 : le flowgraph peut rester similaire, mais le moteur d’exécution de GR4 adopte une architecture beaucoup plus modulaire et flexible.

Son architecture rend notamment les schedulers modulaires. Plusieurs blocs peuvent également être exécutés dans un même thread. Le tutoriel officiel GR4 montre par exemple que le scheduler fourni peut fonctionner en mode monothread ou selon une approche multithread.

Autrement dit, GNU Radio peut disposer d’une organisation du travail beaucoup mieux adaptée au système utilisé.

Pourquoi cela intéresse-t-il le radioamateur ?

Parce que nos SDR deviennent de plus en plus gourmands.

Recevoir quelques centaines de kilohertz avec un RTL-SDR ne représente pas la même charge que traiter simultanément plusieurs dizaines de mégahertz, plusieurs canaux ou différents démodulateurs.

Et nos ordinateurs ont eux aussi changé.

Nous disposons maintenant de processeurs multicœurs, mais aussi de GPU et d’autres accélérateurs matériels capables d’effectuer certains calculs DSP extrêmement rapidement.

L’architecture de GNU Radio 4 a justement été pensée pour mieux prendre en compte ces architectures hétérogènes. La séparation entre les blocs, les buffers et le runtime doit notamment faciliter le déplacement et le traitement des données avec différents accélérateurs.

On peut alors imaginer une chaîne dans laquelle :

SDR → CPU → GPU → traitement DSP → décodage

sans que chaque bloc doive nécessairement gérer lui-même toute la complexité du transfert des données.

C’est une évolution importante : le flowgraph reste notre représentation logique du récepteur, tandis que l’infrastructure située dessous peut devenir beaucoup plus sophistiquée.

Et ce n’est que le début

GNU Radio 4 a également été conçu avec les architectures distribuées en tête. Un flowgraph pourrait ainsi être réparti entre plusieurs ressources ou plusieurs machines, plutôt que d’être obligatoirement exécuté sur un seul ordinateur.

Principe d’un SDR distribué

Principe d’un SDR distribué : l’architecture de GNU Radio 4 est conçue pour permettre de répartir les traitements entre différentes ressources de calcul plutôt que de tout concentrer sur une seule machine.

Ajoutons à cela l’intégration de SoapySDR, destinée à faciliter l’utilisation de nombreuses familles de matériels SDR derrière une couche d’abstraction commune.

On commence alors à comprendre pourquoi GNU Radio 4 représente beaucoup plus qu’un changement de numéro de version.

Pour nous radioamateurs, l’écran pourra finalement sembler assez familier : toujours une source SDR, des filtres, des démodulateurs et des blocs reliés entre eux.

Mais sous le capot, le moteur aura profondément changé.

Un même SDR… mais plus facile à intégrer

Une autre évolution intéressante concerne la relation entre GNU Radio et le matériel.

Nos stations utilisent aujourd’hui des équipements très différents : RTL-SDR, HackRF, LimeSDR, PlutoSDR, SDRplay et bien d’autres. Chacun possède ses pilotes, ses particularités et ses paramètres.

GNU Radio 4 intègre SoapySDR, une couche d’abstraction permettant à GNU Radio de dialoguer avec de nombreuses familles de SDR à travers une interface plus homogène. L’objectif est de mieux séparer deux éléments :

le matériel qui fournit les échantillons I/Q
et
le flowgraph qui les traite.

Cette séparation facilite notamment le remplacement d’une source réelle par des données enregistrées ou simulées pendant la mise au point. C’est particulièrement intéressant lorsque l’on développe un décodeur ou que l’on veut reproduire exactement les mêmes conditions de test.

Attention cependant : SoapySDR existait déjà dans GNU Radio 3.10. La nouveauté de GR4 réside surtout dans son intégration à la nouvelle architecture et à son nouveau modèle d’exécution.

Et GNU Radio Companion ?

C’est probablement la question que beaucoup se poseront :

faudra-t-il programmer en C++ pour utiliser GNU Radio 4 ?

L’environnement graphique reste bien dans les préoccupations du projet. En mai 2026, l’équipe GNU Radio indiquait que GNU Radio Studio était le candidat actuel pour offrir une expérience comparable à GNU Radio Companion.

L’objectif reste donc de conserver ce qui fait une grande partie de l’intérêt de GNU Radio : construire graphiquement un système DSP en reliant des blocs.

Mais cette partie de l’écosystème GR4 est encore en évolution. GNU Radio travaille notamment sur les interfaces graphiques, la documentation, les exemples, le packaging et la simplification de l’installation.

Faut-il installer GNU Radio 4 maintenant ?

Pour expérimenter, certainement.

Pour remplacer immédiatement une installation GNU Radio 3 parfaitement fonctionnelle, probablement pas.

GNU Radio 4 a atteint le stade RC1 en mars 2026. Son architecture centrale est désormais considérée comme stable et les développeurs indiquent que les changements après RC1 devraient essentiellement compléter l’écosystème plutôt que bouleverser les API fondamentales.

Mais il reste encore un travail important : porter des blocs GNU Radio 3, compléter les interfaces matérielles, améliorer la documentation et développer les outils qui entoureront la version définitive.

Il faut donc considérer GR4 comme une technologie désormais suffisamment mature pour être expérimentée, mais dont l’écosystème n’a pas encore la richesse accumulée pendant des années par GNU Radio 3.

Ce qu’il faut retenir

La véritable révolution de GNU Radio 4 ne sera probablement pas immédiatement visible à l’écran.

Nous continuerons à raisonner avec une antenne, un SDR, des échantillons I/Q, des filtres, des démodulateurs et des décodeurs.

Ce qui change profondément se trouve sous le capot.

GNU Radio 4 apporte une architecture moderne et modulaire capable de mieux exploiter les processeurs multicœurs, les accélérateurs matériels et, à terme, les systèmes distribués. Le projet veut permettre à un même concept de traitement DSP de fonctionner depuis un système embarqué jusqu’à une architecture beaucoup plus puissante.

Pour nous radioamateurs, cela pourrait ouvrir la porte à des projets SDR plus ambitieux : récepteurs multicanaux, surveillance de larges portions de spectre, stations satellites automatisées, traitements numériques complexes ou applications associant SDR et intelligence artificielle.

GNU Radio 4 ne change donc pas seulement notre manière de construire un flowgraph.

Il prépare surtout la manière dont nos SDR pourront fonctionner demain.

Liens et ressources utiles

Pour suivre l’évolution de GNU Radio 4 et approfondir les notions abordées dans cet article, privilégiez les ressources officielles du projet :

  • GNU Radio – site officiel : actualités, annonces et évolution du projet.
    GNU Radio
  • GNU Radio 4 – Release Candidate 1 : présentation des nouveautés de GR4, de son architecture, de SoapySDR et des améliorations de performances.
    Découvrir GNU Radio 4 RC1
  • Documentation GNU Radio : guides, installation, tutoriels et documentation destinée aux utilisateurs comme aux développeurs.
    Documentation GNU Radio
  • GR4 – état du projet : informations sur la gouvernance, le développement et la route vers GNU Radio 4.0.
    GNU Radio 4 : Road to 4.0

Ces ressources permettront également de vérifier les évolutions de GR4 au fur et à mesure de sa stabilisation.

Nos 70 cm convoités par les satellites commerciaux : faut-il s’inquiéter ?

Nos 70cm convoités

La bande des 70 cm, de 430 à 440 MHz, est depuis longtemps un formidable terrain d’expérimentation pour les radioamateurs. Relais, liaisons locales, modes numériques, ATV, signaux faibles et surtout satellites : ces dix mégahertz sont loin d’être inutilisés.

Mais voilà que des satellites commerciaux commencent eux aussi à regarder du côté de nos fréquences. L’affaire AST SpaceMobile en est une illustration particulièrement intéressante. Faut-il craindre de voir progressivement les radioamateurs chassés de leurs 70 cm ?

À qui appartient vraiment la bande 430–440 MHz ?

Première précision : une fréquence radio n’« appartient » pas à ses utilisateurs.

Le spectre est organisé internationalement par l’UIT, puis décliné dans les réglementations nationales. La France appartient à la Région 1 de l’UIT, où 430–440 MHz constitue une bande importante pour le service amateur. La réglementation française est ensuite précisée par le Tableau national de répartition des bandes de fréquences (TNRBF) publié par l’ANFR.

À l’intérieur de cette bande, 435–438 MHz est également particulièrement importante pour le service amateur par satellite.

C’est précisément ce qui rend l’affaire actuelle intéressante : un satellite commercial n’est évidemment pas un satellite du service amateur.

À qui appartient vraiment la bande 430–440 MHz ?

AST SpaceMobile entre dans la bande

AST SpaceMobile développe une constellation de satellites en orbite basse destinée notamment à permettre des communications directes avec des téléphones mobiles.

Mais un satellite doit également communiquer avec ses stations de contrôle. Il faut transmettre sa télémétrie, connaître sa position et pouvoir lui envoyer des commandes : ce sont les fonctions TT&C — Telemetry, Tracking and Command.

AST a utilisé cinq fréquences situées en plein dans les 70 cm :

430,500 – 432,300 – 434,100 – 435,900 – 439,500 MHz.

Les satellites BlueBird utilisent des émissions GFSK d’environ 50 kHz de largeur. Le prototype BlueWalker 3 avait également émis sur 437,500 MHz.

L’affaire a pris une tout autre dimension lorsque l’entreprise a demandé que cette possibilité soit étendue à une constellation pouvant atteindre 248 satellites.

Pourquoi cela pose-t-il problème ?

On pourrait objecter qu’un satellite transmettant quelques données pendant quelques instants ne va pas bouleverser toute une bande de 10 MHz.

Mais une émission depuis l’espace possède une caractéristique redoutable : elle est visible sur une immense superficie.

Un émetteur terrestre de faible puissance sur 435 MHz ne porte généralement que sur une zone limitée. À plusieurs centaines de kilomètres d’altitude, le même principe devient très différent : des milliers de stations peuvent se trouver simultanément dans l’empreinte radio du satellite.

Or certaines activités radioamateurs recherchent des signaux extrêmement faibles.

Un opérateur suivant un CubeSat sur 435–438 MHz, une station travaillant en EME ou un amateur observant une portion de spectre avec un SDR peut recevoir un signal commercial considérablement plus puissant que le signal qu’il cherche à décoder.

Avec quelques satellites, le phénomène reste occasionnel. Avec des centaines de satellites, la question devient beaucoup plus sérieuse.

Pourquoi cela pose-t-il problème ?

Une mobilisation qui a porté ses fruits

L’ARRL, l’IARU, l’AMSAT et de nombreux radioamateurs se sont opposés à une utilisation généralisée de 430–440 MHz par la constellation. Plus de 2 500 contributions ont été adressées à la FCC.

Et cette mobilisation a eu un effet concret.

Le 21 avril 2026, la FCC a accordé une autorisation beaucoup plus restrictive que celle initialement envisagée. AST SpaceMobile peut utiliser les cinq canaux de 50 kHz pour ses 248 satellites uniquement pour des opérations TT&C d’urgence, lorsque les autres fréquences ne sont pas disponibles.

Chaque situation d’urgence est limitée à 24 heures et l’autorisation concerne des communications avec cinq stations terrestres déterminées, situées hors des États-Unis. Les administrations des pays concernés doivent en outre autoriser ces communications.

Autrement dit, AST SpaceMobile n’a pas obtenu un accès commercial permanent à nos 70 cm.

Alors, pourquoi rester vigilant ?

Parce que le véritable enjeu dépasse largement AST SpaceMobile.

L’IARU conteste notamment le recours à l’article 4.4 du Règlement des radiocommunications de l’UIT, qui permet sous certaines conditions d’autoriser une utilisation non conforme au tableau international d’attribution des fréquences, à condition de ne pas provoquer de brouillage préjudiciable.

Le problème est donc celui du précédent.

Aujourd’hui, cinq canaux utilisés exceptionnellement. Demain, d’autres constellations pourraient-elles réclamer des dispositions comparables ?

Avec la multiplication des satellites en orbite basse, les fréquences utilisables pour leurs communications deviennent une ressource extrêmement recherchée.

Faut-il donc s’inquiéter pour nos 70 cm ?

Pas de panique : personne ne vient actuellement supprimer la bande 430–440 MHz aux radioamateurs français.

Mais l’affaire AST SpaceMobile constitue un avertissement particulièrement instructif. Les fréquences radio sont une ressource limitée et les bandes dont disposent les radioamateurs peuvent susciter l’intérêt d’autres utilisateurs.

L’épisode montre également que les interventions de l’IARU, des associations nationales, de l’AMSAT et des radioamateurs peuvent réellement peser dans les décisions réglementaires.

Il existe enfin une excellente manière de défendre nos fréquences : les utiliser.

Une bande active, expérimentée, mesurée, documentée et techniquement utile est beaucoup plus facile à défendre qu’une portion de spectre silencieuse.

Liens et ressources utiles

  • ANFR — Tableau national de répartition des bandes de fréquences (TNRBF) : c’est la référence pour connaître les attributions françaises. La version consolidée du 26 mai 2026 est actuellement proposée par l’ANFR.
    Consulter le TNRBF sur le site de l’ANFR
  • ANFR — Tableau détaillé des fréquences : particulièrement intéressant pour vérifier 430–440 MHz. Il montre notamment les différentes attributions françaises et la présence du service amateur par satellite dans 435–438 MHz.
    Consulter le tableau des fréquences ANFR
  • IARU Région 1 — Position sur AST SpaceMobile : c’est probablement le document le plus pertinent pour votre article, car il expose directement les inquiétudes du monde radioamateur concernant l’utilisation de 430–440 MHz par la constellation.
    IARU Région 1 — AST SpaceMobile et 430–440 MHz
  • ARRL — Opposition à l’utilisation commerciale des 70 cm : l’ARRL détaille la demande d’AST SpaceMobile et les raisons techniques de son opposition.
    ARRL — Protecting the 70-centimeter amateur band
  • FCC — décision d’avril 2026 : c’est la source réglementaire américaine à consulter pour connaître précisément les limitations finalement imposées à AST SpaceMobile.
    FCC — décision DA 26-391

FreeDV RADE

Banniere FreeDV RADE

La voix numérique HF est-elle enfin prête à remplacer la SSB ?

Depuis plus d’un demi-siècle, la SSB (Single Side Band ou BLU) règne pratiquement sans partage sur les communications vocales HF radioamateurs. Économe en bande passante, relativement simple et surtout universelle, elle a remarquablement résisté aux évolutions technologiques.

La voix numérique existe pourtant depuis longtemps. FreeDV en est probablement l’exemple le plus connu dans le monde radioamateur. Mais jusqu’ici, ses avantages n’étaient pas toujours suffisamment décisifs pour convaincre l’opérateur SSB de changer ses habitudes.

Avec RADE (Radio Autoencoder), la situation pourrait évoluer. Cette technologie associe traitement numérique du signal et apprentissage automatique pour transmettre une voix de haute qualité dans seulement 1 500 Hz de bande RF, avec un fonctionnement annoncé jusqu’à environ −2 dB de SNR.

Alors, la voix numérique est-elle enfin prête à remplacer notre bonne vieille BLU ?

FreeDV : une voix numérique réellement ouverte

FreeDV est un ensemble de modes de transmission vocale numérique spécialement développé pour les radioamateurs. Sa particularité fondamentale est d’être open source, y compris pour les technologies servant au codage de la parole.

L’idée est également de pouvoir utiliser un transceiver SSB existant. Le logiciel FreeDV installé sur un ordinateur assure le traitement numérique tandis que le poste HF assure l’émission et la réception radio.

RADE est aujourd’hui le mode phare du projet. Il a officiellement intégré FreeDV avec la version 2.0.0 en juin 2025.

RADE : quand l’IA entre dans le modem HF

Dans une transmission numérique classique, plusieurs traitements se succèdent :

Voix → codec → correction d’erreurs → modem → émetteur HF

RADE adopte une approche différente.

Un autoencodeur neuronal apprend à représenter efficacement les caractéristiques essentielles de la parole afin de les transmettre à travers un canal radio.

L’encodeur travaille notamment à partir d’informations décrivant le spectre vocal, la hauteur de la voix et son caractère voisé. Il produit ensuite des symboles destinés à être transportés par une modulation OFDM.

Au récepteur, le réseau effectue l’opération inverse et reconstruit les informations nécessaires au synthétiseur vocal. L’ensemble a été entraîné en présence de bruit et de perturbations caractéristiques des liaisons HF, notamment les trajets multiples.

Autrement dit, RADE n’essaye pas simplement de protéger une suite de bits contre les erreurs : le système apprend comment transmettre intelligemment les informations nécessaires à la reconstruction de la voix.

Comparatif SSB classique et RADE FreeDV

8 kHz de voix dans seulement 1,5 kHz de HF

C’est probablement le chiffre qui surprendra le plus un radioamateur.

RADE V1 traite une parole possédant une bande audio de 8 kHz, alors que le signal radio n’occupe qu’environ 1 500 Hz.

Il ne faut évidemment pas confondre ces deux valeurs. Les 8 kHz concernent la bande audio de la parole traitée, tandis que les 1,5 kHz correspondent à la largeur du signal transmis sur la bande HF.

À titre de comparaison, une communication SSB radioamateur utilise généralement autour de 2,4 à 2,8 kHz.

RADE peut donc transmettre une voix étonnamment naturelle tout en occupant moins de spectre qu’une communication SSB traditionnelle.

Que se passe-t-il lorsque le signal devient faible ?

C’est justement là que les choses deviennent intéressantes.

En SSB, lorsque le rapport signal/bruit diminue, le bruit devient progressivement plus présent. La voix devient difficile à comprendre, mais l’opérateur expérimenté parvient parfois encore à extraire quelques mots du bruit.

Un système numérique se comporte différemment. La qualité peut rester très bonne jusqu’à proximité de sa limite de fonctionnement, puis se détériorer rapidement lorsque la synchronisation ou le décodage deviennent impossibles.

FreeDV annonce pour RADE un fonctionnement pouvant descendre autour de −2 dB de SNR. Des essais sur des canaux HF réels ont également montré des résultats compétitifs avec la SSB aussi bien avec des signaux forts que faibles.

Cela ne signifie évidemment pas que RADE sera systématiquement supérieur : fading, brouillages, sélectivité du canal et conditions de propagation restent déterminants.

Que se passe-t-il lorsque le signal devient faible ?

Peut-on essayer RADE avec notre station actuelle ?

Dans beaucoup de cas, oui.

Une station peut être représentée très simplement :

Micro → ordinateur avec FreeDV → interface audio/USB → transceiver SSB → antenne

À la réception, le trajet est naturellement inversé.

FreeDV fonctionne sous Windows, macOS et Linux. Un ordinateur moderne convient et RADE peut même fonctionner sur un Raspberry Pi 4 ou supérieur. En revanche, ses besoins en calcul et en mémoire sont trop importants pour de petits microcontrôleurs comme les ESP32 ou STM32 et pour certains matériels FreeDV plus anciens.

Un point mérite également l’attention : comme pour beaucoup de modes numériques, il ne faut pas surmoduler l’émetteur. FreeDV recommande de régler le niveau TX de manière à seulement commencer à solliciter l’ALC.

Peut-on essayer RADE avec notre station actuelle ?

RADE contre SSB : le match

Critère SSB RADE V1
Bande RF ≈ 2,4–2,8 kHz ≈ 1,5 kHz
Qualité vocale Bonne Très bonne
Signaux faibles Dégradation progressive Très bonne jusqu’à proximité du seuil
Ordinateur Non Oui
Compatibilité Universelle Encore limitée
Technologie ouverte Oui Oui, open source
Mise en œuvre Très simple Plus complexe

RADE possède donc de sérieux arguments techniques. Mais la SSB conserve un avantage colossal : elle est universelle.

Alors, RADE va-t-il remplacer la SSB ?

Techniquement, RADE commence sérieusement à pouvoir rivaliser avec elle. Le projet FreeDV considère même avoir atteint avec RADE V1 ses objectifs de qualité supérieure à la SSB à fort comme à faible SNR.

Mais une technologie radio ne s’impose pas uniquement parce qu’elle est meilleure.

Pour réaliser un QSO RADE, il faut qu’un correspondant utilise lui aussi FreeDV. En SSB, il suffit de tourner le VFO et d’appuyer sur le PTT.

Le véritable défi sera donc probablement moins technique que communautaire : RADE parviendra-t-il à atteindre une masse critique d’utilisateurs ?

L’histoire de la radio nous rappelle que l’AM semblait autrefois indétrônable avant que la SSB ne s’impose progressivement.

Peut-être assistons-nous aujourd’hui aux premiers pas d’une transition comparable.

Après avoir remplacé l’AM par la SSB, les radioamateurs remplaceront-ils un jour la SSB par une voix numérique entièrement open source ?

Pour aller plus loin

Vous souhaitez expérimenter FreeDV RADE ou simplement mieux comprendre son fonctionnement ? Voici quelques ressources de référence :

  • FreeDV – site officiel : présentation du projet, actualités et documentation. freedv.org
  • RADE – Radio Autoencoder : documentation technique, présentation du mode, code source et ressources destinées aux radioamateurs. Documentation RADE
  • Installer FreeDV : téléchargement de FreeDV GUI pour Windows, macOS et Linux. Télécharger FreeDV
  • Premiers pas avec FreeDV : configuration audio, CAT/PTT, réglages d’émission et conseils pratiques. Guide de démarrage FreeDV
  • Publication scientifique RADE : l’article de David Rowe et Jean-Marc Valin décrit en détail l’autoencodeur neuronal et son fonctionnement sur les canaux HF. Lire la publication RADE

De quoi passer rapidement de la théorie aux premiers essais RADE sur les bandes HF !

Hamlib

Hamlib

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é.

Pourquoi Hamlib ?

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.

Comment une commande arrive jusqu'au poste ?

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 au cœur d'une station automatisée

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 :

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.

Construire une station satellite automatique : du TLE au moteur du rotor

Station Sat

Suivre un satellite à la main avec une antenne directive est tout à fait possible. Mais lorsqu’un satellite en orbite basse traverse le ciel en quelques minutes, il faut simultanément connaître sa position, orienter l’antenne en azimut et en élévation et, pour certaines liaisons, corriger le décalage Doppler.

La bonne nouvelle, c’est que toutes ces opérations peuvent être automatisées.

Derrière une station satellite automatique se cache une chaîne assez logique :

TLE → calcul orbital → logiciel de poursuite → Hamlib → contrôleur → moteurs → antennes

Voyons comment les différents éléments communiquent.

Tout commence par le TLE

Pour suivre un satellite, il faut d’abord savoir où il se trouve et où il va se trouver quelques secondes plus tard.

C’est notamment le rôle des données orbitales appelées TLE — Two-Line Element Set. Malgré leur aspect quelque peu cryptique, ces deux lignes contiennent les paramètres permettant de calculer l’orbite d’un satellite : inclinaison, excentricité, mouvement moyen, époque des éléments, etc.

Des organismes comme CelesTrak publient régulièrement ces données.

Attention cependant : un TLE ne dit pas directement :

« Orientez l’antenne à 137° d’azimut et 43° d’élévation. »

Il faut encore transformer ces paramètres orbitaux en coordonnées utilisables depuis notre station.

Du TLE à la position du satellite

C’est ici qu’intervient un modèle de propagation orbital tel que SGP4.

Le calcul tient compte du TLE, de l’heure et de la position géographique de la station :

TLE + heure UTC + latitude + longitude + altitude → position apparente du satellite

On obtient alors deux valeurs essentielles.

L’azimut (AZ) indique la direction horizontale :

0° = nord — 90° = est — 180° = sud — 270° = ouest.

L’élévation (EL) indique la hauteur du satellite au-dessus de l’horizon :

0° = horizon — 90° = zénith.

Voilà enfin des nombres qu’un rotor peut comprendre.

Du TLE à l’antenne

Gpredict, le chef d’orchestre

Un logiciel comme Gpredict automatise une grande partie de ces opérations.

Après avoir chargé les éléments orbitaux et renseigné la position de la station, il peut prévoir les prochains passages et calculer continuellement l’azimut et l’élévation du satellite.

Pendant un passage, ces valeurs changent constamment :

AZ 125,2° / EL 18,4°

puis quelques secondes plus tard :

AZ 137,4° / EL 42,8°

et ainsi de suite.

Gpredict peut également participer au pilotage de la radio afin de compenser automatiquement le Doppler, particulièrement sensible en VHF et UHF.

Hamlib : faire communiquer logiciel et matériel

Reste un problème : comment transmettre ces coordonnées au rotor ?

Une solution très utilisée dans le monde radioamateur est Hamlib, bibliothèque open source proposant une interface commune avec de nombreux équipements radio.

Pour les rotors, le programme rotctld peut servir d’intermédiaire.

La chaîne devient :

Gpredict → TCP/IP → rotctld → contrôleur du rotor

L’intérêt est considérable : le logiciel de poursuite n’a plus besoin de connaître les détails électroniques ou mécaniques du système.

Il fournit simplement une consigne :

AZ = 137,4° — EL = 42,8°

Le contrôleur se charge du reste.

Arduino ou ESP32 : le contrôleur

Nous arrivons maintenant à la partie qui intéressera particulièrement les amateurs de construction.

Un Arduino, ESP32 ou autre microcontrôleur peut constituer le cerveau du rotor.

Son travail consiste à recevoir les positions demandées, lire les capteurs donnant la position réelle du rotor et commander les moteurs.

Le principe est celui d’un asservissement :

Erreur = position demandée − position mesurée

Si l’azimut demandé est de 137° alors que l’antenne se trouve à 125°, le contrôleur actionne le moteur jusqu’à atteindre la nouvelle position.

Un potentiomètre, un encodeur ou un autre capteur permet de fermer cette boucle de régulation.

Du microcontrôleur au moteur

Les sorties d’un Arduino ne peuvent évidemment pas alimenter directement un moteur de rotor.

Il faut donc ajouter un étage de puissance : pont en H pour certains moteurs à courant continu ou driver adapté pour des moteurs pas-à-pas.

Nous obtenons finalement :

Arduino → driver → moteur → réducteur → rotor

Le réducteur diminue la vitesse et augmente le couple tout en permettant un positionnement plus précis.

Des fins de course peuvent compléter l’installation afin d’éviter qu’une erreur logicielle n’entraîne le rotor au-delà de ses limites mécaniques.

De l’ordinateur aux moteurs

Pourquoi deux moteurs ?

Une station satellite classique possède deux axes indépendants.

Le moteur AZ fait tourner l’ensemble horizontalement, généralement sur une plage proche de 360°.

Le moteur EL incline les antennes entre l’horizon et le zénith.

Les deux mouvements sont effectués simultanément afin que les Yagi VHF/UHF restent orientées vers le satellite pendant tout son passage.

Un passage presque au zénith constitue d’ailleurs un exercice difficile : la direction apparente peut changer très rapidement et le rotor doit être suffisamment réactif.

Rotor satellite AZ/EL

Finalement, rien de mystérieux

Une station satellite automatique peut sembler complexe lorsqu’on l’observe dans son ensemble. Pourtant, elle n’est qu’une succession de blocs relativement simples :

TLE → SGP4 → Gpredict → Hamlib/rotctld → Arduino → drivers → moteurs AZ/EL → antennes.

Chaque bloc possède une fonction précise et peut être remplacé ou amélioré indépendamment.

C’est précisément ce qui rend le projet passionnant pour un radioamateur : informatique, mécanique, électronique, radio et programmation se rencontrent dans une même réalisation.

Et maintenant que nous savons comment tout cela fonctionne, une suite s’impose presque naturellement :

construire notre propre contrôleur de rotor AZ/EL autour d’un Arduino et le faire dialoguer avec Gpredict.

Liens et ressources utiles

Pour aller plus loin et commencer à expérimenter avec votre propre station satellite automatique, voici quelques ressources de référence :

  • CelesTrak — pour récupérer les données orbitales TLE et comprendre leur format : celestrak.org
  • Gpredict — logiciel open source permettant de prévoir les passages des satellites et de piloter radios et rotors : projet Gpredict
  • Hamlib — bibliothèque open source assurant l’interface entre les logiciels radioamateurs et de nombreux transceivers ou contrôleurs de rotors : documentation Hamlib
  • SatNOGS — réseau mondial de stations sol satellites open source, particulièrement intéressant pour découvrir des solutions de rotors, contrôleurs et logiciels réalisés par la communauté : satnogs.org
  • AMSAT — une excellente porte d’entrée pour suivre l’actualité des satellites radioamateurs, leurs fréquences et leurs modes de fonctionnement : AMSAT

Ces ressources permettent de passer progressivement de la théorie à l’expérimentation : récupérer les TLE, prévoir un passage, calculer la trajectoire, commander le rotor et finalement suivre automatiquement un satellite avec ses propres antennes.

LinHT : et si le prochain talkie-walkie radioamateur était entièrement open source ?

LinHT

Nos talkies-walkies modernes ont énormément progressé. FM, DMR, D-Star, C4FM, GPS, Bluetooth… ils embarquent parfois une électronique impressionnante. Pourtant, leur fonctionnement reste généralement déterminé par le constructeur : on peut programmer des fréquences, des mémoires et quelques paramètres, mais certainement pas réinventer le fonctionnement de la radio.

LinHT propose une approche radicalement différente.

Imaginez un portatif UHF contenant un véritable ordinateur Linux, capable d’exécuter GNU Radio et associé à un frontal RF fournissant directement les signaux I/Q. Le mode radio n’est alors plus nécessairement figé dans l’électronique : une partie importante du fonctionnement du poste devient… du logiciel.

C’est précisément l’idée derrière LinHT, pour Linux Handheld Transceiver.

LinHT, c’est quoi exactement ?

LinHT est un projet de talkie-walkie SDR open source développé par des membres de la communauté M17. Il succède au projet OpenHT avec un objectif clairement affiché : réaliser une plateforme radio portable ouverte, modifiable et suffisamment accessible pour permettre l’expérimentation.

Le projet ne part d’ailleurs pas complètement de zéro. Les prototypes actuels utilisent le boîtier d’un Retevis C62 ainsi que plusieurs de ses éléments mécaniques : écran, boutons latéraux, connecteur SMA, prises audio, encodeur et diverses pièces du châssis.

Mais la carte électronique principale est remplacée par celle du LinHT.

Attention toutefois : en 2026, LinHT reste un projet expérimental. Il ne s’agit pas encore d’un talkie que l’on commande pour l’utiliser le lendemain.

À l’intérieur : un véritable ordinateur Linux

Schema LinHT

Le cœur du LinHT n’est pas un petit microcontrôleur comme on pourrait l’imaginer dans un talkie classique.

Il utilise un module informatique basé sur un NXP i.MX93, avec deux cœurs ARM Cortex-A55 cadencés jusqu’à 1,7 GHz, auxquels s’ajoute un Cortex-M33. La configuration actuelle dispose de 2 Go de mémoire LPDDR4 et 32 Go d’eMMC.

Autrement dit, nous sommes beaucoup plus proches d’un petit ordinateur embarqué que d’un poste radio traditionnel.

Le système fonctionne sous Linux, construit avec Yocto, et peut notamment exécuter Python, des outils de développement et surtout GNU Radio.

L’architecture peut être résumée ainsi :

Antenne → frontal RF → signaux I/Q → Linux → GNU Radio → traitement du mode radio

Et détail intéressant : les concepteurs ont choisi de réaliser cette architecture sans FPGA dans la chaîne de traitement.

Le SX1255 : quand le talkie devient SDR

Pour comprendre l’intérêt de LinHT, il faut regarder le composant situé entre l’antenne et l’ordinateur : le Semtech SX1255.

Celui-ci constitue le frontal RF Direct-IQ du poste.

Dans une radio conventionnelle, une grande partie des fonctions de réception et de modulation est assurée par des circuits électroniques spécialisés. Avec LinHT, le SX1255 fournit au système les composantes I et Q du signal.

Sans entrer trop profondément dans les mathématiques, ces deux signaux permettent de conserver les informations d’amplitude et de phase nécessaires au traitement numérique.

Le logiciel peut ensuite filtrer, démoduler ou décoder le signal.

C’est là toute la différence :

le matériel reçoit le signal ; le logiciel décide en grande partie quoi en faire.

La version actuelle reste cependant UHF uniquement et travaille avec une largeur de bande I/Q pouvant atteindre environ 500 kHz.

GNU Radio directement dans le talkie

C’est probablement la partie la plus séduisante du projet pour l’expérimentateur.

LinHT peut exécuter GNU Radio directement à bord.

On peut donc construire une chaîne de réception ressemblant conceptuellement à :

RF → I/Q → filtrage → démodulation → décodage → audio

et réaliser le chemin inverse en émission.

Le projet a naturellement beaucoup travaillé sur M17, protocole numérique vocal open source destiné aux radioamateurs. Dès novembre 2025, LinHT fonctionnait déjà comme un véritable transceiver M17 autonome.

Mais l’architecture ne se limite pas théoriquement à un seul mode. La documentation actuelle mentionne notamment FM, SSB, M17 et différents modes numériques expérimentaux, tandis que des essais de réception TETRA ont également été réalisés.

Un talkie peut ainsi devenir une véritable plateforme portable d’expérimentation SDR.

Et côté puissance ?

Un SDR expérimental capable de décoder des signaux sur une table de laboratoire est une chose. Un véritable talkie capable d’émettre plusieurs watts en est une autre.

La Rev B a justement permis de franchir cette étape.

Elle intègre un amplificateur RF GRF5604. Les essais ont mesuré environ 4,5 W en CW et autour de 3,5 W lors d’un essai M17.

Les concepteurs ont également validé la commutation émission/réception ainsi que deux atténuateurs RF programmables destinés notamment à éviter la saturation du récepteur.

LinHT commence donc réellement à ressembler à un portatif utilisable sur l’air.

Open source… jusqu’au circuit imprimé

L’intérêt du projet ne se limite pas à Linux.

La documentation matérielle est publiée : schémas électroniques, fichiers KiCad, PCB, nomenclature et données nécessaires à la fabrication sont accessibles.

On peut donc étudier le fonctionnement du poste, modifier son électronique et développer ses propres logiciels ou chaînes GNU Radio.

Il faut néanmoins apporter une nuance au terme « open source » : les fichiers matériels sont actuellement distribués sous licence CC BY-NC-SA 4.0, qui comporte notamment une restriction concernant l’utilisation commerciale.

Peut-on déjà construire son LinHT ?

Techniquement, un expérimentateur très bien équipé peut étudier le projet et envisager sa réalisation.

Mais nous sommes encore loin d’un kit à monter tranquillement un dimanche après-midi.

La Rev B a été fabriquée et testée et a permis de valider une grande partie de l’architecture. Plusieurs problèmes ont néanmoins été identifiés, notamment autour du GNSS, de certaines commandes matérielles et de l’intégration audio.

Ces enseignements servent maintenant au développement de la Rev C, qui devra elle-même être fabriquée et mesurée avant que ses performances puissent être considérées comme acquises.

Et si c’était cela, le talkie de demain ?

LinHT est finalement intéressant au-delà du projet lui-même.

Depuis des décennies, nous utilisons des postes dont le constructeur définit les possibilités. LinHT inverse en partie cette logique : le matériel devient une plateforme sur laquelle le radioamateur peut expérimenter.

Linux, GNU Radio, SDR, matériel documenté et logiciels modifiables réunis dans un appareil tenant dans la main…

Après les talkies que l’on pouvait simplement programmer, voici peut-être venir une nouvelle génération : des talkies que l’on pourra véritablement transformer.

Reste maintenant à voir si LinHT restera un formidable terrain de jeu pour quelques passionnés… ou s’il préfigure réellement le talkie-walkie radioamateur de demain.

Pour aller plus loin

Vous souhaitez suivre le développement de LinHT, consulter ses schémas ou découvrir plus en détail son architecture ? Voici les principales ressources officielles du projet.

  • Documentation matérielle LinHT : schémas, fichiers KiCad, Gerber, nomenclature et modèles 3D.
    linux-radio.eu
  • M17 Project : site de la communauté à l’origine de LinHT et du protocole numérique M17.
    m17project.org
  • Actualités LinHT : essais des prototypes et évolution des différentes révisions matérielles.
    Actualités LinHT
  • Architecture interne de LinHT : présentation détaillée du SX1255, de l’i.MX93, de Linux et de GNU Radio.
    Comprendre le fonctionnement de LinHT
  • Sources matérielles : fichiers de conception du circuit imprimé.
    Dépôt LinHT-hw sur GitHub

LinHT évoluant rapidement, privilégiez ces sources officielles pour disposer des informations les plus récentes.

L’examen radioamateur français se modernise

examen radioamateur ANFR

Qu’est-ce qui change réellement ?

L’examen permettant d’obtenir le certificat d’opérateur radioamateur en France évolue. Mais attention : il ne s’agit ni d’un nouvel examen, ni d’une modification du programme. C’est avant tout l’infrastructure informatique utilisée par l’ANFR qui se modernise.

Une évolution assez discrète pour le candidat, mais intéressante puisqu’elle concerne l’outil sur lequel passent les futurs radioamateurs.

Un examen déjà entièrement informatisé

Depuis plusieurs années, les candidats ne répondent plus à un questionnaire papier. L’examen organisé par l’Agence nationale des fréquences (ANFR) est informatisé.

Le principe reste bien connu : une partie consacrée à la réglementation et une seconde aux connaissances techniques.

L’ANFR propose d’ailleurs sur son site une présentation en ligne de l’interface d’examen, permettant de se familiariser avec son fonctionnement. L’Agence précise cependant qu’il s’agit uniquement d’une présentation et non d’un véritable logiciel d’entraînement.

C’est l’infrastructure qui se cache derrière cette interface qui évolue.

Une nouvelle solution informatique

Les informations publiées autour de cette modernisation indiquent que l’examen doit désormais s’appuyer sur la solution d’un éditeur numérique français.

L’objectif est de disposer d’une interface plus moderne et d’une infrastructure plus robuste, mais également d’un système susceptible d’évoluer plus facilement dans les années à venir.

La nouvelle solution doit aussi permettre de conserver un environnement de présentation accessible depuis le site de l’ANFR afin que les futurs candidats puissent découvrir l’interface avant de se présenter à l’examen.

L’évolution concerne donc essentiellement les coulisses informatiques de l’examen, plutôt que l’examen lui-même.

Un hébergement dans un cloud français

Un autre point mérite l’attention : l’hébergement des données.

Les informations disponibles indiquent que les données doivent rester sous la maîtrise de l’ANFR et être hébergées dans un cloud français.

Ce choix prend évidemment une importance particulière lorsqu’une administration manipule les informations personnelles des candidats.

Sur son site officiel, l’ANFR confirme que les données renseignées dans l’outil d’examen font l’objet d’un traitement par l’Agence dans le cadre de sa mission d’organisation des examens. Elle précise également les droits des candidats en matière d’accès, de rectification, d’effacement et d’opposition conformément au RGPD.

Ce qui ne change pas

C’est probablement le point le plus important pour les futurs candidats : cette modernisation informatique ne signifie pas qu’il faut revoir sa préparation à l’examen.

Les informations disponibles indiquent que le contenu des épreuves et les conditions d’accès ne sont pas modifiés par ce changement d’infrastructure.

Le programme reste fixé par l’annexe 1 de l’arrêté du 21 septembre 2000 relatif aux conditions d’obtention des certificats d’opérateur des services d’amateur.

L’inscription continue également de s’effectuer auprès d’un centre d’examen de l’ANFR. L’Agence organise les sessions dans ses services régionaux et ses antennes et précise qu’il convient de prendre rendez-vous directement auprès du centre choisi.

Autrement dit, inutile de jeter vos cours et de recommencer votre préparation !

Vers un examen davantage dématérialisé ?

Cette évolution pourrait néanmoins préparer l’avenir.

Une infrastructure informatique plus moderne et plus souple facilite théoriquement les mises à jour, la maintenance et l’évolution des services proposés aux candidats. Elle ne signifie toutefois pas que l’examen radioamateur pourra prochainement être passé depuis son domicile.

À ce jour, l’ANFR continue d’organiser les examens dans ses centres et antennes, avec la possibilité exceptionnelle d’organiser certaines sessions à l’extérieur de ses locaux. Pour cela, plusieurs conditions doivent être réunies, notamment plus de dix candidats sur une même journée et un éloignement supérieur à 100 km du centre d’examen le plus proche.

Pour les sessions organisées dans un établissement scolaire ou universitaire, l’ANFR recommande même de prendre contact avec le centre concerné au moins six mois auparavant.

Une modernisation bienvenue

Pour le candidat, cette évolution ne provoquera donc probablement aucun bouleversement spectaculaire.

Et c’est finalement plutôt une bonne nouvelle.

Le but n’est pas de réinventer l’examen radioamateur, mais de moderniser l’outil informatique qui permet de l’organiser, d’améliorer sa pérennité et de disposer d’une infrastructure capable d’accompagner les évolutions futures.

Programme, préparation, rendez-vous auprès de l’ANFR et passage des épreuves restent pour l’instant fondamentalement identiques.

La modernisation se déroule surtout derrière l’écran.

Mais dans un hobby où SDR, traitement numérique, modes numériques et stations contrôlées par ordinateur prennent chaque année davantage d’importance, il était finalement assez logique que l’examen permettant de devenir radioamateur modernise lui aussi son infrastructure numérique.

Les liens utiles de l’ANFR pour les futurs radioamateurs

Pour terminer, voici quelques pages officielles de l’Agence nationale des fréquences (ANFR) qu’il est utile de conserver dans ses favoris lorsqu’on prépare l’examen ou que l’on vient d’obtenir son certificat.

Préparer et passer l’examen radioamateur
La page « Les certificats » explique comment choisir un centre d’examen, s’inscrire, préparer les épreuves et se présenter le jour J. Elle rappelle également le déroulement des deux QCM de 20 questions, consacrés à la réglementation et à la technique.

Les certificats et l’examen radioamateur

Découvrir l’interface de l’examen
L’ANFR propose une présentation en ligne permettant de découvrir le fonctionnement des épreuves informatisées. Attention : il ne s’agit pas d’un logiciel d’entraînement complet, mais d’une présentation destinée à se familiariser avec l’interface.

Présentation des épreuves d’examen

Obtenir et gérer son indicatif
Une fois le certificat obtenu, cette rubrique explique les différentes catégories d’indicatifs et les démarches permettant notamment de demander un indicatif personnel, un indicatif de radio-club ou un indicatif spécial. On y trouve également les informations concernant les duplicatas et la suspension d’un indicatif.

Les indicatifs radioamateurs

Accéder au téléservice Radioamateur
Le téléservice de l’ANFR permet d’effectuer en ligne plusieurs démarches administratives liées à son activité radioamateur.

Téléservice Radioamateur de l’ANFR

Consulter l’annuaire officiel des radioamateurs
L’ANFR met également à disposition un annuaire permettant de rechercher les radioamateurs autorisés.

Annuaire officiel des radioamateurs

Trouver une réponse à une question particulière
Changement d’adresse, obtention d’un indicatif, radio-clubs, examen pour les personnes en situation de handicap, bandes de fréquences autorisées… la rubrique Questions/Réponses regroupe de nombreuses informations pratiques.

Questions / Réponses Radioamateurs

Enfin, pour les textes réglementaires qui encadrent notre activité, la rubrique dédiée permet de retrouver les principales références juridiques applicables au service amateur.

Cadre juridique des radioamateurs

Ces pages constituent les sources officielles à privilégier : réglementation, modalités d’examen ou démarches administratives peuvent évoluer et une information ancienne trouvée sur un forum ou un site radioamateur n’est pas nécessairement encore valable.