L’APRS est aujourd’hui l’une des applications les plus visibles du Packet Radio. Sur 144,800 MHz en Europe, des milliers de stations transmettent positions GPS, télémétries, messages ou informations diverses en utilisant généralement le protocole AX.25.
Ce système fonctionne remarquablement bien… tant que le signal reçu est suffisamment propre.
Mais imaginons une station mobile arrivant en limite de couverture. Le signal devient faible, le fading apparaît et quelques bits sont mal reçus. Le contrôle d’erreur détecte alors que la trame AX.25 est incorrecte et celle-ci est rejetée.
Et si, au lieu de simplement détecter l’erreur, le récepteur pouvait réparer la trame ?
C’est précisément l’idée du FX.25.
AX.25 : détecter une erreur, mais pas la réparer
Pour comprendre l’intérêt de FX.25, revenons rapidement à AX.25.
Une trame AX.25 contient notamment les indicatifs source et destination, éventuellement le chemin emprunté par les digipeaters, les informations transportées et, à la fin, un FCS (Frame Check Sequence) calculé à l’aide d’un CRC.
De manière très simplifiée :
FLAG | ADRESSES | CONTROL | PID | INFORMATION | FCS | FLAG
Lorsqu’une trame arrive, le récepteur recalcule le CRC et le compare à celui reçu.
S’ils correspondent, tout va bien.
Dans le cas contraire, le récepteur sait que quelque chose a été altéré pendant la transmission. Le problème est qu’il ne sait pas où se trouve l’erreur ni quelle était la donnée originale.
Même si 99,9 % de la trame est parfaitement reçue, elle risque donc d’être inutilisable.
FX.25 part d’une philosophie différente : ajoutons suffisamment d’informations pour permettre au récepteur de corriger certaines erreurs.
AX.25 rejette une trame erronée ; FX.25 peut la récupérer grâce à la correction d’erreurs Reed-Solomon.
FX.25 : une couche de protection autour d’AX.25
FX.25 signifie Forward Error Correction Extension to AX.25 Link Protocol. La spécification a été publiée en 2006 par Jim McGuire, KB3MPL, pour Stensat.
FX.25 ne cherche pas à réinventer le Packet Radio. Il conserve la trame AX.25 et lui ajoute une protection par FEC – Forward Error Correction.
Autrement dit, la trame AX.25 reste au cœur du système.
On peut schématiser le principe ainsi :
AX.25 → ajout de données de correction → transmission → correction éventuelle → AX.25
Cette approche constitue l’un des principaux intérêts de FX.25 : améliorer la robustesse tout en restant étroitement lié à l’écosystème AX.25 existant. Dire Wolf présente d’ailleurs FX.25 comme une FEC ajoutée tout en maintenant la compatibilité avec les systèmes AX.25 existants.
Une trame FX.25 vue simplement
Sur les ondes, FX.25 ajoute plusieurs éléments autour des données AX.25.
Sans entrer immédiatement dans tous les détails, nous pouvons représenter la transmission ainsi :
Préambule → Correlation Tag → données AX.25 → correction Reed-Solomon → postambule
Le préambule permet notamment au récepteur de se stabiliser et de récupérer correctement le rythme des données.
Vient ensuite un élément caractéristique de FX.25 : le Correlation Tag.
Un Correlation Tag de 64 bits
Le récepteur doit pouvoir reconnaître qu’il est en présence d’une transmission FX.25 et déterminer quelle protection a été utilisée.
Pour cela, FX.25 emploie un Correlation Tag de 64 bits, soit huit octets.
Ce motif particulier fournit une indication robuste de début de bloc même lorsque les conditions radio sont mauvaises. Il permet également d’identifier le type de codage Reed-Solomon employé. La spécification définit plusieurs tags correspondant aux différentes tailles de blocs et protections disponibles.
Le récepteur FX.25 peut ainsi comprendre :
« Voici une trame protégée, et voilà comment je dois la décoder. »
Mais la véritable magie se trouve juste après.
Structure d’une trame FX.25 : la trame AX.25 est complétée par un Correlation Tag et des données de correction Reed-Solomon.
Reed-Solomon : ajouter des octets pour pouvoir réparer
FX.25 utilise une technique de correction d’erreurs appelée Reed-Solomon.
Le principe est utilisé depuis longtemps dans les télécommunications, le stockage numérique et les transmissions spatiales.
Il n’est pas nécessaire de plonger dans l’algèbre des corps de Galois pour en comprendre l’intérêt.
Imaginons que nous devions transmettre un ensemble de données. Avant l’émission, nous calculons à partir de celles-ci plusieurs octets supplémentaires que nous envoyons également.
Si quelques données sont détériorées pendant la transmission, ces informations supplémentaires permettent au décodeur de retrouver, dans certaines limites, les données originales.
C’est une différence fondamentale avec le CRC :
CRC → je sais que la trame est mauvaise.
Reed-Solomon → je peux parfois savoir qu’elle est mauvaise et la réparer.
C’est tout l’intérêt de la Forward Error Correction : aucune retransmission n’est nécessaire lorsque les erreurs restent dans les capacités de correction du code.
16, 32 ou 64 octets de correction
FX.25 prévoit plusieurs niveaux de protection.
Parmi les principaux codes Reed-Solomon utilisés figurent :
| Code | Données | Correction ajoutée | Correction théorique maximale |
|---|---|---|---|
| RS(255,239) | 239 octets | 16 octets | 8 symboles |
| RS(255,223) | 223 octets | 32 octets | 16 symboles |
| RS(255,191) | 191 octets | 64 octets | 32 symboles |
La règle est assez simple : si Reed-Solomon dispose de 2t symboles de contrôle, il peut théoriquement corriger jusqu’à t symboles erronés lorsque les erreurs sont de type inconnu.
Attention cependant au vocabulaire : ici, un symbole Reed-Solomon représente 8 bits, donc un octet. Corriger huit symboles erronés n’est donc pas synonyme de corriger simplement huit bits.
FX.25 prévoit également des codes raccourcis pour les trames plus petites, par exemple RS(144,128), RS(80,64) ou RS(48,32).
Pourquoi ne pas toujours utiliser 64 octets de correction ?
Puisque davantage de redondance permet de corriger davantage d’erreurs, pourquoi ne pas systématiquement choisir la protection maximale ?
Parce que cette robustesse a un prix : le temps d’occupation du canal radio.
Chaque octet de correction doit lui aussi être transmis.
À 1200 bit/s, ajouter plusieurs dizaines d’octets n’est pas négligeable, surtout sur une fréquence APRS partagée par de nombreuses stations.
Nous retrouvons donc un compromis classique des communications numériques :
peu de redondance → transmission plus courte mais protection limitée ;
beaucoup de redondance → meilleure protection mais transmission plus longue.
Le niveau idéal dépend donc du canal radio et de l’application.
FX.25 propose plusieurs niveaux de correction : davantage de redondance améliore la robustesse, mais allonge la durée de transmission.
Pourquoi FX.25 peut être intéressant en APRS
Prenons une station APRS mobile.
Lorsqu’elle se trouve près d’un relais, son signal arrive parfaitement et la FEC apporte peu de bénéfice. Mais lorsqu’elle s’éloigne, traverse une zone masquée ou subit du fading, certaines trames commencent à comporter des erreurs.
En AX.25 classique, ces trames sont perdues dès lors que leur FCS n’est plus valide.
Avec FX.25, une partie d’entre elles peut potentiellement être reconstruite.
Le principe devient particulièrement intéressant pour :
- les stations APRS mobiles ;
- les trackers autonomes ;
- les ballons et pico-ballons ;
- la télémétrie ;
- certaines communications par satellite ;
- les liaisons à faible rapport signal/bruit.
FX.25 avait d’ailleurs été développé à l’origine pour les communications par satellite. Dire Wolf indique aujourd’hui qu’il est également utilisé sur HF.
La FEC ne fait évidemment pas de miracle : un signal totalement noyé dans le bruit reste inexploitable. Elle permet en revanche de récupérer certaines trames qui se situent dans cette zone frustrante où presque tout avait été correctement reçu.
Et mon ancien TNC AX.25 ?
Il faut ici apporter une nuance importante à la notion de compatibilité.
FX.25 conserve une trame AX.25 et a précisément été conçu pour cohabiter avec l’écosystème existant. En revanche, un ancien TNC qui ne connaît pas FX.25 ne peut évidemment pas effectuer la correction Reed-Solomon.
Pour profiter réellement du gain de robustesse, il faut donc disposer d’un décodeur FX.25.
C’est aujourd’hui assez facile grâce aux TNC logiciels.
Essayer FX.25 avec Dire Wolf
Une solution particulièrement intéressante est Dire Wolf, un TNC logiciel fonctionnant notamment sous Windows et Linux et très utilisé avec APRS.
Dire Wolf intègre FX.25 depuis sa version 1.6. La réception FX.25 est activée automatiquement et l’option -X permet d’activer FX.25 à l’émission. Il est notamment possible de demander 16, 32 ou 64 octets de contrôle.
Une expérience intéressante pourrait donc être réalisée avec deux ordinateurs et deux radios :
PC → Dire Wolf → radio → canal perturbé → radio → Dire Wolf → PC
On commence par transmettre une série de trames AX.25 classiques avec un signal progressivement atténué.
On recommence ensuite dans les mêmes conditions avec FX.25.
Il devient alors possible de compter :
| Essai | Trames envoyées | Trames valides | Trames corrigées | Trames perdues |
|---|---|---|---|---|
| AX.25 | 1000 | ? | — | ? |
| FX.25 / 16 | 1000 | ? | ? | ? |
| FX.25 / 32 | 1000 | ? | ? | ? |
| FX.25 / 64 | 1000 | ? | ? | ? |
Voilà une expérience qui pourrait d’ailleurs faire l’objet d’un prochain article F5KEE.
FX.25 n’est pas une nouvelle modulation
Une dernière confusion doit être évitée.
FX.25 n’est pas une modulation radio.
AFSK, FSK, GMSK ou PSK décrivent différentes façons de transformer des données numériques en signal pouvant être transmis par radio.
AX.25 et FX.25 concernent, eux, la manière d’organiser et de protéger ces données.
On peut donc retenir :
AFSK/FSK/etc. → comment les bits voyagent sur les ondes
AX.25 → comment les informations sont organisées
FX.25 → comment la trame AX.25 peut être protégée contre certaines erreurs
Cette distinction est importante, car ajouter FX.25 ne signifie pas nécessairement changer de radio ou de modulation.
Une vieille technologie qui continue d’évoluer
AX.25 est issu d’une époque où les ordinateurs personnels avaient quelques dizaines de kilo-octets de mémoire et où les modems Packet Radio à 1200 bauds semblaient révolutionnaires.
Pourtant, le protocole continue d’être utilisé quotidiennement, notamment grâce à l’APRS.
FX.25 montre qu’il est possible de faire évoluer cette technologie sans nécessairement repartir de zéro : on conserve AX.25 et on lui ajoute une technique de correction d’erreurs beaucoup plus efficace.
D’autres approches existent d’ailleurs. Dire Wolf prend également en charge IL2P, qui propose une autre méthode de FEC avec moins de surcharge, mais sans la compatibilité AX.25 revendiquée par FX.25.
Cela pourrait être le sujet d’un prochain article :
AX.25, FX.25 et IL2P : quel protocole pour le Packet Radio moderne ?
En attendant, FX.25 apporte une idée finalement très simple à nos transmissions APRS :
plutôt que de constater qu’une trame contient quelques erreurs et de la jeter, pourquoi ne pas essayer de la réparer ?
Pour aller plus loin
Spécification FX.25 — FX.25 FEC Extension to AX.25 Link Protocol
Document technique original de Jim McGuire, KB3MPL, décrivant le format FX.25, les Correlation Tags et les codes Reed-Solomon.
Documentation pédagogique « AX.25 + FEC = FX.25 » de Dire Wolf
Une excellente introduction technique au fonctionnement de FX.25 et à son utilisation pratique.
Documentation Dire Wolf
Documentation générale du TNC logiciel et de ses différentes fonctions Packet Radio/APRS.
Projet Dire Wolf
Sources, versions et documentation du logiciel permettant notamment d’expérimenter AX.25, FX.25 et IL2P.
