Message de navigation LEO

Le type de scénario leo-navmsg construit le message d'éphéméride et d'horloge diffusé d'un satellite de positionnement, navigation et synchronisation temporelle (PNT) en orbite terrestre basse (LEO), et répond aux questions que se pose un concepteur de message : combien de temps un message peut-il couvrir, qu'apporte chaque paramètre supplémentaire, que voit un utilisateur lorsque le message change en milieu de passage, et combien de bits faut-il pour le porter au centimètre.

Il est indépendant du système. N'importe quelle orbite, n'importe quelle porteuse et n'importe lequel des quatre modèles d'éphéméride s'exécutent sans aucun préréglage ; les préréglages nommés sont des données facultatives (voir Préréglages).

Affichez un exemple fourni avec kshana example <name> (un nom par appel) et exécutez-le avec kshana scenarios/<name>.toml : leo-navmsg-fit-interval-trade, leo-navmsg-model-comparison, leo-navmsg-midpass-update et leo-navmsg-encode-decode. Le type est aussi l'étape de message du type leo-pnt-chain (LEO-PNT.md) et le membre de la campagne leo-focus-data-services, qui compose quatre configurations de message et rapporte la longueur de trame de chacune (146, 154, 159 et 171 octets).

Code : src/leo_navmsg/ — elements.rs (enregistrements et algorithme utilisateur), truth.rs (orbite et horloge de référence), fit.rs (ajusteur), sisre.rs (erreur de distance du signal dans l'espace), services.rs (ionosphère et temps universel coordonné (UTC)), codec.rs (format binaire), text.rs (exports de type Receiver Independent Exchange Format (RINEX) et de valeurs séparées par des virgules (CSV)), presets/ (un fichier par préréglage), mod.rs (le type).

Ce que porte un message#

Modèles d'éphéméride#

L'algorithme utilisateur (elements::sat_state) est la séquence de l'ICD Galileo (équation de Kepler, corrections du second harmonique, nœud fixe par rapport à la Terre) suivie, pour kepler-rac, des trois polynômes le long du propre repère de l'orbite képlérienne : radial le long de la position évaluée, transverse le long de la normale à l'orbite à partir de l'inclinaison et du nœud corrigés, sur la trace complétant le trièdre. L'horloge ajoute le terme relativiste de l'ICD F·e·√A·sin E ; pour ecef-poly, c'est la forme générale −2 r·v / c² à partir du polynôme et de sa dérivée.

Les termes de Liu et al. suivent l'algorithme utilisateur de l'article (Section 2,2, Éq. 1-7) : A = A0 + ȧ·tk, n = √(μ/A0³) + Δn + ṅ·tk (les versions antérieures à 0,30 utilisaient la convention de navigation civile du Global Positioning System (GPS) ½·ṅ·tk, de sorte qu'un ṅ qu'elles écrivaient valait le double de celui de l'article), et Crs1·sin Φ + Crc1·cos Φ + Crs3·sin 3Φ + Crc3·cos 3Φ ajouté au rayon, Φ l'argument de latitude non corrigé. La convention d'échelle de ṅ est transcrite de l'Éq. 1 de l'article ; la comparaison avec l'article sur des orbites réelles n'en dépend pas (un facteur ½ sur ṅ laisse inchangée chaque valeur ajustée), de sorte que la signification d'une valeur nDot transmise n'y est pas validée.

Deux lectures sont propres à Kshana et sont présentées comme telles :

• Le repère RAC et la normalisation τ = tk / tau_s. Aucun document public ne définit de repère de correction LEO pour un message diffusé.
• L'horloge d'un message à zéro horloge est nulle au total : la boucle d'asservissement est supposée maintenir l'horloge apparente, terme relativiste compris, au temps système.

L'ajusteur#

truth.rs intègre l'orbite avec un Runge–Kutta du quatrième ordre à pas fixe dans un repère qui se transforme en axes fixes par rapport à la Terre par une seule rotation, θ(t) = θ0 + Ω̇e·t, la même rotation unique qu'applique un algorithme utilisateur de diffusion. La gravité est à deux corps (gravity_degree = 0), les harmoniques zonaux J2 à J6 (2 à 6), ou le champ du Earth Gravitational Model 2008 (EGM2008) jusqu'au degré et à l'ordre 7 à 70, dont les termes tesséraux portent la signature à courte période qui rend difficile un ajustement en LEO. La traînée est facultative (densité exponentielle statique). L'horloge est en marche libre (biais, dérive, taux de dérive et bruit de fréquence blanc à un écart-type d'Allan à une seconde indiqué, plus le terme relativiste périodique) ou asservie (un résidu de Gauss–Markov du premier ordre).

fit.rs ajuste le jeu képlérien par Levenberg–Marquardt sur des éléments non singuliers (e·cos ω, e·sin ω, λ0 = M0 + ω) : une orbite LEO est presque circulaire, de sorte que ω et M0 seuls sont presque indiscernables. Il part de l'état osculateur à toe avec le taux de nœud dû à J2. Des a priori faibles centrés sur zéro bornent les taux et les harmoniques qu'un arc court ne peut résoudre ; avec un poids d'observation de 1 cm, ils n'agissent que dans ces directions nulles. L'ajustement liu22 adopte en revanche le départ et l'estimateur de la Section 2,3 de l'article : il part avec chaque terme de correction à zéro, sans a priori (moindres carrés simples) et conserve le plafond de 100 itérations de l'article. Il s'arrête selon la propre règle de convergence des paramètres de Kshana, lorsque chaque pas de paramètre est inférieur à 1e-3 de son écart-type formel ; l'article s'arrête plutôt lorsque le RMS varie de moins de 0,1 mm. Les polynômes RAC sont ensuite ajustés aux résidus sur la trace/transverse/radial par moindres carrés linéaires, et le polynôme d'horloge à l'horloge de référence moins le terme relativiste que l'utilisateur rajoutera.

Un constat que les valeurs par défaut encodent : après un ajustement képlérien par moindres carrés, le résidu est par construction ce que les 16 paramètres ne peuvent pas couvrir, de sorte qu'il oscille sur la fenêtre (plusieurs passages par zéro dans chaque composante) au lieu de dériver. Un polynôme de correction ne l'élimine que si son degré dépasse ce que le jeu képlérien couvre déjà : 7 sur la trace, 5 transverse et 6 radial ramènent un résidu de 15 minutes de quelques centimètres à environ un millimètre, tandis que des degrés transverses plus faibles n'éliminent presque rien (le résidu transverse est impair par rapport au centre de la fenêtre). Un système qui dérive sa partie képlérienne d'une autre façon laisse un résidu de forme différente, et les degrés dont il a besoin en découlent. Les propres degrés de correction du préréglage Celeste (plus bas que ceux-ci ; ils n'existent que dans le fichier de préréglage, src/celeste_iod.rs) s'exécutent ici sur la base de moindres carrés de Kshana, ce qui explique que ses termes transverses contribuent peu dans ce moteur : une affirmation sur l'ajusteur de Kshana, et non sur un système réel. toe et toc sont des secondes entières, comme les porte le format binaire.

Chaque message est utilisé sur une période centrée dans sa fenêtre d'ajustement (le premier tableau de compromis utilise la fenêtre entière). Ce que mesurent les valeurs d'erreur de distance du signal dans l'espace (SISRE) est l'erreur de représentation du message par rapport à la référence sur laquelle il a été ajusté, sous forme de valeur quadratique moyenne (RMS) et de maximum sur l'intervalle. L'erreur de détermination d'orbite et de prédiction d'orbite, qu'un vrai segment sol ou embarqué ajoute en plus, n'est pas modélisée.

Erreur de distance du signal dans l'espace#

sisre.rs utilise le SISRE moyen global de Montenbruck, Steigenberger et Hauschild (2018, Advances in Space Research 61(12) : 3020–3038, doi 10.1016/j.asr.2018.03.041) :

SISRE_orb = sqrt( w_R² R² + w_AC² (A² + C²) )
SISRE     = sqrt( (w_R R − c·dT)² + w_AC² (A² + C²) )

Les poids sont les moyennes sur des utilisateurs répartis uniformément sur la calotte terrestre visible de cos² η et ½ sin² η, avec η l'angle au nadir de la ligne de visée au satellite, calculés pour le rayon propre de l'orbite et le masque d'élévation. À un masque de 0°, le calcul reproduit le tableau de l'article pour l'orbite terrestre moyenne (GPS 0,98 et 1/49, GLONASS 1/45, Galileo 1/61, BeiDou 1/54) et l'orbite géostationnaire (0,99 et 1/126) : c'est la vérification VALIDATED. En LEO, la même moyenne donne

de sorte qu'un utilisateur LEO, qui voit le satellite loin du nadir, ressent beaucoup plus les erreurs sur la trace et transverses qu'un utilisateur en orbite moyenne.

Analyses#

analysis = [...] choisit l'une des quatre (toutes par défaut).

Compromis sur l'intervalle d'ajustement#

[trade] fixe l'intervalle, les intervalles d'ajustement, les périodes de mise à jour et les modèles. scenarios/leo-navmsg-fit-interval-trade.toml (550 km, 97,6°, EGM2008 jusqu'au degré 20 et traînée, 30 minutes de messages) donne, avec une période d'utilisation égale à l'intervalle d'ajustement :

Et avec un ajustement de 300 s, en faisant varier la fréquence à laquelle un nouveau message prend le relais :

Le jeu képlérien à 16 paramètres se dégrade de 0,04 cm à 60 s à 9,35 cm à 900 s : un seul jeu képlérien avec des harmoniques deux fois par révolution ne peut pas suivre les termes de gravité de plus haute fréquence ni la traînée d'un arc LEO pendant plus de quelques minutes, et son résidu de moindres carrés oscille sur la fenêtre. Les polynômes sur la trace/transverse/radial (degrés 7, 5, 6) absorbent ce qui reste : 1,01 cm à 900 s, 0,21 cm à 600 s. Aux intervalles les plus courts, les valeurs képlériennes sont sub-millimétriques et ne sont plus strictement ordonnées (l'ajustement est alors limité par le conditionnement, et non par le modèle).

Comparaison de modèles#

scenarios/leo-navmsg-model-comparison.toml exécute les quatre modèles à 1, 5 et 10 minutes sur la même orbite, avec le nombre de paramètres et les bits d'éphéméride et d'horloge dans l'encodage de Kshana :

La ligne à zéro horloge est évaluée par rapport à une horloge asservie avec un résidu de 0,24 m (la valeur d'ATOMIC), les autres par rapport à l'horloge en marche libre qu'elles ajustent.

Liu et al. 2025, SISRE en fonction de l'altitude (MODELLED). Le même scénario ajuste le modèle à 22 paramètres de Kshana sur des arcs de 20 minutes aux cinq altitudes de l'article, à l'inclinaison de chaque satellite :

Ce n'est pas une validation. L'article a ajusté de vraies orbites scientifiques précises des satellites nommés (avec leur historique complet de gravité, de traînée et de forces non gravitationnelles) ; Kshana ajuste sa propre orbite intégrée, évalue les six paramètres ajoutés comme décrit ci-dessus, et utilise ses propres poids SISRE. La comparaison montre la tendance et l'ordre de grandeur. La comparaison sur les mêmes orbites réelles que l'article a ajustées est tests/leo_navmsg_fit_real_orbit_oracle.rs (depuis 0,30, l'ajustement à 22 paramètres y concorde à l'intérieur du facteur 1,5 préenregistré, sur les jours de l'article et sur huit jours réservés).

Mise à jour en milieu de passage#

[midpass] place un utilisateur (par défaut 45° N, 10° E), trouve le passage le plus haut au-dessus du masque dans search_s, et planifie des messages toutes les update_period_s. À chaque changement pendant le passage, il rapporte le saut de position, le saut d'horloge, le saut de pseudodistance de l'utilisateur (nouveau message moins ancien), le plus grand saut que pourrait voir un utilisateur visible (forme fermée sur le cône au nadir), l'erreur de distance avant et après, et PASS ou FAIL par rapport à threshold_m. scenarios/leo-navmsg-midpass-update.toml (ajustements de 300 s mis à jour toutes les 150 s) :

Le passage le plus haut en une journée atteint 43,7° et dure 455 s. Ses changements :

Plus grand saut de distance utilisateur : 0,35 mm pour un seuil de 5 cm : PASS.

Encodage et décodage#

scenarios/leo-navmsg-encode-decode.toml encode le premier de trois messages, le décode, vérifie le CRC et rejette une copie corrompue, affiche le budget de quantification, puis écrit et relit le bloc de type RINEX et la table CSV :

• trame : 171 octets (1310 bits de charge utile, dont 1045 d'éphéméride et d'horloge), contrôle de redondance cyclique sur 24 bits (CRC-24Q) 0x19105F ;
• plus grand effet d'un demi-pas pour un champ isolé : af0, 0,545 mm ;
• message entier après quantification : position à 1,126 mm près et horloge à 0,185 mm près du message exact ; SISRE 0,113 cm exact, 0,129 cm décodé ;
• une trame dont un bit est inversé est rejetée : vrai ;
• aller-retour RINEX à 5.0e-06 m près, aller-retour CSV à 0.0e+00 m près.

Indépendance vis-à-vis de la plateforme#

Une trame est transmise sous forme d'entiers : ce doivent être les mêmes entiers où et comment que le scénario s'exécute, que ce soit avec le binaire natif sur n'importe quel système d'exploitation, avec une version de débogage ou de production, ou avec la version WebAssembly (WASM) dans un navigateur. Trois obstacles se présentaient. Le sinus, le cosinus, l'arc tangente et l'exponentielle de la bibliothèque mathématique d'un hôte ne sont pas tenus d'être correctement arrondis et diffèrent d'un hôte à l'autre sur la dernière décimale. Une version optimisée sous macOS prend le sinus et le cosinus d'un même argument dans la routine combinée du système, qui ne renvoie pas toujours la valeur du sinus seul ; une version de débogage et une version de production différaient donc aussi. Et l'échantillonneur normal usuel appelle l'exponentielle et le logarithme de l'hôte dans ses branches rares. L'ajustement transforme une différence aussi minime en champs quantifiés différents. Le type de scénario entier (orbite et horloge de vérité, ajustement, algorithme utilisateur, erreur de distance du signal dans l'espace (SISRE), codec) calcule donc chacune de ces fonctions avec la bibliothèque Rust pure libm par l'intermédiaire de src/portable_math.rs, les puissances entières sous forme de produits explicites, et les écarts normaux par la méthode polaire sur la sortie brute du générateur. leo_navmsg::tests::the_encoded_frame_is_the_same_bytes_on_every_platform fige la trame de 171 octets du scénario d'encodage et de décodage ci-dessous et une valeur de contrôle par modèle d'éphéméride ; une version de débogage, une version de production et la version WASM donnent des documents de résultats identiques octet pour octet pour les cinq scénarios leo-navmsg fournis.

Format binaire#

Il s'agit de l'encodage documenté propre à Kshana. Il porte les composantes que nomment les descriptions publiées des messages de navigation LEO, sur le modèle de l'ensemble de champs de l'ICD Galileo. Ce n'est pas la disposition binaire de Celeste ni d'aucun autre système : aucune n'est publique.

Trame : préambule 0xA7 (8 bits), version 1 (4), modèle (4 : 1 kepler16, 2 kepler-rac, 3 liu22, 4 ecef-poly), longueur de la charge utile en octets (12), charge utile complétée par des zéros jusqu'à l'octet, CRC-24Q (un contrôle de redondance cyclique sur 24 bits, 24 bits) sur tous les octets précédents. Le CRC-24Q est le contrôle de la norme RTCM 10403 de la Radio Technical Commission for Maritime Services et de l'ICD Galileo (polynôme 0x1864CFB, valeur initiale 0) ; le code reproduit la valeur de contrôle du catalogue 0xCDE703 pour 123456789 et les octets de contrôle de la trame d'exemple de type de message 1005 de la RTCM 10403 (VALIDATED).

Les pas de l'ICD Galileo ont été choisis pour l'orbite terrestre moyenne et sont trop grossiers pour un message LEO de niveau centimétrique : Crs par pas de 2⁻⁵ m (3,1 cm), Cuc 2⁻²⁹ rad (1,3 cm au rayon LEO), les angles 2⁻³¹ demi-cercles (1,0 cm) et af0 2⁻³⁴ s (1,7 cm). Kshana conserve les unités de l'ICD et la convention du demi-cercle, affine les pas pour que l'erreur d'un demi-pas de chaque champ reste inférieure à 1 mm de position ou de distance sur une fenêtre de 15 minutes, et élargit les champs pour conserver les plages dont un ajustement LEO a besoin :

Une valeur hors de la plage de son champ est refusée, et non ramenée par repli modulaire. Les plages ont été vérifiées en encodant des ajustements à 300 jusqu'à 2000 km, des inclinaisons de 0° à 140° et des intervalles d'ajustement allant jusqu'à 20 minutes : deltaN et OmegaDot sont larges parce que, sur une orbite quasi équatoriale, le nœud est mal défini et que l'ajustement répartit entre eux la dérive J2 de l'argument de latitude, et aDot et nDot parce que l'ajustement à 22 paramètres sur 20 minutes absorbe une partie de l'oscillation à courte période du demi-grand axe. Depuis la version 0,30, l'ajustement à 22 paramètres est les moindres carrés ordinaires de l'article, sans a priori, et un ajustement équatorial à 800 km exige alors un nDot d'environ 6.3e-10 demi-cercle/s^2, si bien que son échelle est passée de 2^-60 à 2^-58. Les corrections along-track de degré 7 de kepler-rac tiennent dans la plage de coefficients de 22 bits jusqu'à 15 minutes ; un ajustement plus long peut la dépasser et est alors refusé. quantisation_budget indique, pour chaque champ d'éphéméride et d'horloge, la plus grande variation de position et de distance que provoque un changement d'un demi-pas sur la période d'utilisation, ainsi que la variation du message entier après quantification.

Exports texte#

RINEX 4,02 ne définit aucun enregistrement de navigation LEO (ses lettres de système sont G, R, E, J, C, I et S ; International Global Navigation Satellite System (GNSS) Service (IGS) RINEX 4,02). Le bloc qu'écrit text.rs emprunte la forme de RINEX 4 — un en-tête d'enregistrement > EPH, une ligne de satellite et d'époque avec trois termes d'horloge, des lignes d'orbite diffusée de quatre champs D19.12 — et constitue une extension de Kshana documentée : lettre de système L, types d'enregistrement KP16, KRAC, LU22, APOL, et trois commentaires d'en-tête qui le disent. Travaux antérieurs sur les orbites LEO dans des enregistrements de navigation de style RINEX-4 : arXiv 2401,17767.

> EPH L04 KRAC
L04 yyyy mm dd hh mm ss  af0 af1 af2
     IOD      Crs      deltaN   M0
     Cuc      e        Cus      sqrtA
     toe      Cic      Omega0   Cis
     i0       Crc      omega    OmegaDot
     IDOT     Band     Week     Health
     txTOW    clock    degA     degC
     degR     tau_s    a0       a1         then the rest of a_k, c_k and r_k, four per line

La table CSV porte les messages kepler16 et kepler-rac, un par ligne. Les colonnes par défaut utilisent les noms de l'ICD Galileo (SVID, IOD, Band, WeekNumber, ToW, Health, toc, af0, af1, af2, toe, M0, sqrtA, e, deltaN, Omega0, OmegaDot, iDot, i0, omega, Crc, Crs, Cic, Cis, Cuc, Cus, a0…, c0…, r0…, racTau) ; csv_schema choisit à la place l'orthographe d'un préréglage. Les deux formats sont relus.

Ionosphère et UTC#

• Klobuchar : le modèle L1 du moteur (gnss_sim::klobuchar_delay_m, vérifié par rapport à RTKLIB) ramené à la porteuse par la loi du premier ordre (f_L1 / f)².
• NeQuick-G : les coefficients voyagent dans le message et effective_ionisation_level renvoie Az = ai0 + ai1·μ + ai2·μ² pour une latitude magnétique modifiée μ, avec les règles de l'algorithme (des coefficients tous nuls donnent 63,7 unités de flux solaire, sfu ; le résultat est borné à [0, 400] sfu). Le modèle de densité électronique NeQuick et son intégration oblique, qui transforment Az en un retard, ne sont pas implémentés.
• Un satellite à quelques centaines de kilomètres vole à l'intérieur de l'ionosphère. Aucun des deux modèles diffusés ne tient compte du contenu électronique situé au-dessus du satellite, et aucune correction à ce titre n'est appliquée.
• UTC : system_to_utc applique les trois cas de l'ICD Galileo §5.1.7 (avant, dans les six heures qui entourent, et après un événement de seconde intercalaire) ; une seconde insérée se lit 86400.

Préréglages#

Les préréglages sont des données, un fichier chacun sous src/leo_navmsg/presets/, avec leurs sources. Le moteur et tous les scénarios fournis, sauf celui de Celeste, s'exécutent sans eux.

RNSS désigne le service de radionavigation par satellite ; RNTF la Resilient Navigation and Timing Foundation.

Celeste IOD. Le préréglage de la démonstration en orbite (IOD) Celeste de l'Agence spatiale européenne (ESA) est le seul à utiliser des éléments présentés à l'atelier LEO-PNT du programme d'innovation et de soutien à la navigation (NAVISP) de l'ESA, 2026 : la structure du message (ensemble képlérien Galileo plus polynômes de correction along/cross/radial, polynôme d'horloge, SVID, santé, IOD, paramètres ionosphériques et UTC), l'espacement des enregistrements et les noms de colonnes CSV. L'orbite (510 km, quasi polaire héliosynchrone) et la porteuse proviennent de sources publiques citées dans le fichier. La disposition binaire de Celeste n'est pas publique et n'est pas reproduite ; les phases ultérieures de Celeste et le système LEO-PNT de l'Union européenne (UE) peuvent différer. Chaque valeur issue de l'atelier se trouve dans le module navmsg de src/celeste_iod.rs, utilisé par scenarios/leo-navmsg-celeste-iod.toml. Comment le préréglage est tenu à l'écart : chaque nombre issu de l'atelier figure dans un seul fichier du moteur, src/celeste_iod.rs, que build.rs ne compile que s'il existe, et dans les scénarios réservés au dépôt scenarios/*celeste-iod*.toml. Supprimer ce fichier et ces scénarios retire le préréglage sans modification de source ; tous les autres tests, références indépendantes et scénarios s'exécutent sans lui, et le décompte des fichiers de scénario du README compte toujours les fichiers retirés.

Vérification#

Limites#

• Le SISRE n'est qu'une erreur de représentation : il ne contient aucune erreur de détermination ou de prédiction d'orbite.
• La vérité est une intégration de Kshana (sans troisième corps, pression de radiation solaire ni marées), et non l'orbite précise d'un satellite réel.
• Le format binaire et le bloc de type RINEX sont propres à Kshana.
• NeQuick-G est transporté, non intégré en un retard ; aucune correction pour un satellite situé à l'intérieur de l'ionosphère.
• La comparaison avec Liu et al. diffère par les orbites, la lecture des paramètres et les pondérations.