Dans notre précédent article, nous avons découvert comment WSPR pouvait transmettre un minuscule message radio à des milliers de kilomètres avec quelques milliwatts. Nous savons maintenant qu’une émission dure environ 110,6 secondes, utilise quatre fréquences très proches et ne transporte que quelques informations.

Mais nous avons volontairement laissé une boîte fermée.

Comment un message aussi banal que :

F5KEE JN18 20

peut-il devenir une succession de 162 symboles radio ?

Et, question encore plus intéressante : comment le récepteur réussit-il à effectuer l’opération inverse lorsque le signal est presque entièrement noyé dans le bruit ?

Cette fois, ouvrons le capot.

Première étape : faire entrer F5KEE dans 28 bits

Un ordinateur pourrait naturellement coder chaque caractère de notre message séparément. Mais ce serait un énorme gaspillage pour WSPR.

Le protocole exploite le fait qu’un indicatif radioamateur possède une structure relativement prévisible.

Un indicatif standard peut être représenté par seulement 28 bits.

Pourquoi 28 ?

Avec 28 bits, nous pouvons représenter :

2²⁸ = 268 435 456 valeurs différentes.

C’est suffisamment pour numéroter les indicatifs standards que le protocole doit représenter.

WSPR ne transmet donc pas réellement les caractères :

F – 5 – K – E – E

Il applique une procédure de codage qui transforme l’indicatif complet en un nombre, puis représente ce nombre sur 28 bits.

C’est une première astuce fondamentale :

plutôt que transmettre des caractères, on transmet leur numéro dans un ensemble de combinaisons possibles.

Notre indicatif F5KEE devient ainsi une valeur numérique parfaitement réversible.

Le locator subit le même traitement

Notre message contient ensuite :

JN18

Là encore, transmettre quatre caractères séparément serait inutile.

Un locator Maidenhead à quatre caractères découpe la Terre en un nombre limité de cases.

Il existe 18 × 18 possibilités pour les deux lettres et 10 × 10 possibilités pour les deux chiffres :

18 × 18 × 10 × 10 = 32 400 locators possibles.

Or :

2¹⁵ = 32 768

Quinze bits suffisent donc pour identifier n’importe lequel des 32 400 locators.

Notre JN18 devient donc à son tour un nombre codé sur :

15 bits.

Nous avons maintenant :

F5KEE → 28 bits

JN18 → 15 bits

soit déjà :

43 bits.

Et les 7 derniers bits ?

Il reste la puissance.

Dans notre exemple :

20 dBm = 100 mW.

WSPR réserve 7 bits à ce dernier champ dans un message standard de type 1.

Nous arrivons donc exactement à :

28 + 15 + 7 = 50 bits.

De F5KEE JN18 20 aux 50 bits du message WSPR. Le codage source transforme l’indicatif, le locator Maidenhead et la puissance en valeurs numériques compactes : 28 bits + 15 bits + 7 bits = 50 bits. Ces 50 bits constituent l’information utile qui sera ensuite protégée par le codage correcteur d’erreurs avant la transmission.

Voilà notre premier tour de force.

Le message parfaitement lisible :

F5KEE JN18 20

est devenu un paquet de seulement :

50 bits.

Cette opération s’appelle le codage source : représenter l’information utile avec le moins de bits possible.

Mais si nous envoyions directement ces 50 bits, le moindre parasite pourrait transformer un 0 en 1 et rendre le message inutilisable.

Il faut donc maintenant faire quelque chose qui peut sembler contradictoire :

nous allons volontairement ajouter de l’information.

De 50 à 162 bits : le code convolutif

WSPR utilise un puissant système de correction d’erreurs appelé codage convolutif.

Ses deux caractéristiques principales sont :

K = 32

et

r = 1/2.

Le taux 1/2 signifie, de façon simplifiée, que pour chaque bit présenté au codeur, celui-ci produit deux bits codés.

Mais il ne regarde pas uniquement le bit actuel.

Il tient également compte des bits précédents grâce à une mémoire comparable à un registre à décalage.

C’est là qu’intervient :

K = 32

appelé constraint length, ou longueur de contrainte.

Autrement dit, chaque décision produite par le codeur dépend d’une longue histoire des bits qui l’ont précédée.

Cette propriété crée une forte redondance structurée dans le message.

Pour terminer correctement le processus, 31 positions supplémentaires sont nécessaires.

Nous obtenons donc :

(50 + 31) × 2 = 162 bits codés.

Le codage convolutif du WSPR. Les 50 bits d’information sont complétés par 31 bits de terminaison, puis traversent un codeur convolutif de longueur de contrainte K = 32 et de taux 1/2. Chaque bit traité produit deux bits codés selon les polynômes générateurs du protocole : 81 × 2 = 162 bits, apportant la redondance qui permettra au récepteur de corriger de nombreuses erreurs dues au bruit et au fading.

Et voilà enfin apparaître notre fameux nombre :

162

Il ne vient donc absolument pas de nulle part.

Les 50 bits d’information originale, accompagnés de la mémoire nécessaire au code convolutif, produisent les 162 bits codés utilisés pour construire la transmission WSPR.

À quoi sert toute cette redondance ?

Imaginons qu’un signal soit momentanément affaibli par du fading.

Quelques bits deviennent alors très difficiles à déterminer.

Sans correction d’erreurs, le récepteur devrait décider :

0 ou 1 ?

et espérer avoir choisi correctement.

Avec le codage convolutif, les bits ne sont plus indépendants. Ils appartiennent à une structure logique que le décodeur connaît.

Le récepteur peut donc rechercher quelle succession de bits d’origine explique le mieux l’ensemble des informations reçues.

C’est un peu comme lire :

R_DIO_MATEUR

Même avec des lettres manquantes, nous pouvons raisonnablement reconstruire :

RADIOAMATEUR

Le code correcteur fait quelque chose de conceptuellement comparable, mais avec des mathématiques plutôt qu’un dictionnaire.

Et maintenant, mélangeons tout !

Nous possédons désormais 162 bits.

On pourrait les transmettre dans leur ordre.

WSPR choisit pourtant de les mélanger volontairement.

C’est l’entrelacement, ou interleaving.

Imaginons une suite :

A B C D E F G H

et une perturbation radio qui détruit quatre éléments consécutifs :

A B ? ? ? ? G H

Une partie entière de notre information est touchée.

Si nous avions préalablement réorganisé les données, la même perturbation affecterait des informations qui, une fois remises dans leur ordre initial, seraient dispersées dans le message.

C’est exactement l’intérêt de l’entrelacement.

WSPR réorganise donc les 162 bits codés avant leur transmission.

Au récepteur, l’opération inverse — le désentrelacement — permettra de retrouver leur ordre logique.

L’entrelacement des 162 bits WSPR. Après le codage convolutif, les bits sont volontairement réordonnés avant leur transmission. Cette dispersion évite qu’une perturbation brève ou un fading n’endommage une série de bits voisins : après désentrelacement au récepteur, les erreurs se retrouvent réparties dans le message et deviennent plus faciles à traiter par le code correcteur.

Cela améliore la résistance aux perturbations brèves, au fading et aux interférences.

Nous avons 162 bits… mais toujours pas quatre tons

À ce stade, notre message :

F5KEE JN18 20

est devenu :

50 bits utiles → codage convolutif → 162 bits → entrelacement.

Chaque bit obtenu ne peut toujours prendre que deux valeurs :

0 ou 1.

Or WSPR utilise quatre tons :

0, 1, 2 ou 3.

Il nous manque donc une pièce du puzzle.

Et cette pièce est particulièrement astucieuse.

Le deuxième bit que connaît déjà le récepteur

WSPR possède une séquence de synchronisation pseudo-aléatoire de 162 bits.

Mais contrairement aux données de F5KEE, cette séquence n’est pas une information inconnue que le récepteur doit découvrir.

Le récepteur la connaît déjà.

Nous avons donc, pour chaque position :

un bit de données, provenant de notre message ;

et un bit de synchronisation, appartenant à une séquence connue.

Ces deux bits déterminent ensemble lequel des quatre tons doit être transmis.

La règle est remarquablement simple :

Ton = 2 × Data + Sync

Regardons ce que cela donne :

Data	Sync	Ton
0	0	0
0	1	1
1	0	2
1	1	3

Et voilà !

Nous venons de fabriquer les quatre états de la modulation WSPR.

C’est une notion essentielle pour comprendre le protocole.

Les quatre tons ne transportent donc pas simplement « deux bits de notre message ».

Un bit correspond aux données codées, tandis que l’autre appartient à la séquence de synchronisation connue du récepteur.

Du symbole à la fréquence radio

Chaque résultat 0, 1, 2 ou 3 sélectionne maintenant l’une des quatre fréquences possibles.

Si nous appelons f₀ la fréquence du ton le plus bas :

Ton 0 → f₀

Ton 1 → f₀ + 1,4648 Hz

Ton 2 → f₀ + 2,9296 Hz

Ton 3 → f₀ + 4,3944 Hz

L’écart entre deux tons voisins est donc d’environ :

1,4648 Hz.

Supposons, pour simplifier, qu’une petite partie de notre séquence devienne :

2 – 0 – 3 – 1 – 2 – 2 – 0 – 1…

L’émetteur ne transmet pas les chiffres.

Il produit successivement :

f₂ – f₀ – f₃ – f₁ – f₂ – f₂ – f₀ – f₁…

Chaque fréquence est maintenue pendant environ 0,683 seconde, puis l’émetteur passe au symbole suivant.

À raison de 162 symboles :

162 × 0,683 ≈ 110,6 secondes.

Nous avons maintenant suivi pratiquement toute la chaîne :

F5KEE JN18 20

↓

50 bits

↓

codage convolutif

↓

162 bits

↓

entrelacement

↓

+ 162 bits de synchronisation connus

↓

162 valeurs de 0 à 3

↓

162 tons 4-FSK

↓

110,6 secondes de radio.

Notre indicatif est maintenant dans l’air !

Mais à l’autre bout, il n’y a presque rien…

Imaginons maintenant notre transmission reçue à plusieurs milliers de kilomètres.

Le signal a subi l’ionosphère, du fading, du bruit atmosphérique, les parasites locaux et éventuellement les émissions voisines.

Avec quelques milliwatts au départ, sa trace peut être presque invisible.

Le récepteur doit pourtant retrouver :

F5KEE JN18 20

Nous allons donc refaire tout le voyage… à l’envers.

Du signal WSPR noyé dans le bruit au message F5KEE JN18 20. À la réception, le logiciel effectue le chemin inverse de l’encodage : il recherche et synchronise le signal, analyse les quatre tons, récupère les bits de données, les désentrelace puis exploite le code correcteur pour reconstruire les 50 bits utiles. Le décodage source permet finalement de retrouver l’indicatif, le locator et la puissance transmis.

Première mission : retrouver où se cache le WSPR

Le logiciel ne sait pas nécessairement exactement où se trouve notre signal dans la petite fenêtre WSPR.

Il doit rechercher une correspondance en temps et en fréquence.

C’est ici que notre séquence de synchronisation devient particulièrement précieuse.

Rappelez-vous : le récepteur la connaît.

Il peut donc rechercher dans le signal reçu une structure compatible avec cette séquence.

Lorsqu’une forte correspondance apparaît à une certaine fréquence et avec un certain décalage temporel, nous avons un candidat :

il y a peut-être une transmission WSPR ici.

La synchronisation aide ainsi le logiciel à déterminer précisément quand et où analyser le signal.

Le récepteur ne doit pas décider trop vite

Voici une autre notion importante.

Pour chaque symbole, le logiciel pourrait simplement rechercher laquelle des quatre fréquences possède le plus d’énergie et déclarer :

« C’est le ton 2 ! »

Mais lorsque le signal se trouve très profondément dans le bruit, une décision aussi brutale serait souvent fausse.

Le décodeur peut conserver des informations sur la probabilité ou la vraisemblance des différentes possibilités.

Au lieu de penser :

Ton 2 certain

il peut, conceptuellement, travailler avec quelque chose comme :

ton 2 très probable, ton 3 possible, tons 0 et 1 peu probables.

Ces informations deviennent extrêmement utiles pour le décodage correcteur.

Retirer ce que nous connaissons déjà

Une fois la synchronisation établie et les symboles analysés, nous savons que chaque symbole obéissait à :

Ton = 2 × Data + Sync.

Puisque Sync est connu, le logiciel peut retrouver l’information correspondant aux données.

Il obtient ainsi les estimations des 162 bits codés.

Mais souvenons-nous : nous les avions mélangés.

Il faut donc maintenant effectuer le :

désentrelacement.

Les bits retrouvent alors l’ordre attendu par le code convolutif.

Le moment où le correcteur entre en scène

Nous arrivons au véritable cœur du décodage faible signal.

Le décodeur connaît les règles exactes utilisées par le codeur.

Il peut donc rechercher quelle séquence initiale de 50 bits est la plus compatible avec les 162 informations reçues.

Un symbole peut être douteux.

Deux peuvent être mauvais.

Certains peuvent avoir pratiquement disparu.

Mais le décodeur ne juge pas chacun indépendamment : il cherche une séquence complète cohérente avec les contraintes du code.

C’est ce qui donne au WSPR une part importante de sa remarquable capacité à fonctionner à très faible rapport signal/bruit.

La documentation WSJT-X indique un seuil de décodage voisin de –31 dB dans une bande de référence de 2500 Hz.

À l’oreille, nous sommes depuis longtemps dans le domaine du « je n’entends absolument rien ».

Le logiciel, lui, possède encore suffisamment d’informations statistiques et structurelles pour tenter de reconstruire le message.

Nous retrouvons enfin nos 50 bits

Si le décodage réussit, nous revenons finalement aux :

50 bits d’origine.

Il ne reste plus qu’à inverser le codage source.

Les premiers champs permettent de reconstruire l’indicatif.

Le nombre redevient :

F5KEE

Les 15 bits du locator redeviennent :

JN18

et les 7 derniers bits permettent de récupérer :

20 dBm.

Après 110,6 secondes de transmission, des milliers de kilomètres de propagation et une bonne quantité de bruit, nous retrouvons exactement :

F5KEE JN18 20

C’est tout de même assez remarquable.

Finalement, que contiennent réellement les 162 symboles ?

Nous pouvons maintenant répondre beaucoup plus précisément que dans notre premier article.

Une transmission WSPR classique commence par seulement 50 bits d’information utile.

Le code convolutif K=32 de taux 1/2 apporte la redondance nécessaire pour obtenir 162 bits codés.

Ces bits sont entrelacés.

Chacun est ensuite associé à un bit provenant d’une séquence de synchronisation connue.

La combinaison :

2 × Data + Sync

produit l’une des quatre valeurs :

0 – 1 – 2 – 3

qui sélectionne l’un des quatre tons 4-FSK espacés d’environ 1,4648 Hz.

Ces 162 symboles sont transmis à environ 1,465 baud pendant 110,6 secondes.

À la réception, le logiciel effectue essentiellement le parcours inverse :

RF → synchronisation → analyse des tons → données → désentrelacement → correction d’erreurs → 50 bits → F5KEE JN18 20.

Voilà ce qui se cachait derrière nos 162 petits symboles.

Et surtout, nous pouvons maintenant comprendre pourquoi WSPR est si performant : il ne repose pas sur une astuce miraculeuse, mais sur une succession de choix particulièrement intelligents.

Très peu d’information, énormément de temps pour la transmettre, une bande passante minuscule, une synchronisation connue et une forte redondance permettant au logiciel de retrouver ce que le bruit avait presque effacé.

Et si nous fabriquions nous-mêmes ces 162 symboles ?

Maintenant que nous savons comment fonctionne la machine, une question devient inévitable.

Pourquoi laisser WSJT-X faire tout le travail ?

On pourrait très bien imaginer une fonction :

encode_wspr("F5KEE", "JN18", 20)

qui nous retournerait simplement :

2, 0, 3, 1, 2, 2, 0, 1...

jusqu’au 162e symbole.

Un petit microcontrôleur n’aurait ensuite plus qu’à transformer chacune de ces valeurs en l’une des quatre fréquences RF appropriées.

Un RP2040, un synthétiseur de fréquence, un filtre passe-bas, quelques composants et une antenne pourraient alors suffire pour construire une véritable balise WSPR autonome.

Mais ça…

ce sera une autre histoire.

Pour aller plus loin

• Guide officiel WSJT-X — spécification des protocoles — La référence à privilégier. Elle décrit les 50 bits, le code convolutif K=32, r=1/2, les 162 symboles, l’entrelacement et la combinaison des bits Data et Sync pour obtenir les quatre tons.
• WSJT-X — utilisation du mode WSPR — Pour passer de la théorie à la pratique avec WSJT-X : configuration, périodes de deux minutes, puissance d’émission et réception des spots. Le guide indique également une capacité de décodage pouvant atteindre environ –31 dB dans 2500 Hz.
• Code source officiel de WSJT-X sur GitHub — Pour ceux qui veulent aller jusqu’au code utilisé par WSJT-X et comprendre comment les différents modes faibles sont implémentés.
• WSPRcode.f90 — exemple d’encodage et de décodage WSPR — Probablement le lien le plus intéressant pour accompagner notre article. Ce petit programme montre explicitement l’encodage source, le codage convolutif, l’entrelacement, les symboles de synchronisation et la formule 2*dat(i)+sync(i) qui produit les 162 symboles transmis.
• JTEncode — bibliothèque Arduino pour générer du WSPR — Particulièrement intéressant pour les radioamateurs qui voudraient passer de la théorie à la construction : cette bibliothèque permet notamment de générer les symboles WSPR depuis un microcontrôleur. Elle constitue une excellente transition vers une future balise WSPR autonome.