Décoder une balise de détresse avec un talkie-walkie à quelques dizaines d’euros

Publié par f4wat le

Quand un bateau coule, qu’un avion se pose en catastrophe ou qu’un randonneur se blesse loin de tout, il existe un petit appareil qui peut lui sauver la vie : la balise de détresse. On l’active, et elle se met à crier dans le ciel, à intervalles réguliers, un court message radio. Des satellites l’entendent, et les secours savent qui appelle et d’où.

J’ai voulu savoir si un simple talkie-walkie de radioamateur, un Quansheng UV-K1 (lien affilié) qui coûte quelques dizaines d’euros, pouvait entendre ce message et l’afficher sur son petit écran. Pas avec un ordinateur branché à côté. Directement dans la radio.

La réponse est oui. Mais le chemin a été plus sinueux que prévu, et c’est ce chemin que je raconte ici.

Une balise de détresse, comment ça marche ?

Les balises modernes émettent sur une fréquence réservée au monde entier : 406 MHz. Elles font partie d’un système international appelé Cospas-Sarsat, qui existe depuis les années 1980 et qui a contribué à sauver des dizaines de milliers de personnes.

Selon l’usage, la balise porte un nom différent :

  • EPIRB pour les bateaux,
  • ELT pour les avions,
  • PLB pour les personnes (randonneurs, marins solitaires).

Une fois déclenchée, la balise envoie environ toutes les cinquante secondes un message très court, d’une demi-seconde. Ce message ressemble à une carte d’identité numérique :

  • un identifiant unique de 15 caractères, enregistré auprès des autorités,
  • le pays d’enregistrement (la France porte le numéro 227),
  • le type de balise,
  • et, si elle a un GPS, sa position.

Pour que ce message arrive intact malgré le bruit et la distance, il est protégé par des codes de contrôle. Un peu comme la clé d’un numéro de sécurité sociale : si un seul chiffre est faux, le calcul ne tombe plus juste, et on sait que le message est abîmé.

Pourquoi un radioamateur s’y intéresse-t-il ? Parce que les satellites donnent une position, mais qu’il faut ensuite quelqu’un sur le terrain pour trouver la balise précisément. En France, ce sont notamment les bénévoles des ADRASEC (comme l’ADRASEC 27 dans l’Eure), les associations de radioamateurs de la Sécurité civile, qui partent chercher les balises avec des récepteurs et des antennes directives. Pouvoir lire le message de la balise sur une radio de poche, c’est savoir tout de suite à quelle balise on a affaire.

Le talkie-walkie, et son « système d’exploitation »

Le Quansheng UV-K1 est un petit portatif chinois très répandu chez les radioamateurs. Sa grande qualité : son logiciel interne, qu’on appelle le firmware, peut être remplacé. Comme on installerait un autre système d’exploitation sur un ordinateur.

Un radioamateur français, Armel, F4HWN, développe un firmware alternatif pour ces radios, bien plus riche que l’original. Il y a récemment ajouté une idée astucieuse : des petites applications qu’on installe dans la radio sans toucher au reste. Une application de chasse au renard, une radio FM, des jeux…

Il y a une contrainte énorme : chaque application doit tenir dans 4 kilo-octets. Pour donner un ordre de grandeur, c’est à peu près deux pages de roman, en texte brut. Pas une image, pas un son : quelques milliers de caractères pour tout faire, du calcul à l’affichage.

L’objectif était donc d’écrire une de ces petites applications, capable de reconnaître et de décoder un message de balise.

Le banc d’essai : une fausse balise, et jamais sur 406 MHz

Première règle, non négociable : on n’émet jamais sur 406 MHz. Une émission sur cette fréquence peut déclencher une vraie alerte et mobiliser les secours pour rien.

J’ai donc utilisé un générateur : un petit ordinateur Raspberry Pi qui fabrique un message de balise parfaitement réaliste, mais qui l’émet sur une fréquence de la bande radioamateur (433,650 MHz), que j’ai le droit d’utiliser avec mon indicatif. Le message de test contient un identifiant, le pays 227 (France) et une position fictive.

À côté, une clé radio branchée sur l’ordinateur, avec un logiciel de décodage éprouvé, me sert de référence : elle me dit ce que la balise a réellement envoyé. Si la radio affiche la même chose, c’est gagné.

Le premier obstacle : la radio n’a pas d’oreille pour ça

Pour décoder un message, il faut l’écouter. Dans une radio, c’est une puce spécialisée qui capte le signal et le transforme en son pour le haut-parleur. Le petit processeur qui fait tourner les applications, lui, ne reçoit pas ce son. Il sait lire le niveau du signal, la batterie, les touches. Mais pas l’audio.

C’est un peu comme demander à quelqu’un de retranscrire une conversation qui se déroule dans la pièce d’à côté, porte fermée.

La première étape a donc été une enquête. J’ai écrit une application « sonde », baptisée 406 Lab, qui passe en revue tout ce que le processeur peut lire pendant qu’une fausse balise émet, et qui repère ce qui bouge au rythme du message.

Et elle a trouvé une porte entrouverte. Une des broches du processeur, prévue à l’origine pour les annonces vocales de la radio (une fonction désactivée dans cette version du firmware), se trouve reliée au circuit audio. Pendant le message de la balise, elle s’agite. Le son est là.

Bonne nouvelle : aucune soudure, aucune modification du firmware. Une application peut écouter la radio par ce chemin détourné.

Apprendre à comprendre le message

Entendre ne suffit pas, il faut comprendre. Le message de la balise n’est pas de la voix : c’est une suite très rapide de 0 et de 1, codée par de légers sauts dans l’onde radio, 400 fois par seconde.

Le « traducteur » qui transforme ce son en informations a d’abord été mis au point sur l’ordinateur, pas dans la radio. L’idée : fabriquer par calcul le son que la radio devrait entendre, y ajouter du bruit, des imperfections, un émetteur légèrement décalé, puis vérifier que le traducteur retrouve exactement le bon message. Une vingtaine de situations différentes, toutes réussies.

Restait à faire entrer ce traducteur, l’écoute et l’affichage dans les fameux 4 kilo-octets. La première version dépassait de 700 octets. Il a fallu ruser : réécrire certains calculs plus sobrement, bannir les divisions (le processeur de la radio ne sait pas en faire nativement, et la routine qui les remplace prend de la place), raccourcir les textes affichés. L’application finale, EPIRB 406, occupe 4 052 octets sur 4 096. Il reste de quoi écrire une phrase.

Premier essai sur la radio : presque, mais pas tout à fait

La radio a bien reconnu qu’une balise parlait, et elle a affiché un message. Mais faux. Au lieu de l’identifiant attendu, des morceaux corrects mélangés à des erreurs, un pays qui n’existait pas, une position à l’autre bout du monde.

En comparant le message reçu avec l’original, un motif est apparu : certaines combinaisons précises de 0 et de 1 étaient systématiquement mal lues, toujours de la même façon. Ce n’était pas du hasard, c’était un défaut de fabrication quelque part.

Pour le trouver, j’ai ajouté à l’application de sonde un mode oscilloscope, qui mesure le son exactement comme le traducteur le reçoit. Le verdict était clair : pendant le message, la moitié du signal était écrasée contre zéro, comme un enregistrement dont on aurait coupé tout ce qui dépasse vers le bas.

Le fil qui flottait

L’explication est électrique, mais elle se comprend bien. La broche que nous utilisions n’était reliée à aucun point de référence stable : elle « flottait ». Et chaque fois que le processeur la mesure, il prélève une toute petite quantité d’électricité. En la mesurant près de dix mille fois par seconde, on finissait par la vider, comme on viderait un ballon en y piquant une aiguille dix mille fois. Le signal s’effondrait vers zéro.

La solution a été élégante. Cette même broche est aussi la sortie d’un petit générateur de tension du processeur, celui qui servait aux annonces vocales. En l’allumant à mi-course, avec une force volontairement faible, on donne à la broche un point d’appui à mi-hauteur, sans étouffer le son qui arrive. Comme un ballon qu’on gonfle doucement en permanence pendant qu’on le mesure.

Résultat : un signal propre, centré, sans aucune partie écrasée. La radio a immédiatement lu correctement l’identifiant, le pays et le type de balise.

Le bug de l’arrondi

Il restait pourtant des erreurs à la fin du message, et jamais les mêmes d’un essai à l’autre.

En faisant tourner le traducteur sur l’ordinateur avec un signal aussi faible que celui mesuré sur la radio, le problème est apparu. Pour suivre le niveau moyen du son, le traducteur fait en permanence de petites corrections. Or la façon dont le calcul était écrit arrondissait toujours vers le bas, même les nombres négatifs. Imaginez un caissier qui arrondirait systématiquement chaque rendu de monnaie au centime inférieur : sur une transaction, ça ne se voit pas ; sur des milliers, la caisse finit par être fausse. Ici, la moyenne dérivait lentement vers le bas, et au bout de quelques centaines de millisecondes, la fin du message partait de travers.

La correction tient en une ligne : arrondir au plus proche. Et pour que ce genre de piège ne passe plus inaperçu, j’ai durci les tests : même niveau de signal que sur la radio, plusieurs tirages de bruit différents. L’ancienne version échouait à six d’entre eux ; la nouvelle les réussit tous.

Enregistrer la réalité plutôt que la deviner

Malgré ces deux corrections, la fin du message restait abîmée sur la radio. Deux corrections justes sur le papier, et toujours pas de résultat : il était temps d’arrêter de raisonner sur des modèles et d’aller chercher la réalité.

J’ai donc écrit une troisième application, 406 Rec, qui enregistre le son exactement tel que la radio l’entend pendant une émission de balise, et l’envoie à l’ordinateur par le câble de programmation. Pour la faire tenir dans les 4 kilo-octets, il a fallu compresser l’enregistrement de façon intelligente, avec beaucoup de précision pour les petits signaux et moins pour les grands.

Ces enregistrements ont été une révélation. Le traducteur, sur l’ordinateur, reproduisait exactement l’erreur de la radio. Et on voyait pourquoi : au bout de 400 millisecondes, le signal de la balise disparaissait, remplacé par du bruit. Les 40 derniers chiffres du message n’arrivaient jamais.

Ma première conclusion a été que le générateur coupait son émission trop tôt. Elle était fausse. La clé radio de référence, elle, recevait le message en entier. Le problème était donc du côté du talkie-walkie.

Une dernière mesure a tranché : en relevant la force du signal toutes les dix millisecondes, on voyait le signal tomber d’un coup à zéro, toujours au même moment. Le récepteur ne l’entendait plus du tout.

L’émetteur qui glissait

L’explication la plus probable était aussi la plus simple, et l’essai suivant l’a confirmée. Le petit Raspberry Pi qui joue le rôle de balise n’est pas un émetteur de précision : sa fréquence glisse légèrement pendant l’émission. La clé radio de référence écoute une large bande et suit ce glissement sans problème. Le talkie-walkie, lui, écoute un canal étroit. Vers la fin du message, l’émetteur sortait de ce canal, comme une station de radio qui dériverait hors de la graduation où l’on a réglé son poste.

Il a suffi de régler le talkie-walkie 5 kHz plus bas que la fréquence d’émission. Et là, tout le message est passé :

  • identifiant 1C7C2468ACFFBFF,
  • pays 227,
  • balise de test,
  • position 49,27111 N, 0,78222 E,
  • codes de contrôle valides.

Exactement ce que la balise avait envoyé.

Pour simplifier ce réglage sur le terrain, l’application permet désormais de décaler l’écoute de 5 kHz en 5 kHz avec les flèches, sans quitter l’écran de décodage. Une vraie balise est beaucoup plus stable qu’un Raspberry Pi, mais un décalage de réglage peut toujours arriver, et il vaut mieux pouvoir le corriger d’un geste.

Ce que je retiens

Mesurer plutôt que supposer. Deux problèmes réels ont été corrigés à partir de raisonnements. Mais c’est l’enregistrement du signal réel qui a révélé la dernière cause. J’aurais dû construire cet outil plus tôt.

Se méfier de ses propres conclusions. J’ai accusé le générateur à tort. C’est une vérification indépendante, la clé radio de référence, qui a remis les choses à l’endroit.

Les petites contraintes rendent inventif. 4 kilo-octets, pas de division, une broche détournée de son usage : chaque limite a forcé une solution plus simple que la première idée.

Un bon banc d’essai vaut de l’or. Un générateur réaliste, une référence fiable, et la règle absolue de ne jamais émettre sur 406 MHz : c’est ce qui a permis d’avancer vite et sans risque.

Le développement s’est fait en une journée, en binôme avec un assistant de programmation basé sur l’intelligence artificielle : lui écrivait et analysait le code, moi je tenais le banc d’essai, la radio, les mesures et les décisions. Une répartition qui a bien fonctionné, précisément parce que l’assistant ne voit pas la radio : chaque hypothèse devait être confirmée par une vraie mesure.

Et maintenant ?

L’application décode aujourd’hui les messages de balise de première génération, qui représentent encore l’immense majorité du parc. Plusieurs pistes restent ouvertes : corriger automatiquement les petites erreurs de réception grâce aux codes de contrôle, décoder la position de toutes les familles de balises, estimer tout seul le décalage de fréquence, et surtout la tester avec le mode autotest d’une vraie balise, en conditions réelles, lors d’un exercice ADRASEC.

Un rappel important : cette application est un outil d’expérimentation et d’apprentissage. Elle ne remplace en rien les moyens officiels de recherche et de sauvetage. Et encore une fois : on n’émet jamais sur 406 MHz pour faire des essais.

Pour aller plus loin

Johan Denoyer, F4WAT

Les liens vers Amazon sont des liens affiliés : si vous achetez par leur intermédiaire, je touche une petite commission, sans surcoût pour vous. En tant que partenaire Amazon, je réalise un bénéfice sur les achats remplissant les conditions requises.

1 commentaire sur “Décoder une balise de détresse avec un talkie-walkie à quelques dizaines d’euros”

Laisser un commentaire