Décodage de BepiColombo
Traduction d’un document posté le par destevez
BepiColombo est une mission conjointe entre l’ESA et la JAXA pour envoyer deux vaisseaux spatiaux scientifiques à Mercure. Les deux vaisseaux spatiaux, le Mercury Planetary Orbiter, construit par l’ESA, et le Mercury Magnetospheric Orbiter, construit par JAXA, voyagent ensemble, rejoints par le Mercury Transfer Module, qui fournit la propulsion et le soutien pendant la croisière, et se sépareront à leur arrivée à Mercure. La mission a été lancée en octobre 2018 et arrivera sur une orbite autour de Mercure en décembre 2025. La longue croisière se compose d’un survol de la Terre, de deux survols de Vénus et de six survols de Mercure.
Le survol de la Terre aura lieu dans quelques jours, le 2020-04-10, donc actuellement BepiColombo s’approche rapidement de la Terre à une vitesse de 4 km / s. Hier, le 2020-04-04, le vaisseau spatial était à 2 millions de kilomètres de la Terre, ce qui est assez proche pour que les stations DSN amateurs puissent recevoir les bandes latérales de modulation des données. Paul Marsh M0EYT , Jean-Luc Milette et d’autres ont publié leurs rapports de réception sur Twitter.
Paul m’a envoyé un court enregistrement qu’il a fait le 2020-04-04 à 15:16 UTC à une fréquence de 8420.535MHz, afin que je puisse voir s’il était possible de décoder le signal. J’ai décodé les images avec succès, avec très peu d’erreurs. Ce message est un résumé de mon décodage.
Le signal en bande X de BepiColombo est très semblable à celui de Solar Orbiter que j’ai décodé il y a quelques mois, j’ai donc pu réutiliser la plupart des logiciels. Le signal est modulé PCM / PM / Bi-φ à environ 700 kbauds et utilise un code Turbo r = 1/2 avec une longueur de bloc de 8920 bits. Ainsi, la seule différence entre BepiColombo et Solar Orbiter est le débit en bauds (Solar Orbiter utilisait environ 555,5 kbaud).
Le SNR dans cet enregistrement de BepiColombo est plus bas que dans l’enregistrement de Paul de Solar Orbiter, donc mon décodeur n’a pas fonctionné: la constellation verrouillée, mais c’était trop bruyant pour le décodeur Turbo pour corriger toutes les erreurs de bit. Par conséquent, j’ai essayé une approche alternative de décodage qui semble fonctionner mieux.
Le décodeur peut être vu dans la figure ci-dessous. Un PLL est utilisée pour suivre la porteuse résiduelle, la démodulation de phase est effectuée et le signal est ré-échantillonné à 10 échantillons par symbole. Après cela, il y a un filtre FIR dont les prises sont une séquence de cinq -1 et cinq + 1. Cela devrait être considéré comme un filtre adapté à l’impulsion de Manchester. Aux points d’échantillonnage appropriés, les prises du filtre sont alignées avec l’horloge de Manchester et le filtre efface la modulation de Manchester. Après cela, nous exécutons la récupération de l’horloge avec l’algorithme Gardner, puis détectons l’ASM 64 bits qui marque le début des mots de code Turbo.
Je ne suis pas tout à fait sûr qu’il soit impossible pour cette approche de décodeur de verrouiller à faux décalé d’1/2-symbole de l’horloge correcte de symbole, mais jusqu’à présent, cela semble bien fonctionner.
L’organigramme du décodeur GNU Radio peut être trouvé ici . Comme dans le cas du décodeur Solar Orbiter, il utilise gr-dslwp pour le décodage Turbo, donc le diagramme de flux est pour GNU Radio 3.7, car gr-dswlp n’a pas été porté sur 3.8 jusqu’à présent. Notez que le décodage Turbo est très gourmand en CPU, il serait donc très difficile d’exécuter le décodeur en temps réel. Lorsque je l’exécute sur mon ordinateur portable i7-2620M, le démodulateur effectue l’enregistrement assez rapidement, mais le décodeur Turbo continue de fonctionner pendant plusieurs minutes jusqu’à ce qu’il termine le traitement de toutes les images.
Le décodeur peut être vu en cours d’exécution dans la figure ci-dessous. Le spectre des branches en phase et en quadrature du signal verrouillé en PLL est tracé, montrant clairement les bandes latérales de données modulées en phase dans la composante en quadrature. Il y a beaucoup d’erreurs sur les bits, mais même ainsi, le décodeur Turbo est capable de les corriger toutes.
L’analyse des images décodées peut être vue dans ce bloc – notes Jupyter et le fichier avec les images décodées est ici au cas où quelqu’un voudrait avoir un aperçu plus détaillé.
Un total de 1808 images ont été décodées à partir de l’enregistrement de 46,5 secondes de Paul. Un seul d’entre eux a un CRC incorrect. Les trames sont des trames TM Space Data Link. Selon le champ de comptage de trames du canal maître, seulement 8 trames ont été perdues dans mon processus de décodage.
Quatre canaux virtuels différents sont utilisés pour transmettre les données. L’utilisation relative de ces derniers peut être vue ci-dessous.
ID de canal virtuel 0: 38 images ID de canal virtuel 1: 99 images ID de canal virtuel 2:39 images ID de canal virtuel 7: 1631 images
Le contenu des canaux virtuels peut être vu ci-dessous. Chaque trame est tracée sur une ligne du graphique, avec des octets codés par couleur. On peut voir que les données sur chaque canal virtuel sont assez différentes. Le canal virtuel 2 est peut-être le plus intéressant, car il semble avoir de très longues séquences de zéros. Le canal virtuel 7, où la majeure partie des données est envoyée, affiche une structure répétitive qui ne correspond pas à la taille de la trame.
Je n’ai pas encore examiné les données plus en détail. Ce qui m’intéresse, ce sont les pics que l’on peut voir dans la branche en quadrature près du porteur. En fait, il y a plusieurs pics, comme on peut le voir sur la figure ci-dessous, qui montre un spectre rapproché du signal verrouillé en PLL.
J’ai mesuré la fréquence de ces pics à 12490Hz, 22088Hz, 24981Hz et 37417Hz, précise à 1Hz environ. Les deux derniers sont alors les 2e et 3e harmoniques de 12490Hz. Les tons 12490Hz et 22088Hz semblent être liés par la fraction 4016/2271. Cette numérologie est peut-être trop une supposition, mais puisque 4016 et 2271 sont des coprimes, elle soutient l’idée qu’il s’agit de tons variant. En effet, 12490Hz / 2271 est assez proche de 5,5Hz (l’erreur est de 40ppm, ce qui pourrait s’expliquer par le Doppler et la dérive d’horloge).
Donc, je suppose que les 2271e et 4016e harmoniques d’une horloge de 5,5 Hz sont utilisées pour la plage. L’ambiguïté de portée est donnée par l’horloge de 5,5 Hz et est d’environ 5,5 millions de km. En ce qui concerne les performances de télémétrie, avec un SNR en boucle de 20 dB sur le ton 22088Hz (ce qui n’est peut-être pas possible de réaliser avec cet enregistrement, mais ce n’est certainement pas trop loin), la gigue de suivi de ce ton serait de 0,1rad RMS, ce qui est équivalent à 216m, ce n’est donc pas mal du tout. Cependant, notez que la résolution des ambiguïtés entières nécessiterait de faire la moyenne de la gigue de phase sur la tonalité 22088Hz à une valeur nettement inférieure à 1 mrad, de sorte que le SNR nécessaire pour une plage non ambiguë est certainement beaucoup plus que ce qui est présent dans cet enregistrement.
Lors de la recherche de ces tons, j’ai également mesuré la vitesse de transmission avec précision en utilisant l’analyse cyclostationnaire. Il s’avère qu’il est de 699070,5 bauds (précis à environ 1 baud), donc je ne pense pas que le débit en bauds soit lié aux fréquences de ces tonalités.
Radiotélescope du Parc de La Villette 