LEO-navigationsbesked

Scenarietypen leo-navmsg bygger den udsendte efemeride- og urmeddelelse for en PNT-satellit (positionering, navigation og tidssynkronisering) i lav jordbane (LEO) og besvarer de spørgsmål, en meddelelsesudformer stiller: hvor længe kan én meddelelse dække, hvad køber hver ekstra parameter, hvad ser en bruger, når meddelelsen skifter midt i en passage, og hvor mange bits kræver det at bære den til centimeteren.

Den er systemuafhængig. Enhver bane, enhver bærebølge og enhver af fire efemeridemodeller kører helt uden forudindstilling; de navngivne forudindstillinger er valgfrie data (se Presets).

Udskriv et medfølgende eksempel med kshana example <name> (ét navn pr. kald) og kø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å meddelelsestrinnet i typen leo-pnt-chain (LEO-PNT.md) og medlem af kampagnen leo-focus-data-services, som sammensætter fire meddelelseskonfigurationer og rapporterer hver ens rammelængde (146, 154, 159 og 171 bytes).

Kode: src/leo_navmsg/ — elements.rs (poster og brugeralgoritme), truth.rs (sand bane og sandt ur), fit.rs (tilpasningsrutine), sisre.rs (afstandsfejl for signal i rummet), services.rs (ionosfære og Coordinated Universal Time (UTC)), codec.rs (binært format), text.rs (eksport i Receiver Independent Exchange Format (RINEX)-stil og kommasepareret (CSV) form), presets/ (én fil pr. forudindstilling), mod.rs (selve typen).

Hvad en meddelelse indeholder#

Efemeridemodeller#

Brugeralgoritmen (elements::sat_state) er Galileo-ICD-sekvensen (Keplers ligning, andenharmoniske korrektioner, jordfast knude) efterfulgt, for kepler-rac, af de tre polynomier langs den Keplerske banes eget system: radialt langs den evaluerede position, på tværs af banen langs banenormalen ud fra den korrigerede inklinering og knude, langs banen, så triaden fuldføres. Uret tilføjer ICD'ets relativistiske led F·e·√A·sin E; for ecef-poly er det den generelle form −2 r·v / c² ud fra polynomiet og dets afledede.

Leddene fra Liu et al. følger artiklens brugeralgoritme (Section 2,2, Eq. 1-7): A = A0 + ȧ·tk, n = √(μ/A0³) + Δn + ṅ·tk (udgivelser før 0,30 brugte konventionen for Global Positioning System (GPS) civil navigation ½·ṅ·tk, så en ṅ, de skrev, er det dobbelte af artiklens), og Crs1·sin Φ + Crc1·cos Φ + Crs3·sin 3Φ + Crc3·cos 3Φ lagt til radius, Φ det ukorrigerede breddegradsargument. Skalakonventionen for ṅ er afskrevet fra artiklens Eq. 1; sammenligningen med artiklen på reelle baner afhænger ikke af den (en faktor ½ på ṅ lader alle tilpassede tal være uændrede), så betydningen af en udsendt nDot-værdi er ikke valideret dér.

To aflæsninger er Kshanas egne og angives som sådan:

• RAC-systemet og normaliseringen τ = tk / tau_s. Intet offentligt dokument definerer et korrektionssystem for LEO til en udsendt meddelelse.
• Et nul-urs meddelelse har i alt nul ur: styresløjfen antages at holde det tilsyneladende ur, relativistisk led inklusive, på systemtid.

Tilpasningsrutinen#

truth.rs integrerer banen med en fjerdeordens Runge–Kutta med fast trin i et system, der drejes over i jordfaste akser ved én rotation, θ(t) = θ0 + Ω̇e·t, den samme enkelte rotation, som en udsendt brugeralgoritme anvender. Tyngdekraften er tolegeme (gravity_degree = 0), de zonale harmoniske J2 til J6 (2 til 6), eller feltet Earth Gravitational Model 2008 (EGM2008) til grad og orden 7 til 70, hvis tesserale led bærer det kortperiodiske aftryk, der gør en LEO-tilpasning svær. Luftmodstand er valgfri (statisk eksponentiel massefylde). Uret er frit løbende (bias, drift, driftrate og hvid frekvensstøj ved en angiven Allan-deviation på ét sekund, plus det periodiske relativistiske led) eller styret (en førsteordens Gauss–Markov-residual).

fit.rs tilpasser det Keplerske sæt med Levenberg–Marquardt på ikke-singulære elementer (e·cos ω, e·sin ω, λ0 = M0 + ω): en LEO-bane er næsten cirkulær, så ω og M0 hver for sig er næsten umulige at skelne. Den starter fra den oskulerende tilstand ved toe med J2-knuderaten. Svage nul-centrerede apriorier begrænser de rater og harmoniske, som en kort bue ikke kan opløse; med en observationsvægt på 1 cm virker de kun i disse nulretninger. Tilpasningen liu22 tager i stedet artiklens Section 2,3 start og estimator: den starter med alle korrektionsled lig nul, har ingen apriorier (almindelig mindste kvadraters metode) og beholder artiklens loft på 100 iterationer. Den stopper efter Kshanas egen konvergensregel for parametre, når hvert parametertrin er under 1e-3 af dets formelle standardafvigelse; artiklen stopper i stedet, når RMS ændrer sig med mindre end 0,1 mm. RAC-polynomierne tilpasses derefter til residualerne langs/på tværs/radialt med lineær mindste kvadraters metode, og urpolynomiet til det sande ur minus det relativistiske led, som brugeren lægger til igen.

Et fund, som standardværdierne afspejler: efter en Keplersk tilpasning med mindste kvadrater er residualen pr. konstruktion det, som de 16 parametre ikke kan spænde over, så den svinger hen over vinduet (flere nulgennemgange i hver komponent) frem for at drive. Et korrektionspolynomium fjerner den kun, når dets grad overstiger det, det Keplerske sæt allerede spænder over: langs banen 7, på tværs af banen 5 og radialt 6 bringer en 15-minutters residual fra centimeter til omkring en millimeter, mens lavere grader på tværs af banen fjerner næsten intet (residualen på tværs af banen er ulige om vinduets midte). Et system, der udleder sin Keplerske del på anden vis, efterlader en residual af en anden form, og de grader, det kræver, følger heraf. Forudindstillingen Celestes egne korrektionsgrader (lavere end disse; de findes kun i forudindstillingsfilen, src/celeste_iod.rs) kører her på Kshanas mindste-kvadraters-grundlag, hvorfor dens led på tværs af banen bidrager lidt i denne motor: en udtalelse om Kshanas tilpasningsrutine, ikke om noget reelt system. toe og toc er hele sekunder, som det binære format bærer dem.

Hver meddelelse bruges over en periode centreret i sit tilpasningsvindue (den første afvejningstabel bruger hele vinduet). Det, tallene for signal-i-rummet-afstandsfejl (SISRE) måler, er meddelelsens repræsentationsfejl mod den sandhed, den blev tilpasset til, som root mean square (RMS) og et maksimum over spændet. Fejlen ved banebestemmelse og baneprædiktion, som et reelt jord- eller ombordsegment tilføjer ovenpå, er ikke modelleret.

Afstandsfejl for signal i rummet#

sisre.rs bruger den globale gennemsnitlige SISRE fra 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²) )

Vægtene er gennemsnittene over brugere jævnt fordelt på den synlige jordkalot af cos² η og ½ sin² η, hvor η er synslinjens nadirvinkel ved satellitten, beregnet for banens egen radius og elevationsmaske. Ved en maske på 0° gengiver beregningen artiklens tabel for mellemhøj jordbane (GPS 0,98 og 1/49, GLONASS 1/45, Galileo 1/61, BeiDou 1/54) og geostationær bane (0,99 og 1/126): det er den VALIDATED kontrol. I LEO giver det samme gennemsnit

så en LEO-bruger, der ser satellitten langt fra nadir, mærker fejl langs og på tværs af banen langt mere end en bruger i mellemhøj bane.

Analyser#

analysis = [...] vælger en hvilken som helst af de fire (standard alle).

Afvejning af tilpasningsinterval#

[trade] angiver spændet, tilpasningsintervallerne, opdateringsperioderne og modellerne. scenarios/leo-navmsg-fit-interval-trade.toml (550 km, 97,6°, EGM2008 til grad 20 og luftmodstand, 30 minutters meddelelser) giver, med brugsperioden lig tilpasningsintervallet:

Og med en tilpasning på 300 s, idet det varieres, hvor ofte en ny meddelelse overtager:

Det Keplerske sæt med 16 parametre forringes fra 0,04 cm ved 60 s til 9,35 cm ved 900 s: ét Kepler-sæt med harmoniske to gange pr. omløb kan ikke følge tyngdekraftens højfrekvente led og luftmodstanden på en LEO-bue i mere end nogle få minutter, og dets residual efter mindste kvadrater svinger hen over vinduet. Polynomierne langs/på tværs/radialt (grader 7, 5, 6) optager det, der er tilbage: 1,01 cm ved 900 s, 0,21 cm ved 600 s. Ved de korteste intervaller er de Keplerske tal under en millimeter og ikke længere strengt ordnede (tilpasningen er da begrænset af kondition, ikke af modellen).

Modelsammenligning#

scenarios/leo-navmsg-model-comparison.toml kører de fire modeller ved 1, 5 og 10 minutter på samme bane, med antallet af parametre og efemeride- og urbits i Kshanas kodning:

Rækken med nul-ur bedømmes mod et ur styret med en residual på 0,24 m (ATOMIC-tallet), de øvrige mod det frit løbende ur, de tilpasser.

Liu et al. 2025, SISRE som funktion af højde (MODELLED). Det samme scenarie tilpasser Kshanas 22-parametermodel over 20-minutters buer i artiklens fem højder, ved hver satellits inklinering:

Dette er ikke en validering. Artiklen tilpassede reelle præcise videnskabelige baner for de nævnte satellitter (med deres fulde tyngde-, luftmodstands- og ikke-gravitationelle historik); Kshana tilpasser sin egen integrerede bane, evaluerer de seks tilføjede parametre som beskrevet ovenfor og bruger sine egne SISRE-vægte. Sammenligningen viser tendensen og størrelsesordenen. Sammenligningen på de samme reelle baner, som artiklen tilpassede, er tests/leo_navmsg_fit_real_orbit_oracle.rs (siden 0,30 stemmer 22-parametertilpasningen dér inden for den på forhånd fastsatte faktor 1,5, på artiklens dage og på otte tilbageholdte dage).

Opdatering midt i passagen#

[midpass] placerer en bruger (standard 45° N, 10° E), finder den højeste passage over masken inden for search_s og planlægger meddelelser hver update_period_s. Ved hvert skift inden i passagen rapporterer den positionsspringet, urspringet, brugerens pseudoafstandsspring (ny meddelelse minus gammel), det største spring, en synlig bruger kunne se (lukket form over nadirkeglen), afstandsfejlen før og efter, og PASS eller FAIL mod threshold_m. scenarios/leo-navmsg-midpass-update.toml (300 s tilpasninger opdateret hver 150 s):

Den højeste passage på et døgn når 43,7° og varer 455 s. Dens skift:

Største spring i brugerafstand 0,35 mm mod en tærskel på 5 cm: PASS.

Kodning og afkodning#

scenarios/leo-navmsg-encode-decode.toml koder den første af tre meddelelser, afkoder den, kontrollerer CRC'en og afviser en beskadiget kopi, udskriver kvantiseringsbudgettet og skriver og indlæser igen RINEX-lignende blok og CSV-tabel:

• ramme: 171 bytes (1310 nyttelastbits, heraf 1045 efemeride og ur), 24-bit cyklisk redundanskontrol (CRC-24Q) 0x19105F;
• største halvtrinseffekt for et enkelt felt: af0, 0,545 mm;
• hele meddelelsen efter kvantisering: position inden for 1,126 mm og ur inden for 0,185 mm af den nøjagtige meddelelse; SISRE 0,113 cm nøjagtig, 0,129 cm afkodet;
• en ramme med én vendt bit afvises: sandt;
• RINEX-lignende rundtur inden for 5.0e-06 m, CSV-rundtur inden for 0.0e+00 m.

Platformsuafhængighed#

En ramme er transmitterede heltal, så den skal være de samme heltal, uanset hvor og hvordan scenariet køres: den native binære fil på ethvert operativsystem, et debug- eller et release-build og WebAssembly-buildet (WASM) i en browser. Tre ting stod i vejen. Sinus, cosinus, arcustangens og eksponentialfunktion i en værts matematikbibliotek skal ikke være korrekt afrundede og afviger mellem værter i sidste decimal. Et optimeret build på macOS henter sinus og cosinus af ét argument fra systemets kombinerede rutine, som ikke altid returnerer samme værdi som den enkelte sinus, så et debug- og et release-build afveg også fra hinanden. Og den sædvanlige normalfordelingssampler kalder værtens eksponential- og logaritmefunktion i sine sjældne grene. Tilpasningen gør en så lille forskel til forskellige kvantiserede felter. Hele typen (sand bane og sandt ur, tilpasning, brugeralgoritme, signal-i-rummet-afstandsfejl (SISRE), kodek) beregner derfor alle sådanne funktioner med den rene Rust-kasse libm via src/portable_math.rs, heltalspotenser som eksplicitte produkter og normalfordelte afvigelser med polarmetoden på generatorens rå output. leo_navmsg::tests::the_encoded_frame_is_the_same_bytes_on_every_platform fastlåser rammen på 171 bytes fra scenariet med kodning og afkodning nedenfor og én kontrolværdi pr. efemeridemodel; et debug-build, et release-build og WASM-buildet giver byte-identiske resultatdokumenter for alle fem medfølgende leo-navmsg-scenarier.

Binært format#

Dette er Kshanas egen dokumenterede kodning. Den bærer de komponenter, som de offentliggjorte beskrivelser af LEO-navigationsmeddelelser nævner, modelleret efter Galileo ICD's feltsæt. Den er ikke bitlayoutet for Celeste eller noget andet system: ingen er offentlige.

Ramme: præambel 0xA7 (8 bits), version 1 (4), model (4: 1 kepler16, 2 kepler-rac, 3 liu22, 4 ecef-poly), nyttelastlængde i bytes (12), nyttelast udfyldt med nuller til en hel byte, CRC-24Q (en 24-bit cyklisk redundanskontrol, 24 bits) over alle foregående bytes. CRC-24Q er kontrollen i standarden RTCM 10403 fra Radio Technical Commission for Maritime Services og i Galileo ICD (polynomium 0x1864CFB, startværdi 0); koden gengiver katalogets kontrolværdi 0xCDE703 for 123456789 og kontrolbytes i eksempelrammen af RTCM 10403 meddelelsestype 1005 (VALIDATED).

Galileo ICD's trin blev valgt til middelhøj jordbane og er for grove til en LEO-meddelelse på centimeterniveau: Crs i trin på 2⁻⁵ m (3,1 cm), Cuc 2⁻²⁹ rad (1,3 cm ved LEO-radius), vinklerne 2⁻³¹ halvcirkler (1,0 cm) og af0 2⁻³⁴ s (1,7 cm). Kshana beholder ICD-enhederne og halvcirkelkonventionen, forfiner trinnene, så hvert felts halvtrinsfejl holdes under 1 mm i position eller afstand over et 15-minutters vindue, og udvider felterne, så de dækker de intervaller, en LEO-tilpasning har brug for:

En værdi uden for sit felts interval afvises og ombrydes ikke. Intervallerne blev kontrolleret ved at kode tilpasninger ved 300 til 2000 km, banehældninger fra 0° til 140° og tilpasningsintervaller op til 20 minutter: deltaN og OmegaDot er brede, fordi knuden er dårligt defineret på en næsten ækvatorial bane, og tilpasningen fordeler argumentets J2-drift for breddevinklen mellem dem, og aDot og nDot er det, fordi 22-parametertilpasningen over 20 minutter optager en del af den kortperiodiske svingning i den halve storakse. Siden 0,30 er 22-parametertilpasningen artiklens almindelige mindste kvadraters metode uden apriori-værdier, og en ækvatorial tilpasning ved 800 km har da brug for nDot på omkring 6.3e-10 halvcirkel/s^2, så dens skala gik fra 2^-60 til 2^-58. De langsgående korrektioner af grad 7 for kepler-rac passer i koefficientintervallet på 22 bit op til 15 minutter; en længere tilpasning kan overskride det og afvises da. quantisation_budget rapporterer for hvert efemeride- og urfelt den største ændring i position og afstand, som en ændring på et halvt trin giver over brugsperioden, samt ændringen i hele meddelelsen efter kvantisering.

Teksteksport#

RINEX 4,02 definerer ingen LEO-navigationsposter (dets systembogstaver 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 formen fra RINEX 4 — en postoverskrift > EPH, en linje med satellit og epoke med tre urled, broadcast-banelinjer med fire D19.12-felter — og er en dokumenteret Kshana-udvidelse: systembogstav L, posttyper KP16, KRAC, LU22, APOL og tre overskriftskommentarer, der siger det. Tidligere arbejde om LEO-baner i navigationsposter 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 kepler16- og kepler-rac-meddelelser, én pr. række. Standardkolonnerne bruger Galileo ICD's navne (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 vælger i stedet en forudindstillings stavemåde. Begge formater kan læses tilbage.

Ionosfære og UTC#

• Klobuchar: motorens L1-model (gnss_sim::klobuchar_delay_m, kontrolleret mod RTKLIB) skaleret til bærebølgen med førsteordens-loven (f_L1 / f)².
• NeQuick-G: koefficienterne følger med i meddelelsen, og effective_ionisation_level returnerer Az = ai0 + ai1·μ + ai2·μ² for en modificeret dip-breddegrad μ efter algoritmens regler (koefficienter, der alle er nul, giver 63,7 solar flux units, sfu; resultatet begrænses til [0, 400] sfu). NeQuick-elektrontæthedsmodellen og dens integration langs skråvejen, som omsætter Az til en forsinkelse, er ikke implementeret.
• En satellit i nogle hundrede kilometers højde flyver inde i ionosfæren. Ingen af de to broadcast-modeller tager højde for elektronindholdet over satellitten, og der anvendes ingen korrektion for det.
• UTC: system_to_utc anvender de tre tilfælde i Galileo ICD §5.1.7 (før, inden for seks timer af og efter en skudsekundshændelse); et indskudt sekund læses som 86400.

Forudindstillinger#

Forudindstillinger er data, én fil hver under src/leo_navmsg/presets/, med deres kilder. Motoren og alle medfølgende scenarier undtagen Celeste-scenariet kører uden dem.

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

Celeste IOD. Forudindstillingen for Den Europæiske Rumorganisations (ESA's) Celeste-demonstration i kredsløb (IOD) er den eneste, der bruger materiale fremlagt på ESA Navigation Innovation and Support Programme (NAVISP) LEO-PNT-workshoppen, 2026: meddelelsesstrukturen (Galileos Kepler-sæt plus korrektionspolynomier langs/på tværs/radialt, urpolynomium, SVID, helbred, IOD, ionosfære- og UTC-parametre), postafstanden og CSV-kolonnenavnene. Banen (510 km, næsten polær solsynkron) og bærebølgen stammer fra offentlige kilder, der er nævnt i filen. Celestes bitlayout er ikke offentligt og gengives ikke; senere Celeste-faser og Den Europæiske Unions (EU's) LEO-PNT-system kan afvige. Hver værdi afledt af workshoppen findes i modulet navmsg i src/celeste_iod.rs, som bruges af scenarios/leo-navmsg-celeste-iod.toml. Sådan holdes forudindstillingen tilbage: hvert tal i motoren, der stammer fra workshoppen, ligger i én fil, src/celeste_iod.rs, som build.rs kun kompilerer med, når den findes, og i de scenarier, der kun findes i repositoriet, scenarios/*celeste-iod*.toml. Sletter man den fil og de scenarier, holdes forudindstillingen tilbage uden nogen ændring af kildekoden; alle andre tests, uafhængige referencer og scenarier kører uden den, og READMEs antal scenariefiler tæller stadig de tilbageholdte filer med.

Verifikation#

Begrænsninger#

• SISRE er kun repræsentationsfejl: ingen fejl fra banebestemmelse eller prædiktion.
• Referencen er en Kshana-integration (uden tredjelegeme, solstrålingstryk eller tidevand), ikke en virkelig satellits præcise bane.
• Det binære format og den RINEX-lignende blok er Kshanas egne.
• NeQuick-G bæres med, men integreres ikke til en forsinkelse; ingen korrektion for en satellit inde i ionosfæren.
• Sammenligningen med Liu et al. afviger i baner, parameterlæsning og vægte.