LEO-navigeringsmeddelande

Scenariotypen leo-navmsg bygger sändningsefemeriden och klockmeddelandet för en satellit för positionering, navigering och tidssynkronisering (PNT) i låg omloppsbana (LEO) och besvarar de frågor som den som utformar ett meddelande ställer: hur länge kan ett meddelande gälla, vad ger varje extra parameter, vad ser en användare när meddelandet byts mitt i en passage, och hur många bitar krävs för att bära det med centimeternoggrannhet.

Den är systemoberoende. Valfri bana, valfri bärvåg och någon av fyra efemeridmodeller körs helt utan förinställning; de namngivna förinställningarna är valfria data (se Förinställningar).

Skriv ut ett medföljande exempel med kshana example <name> (ett namn per anrop) och kör det med kshana scenarios/<name>.toml: leo-navmsg-fit-interval-trade, leo-navmsg-model-comparison, leo-navmsg-midpass-update och leo-navmsg-encode-decode. Typen är också meddelandesteget i typen leo-pnt-chain (LEO-PNT.md) och en del av kampanjen leo-focus-data-services, som sätter ihop fyra meddelandekonfigurationer och redovisar ramlängden för var och en (146, 154, 159 och 171 bytes).

Kod: src/leo_navmsg/ — elements.rs (poster och användaralgoritm), truth.rs (referensbana och referensklocka), fit.rs (anpassning), sisre.rs (avståndsfel i signalen i rymden), services.rs (jonosfär och Coordinated Universal Time (UTC)), codec.rs (binärt format), text.rs (exporter i stil med Receiver Independent Exchange Format (RINEX) och kommaseparerade värden (CSV)), presets/ (en fil per förinställning), mod.rs (typen).

Vad ett meddelande innehåller#

Efemeridmodeller#

Användaralgoritmen (elements::sat_state) är Galileo ICD:s sekvens (Keplers ekvation, korrektioner av andra övertonen, jordfast nod) följd, för kepler-rac, av de tre polynomen längs den keplerska banans eget system: radiellt längs den beräknade positionen, tvärs banan längs banans normal utifrån korrigerad inklination och nod, och längs banan som fullbordar triaden. Klockan lägger till ICD:s relativistiska term F·e·√A·sin E; för ecef-poly är det den allmänna formen −2 r·v / c² från polynomet och dess derivata.

Termerna enligt Liu m.fl. följer artikelns användaralgoritm (avsnitt 2,2, ekv. 1-7): A = A0 + ȧ·tk, n = √(μ/A0³) + Δn + ṅ·tk (utgåvor före 0,30 använde konventionen för Global Positioning System (GPS) civil navigering ½·ṅ·tk, så en ṅ som de skrev är dubbelt så stor som artikelns), och Crs1·sin Φ + Crc1·cos Φ + Crs3·sin 3Φ + Crc3·cos 3Φ adderat till radien, där Φ är det okorrigerade breddargumentet. Skalkonventionen för ṅ är hämtad från artikelns ekv. 1; jämförelsen med artikeln på verkliga banor beror inte på den (en faktor ½ på ṅ lämnar varje anpassad storhet oförändrad), så innebörden av ett sänt nDot-värde är inte validerad där.

Två tolkningar är Kshanas egna och anges som sådana:

• RAC-systemet och normaliseringen τ = tk / tau_s. Inget offentligt dokument definierar ett LEO-korrektionssystem för ett sänt meddelande.
• Klockan i ett meddelande med nollklocka är noll totalt: styrslingan antas hålla den skenbara klockan, inklusive den relativistiska termen, vid systemtid.

Anpassningen#

truth.rs integrerar banan med en Runge–Kutta av fjärde ordningen med fast steg i ett system som övergår i jordfasta axlar genom en rotation, θ(t) = θ0 + Ω̇e·t, samma enda rotation som en sänd användaralgoritm tillämpar. Gravitationen är tvåkropps (gravity_degree = 0), de zonala övertonerna J2 till J6 (2 till 6) eller fältet Earth Gravitational Model 2008 (EGM2008) till grad och ordning 7 till 70, vars tesserala termer bär den kortperiodiska signatur som gör en LEO-anpassning svår. Luftmotstånd är valfritt (statisk exponentiell täthet). Klockan är antingen fritt gående (bias, drift, driftändring och vitt frekvensbrus vid en angiven Allan-deviation på en sekund, plus den periodiska relativistiska termen) eller styrd (en residual av Gauss–Markov av första ordningen).

fit.rs anpassar den keplerska uppsättningen med Levenberg–Marquardt på icke-singulära element (e·cos ω, e·sin ω, λ0 = M0 + ω): en LEO-bana är nästan cirkulär, så ω och M0 är var för sig nästan omöjliga att skilja åt. Den startar från det oskulerande tillståndet vid toe med J2-nodhastigheten. Svaga nollcentrerade a priori-villkor begränsar de hastigheter och övertoner som en kort båge inte kan lösa upp; med en observationsvikt på 1 cm verkar de bara i just de nollriktningarna. Anpassningen liu22 utgår i stället från artikelns start och skattare i avsnitt 2,3: den börjar med alla korrektionstermer lika med noll, har inga a priori-villkor (vanlig minstakvadratmetod) och behåller artikelns tak på 100 iterationer. Den stoppar enligt Kshanas egen konvergensregel för parametrar, när varje parametersteg är mindre än 1e-3 av dess formella standardavvikelse; artikeln stoppar i stället när RMS ändras med mindre än 0,1 mm. RAC-polynomen anpassas därefter till residualerna längs/tvärs/radiellt med linjär minstakvadratmetod, och klockpolynomet till referensklockan minus den relativistiska term som användaren lägger tillbaka.

Ett fynd som standardvärdena speglar: efter en keplersk minstakvadratanpassning är residualen per konstruktion det som de 16 parametrarna inte kan spänna upp, så den svänger över fönstret (flera nollgenomgångar i varje komponent) i stället för att driva. Ett korrektionspolynom tar bort den först när dess grad överstiger vad den keplerska uppsättningen redan spänner upp: längs banan 7, tvärs banan 5 och radiellt 6 tar en residual på centimeter över 15 minuter ner till ungefär en millimeter, medan lägre grad tvärs banan tar bort nästan ingenting (residualen tvärs banan är udda kring fönstrets mitt). Ett system som härleder sin keplerska del på något annat sätt lämnar en residual med annan form, och de grader det behöver följer av den. Förinställningen Celestes egna korrektionsgrader (lägre än dessa; de finns bara i förinställningsfilen, src/celeste_iod.rs) körs här på Kshanas minstakvadratbas, vilket är anledningen till att dess tvärbanetermer bidrar lite i den här motorn: ett påstående om Kshanas anpassning, inte om något verkligt system. toe och toc är hela sekunder, eftersom det binära formatet bär dem så.

Varje meddelande används under en period centrerad i sitt anpassningsfönster (den första avvägningstabellen använder hela fönstret). Det som siffrorna för avståndsfel i signalen i rymden (SISRE) mäter är meddelandets representationsfel mot den referens det anpassades till, som ett kvadratiskt medelvärde (RMS) och ett maximum över intervallet. Felet vid banbestämning och banprediktion, som ett verkligt mark- eller ombordsegment lägger till ovanpå, modelleras inte.

Avståndsfel i signalen i rymden#

sisre.rs använder det globala genomsnittliga SISRE från Montenbruck, Steigenberger och 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²) )

Vikterna är medelvärdena över användare jämnt utspridda på den synliga jordkalotten av cos² η och ½ sin² η, där η är nadirvinkeln för siktlinjen vid satelliten, beräknad för banans egen radie och elevationsmask. Vid en mask på 0° återger beräkningen artikelns tabell för medelhög jordbana (GPS 0,98 och 1/49, GLONASS 1/45, Galileo 1/61, BeiDou 1/54) och geostationär bana (0,99 och 1/126): det är kontrollen som är VALIDATED. I LEO ger samma medelvärde

så en LEO-användare, som ser satelliten långt från nadir, känner av fel längs och tvärs banan mycket mer än en användare i medelhög bana.

Analyser#

analysis = [...] väljer vilken som helst av de fyra (standard alla).

Avvägning av anpassningsintervall#

[trade] anger intervallet, anpassningsintervallen, uppdateringsperioderna och modellerna. scenarios/leo-navmsg-fit-interval-trade.toml (550 km, 97,6°, EGM2008 till grad 20 och luftmotstånd, 30 minuter av meddelanden) ger, med användningsperioden lika med anpassningsintervallet:

Och med en anpassning på 300 s, med varierande hur ofta ett nytt meddelande tar över:

Den keplerska uppsättningen med 16 parametrar försämras från 0,04 cm vid 60 s till 9,35 cm vid 900 s: en keplersk uppsättning med övertoner två gånger per varv kan inte följa de högfrekventa gravitationstermerna och luftmotståndet i en LEO-båge i mer än några minuter, och dess minstakvadratresidual svänger över fönstret. Polynomen längs/tvärs/radiellt (grader 7, 5, 6) tar hand om det som återstår: 1,01 cm vid 900 s, 0,21 cm vid 600 s. Vid de kortaste intervallen ligger de keplerska siffrorna under en millimeter och är inte längre strikt ordnade (anpassningen begränsas då av konditioneringen, inte av modellen).

Modelljämförelse#

scenarios/leo-navmsg-model-comparison.toml kör de fyra modellerna vid 1, 5 och 10 minuter på samma bana, med antalet parametrar och efemerid- och klockbitarna i Kshanas kodning:

Raden med nollklocka bedöms mot en klocka som styrs med en residual på 0,24 m (ATOMIC-värdet), de övriga mot den fritt gående klocka de anpassar.

Liu m.fl. 2025, SISRE mot höjd (MODELLED). Samma scenario anpassar Kshanas 22-parametersmodell över bågar på 20 minuter vid artikelns fem höjder, med varje satellits inklination:

Detta är inte en validering. Artikeln anpassade verkliga precisa vetenskapliga banor för de namngivna satelliterna (med deras fulla gravitations-, luftmotstånds- och icke-gravitationshistorik); Kshana anpassar sin egen integrerade bana, beräknar de sex tillagda parametrarna som beskrivits ovan och använder sina egna SISRE-vikter. Jämförelsen visar trenden och storleksordningen. Jämförelsen på de verkliga banor som artikeln anpassade är tests/leo_navmsg_fit_real_orbit_oracle.rs (sedan 0,30 stämmer 22-parametersanpassningen där överens inom den i förväg fastställda faktorn 1,5, på artikelns dagar och på åtta undanhållna dagar).

Uppdatering mitt i passagen#

[midpass] placerar en användare (standard 45° N, 10° E), hittar den högsta passagen över masken inom search_s och schemalägger meddelanden var update_period_s. Vid varje byte inom passagen redovisas positionshoppet, klockhoppet, användarens pseudoavståndshopp (nytt minus gammalt meddelande), det största hopp någon synlig användare kunde se (sluten form över nadirkonen), avståndsfelet före och efter, samt PASS eller FAIL mot threshold_m. scenarios/leo-navmsg-midpass-update.toml (anpassningar på 300 s som uppdateras var 150 s):

Den högsta passagen under ett dygn når 43,7° och varar 455 s. Dess byten:

Största avståndshopp för användaren 0,35 mm mot en tröskel på 5 cm: PASS.

Koda och avkoda#

scenarios/leo-navmsg-encode-decode.toml kodar det första av tre meddelanden, avkodar det, kontrollerar CRC och avvisar en skadad kopia, skriver ut kvantiseringsbudgeten, samt skriver och läser tillbaka RINEX-blocket och CSV-tabellen:

• ram: 171 bytes (1310 nyttolastbitar, varav 1045 är efemerid och klocka), 24-bitars cyklisk redundanskontroll (CRC-24Q) 0x19105F;
• största effekt av ett halvt steg för något enskilt fält: af0, 0,545 mm;
• hela meddelandet efter kvantisering: position inom 1,126 mm och klocka inom 0,185 mm från det exakta meddelandet; SISRE 0,113 cm exakt, 0,129 cm avkodat;
• en ram med en omvänd bit avvisas: true;
• RINEX-rundtur inom 5.0e-06 m, CSV-rundtur inom 0.0e+00 m.

Plattformsoberoende#

En ram består av sända heltal, så den måste vara samma heltal oavsett var och hur scenariot körs: den inbyggda binären på vilket operativsystem som helst, en debug- eller release-bygge, och WebAssembly-bygget (WASM) i en webbläsare. Tre saker stod i vägen. Sinus, cosinus, arcustangens och exponentialfunktion i en värds matematikbibliotek måste inte vara korrekt avrundade och skiljer sig mellan värdar i sista siffran. Ett optimerat bygge på macOS hämtar sinus och cosinus för ett argument från systemets kombinerade rutin, som inte alltid returnerar samma värde som den ensamma sinusen, så ett debug- och ett release-bygge skilde sig också åt. Och den vanliga normalfördelningsgeneratorn anropar värdens exponential och logaritm i sina sällsynta grenar. Anpassningen förvandlar en så liten skillnad till olika kvantiserade fält. Hela typen (referensbana och referensklocka, anpassning, användaralgoritm, avståndsfel i signalen i rymden (SISRE), kodek) beräknar därför varje sådan funktion med Rust-biblioteket libm genom src/portable_math.rs, heltalspotenser som uttryckliga produkter och normalfördelade värden med polarmetoden på generatorns råa utdata. leo_navmsg::tests::the_encoded_frame_is_the_same_bytes_on_every_platform fastställer den 171 bytes långa ramen i scenariot för kodning och avkodning nedan och ett kontrollvärde per efemeridmodell; ett debug-bygge, ett release-bygge och WASM-bygget ger byteidentiska resultatdokument för alla fem medföljande leo-navmsg-scenarier.

Binärt format#

Detta är Kshanas egen dokumenterade kodning. Den bär de komponenter som de publicerade beskrivningarna av LEO-navigeringsmeddelanden nämner, modellerad efter Galileo ICD:s fältuppsättning. Den är inte bitlayouten för Celeste eller något annat system: ingen sådan är offentlig.

Ram: preamble 0xA7 (8 bitar), version 1 (4), modell (4: 1 kepler16, 2 kepler-rac, 3 liu22, 4 ecef-poly), nyttolastlängd i bytes (12), nyttolast nollfylld till en byte, CRC-24Q (en 24-bitars cyklisk redundanskontroll, 24 bitar) över varje föregående byte. CRC-24Q är kontrollen i standarden RTCM 10403 från Radio Technical Commission for Maritime Services och i Galileo ICD (polynom 0x1864CFB, startvärde 0); koden återger katalogens kontrollvärde 0xCDE703 för 123456789 och kontrollbytena i exempelramen för RTCM 10403 meddelandetyp 1005 (VALIDATED).

Stegen i Galileo ICD valdes för medelhög jordbana och är för grova för ett LEO-meddelande på centimeternivå: Crs i steg om 2⁻⁵ m (3,1 cm), Cuc 2⁻²⁹ rad (1,3 cm vid LEO-radie), vinklarna 2⁻³¹ halvcirklar (1,0 cm) och af0 2⁻³⁴ s (1,7 cm). Kshana behåller ICD:s enheter och halvcirkelkonventionen, förfinar stegen så att varje fälts fel för ett halvt steg stannar under 1 mm i position eller avstånd över ett fönster på 15 minuter, och vidgar fälten för att rymma de intervall som en LEO-anpassning behöver:

Ett värde utanför fältets intervall avvisas, det lindas inte runt. Intervallen kontrollerades genom att koda anpassningar vid 300 till 2000 km, inklinationer från 0° till 140° och anpassningsintervall upp till 20 minuter: deltaN och OmegaDot är breda eftersom noden är dåligt definierad i en bana nära ekvatorn och anpassningen fördelar J2-driften i breddargumentet mellan dem, och aDot och nDot eftersom 22-parametersanpassningen över 20 minuter tar upp en del av den kortperiodiska svängningen i halva storaxeln. Sedan 0,30 är 22-parametersanpassningen artikelns vanliga minstakvadratmetod utan a priori-villkor, och en anpassning vid 800 km nära ekvatorn behöver då nDot på ungefär 6.3e-10 halvcirkel/s^2, så dess skala gick från 2^-60 till 2^-58. Korrektionerna längs banan av grad 7 som kepler-rac använder ryms i koefficientintervallet på 22 bitar upp till 15 minuter; en längre anpassning kan överskrida det och avvisas då. quantisation_budget redovisar, för varje efemerid- och klockfält, den största positions- och avståndsändring som en ändring med ett halvt steg ger över användningsperioden, samt ändringen av hela meddelandet efter kvantisering.

Textexporter#

RINEX 4,02 definierar inga LEO-navigeringsposter (dess systembokstäver är G, R, E, J, C, I och S; International GNSS Service (IGS) RINEX 4,02). Blocket som text.rs skriver lånar formen från RINEX 4 — ett postrubrik > EPH, en rad med satellit och epok med tre klocktermer, sända banrader med fyra D19.12-fält — och är ett dokumenterat Kshana-tillägg: systembokstav L, posttyper KP16, KRAC, LU22, APOL, och tre rubrikkommentarer som säger det. Tidigare arbete om LEO-banor i navigeringsposter 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är meddelandena kepler16 och kepler-rac, ett per rad. Standardkolumnerna använder namnen i 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 väljer i stället en förinställnings stavning. Båda formaten kan läsas tillbaka.

Jonosfär och UTC#

• Klobuchar: motorns L1-modell (gnss_sim::klobuchar_delay_m, kontrollerad mot RTKLIB) skalad till bärvågen med förstaordningslagen (f_L1 / f)².
• NeQuick-G: koefficienterna sänds i meddelandet och effective_ionisation_level returnerar Az = ai0 + ai1·μ + ai2·μ² för en modifierad dip-latitud μ, med algoritmens regler (koefficienter som alla är noll ger 63,7 solar flux units, sfu; resultatet begränsas till [0, 400] sfu). Elektrontäthetsmodellen NeQuick och dess integrering längs signalvägen, som omvandlar Az till en fördröjning, är inte implementerade.
• En satellit på några hundra kilometers höjd flyger inuti jonosfären. Ingen av de sända modellerna tar hänsyn till elektroninnehållet ovanför satelliten, och ingen korrektion för det tillämpas.
• UTC: system_to_utc tillämpar de tre fallen i Galileo ICD §5.1.7 (före, inom sex timmar från och efter en skottsekundshändelse); en inskjuten sekund läses som 86400.

Förinställningar#

Förinställningar är data, en fil vardera under src/leo_navmsg/presets/, med sina källor. Motorn och alla medföljande scenarier utom Celeste-scenariot körs utan dem.

RNSS är radionavigeringssatellittjänsten; RNTF är Resilient Navigation and Timing Foundation.

Celeste IOD. Förinställningen för Europeiska rymdorganisationens (ESA) Celeste-demonstration i omloppsbana (IOD) är den enda som använder material som presenterades vid ESA:s LEO-PNT-workshop inom Navigation Innovation and Support Programme (NAVISP), 2026: meddelandestrukturen (Galileos keplerska uppsättning plus korrektionspolynom längs/tvärs/radiellt, klockpolynom, SVID, hälsa, IOD, jonosfärs- och UTC-parametrar), postavståndet och CSV-kolumnnamnen. Banan (510 km, nästan polär solsynkron) och bärvågen kommer från offentliga källor som anges i filen. Bitlayouten för Celeste är inte offentlig och återges inte; senare Celeste-faser och Europeiska unionens (EU) LEO-PNT-system kan skilja sig åt. Varje värde som härrör från workshopen finns i modulen navmsg i src/celeste_iod.rs, som används av scenarios/leo-navmsg-celeste-iod.toml. Så hålls förinställningen undan: varje tal från workshopen i motorn finns i en enda fil, src/celeste_iod.rs, som build.rs bara kompilerar in när den finns, och i de scenarier som bara finns i förrådet scenarios/*celeste-iod*.toml. Om man tar bort den filen och de scenarierna hålls förinställningen undan utan någon källkodsändring; alla andra tester, referenser och scenarier körs utan den, och antalet scenariofiler i README räknar fortfarande med de undanhållna filerna.

Verifiering#

Begränsningar#

• SISRE är bara representationsfel: inget fel vid banbestämning eller banprediktion.
• Referensen är en integration i Kshana (ingen tredje kropp, strålningstryck från solen eller tidvatten), inte en verklig satellits precisa bana.
• Det binära formatet och RINEX-blocket är Kshanas egna.
• NeQuick-G sänds men integreras inte till en fördröjning; ingen korrektion för en satellit inuti jonosfären.
• Jämförelsen med Liu m.fl. skiljer sig i banor, tolkning av parametrar och vikter.