LEO-navigasjonsmelding

Scenariotypen leo-navmsg bygger den kringkastede efemeride- og klokkemeldingen til en satellitt for posisjonering, navigasjon og tidssynkronisering (PNT) i lav jordbane (LEO), og svarer på spørsmålene en meldingsutvikler stiller: hvor lenge kan én melding dekke, hva gir hver ekstra parameter, hva ser en bruker når meldingen skiftes midt i en overflyging, og hvor mange bit trengs for å bære den ned til centimeteren.

Den er systemuavhengig. Enhver bane, enhver bærebølge og hver av fire efemeridemodeller kjører uten noen forhåndsinnstilling i det hele tatt; de navngitte forhåndsinnstillingene er valgfrie data (se Forhåndsinnstillinger).

Skriv ut et medfølgende eksempel med kshana example <name> (ett navn per kall) og kjør det med kshana scenarios/<name>.toml: leo-navmsg-fit-interval-trade, leo-navmsg-model-comparison, leo-navmsg-midpass-update og leo-navmsg-encode-decode. Typen er også meldingstrinnet i typen leo-pnt-chain (LEO-PNT.md) og medlem av kampanjen leo-focus-data-services, som setter sammen fire meldingskonfigurasjoner og rapporterer rammelengden for hver (146, 154, 159 og 171 bytes).

Kode: src/leo_navmsg/ — elements.rs (poster og brukeralgoritme), truth.rs (referansebane og -klokke), fit.rs (tilpasser), sisre.rs (avstandsfeil i signalet i rommet), services.rs (ionosfære og Coordinated Universal Time (UTC)), codec.rs (binærformat), text.rs (eksport i Receiver Independent Exchange Format (RINEX)-stil og som kommaseparerte verdier (CSV)), presets/ (én fil per forhåndsinnstilling), mod.rs (typen).

Hva en melding bærer#

Efemeridemodeller#

Brukeralgoritmen (elements::sat_state) er Galileo ICD-sekvensen (Keplers ligning, andreharmoniske korreksjoner, jordfast node), etterfulgt, for kepler-rac, av de tre polynomene langs Kepler-banens eget referansesystem: radielt langs den evaluerte posisjonen, på tvers av banen langs banenormalen fra den korrigerte inklinasjonen og noden, og langs banen som fullfører treleddet. Klokken legger til ICD-ens relativistiske ledd F·e·√A·sin E; for ecef-poly er det den generelle formen −2 r·v / c² fra polynomet og dets deriverte.

Leddene fra Liu et al. følger artikkelens brukeralgoritme (seksjon 2,2, ligning 1-7): A = A0 + ȧ·tk, n = √(μ/A0³) + Δn + ṅ·tk (utgivelser før 0,30 brukte sivilnavigasjonskonvensjonen i Global Positioning System (GPS) ½·ṅ·tk, så en ṅ de skrev er det dobbelte av artikkelens), og Crs1·sin Φ + Crc1·cos Φ + Crs3·sin 3Φ + Crc3·cos 3Φ lagt til radiusen, der Φ er det ukorrigerte breddeargumentet. Skalakonvensjonen for ṅ er overført fra artikkelens ligning 1; sammenligningen med artikkelen på reelle baner avhenger ikke av den (en faktor ½ på ṅ lar alle tilpassede tall være uendret), så meningen med verdien av en sendt nDot er ikke validert der.

To tolkninger er Kshanas egne og oppgis som sådan:

• RAC-referansesystemet og normaliseringen τ = tk / tau_s. Intet offentlig dokument definerer et korreksjonsreferansesystem for LEO for en kringkastet melding.
• Klokken i en nullklokkemelding er null i sum: styringssløyfen antas å holde den tilsynelatende klokken, inkludert det relativistiske leddet, mot systemtid.

Tilpasseren#

truth.rs integrerer banen med en fjerdeordens Runge–Kutta med fast steg i et referansesystem som dreies til jordfaste akser med én rotasjon, θ(t) = θ0 + Ω̇e·t, den samme ene rotasjonen en kringkastet brukeralgoritme anvender. Tyngdekraften er tolegemeproblemet (gravity_degree = 0), de sonale harmoniske J2 til J6 (2 til 6), eller feltet Earth Gravitational Model 2008 (EGM2008) til grad og orden 7 til 70, hvis tesserale ledd bærer den kortperiodiske signaturen som gjør en LEO-tilpasning vanskelig. Luftmotstand er valgfritt (statisk eksponentiell tetthet). Klokken er enten fritt gående (bias, drift, driftrate og hvit frekvensstøy ved en oppgitt Allan-deviasjon på ett sekund, pluss det periodiske relativistiske leddet) eller styrt (en førsteordens Gauss–Markov-rest).

fit.rs tilpasser Kepler-settet med Levenberg–Marquardt på ikke-singulære elementer (e·cos ω, e·sin ω, λ0 = M0 + ω): en LEO-bane er nesten sirkulær, så ω og M0 alene er nesten umulige å skille. Den starter fra den oskulerende tilstanden ved toe med J2-noderaten. Svake nullsentrerte priorer begrenser ratene og harmoniske som en kort bue ikke kan oppløse; med en observasjonsvekt på 1 cm virker de bare i disse nullretningene. Tilpasningen liu22 bruker i stedet artikkelens start og estimator fra seksjon 2,3: den starter med at alle korreksjonsledd er null, har ingen priorer (ren minste kvadraters metode) og beholder artikkelens grense på 100 iterasjoner. Den stopper etter Kshanas egen regel for parameterkonvergens, når hvert parametersteg er under 1e-3 av sitt formelle standardavvik; artikkelen stopper i stedet når RMS endres med mindre enn 0,1 mm. RAC-polynomene tilpasses deretter til residualene langs/på tvers/radielt med lineær minste kvadraters metode, og klokkepolynomet til referanseklokken minus det relativistiske leddet brukeren legger til igjen.

Et funn som standardverdiene koder: etter en Kepler-tilpasning med minste kvadrater er residualet per konstruksjon det de 16 parameterne ikke kan spenne over, så det oscillerer over vinduet (flere nullgjennomganger i hver komponent) i stedet for å drive. Et korreksjonspolynom fjerner det bare når graden overstiger det Kepler-settet allerede spenner over: langs banen 7, på tvers 5 og radielt 6 tar et residual på 15 minutter fra centimeter til omtrent én millimeter, mens lavere grader på tvers nesten ikke fjerner noe (residualet på tvers er odde om vindussenteret). Et system som utleder sin Kepler-del på en annen måte, etterlater et residual med en annen form, og gradene det trenger følger av det. Celeste-forhåndsinnstillingens egne korreksjonsgrader (lavere enn disse; de finnes bare i forhåndsinnstillingsfilen, src/celeste_iod.rs) kjører her på Kshanas minste kvadraters grunnlag, og det er grunnen til at leddene på tvers bidrar lite i denne motoren: en uttalelse om Kshanas tilpasser, ikke om noe reelt system. toe og toc er hele sekunder, slik binærformatet bærer dem.

Hver melding brukes over en periode sentrert i sitt tilpasningsvindu (den første avveiningstabellen bruker hele vinduet). Det tallene for avstandsfeil i signalet i rommet (SISRE) måler, er meldingens representasjonsfeil mot referansen den ble tilpasset, som rotmiddelkvadrat (RMS) og et maksimum over spennet. Feilen i banebestemmelse og banepredikering, som et reelt bakke- eller ombordsegment legger til ovenpå, er ikke modellert.

Avstandsfeil i signalet i rommet#

sisre.rs bruker den globalt midlede SISRE-verdien til Montenbruck, Steigenberger og 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²) )

Vektene er gjennomsnittene over brukere jevnt fordelt på den synlige jordkalotten av cos² η og ½ sin² η, der η er nadirvinkelen til siktelinjen ved satellitten, beregnet for banens egen radius og elevasjonsmaske. Ved en maske på 0° gjengir beregningen artikkelens tabell for middels jordbane (GPS 0,98 og 1/49, GLONASS 1/45, Galileo 1/61, BeiDou 1/54) og geostasjonær bane (0,99 og 1/126): det er den VALIDATED kontrollen. I LEO gir det samme gjennomsnittet

så en LEO-bruker, som ser satellitten langt fra nadir, merker feil langs og på tvers av banen mye mer enn en bruker i middels bane.

Analyser#

analysis = [...] velger en vilkårlig av de fire (standard alle).

Avveining av tilpasningsintervall#

[trade] setter spennet, tilpasningsintervallene, oppdateringsperiodene og modellene. scenarios/leo-navmsg-fit-interval-trade.toml (550 km, 97,6°, EGM2008 til grad 20 og luftmotstand, 30 minutter med meldinger) gir, med bruksperioden lik tilpasningsintervallet:

Og med en tilpasning på 300 s, der det varieres hvor ofte en ny melding tar over:

Kepler-settet med 16 parametere forringes fra 0,04 cm ved 60 s til 9,35 cm ved 900 s: ett Kepler-sett med harmoniske to ganger per omløp kan ikke følge de høyfrekvente gravitasjonsleddene og luftmotstanden til en LEO-bue i mer enn noen få minutter, og dets minste kvadraters residual oscillerer over vinduet. Polynomene langs/på tvers/radielt (grader 7, 5, 6) absorberer det som er igjen: 1,01 cm ved 900 s, 0,21 cm ved 600 s. Ved de korteste intervallene er Kepler-tallene under en millimeter og ikke lenger strengt ordnet (tilpasningen er da begrenset av kondisjoneringen, ikke av modellen).

Modellsammenligning#

scenarios/leo-navmsg-model-comparison.toml kjører de fire modellene ved 1, 5 og 10 minutter på samme bane, med antall parametere og efemeride- og klokkebitene i Kshanas koding:

Nullklokke-raden vurderes mot en klokke styrt med en rest på 0,24 m (ATOMIC-tallet), de andre mot den fritt gående klokken de tilpasser.

Liu et al. 2025, SISRE mot høyde (MODELLED). Det samme scenarioet tilpasser Kshanas modell med 22 parametere over buer på 20 minutter ved artikkelens fem høyder, ved hver satellitts inklinasjon:

Dette er ikke en validering. Artikkelen tilpasset reelle presise vitenskapelige baner for de navngitte satellittene (med full gravitasjons-, luftmotstands- og ikke-gravitasjonshistorikk); Kshana tilpasser sin egen integrerte bane, evaluerer de seks tilføyde parameterne som beskrevet ovenfor, og bruker egne SISRE-vekter. Sammenligningen viser trenden og størrelsesordenen. Sammenligningen på de samme reelle banene artikkelen tilpasset er tests/leo_navmsg_fit_real_orbit_oracle.rs (siden 0,30 stemmer tilpasningen med 22 parametere der innenfor den forhåndsregistrerte faktoren 1,5, på artikkelens dager og på åtte tilbakeholdte dager).

Oppdatering midt i overflygingen#

[midpass] plasserer en bruker (standard 45° N, 10° Ø), finner den høyeste overflygingen over masken innenfor search_s, og planlegger meldinger hver update_period_s. Ved hvert skifte inne i overflygingen rapporterer den posisjonshoppet, klokkehoppet, brukerens pseudoavstandshopp (ny melding minus gammel), det største hoppet en synlig bruker kan se (lukket form over nadirkjeglen), avstandsfeilen før og etter, og PASS eller FAIL mot threshold_m. scenarios/leo-navmsg-midpass-update.toml (tilpasninger på 300 s oppdatert hver 150 s):

Den høyeste overflygingen i løpet av et døgn når 43,7° og varer 455 s. Skiftene:

Største hopp i brukeravstand 0,35 mm mot en terskel på 5 cm: PASS.

Koding og dekoding#

scenarios/leo-navmsg-encode-decode.toml koder den første av tre meldinger, dekoder den, kontrollerer CRC-en og avviser en ødelagt kopi, skriver ut kvantiseringsbudsjettet, og skriver og leser tilbake RINEX-lignende blokken og CSV-tabellen:

• ramme: 171 bytes (1310 nyttelastbiter, hvorav 1045 er efemeride og klokke), 24-bits syklisk redundanskontroll (CRC-24Q) 0x19105F;
• største halvtrinnseffekt av et enkelt felt: af0, 0,545 mm;
• hele meldingen etter kvantisering: posisjon innenfor 1,126 mm og klokke innenfor 0,185 mm av den eksakte meldingen; SISRE 0,113 cm eksakt, 0,129 cm dekodet;
• en ramme med én snudd bit avvises: true;
• RINEX-lignende rundtur innenfor 5.0e-06 m, CSV-rundtur innenfor 0.0e+00 m.

Plattformuavhengighet#

En ramme er sendte heltall, så det må være de samme heltallene uansett hvor og hvordan scenarioet kjøres: den native binærfilen på et hvilket som helst operativsystem, et debug- eller et release-bygg, og WebAssembly-bygget (WASM) i en nettleser. Tre ting sto i veien. Sinus, cosinus, arcustangens og eksponentialfunksjon i en verts matematikkbibliotek er ikke pålagt å være korrekt avrundet, og de er forskjellige mellom verter i siste siffer. Et optimalisert bygg på macOS henter sinus og cosinus av ett argument fra systemets kombinerte rutine, som ikke alltid gir samme verdi som sinus alene, så et debug- og et release-bygg avvek også fra hverandre. Og den vanlige normalfordelingssampleren kaller vertens eksponential- og logaritmefunksjon i sine sjeldne grener. Tilpasningen gjør en så liten forskjell om til andre kvantiserte felt. Hele scenariotypen (referansebane og -klokke, tilpasning, brukeralgoritme, avstandsfeil i signal i rommet (SISRE), kodek) beregner derfor hver slik funksjon med den rene Rust-biblioteket libm via src/portable_math.rs, heltallspotenser som eksplisitte produkter, og normalfordelte avvik med polarmetoden på generatorens rå utdata. leo_navmsg::tests::the_encoded_frame_is_the_same_bytes_on_every_platform låser den 171 byte lange rammen i kode-og-dekode-scenarioet nedenfor og én kontrollverdi per efemeridemodell; et debug-bygg, et release-bygg og WASM-bygget gir byte-identiske resultatdokumenter for alle fem medfølgende leo-navmsg-scenarioer.

Binærformat#

Dette er Kshanas egen dokumenterte koding. Den bærer komponentene som de publiserte beskrivelsene av LEO-navigasjonsmeldinger nevner, modellert etter Galileo ICD-feltsettet. Den er ikke bitoppsettet til Celeste eller noe annet system: ingen av dem er offentlige.

Ramme: preamble 0xA7 (8 biter), versjon 1 (4), modell (4: 1 kepler16, 2 kepler-rac, 3 liu22, 4 ecef-poly), nyttelastlengde i bytes (12), nyttelast nullutfylt til en byte, CRC-24Q (en 24-bits syklisk redundanskontroll, 24 biter) over hver foregående byte. CRC-24Q er kontrollen i standarden RTCM 10403 fra Radio Technical Commission for Maritime Services og i Galileo ICD (polynom 0x1864CFB, startverdi 0); koden gjengir katalogens kontrollverdi 0xCDE703 for 123456789 og kontrollbytene i RTCM 10403-eksempelrammen for meldingstype 1005 (VALIDATED).

Galileo ICD-trinnene ble valgt for middels høy jordbane og er for grove for en LEO-melding på centimeternivå: Crs i trinn på 2⁻⁵ m (3,1 cm), Cuc 2⁻²⁹ rad (1,3 cm ved LEO-radius), vinklene 2⁻³¹ semisirkler (1,0 cm) og af0 2⁻³⁴ s (1,7 cm). Kshana beholder ICD-enhetene og semisirkelkonvensjonen, forfiner trinnene slik at halvtrinnsfeilen i hvert felt holder seg under 1 mm i posisjon eller avstand over et 15-minutters vindu, og utvider feltene for å dekke områdene en LEO-tilpasning trenger:

En verdi utenfor feltets område avvises, den bretter seg ikke rundt. Områdene ble kontrollert ved å kode tilpasninger på 300 til 2000 km, banehellinger fra 0° til 140° og tilpasningsintervaller på opptil 20 minutter: deltaN og OmegaDot er brede fordi knutepunktet er dårlig definert i en bane nær ekvator og tilpasningen fordeler J2-driften i breddeargumentet mellom dem, og aDot og nDot fordi 22-parametertilpasningen over 20 minutter tar opp en del av den korte perioden i svingningen av store halvakse. Siden 0,30 er 22-parametertilpasningen artikkelens rene minste kvadraters metode uten forhåndsinformasjon, og en ekvatorial tilpasning på 800 km trenger da nDot på omtrent 6.3e-10 semisirkel/s^2, så skalaen gikk fra 2^-60 til 2^-58. De langsgående korreksjonene av grad 7 i kepler-rac passer inn i 22-biters koeffisientområdet opptil 15 minutter; en lengre tilpasning kan overskride det og avvises da. quantisation_budget rapporterer, for hvert efemeride- og klokkefelt, den største endringen i posisjon og avstand som en halvtrinnsendring gir over bruksperioden, og endringen i hele meldingen etter kvantisering.

Teksteksport#

RINEX 4,02 definerer ingen LEO-navigasjonsposter (systembokstavene er G, R, E, J, C, I og S; International Global Navigation Satellite System (GNSS) Service (IGS) RINEX 4,02). Blokken som text.rs skriver låner RINEX 4-formen — en > EPH-posthode, en linje med satellitt og epoke med tre klokkeledd, linjer med kringkastet bane på fire D19.12-felt — og er en dokumentert Kshana-utvidelse: systembokstav L, posttypene KP16, KRAC, LU22, APOL, og tre hodekommentarer som sier det. Tidligere arbeid om LEO-baner i navigasjonsposter i RINEX-4-stil: 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

CSV-tabellen bærer meldingene kepler16 og kepler-rac, én per rad. Standardkolonnene bruker Galileo ICD-navnene (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 velger i stedet stavemåten til en forhåndsinnstilling. Begge formatene kan leses tilbake.

Ionosfære og UTC#

• Klobuchar: motorens L1-modell (gnss_sim::klobuchar_delay_m, kontrollert mot RTKLIB) skalert til bærebølgen med førsteordens-loven (f_L1 / f)².
• NeQuick-G: koeffisientene følger med i meldingen, og effective_ionisation_level returnerer Az = ai0 + ai1·μ + ai2·μ² for en modifisert dip-breddegrad μ, med algoritmens regler (koeffisienter som alle er null gir 63,7 solfluksenheter, sfu; resultatet begrenses til [0, 400] sfu). NeQuick-elektrontetthetsmodellen og dens integrasjon langs siktlinjen, som gjør Az om til en forsinkelse, er ikke implementert.
• En satellitt på noen hundre kilometers høyde flyr inne i ionosfæren. Ingen av de to kringkastede modellene tar hensyn til elektroninnholdet over satellitten, og det anvendes ingen korreksjon for det.
• UTC: system_to_utc anvender de tre tilfellene i Galileo ICD §5.1.7 (før, innen seks timer av og etter en skuddsekundhendelse); et innsatt sekund leses som 86400.

Forhåndsinnstillinger#

Forhåndsinnstillinger er data, én fil hver under src/leo_navmsg/presets/, med kildene sine. Motoren og alle medfølgende scenarioer unntatt Celeste-scenarioet kjører uten dem.

RNSS er radionavigasjonssatellitttjenesten; RNTF er Resilient Navigation and Timing Foundation.

Celeste IOD. Forhåndsinnstillingen for Celeste-demonstrasjonen i bane (IOD) fra Den europeiske romorganisasjonen (ESA) er den eneste som bruker materiale presentert på ESA Navigation Innovation and Support Programme (NAVISP) LEO-PNT-workshopen, 2026: meldingsstrukturen (Galileos Kepler-sett pluss korreksjonspolynomer langs/på tvers/radielt, klokkepolynom, SVID, helse, IOD, ionosfære- og UTC-parametere), postavstanden og CSV-kolonnenavnene. Banen (510 km, nesten polar solsynkron) og bærebølgen kommer fra offentlige kilder som er oppgitt i filen. Celestes bitoppsett er ikke offentlig og gjengis ikke; senere Celeste-faser og EUs LEO-PNT-system kan avvike. Hver verdi som stammer fra workshopen ligger i modulen navmsg i src/celeste_iod.rs, brukt av scenarios/leo-navmsg-celeste-iod.toml. Slik holdes forhåndsinnstillingen tilbake: hvert tall fra workshopen i motoren ligger i én fil, src/celeste_iod.rs, som build.rs bare kompilerer inn når den finnes, og i scenarioene scenarios/*celeste-iod*.toml som bare finnes i repositoriet. Når den filen og de scenarioene slettes, holdes forhåndsinnstillingen tilbake uten kildeendring; alle andre tester, uavhengige referanser og scenarioer kjører uten den, og antallet scenariofiler i README teller fortsatt de tilbakeholdte filene.

Verifikasjon#

Begrensninger#

• SISRE er bare representasjonsfeil: ingen feil fra banebestemmelse eller prediksjon.
• Referansen er en Kshana-integrasjon (uten tredjelegeme, solstrålingstrykk eller tidevann), ikke den presise banen til en virkelig satellitt.
• Binærformatet og den RINEX-lignende blokken er Kshanas egne.
• NeQuick-G bæres med, men integreres ikke til en forsinkelse; ingen korreksjon for en satellitt inne i ionosfæren.
• Sammenligningen med Liu et al. avviker i baner, tolkning av parametere og vekter.