LEO-Navigationsnachricht

Der Szenariotyp leo-navmsg baut die Rundsende-Nachricht aus Ephemeride und Uhr eines Satelliten für Positionierung, Navigation und Zeitgebung (PNT) im niedrigen Erdorbit (LEO) und beantwortet die Fragen, die sich ein Nachrichtenentwickler stellt: Wie lange kann eine Nachricht gelten, was bringt jeder zusätzliche Parameter, was sieht ein Nutzer, wenn sich die Nachricht mitten in einem Überflug ändert, und wie viele Bit braucht es, um sie auf den Zentimeter genau zu übertragen.

Er ist systemunabhängig. Jede Bahn, jeder Träger und jedes der vier Ephemeridenmodelle laufen ganz ohne Voreinstellung; die benannten Voreinstellungen sind optionale Daten (siehe Voreinstellungen).

Ein mitgeliefertes Beispiel mit kshana example <name> ausgeben (ein Name je Aufruf) und mit kshana scenarios/<name>.toml ausführen: leo-navmsg-fit-interval-trade, leo-navmsg-model-comparison, leo-navmsg-midpass-update und leo-navmsg-encode-decode. Der Typ ist außerdem die Nachrichtenstufe des Typs leo-pnt-chain (LEO-PNT.md) und ein Mitglied der Kampagne leo-focus-data-services, die vier Nachrichtenkonfigurationen zusammensetzt und die Rahmenlänge jeder einzelnen berichtet (146, 154, 159 und 171 Bytes).

Code: src/leo_navmsg/ — elements.rs (Datensätze und Nutzeralgorithmus), truth.rs (wahre Bahn und Uhr), fit.rs (Anpassung), sisre.rs (Entfernungsfehler im Signal im Raum), services.rs (Ionosphäre und koordinierte Weltzeit (UTC)), codec.rs (Binärformat), text.rs (Exporte im Stil von Receiver Independent Exchange Format (RINEX) und als kommagetrennte Werte (CSV)), presets/ (eine Datei je Voreinstellung), mod.rs (der Typ).

Was eine Nachricht enthält#

Ephemeridenmodelle#

Der Nutzeralgorithmus (elements::sat_state) ist die Abfolge des Galileo-ICD (Kepler-Gleichung, Korrekturen zweiter Harmonischer, erdfester Knoten), gefolgt, für kepler-rac, von den drei Polynomen im eigenen Bezugssystem der Kepler-Bahn: radial entlang der ausgewerteten Position, quer zur Bahn entlang der Bahnnormalen aus korrigierter Inklination und korrigiertem Knoten, längs der Bahn als Ergänzung zum Dreibein. Die Uhr fügt den relativistischen Term des ICD F·e·√A·sin E hinzu; für ecef-poly ist es die allgemeine Form −2 r·v / c² aus dem Polynom und seiner Ableitung.

Die Terme nach Liu et al. folgen dem Nutzeralgorithmus der Veröffentlichung (Abschnitt 2,2, Gl. 1-7): A = A0 + ȧ·tk, n = √(μ/A0³) + Δn + ṅ·tk (Versionen vor 0,30 verwendeten die Konvention der zivilen Navigation des Global Positioning System (GPS) ½·ṅ·tk, sodass ein von ihnen geschriebenes ṅ das Doppelte desjenigen der Veröffentlichung ist), und Crs1·sin Φ + Crc1·cos Φ + Crs3·sin 3Φ + Crc3·cos 3Φ, zum Radius addiert, Φ ist das unkorrigierte Breitenargument. Die Skalierungskonvention von ṅ ist aus Gl. 1 der Veröffentlichung übernommen; der Vergleich mit der Veröffentlichung an realen Bahnen hängt nicht davon ab (ein Faktor ½ auf ṅ lässt jede angepasste Zahl unverändert), sodass die Bedeutung eines übertragenen nDot-Wertes dort nicht validiert ist.

Zwei Auslegungen stammen von Kshana selbst und sind als solche angegeben:

• Das RAC-Bezugssystem und die Normierung τ = tk / tau_s. Kein öffentliches Dokument definiert ein LEO-Korrekturbezugssystem für eine Rundsende-Nachricht.
• Die Uhr einer Zero-Clock-Nachricht ist insgesamt null: Es wird angenommen, dass die Steuerschleife die scheinbare Uhr, einschließlich des relativistischen Terms, auf der Systemzeit hält.

Die Anpassung#

truth.rs integriert die Bahn mit einem Runge-Kutta vierter Ordnung fester Schrittweite in einem Bezugssystem, das durch eine einzige Drehung in erdfeste Achsen übergeht, θ(t) = θ0 + Ω̇e·t, dieselbe einzelne Drehung, die ein Rundsende-Nutzeralgorithmus anwendet. Die Gravitation ist Zweikörper (gravity_degree = 0), die zonalen Harmonischen J2 bis J6 (2 bis 6) oder das Feld des Earth Gravitational Model 2008 (EGM2008) bis Grad und Ordnung 7 bis 70, dessen tesserale Terme die kurzperiodische Signatur tragen, die eine LEO-Anpassung schwer macht. Der Luftwiderstand ist optional (statische exponentielle Dichte). Die Uhr ist freilaufend (Versatz, Drift, Driftrate und weißes Frequenzrauschen bei einer angegebenen Allan-Abweichung von einer Sekunde, dazu der periodische relativistische Term) oder gesteuert (ein Gauß-Markov-Rest erster Ordnung).

fit.rs passt den Kepler-Satz mit Levenberg–Marquardt an nichtsinguläre Elemente an (e·cos ω, e·sin ω, λ0 = M0 + ω): Eine LEO-Bahn ist nahezu kreisförmig, sodass ω und M0 allein kaum zu unterscheiden sind. Sie beginnt beim oskulierenden Zustand bei toe mit der J2-Knotenrate. Schwache, auf null zentrierte A-priori-Werte begrenzen die Raten und Harmonischen, die ein kurzer Bogen nicht auflösen kann; mit einem Beobachtungsgewicht von 1 cm wirken sie nur in diesen Nullrichtungen. Die Anpassung liu22 übernimmt stattdessen Start und Schätzer aus Abschnitt 2,3 der Veröffentlichung: Sie beginnt mit allen Korrekturtermen null, hat keine A-priori-Werte (einfache Methode der kleinsten Quadrate) und behält die Obergrenze von 100 Iterationen der Veröffentlichung. Sie endet nach Kshanas eigener Regel zur Parameterkonvergenz, wenn jeder Parameterschritt unter 1e-3 seiner formalen Standardabweichung liegt; die Veröffentlichung endet stattdessen, wenn sich der RMS um weniger als 0,1 mm ändert. Die RAC-Polynome werden dann durch lineare Methode der kleinsten Quadrate an die Residuen längs/quer/radial angepasst, und das Uhrenpolynom an die wahre Uhr abzüglich des relativistischen Terms, den der Nutzer wieder hinzufügt.

Ein Befund, den die Standardwerte abbilden: Nach einer Kepler-Anpassung nach der Methode der kleinsten Quadrate ist das Residuum konstruktionsbedingt das, was die 16 Parameter nicht abdecken können; es schwingt daher über das Fenster (mehrere Nulldurchgänge in jeder Komponente), statt zu driften. Ein Korrekturpolynom beseitigt es nur, wenn sein Grad höher ist als das, was der Kepler-Satz bereits abdeckt: Längs der Bahn 7, quer zur Bahn 5 und radial 6 bringen ein 15-Minuten-Residuum von Zentimetern auf etwa einen Millimeter, während niedrigere Grade quer zur Bahn fast nichts beseitigen (das Residuum quer zur Bahn ist ungerade um die Fenstermitte). Ein System, das seinen Kepler-Anteil auf andere Weise ableitet, hinterlässt ein Residuum anderer Form, und die Grade, die es braucht, ergeben sich daraus. Die eigenen Korrekturgrade der Voreinstellung Celeste (niedriger als diese; sie stehen nur in der Voreinstellungsdatei src/celeste_iod.rs) laufen hier auf Kshanas Basis nach der Methode der kleinsten Quadrate, weshalb ihre Terme quer zur Bahn in dieser Engine wenig beitragen: eine Aussage über Kshanas Anpassung, nicht über irgendein reales System. toe und toc sind ganze Sekunden, so wie das Binärformat sie trägt.

Jede Nachricht wird über einen Zeitraum verwendet, der in ihrem Anpassungsfenster zentriert ist (die erste Abwägungstabelle verwendet das ganze Fenster). Die Zahlen zum Entfernungsfehler im Signal im Raum (SISRE) messen den Darstellungsfehler der Nachricht gegenüber der Wahrheit, an die sie angepasst wurde, als quadratischen Mittelwert (RMS) und als Maximum über die Spanne. Der Fehler von Bahnbestimmung und Bahnvorhersage, den ein reales Boden- oder Bordsegment zusätzlich hinzufügt, ist nicht modelliert.

Entfernungsfehler im Signal im Raum#

sisre.rs verwendet den global gemittelten SISRE von Montenbruck, Steigenberger und 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²) )

Die Gewichte sind die Mittelwerte über Nutzer, die gleichmäßig auf der sichtbaren Erdkappe verteilt sind, von cos² η und ½ sin² η, wobei η der Nadirwinkel der Sichtlinie am Satelliten ist, berechnet für den eigenen Radius und die eigene Elevationsmaske der Bahn. Bei einer Maske von 0° reproduziert die Berechnung die Tabelle der Veröffentlichung für die mittlere Erdumlaufbahn (GPS 0,98 und 1/49, GLONASS 1/45, Galileo 1/61, BeiDou 1/54) und die geostationäre Bahn (0,99 und 1/126): Das ist die VALIDATED-Prüfung. Im LEO ergibt derselbe Mittelwert

sodass ein LEO-Nutzer, der den Satelliten weit vom Nadir entfernt sieht, Fehler längs und quer zur Bahn viel stärker spürt als ein Nutzer in mittlerer Umlaufbahn.

Analysen#

analysis = [...] wählt beliebige der vier aus (Standard: alle).

Abwägung des Anpassungsintervalls#

[trade] legt die Spanne, die Anpassungsintervalle, die Aktualisierungsperioden und die Modelle fest. scenarios/leo-navmsg-fit-interval-trade.toml (550 km, 97,6°, EGM2008 bis Grad 20 und Luftwiderstand, 30 Minuten Nachrichten) ergibt, bei einer Nutzungsdauer gleich dem Anpassungsintervall:

Und bei einer Anpassung von 300 s, wobei variiert wird, wie oft eine neue Nachricht übernimmt:

Der 16-Parameter-Kepler-Satz verschlechtert sich von 0,04 cm bei 60 s auf 9,35 cm bei 900 s: Ein Kepler-Satz mit Harmonischen zweimal je Umlauf kann den höherfrequenten Gravitationstermen und dem Luftwiderstand eines LEO-Bogens nicht länger als wenige Minuten folgen, und sein Residuum nach der Methode der kleinsten Quadrate schwingt über das Fenster. Die Polynome längs/quer/radial (Grade 7, 5, 6) nehmen auf, was übrig bleibt: 1,01 cm bei 900 s, 0,21 cm bei 600 s. Bei den kürzesten Intervallen liegen die Kepler-Zahlen im Submillimeterbereich und sind nicht mehr streng geordnet (die Anpassung ist dann durch die Konditionierung begrenzt, nicht durch das Modell).

Modellvergleich#

scenarios/leo-navmsg-model-comparison.toml lässt die vier Modelle bei 1, 5 und 10 Minuten auf derselben Bahn laufen, mit der Zahl der Parameter und den Bits für Ephemeride und Uhr in Kshanas Kodierung:

Die Zeile mit Zero-Clock wird gegen eine Uhr bewertet, die mit einem Residuum von 0,24 m gesteuert wird (die ATOMIC-Zahl), die anderen gegen die freilaufende Uhr, die sie anpassen.

Liu et al. 2025, SISRE gegenüber der Höhe (MODELLED). Dasselbe Szenario passt Kshanas 22-Parameter-Modell über 20-Minuten-Bögen in den fünf Höhen der Veröffentlichung an, jeweils bei der Inklination des Satelliten:

Das ist keine Validierung. Die Veröffentlichung hat reale präzise wissenschaftliche Bahnen der genannten Satelliten angepasst (mit ihrer vollen Gravitations-, Luftwiderstands- und nichtgravitativen Vorgeschichte); Kshana passt seine eigene integrierte Bahn an, wertet die sechs hinzugefügten Parameter wie oben beschrieben aus und verwendet seine eigenen SISRE-Gewichte. Der Vergleich zeigt den Trend und die Größenordnung. Der Vergleich an denselben realen Bahnen, die die Veröffentlichung angepasst hat, ist tests/leo_navmsg_fit_real_orbit_oracle.rs (seit 0,30 stimmt die 22-Parameter-Anpassung dort innerhalb des vorab festgelegten Faktors 1,5 überein, an den Tagen der Veröffentlichung und an acht zurückgehaltenen Tagen).

Aktualisierung mitten im Überflug#

[midpass] platziert einen Nutzer (Standard 45° N, 10° O), findet den höchsten Überflug über der Maske innerhalb von search_s und plant Nachrichten alle update_period_s. Bei jedem Wechsel innerhalb des Überflugs berichtet es den Positionssprung, den Uhrensprung, den Pseudoentfernungssprung des Nutzers (neue Nachricht minus alte), den größten Sprung, den ein sichtbarer Nutzer sehen könnte (geschlossene Form über den Nadirkegel), den Entfernungsfehler davor und danach sowie PASS oder FAIL gegen threshold_m. scenarios/leo-navmsg-midpass-update.toml (300-s-Anpassungen, alle 150 s aktualisiert):

Der höchste Überflug eines Tages erreicht 43,7° und dauert 455 s. Seine Wechsel:

Größter Entfernungssprung des Nutzers 0,35 mm gegen eine Schwelle von 5 cm: PASS.

Kodieren und Dekodieren#

scenarios/leo-navmsg-encode-decode.toml kodiert die erste von drei Nachrichten, dekodiert sie, prüft die CRC und weist eine beschädigte Kopie zurück, gibt das Quantisierungsbudget aus und schreibt und liest den Block im RINEX-Stil sowie die CSV-Tabelle zurück:

• Rahmen: 171 Bytes (1310 Nutzdatenbits, davon 1045 für Ephemeride und Uhr), 24-Bit-Prüfsumme (zyklische Redundanzprüfung, CRC-24Q) 0x19105F;
• größte Halbschrittwirkung eines einzelnen Feldes: af0, 0,545 mm;
• ganze Nachricht nach der Quantisierung: Position innerhalb von 1,126 mm und Uhr innerhalb von 0,185 mm der exakten Nachricht; SISRE 0,113 cm exakt, 0,129 cm dekodiert;
• ein Rahmen mit einem gekippten Bit wird zurückgewiesen: true;
• Hin-und-zurück-Lauf im RINEX-Stil innerhalb von 5.0e-06 m, Hin-und-zurück-Lauf der CSV innerhalb von 0.0e+00 m.

Plattformunabhängigkeit#

Ein Rahmen besteht aus übertragenen ganzen Zahlen, also müssen es dieselben ganzen Zahlen sein, wo und wie auch immer das Szenario läuft: das native Binärprogramm auf jedem Betriebssystem, ein Debug- oder ein Release-Build und der WebAssembly-Build (WASM) in einem Browser. Drei Dinge standen im Weg. Sinus, Kosinus, Arkustangens und Exponentialfunktion der Mathematikbibliothek eines Rechners müssen nicht korrekt gerundet sein und unterscheiden sich zwischen Rechnern in der letzten Stelle. Ein optimierter Build auf macOS nimmt Sinus und Kosinus eines Arguments aus der kombinierten Routine des Systems, die nicht immer den Wert des einzelnen Sinus liefert, sodass sich auch ein Debug- und ein Release-Build unterschieden. Und der übliche Normalverteilungs-Sampler ruft in seinen seltenen Zweigen die Exponential- und Logarithmusfunktion des Rechners auf. Die Anpassung macht aus einem so kleinen Unterschied andere quantisierte Felder. Der gesamte Typ (wahre Bahn und Uhr, Anpassung, Nutzeralgorithmus, Entfernungsfehler im Signal im Raum (SISRE), Codec) berechnet daher jede solche Funktion mit der reinen Rust-Bibliothek libm über src/portable_math.rs, ganzzahlige Potenzen als ausdrückliche Produkte und normalverteilte Abweichungen nach dem Polarverfahren aus der Rohausgabe des Generators. leo_navmsg::tests::the_encoded_frame_is_the_same_bytes_on_every_platform legt den 171-Byte-Rahmen des unten stehenden Szenarios zum Kodieren und Dekodieren fest, dazu einen Prüfwert je Ephemeridenmodell; ein Debug-Build, ein Release-Build und der WASM-Build liefern für alle fünf mitgelieferten leo-navmsg-Szenarien byteidentische Ergebnisdokumente.

Binärformat#

Dies ist Kshanas eigene dokumentierte Kodierung. Sie trägt die Komponenten, die die veröffentlichten Beschreibungen von LEO-Navigationsnachrichten nennen, nach dem Vorbild des Galileo-ICD-Feldsatzes. Sie ist nicht das Bitlayout von Celeste oder eines anderen Systems: keines ist öffentlich.

Rahmen: Präambel 0xA7 (8 Bits), Version 1 (4), Modell (4: 1 kepler16, 2 kepler-rac, 3 liu22, 4 ecef-poly), Nutzdatenlänge in Bytes (12), auf ein Byte mit Nullen aufgefüllte Nutzdaten, CRC-24Q (eine 24-Bit-zyklische Redundanzprüfung, 24 Bits) über jedes vorangehende Byte. CRC-24Q ist die Prüfung des Standards RTCM 10403 der Radio Technical Commission for Maritime Services und des Galileo-ICD (Polynom 0x1864CFB, Anfangswert 0); der Code reproduziert den Katalog-Prüfwert 0xCDE703 für 123456789 und die Prüfbytes des Beispielrahmens RTCM 10403 Nachrichtentyp 1005 (VALIDATED).

Die Schritte des Galileo-ICD wurden für die mittlere Erdumlaufbahn gewählt und sind für eine LEO-Nachricht im Zentimeterbereich zu grob: Crs in Schritten von 2⁻⁵ m (3,1 cm), Cuc 2⁻²⁹ rad (1,3 cm beim LEO-Radius), die Winkel 2⁻³¹ Halbkreise (1,0 cm) und af0 2⁻³⁴ s (1,7 cm). Kshana behält die Einheiten des ICD und die Halbkreiskonvention bei, verfeinert die Schritte so, dass der Halbschrittfehler jedes Feldes über ein 15-Minuten-Fenster unter 1 mm Position oder Entfernung bleibt, und erweitert die Felder, um die Bereiche zu halten, die eine LEO-Anpassung braucht:

Ein Wert außerhalb des Bereichs seines Feldes wird zurückgewiesen, nicht umgebrochen. Die Bereiche wurden durch Kodieren von Anpassungen bei 300 bis 2000 km, Inklinationen von 0° bis 140° und Anpassungsintervallen bis 20 Minuten geprüft: deltaN und OmegaDot sind breit, weil auf einer nahezu äquatorialen Bahn der Knoten schlecht definiert ist und die Anpassung die J2-Drift des Breitenarguments zwischen ihnen aufteilt, und aDot und nDot, weil die 22-Parameter-Anpassung über 20 Minuten einen Teil der kurzperiodischen Schwingung der großen Halbachse aufnimmt. Seit 0,30 ist die 22-Parameter-Anpassung die einfache Methode der kleinsten Quadrate der Veröffentlichung ohne A-priori-Werte, und eine äquatoriale Anpassung bei 800 km braucht dann nDot von etwa 6.3e-10 Halbkreis/s^2, sodass ihre Skala von 2^-60 auf 2^-58 ging. Die Längs-Korrekturen vom Grad 7 von kepler-rac passen in den 22-Bit-Koeffizientenbereich bis 15 Minuten; eine längere Anpassung kann ihn überschreiten und wird dann zurückgewiesen. quantisation_budget berichtet für jedes Ephemeriden- und Uhrenfeld die größte Positions- und Entfernungsänderung, die eine Halbschrittänderung über die Nutzungsdauer bewirkt, sowie die Änderung der ganzen Nachricht nach der Quantisierung.

Textexporte#

RINEX 4,02 definiert keine LEO-Navigationsdatensätze (seine Systembuchstaben sind G, R, E, J, C, I und S; International Global Navigation Satellite System (GNSS) Service (IGS) RINEX 4,02). Der Block, den text.rs schreibt, entlehnt die Form von RINEX 4 — einen Datensatzkopf > EPH, eine Zeile zu Satellit und Epoche mit drei Uhrentermen, Zeilen der Rundsende-Bahn mit je vier D19.12-Feldern — und ist eine dokumentierte Kshana-Erweiterung: Systembuchstabe L, Datensatztypen KP16, KRAC, LU22, APOL und drei Kopfkommentare, die das sagen. Vorarbeiten zu LEO-Bahnen in Navigationsdatensätzen im Stil von 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

Die CSV-Tabelle trägt Nachrichten der Modelle kepler16 und kepler-rac, eine je Zeile. Die Standardspalten verwenden die Namen des Galileo-ICD (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 wählt stattdessen die Schreibweise einer Voreinstellung. Beide Formate lassen sich zurücklesen.

Ionosphäre und UTC#

• Klobuchar: das L1-Modell der Engine (gnss_sim::klobuchar_delay_m, gegen RTKLIB geprüft), durch das Gesetz erster Ordnung (f_L1 / f)² auf den Träger skaliert.
• NeQuick-G: Die Koeffizienten reisen in der Nachricht, und effective_ionisation_level liefert Az = ai0 + ai1·μ + ai2·μ² für eine modifizierte Neigungsbreite μ, mit den Regeln des Algorithmus (Koeffizienten, die alle null sind, ergeben 63,7 Solarflusseinheiten, sfu; das Ergebnis wird auf [0, 400] sfu begrenzt). Das NeQuick-Elektronendichtemodell und seine Schrägintegration, die Az in eine Verzögerung umsetzen, sind nicht implementiert.
• Ein Satellit in wenigen hundert Kilometern Höhe fliegt innerhalb der Ionosphäre. Keines der beiden Rundsende-Modelle berücksichtigt den Elektronengehalt oberhalb des Satelliten, und es wird keine Korrektur dafür angewendet.
• UTC: system_to_utc wendet die drei Fälle des Galileo-ICD §5.1.7 an (vor, innerhalb von sechs Stunden um und nach einem Schaltsekundenereignis); eine eingefügte Sekunde liest 86400.

Voreinstellungen#

Voreinstellungen sind Daten, je eine Datei unter src/leo_navmsg/presets/, mit ihren Quellen. Die Engine und jedes mitgelieferte Szenario außer dem von Celeste laufen ohne sie.

RNSS ist der Funknavigationssatellitendienst; RNTF die Resilient Navigation and Timing Foundation.

Celeste IOD. Die Voreinstellung für die Celeste-Demonstration im Orbit (IOD) der Europäischen Weltraumorganisation (ESA) ist die einzige, die Material verwendet, das auf dem LEO-PNT-Workshop des ESA-Programms Navigation Innovation and Support Programme (NAVISP), 2026, vorgestellt wurde: die Nachrichtenstruktur (Galileo-Kepler-Satz plus Korrekturpolynome längs/quer/radial, Uhrenpolynom, SVID, Zustand, IOD, ionosphärische und UTC-Parameter), der Datensatzabstand und die CSV-Spaltennamen. Die Bahn (510 km, nahezu polar sonnensynchron) und der Träger stammen aus öffentlichen Quellen, die in der Datei genannt sind. Das Celeste-Bitlayout ist nicht öffentlich und wird nicht wiedergegeben; spätere Celeste-Phasen und das LEO-PNT-System der Europäischen Union (EU) können abweichen. Jeder aus dem Workshop abgeleitete Wert steht im Modul navmsg von src/celeste_iod.rs, verwendet von scenarios/leo-navmsg-celeste-iod.toml. So wird die Voreinstellung zurückgehalten: Jede aus dem Workshop abgeleitete Zahl der Engine steht in einer Datei, src/celeste_iod.rs, die build.rs nur einkompiliert, wenn sie existiert, und in den nur im Repository vorhandenen Szenarien scenarios/*celeste-iod*.toml. Das Löschen dieser Datei und dieser Szenarien hält die Voreinstellung ohne Quelltextänderung zurück; jeder andere Test, jede andere unabhängige Referenz und jedes andere Szenario läuft ohne sie, und die Zählung der Szenariodateien in der README zählt die zurückgehaltenen Dateien weiterhin mit.

Verifikation#

Einschränkungen#

• SISRE ist nur der Darstellungsfehler: kein Fehler aus Bahnbestimmung oder Bahnvorhersage.
• Die Wahrheit ist eine Kshana-Integration (ohne dritten Körper, Strahlungsdruck der Sonne oder Gezeiten), nicht die präzise Bahn eines realen Satelliten.
• Das Binärformat und der Block im RINEX-Stil sind Kshanas eigene.
• NeQuick-G wird getragen, nicht zu einer Verzögerung integriert; keine Korrektur für einen Satelliten innerhalb der Ionosphäre.
• Der Vergleich mit Liu et al. unterscheidet sich in Bahnen, Parameterdeutung und Gewichten.