leo-pnt-chain (Szenarioart)

Szenarioart der Engine v0.40.0, Familie Low-Earth-orbit navigation. Hinweis (beratend): Analyseausgabe eines Forschungs- und Engineering-Werkzeugs, keine typzugelassene Navigationsausrüstung und kein Safety-of-Life-Dienst. Jede Bezeichnung hier stammt von der Engine oder der Verifikationsmatrix; eine Szenarioart ist MODELLED, sofern die Matrix nichts anderes sagt (wie eine Bezeichnung erworben wird: der Abschnitt Evidence der README).

Was es tut#

Ein LEO-PNT-System (Positionierung, Navigation und Zeitgebung aus dem niedrigen Erdorbit) von Anfang bis Ende, für jede Konstellation und jedes Signal: Das mit signal_design benannte leo-signal-Design (eine öffentliche Voreinstellung oder ein Inline-Design [signal]) legt Mitte, Bandbreite, Chiprate und EIRP-Aufteilung eines Bandes [pass] fest, das Link-Budget von leo-pass liefert das verfolgte C/N0 und den bandbegrenzten Codejitter über den Überflug, eine C/N0-Gerade in sin(Elevation) und das ausgesendete SISRE der Nachricht [navmsg] (angepasst in der Höhe des Überflugsatelliten) speisen jedes LEO-System des gemeinsamen Fixes leo-pvt unter [fusion] und optional die Fälle leo-ppp unter [ppp]; jede Übergabe wird mit Wert und Einheit aufgelistet. MODELLED.

Ein Lauf von scenarios/leo-pnt-end-to-end.toml fasst sich so zusammen: LEO-PNT end to end, generic 1080 km constellation signal generic-l (https://www.itu.int/pub/R-REG-RR), tracked pilot at 10,230 Mchip/s, C/N0 offset -2.57 dB pass LEO-1 1080 km: tracked C/N0 peak 58,2 dB-Hz, code jitter median 0,050 m; C/N0 line 35,6 + 24,3 sin(el) dB-Hz message kepler-rac 300 s fit / 300 s update: representation SISRE 0,907 mm RMS (orbit 0,005 mm), with 0,250 m orbit determination: 0,250 m handed on fused fix: GNSS only PDOP 1,47 RMS 3D 1,60 m -> GNSS + LEO PDOP 1,06 RMS 3D 0,43 m PPP convergence: GNSS only 11,5 min, 240 LEO 7,5 min 11 values handed between stages. MODELLED.

Eingaben#

Aus dem Schema (kshana kinds --json):

• Pflichtfelder: signal_design, pass, fusion
• Optionale Felder: name, description, seed, signal, navmsg, od_sisre_m, ppp

Das Beispiel scenarios/leo-pnt-end-to-end.toml setzt unter anderem:

Ausführen#

kshana scenarios/leo-pnt-end-to-end.toml

3 mitgelieferte Szenarien verwenden diesen Typ; die übrigen stehen in scenarios/.

Was es liefert#

Die skalaren Ergebnisse dieses Laufs, mit den Einheiten, die die Engine angibt:

Ergebnisbezeichnung (der Engine): MODELLED — die Kette reicht die Ausgabe jeder Stufe an die nächste weiter; die Stufen behalten ihre eigenen Bezeichnungen (die Zeilen leo-signal, leo-pass, leo-navmsg, leo-pvt und leo-ppp der Verifikationsmatrix).

Nachweise#

MODELLED: die Zeilen der Verifikationsmatrix, die diese Art nennen.

• MODELLED Die Szenarioart leo-pnt-chain: Ein leo-signal-Design (öffentliche Voreinstellung oder inline) legt Mitte, Bandbreite, Chiprate und EIRP-Aufteilung eines Bandes von leo-pass fest; der Überflug liefert je Epoche das C/N0 der verfolgten Komponente und den bandbegrenzten Codejitter; ein C/ Tests: leo_pnt_chain.rs.

Die Zeilen, die der Lauf selbst ausgeübt hat, mit der unabhängigen Referenz, die die Matrix jeder gibt (die öffentlichen Quellen sind dort genannt):

• MODELLED Deterministisch, szenario-gehasht, SBOM- und plattformübergreifende Golden-Gates. Unabhängige Referenz (ExternalDataset): SBOM-Übereinstimmung mit dem offiziellen CycloneDX-1,5-JSON-Schema (+ gültige SPDX-Kennungen) — ein externer veröffentlichter Standard, null Validierungsfehler über den gesamten Abhängigkeitsgraphen; der Teil FoM-Determinismus / Byte-Reproduzierbarkeit bleibt eine festgelegte Selbstkonsistenzprüfung, daher bleibt die Zeile MODELLED
• VALIDATED navsignal: das Sinusintegral (sine_integral), der BPSK-R-Leistungsanteil innerhalb eines doppelseitigen Bandes in geschlossener Form (bpsk_power_in_band_closed_form), das Band. Orakel (ExternalDataset): Extern festgelegt: 90,3 Prozent Hauptkeulenleistung, der kohärente Early-Late-Jitter am angegebenen Arbeitspunkt, die Tabellenwerte des Sinusintegrals und der spektrale Selbst-Trennungskoeffizient von BPSK 2/(3 R_c) bei Nullversatz. Nur interne Gegenprüfungen, keine externe Validierung: die geschlossene Form der bandbegrenzten BPSK-Gabor-Bandbreite und ihre Asymptote sowie der spektrale Trennungskoeffizient von BPSK mit Versatz bei von null verschiedenen Versätzen, beide
• MODELLED Die Szenarioart leo-signal: parametrisierte Signaldesigns (Band, Sendebandbreite, ITU-Zuweisung; Akquisitions-, Daten- und Pilotkomponenten mit BPSK(n), BOC(m,n), MB. Orakel (InternalConsistency): Die validierten geschlossenen Formen der beiden Zeilen darüber, die Quadratgesetz-Identität des Fehlalarms P_d(snr = 0) = P_fa und die mittlere Akquisitionszeit nach Holmes sowie die Reduktion auf die eigene SSC-Kette des Spektrum-Szenarioart (derselbe Code Jammer::ssc). Die Designs selbst sind Eingaben: Als REPRESENTATIVE oder WORKSHOP markierte Voreinstellungen sind keine veröffentlichten Spezifikationen, erweiterte Feher-QPSK-, Code-Shift-Keying- und OFDM-Spektren werden angenähert, und die Form
• VALIDATED ITU-R P.618-14 Abschnitt 2.4.1 Schritte 3 bis 9 (Referenz-Sigma aus N_wet, effektive Weglänge, Antennenmittelungsfaktor, Schwundtiefe für 0,01 % bis 50 % der Zei. Orakel (ExternalDataset): Validierungsbeispiele der ITU-R Study Group 3 (CG-3M3J-13-ValEx-Rev8.3.0) für die Szintillation nach P.618-14, wobei das N_wet nach P.453-14 jedes Standorts aus denselben Beispielen stammt; eingecheckt in tests/fixtures/leo_link/p618_14_scintillation.csv mit den URLs und dem Abrufdatum. Der Ausdruck für die feuchte Refraktivität aus Temperatur und Feuchte wird von dieser Zeile nicht abgedeckt
• VALIDATED Gruppenlaufzeit 40,3 STEC/f^2 je Band; die ionosphärenfreien Koeffizienten f1^2/(f1^2 - f2^2) und -f2^2/(f1^2 - f2^2) und die Rauschverstärkung sqrt(a1^2 s1^2 + a2^. Orakel (ExternalDataset): IS-GPS-200 Abschnitt 20.3.3.3.3.2, der das L1/L2-Gruppenlaufzeitverhältnis gamma = (77/60)^2 nennt, das aus der Skalierung erster Ordnung mit 1/f^2 folgt, und die Friis-Übertragungsformel (Proc. IRE, 1946). Validiert die Skalierungsgesetze, kein schräger TEC

Einschränkungen#

Was der eigene Bericht des Laufs als nicht modelliert oder nicht validiert nennt:

• Die Positionierungsstufe modelliert C/N0 als Gerade im Sinus der Elevation zwischen Maske und Zenit; die Kette passt diese Gerade an das verfolgte C/N0 des Überflugs an, sodass eine überflugspezifische Form (ein Isoflux-Plateau, ein Strahlrand) auf zwei Zahlen reduziert wird. (Ergebnis limitations[0])
• Das SISRE, das an die Positionierungsstufen weitergegeben wird, ist der Darstellungsfehler der Navigationsnachricht gegen eine von Kshana integrierte Wahrheitsbahn, zuzüglich des im Szenario angegebenen od_sisre_m als Wurzel der Quadratsumme; die Nachrichtenstufe selbst modelliert keine Bahnbestimmung oder -vorhersage. (Ergebnis limitations[1])
• Die Positionierungsstufe berechnet ihren eigenen Delay-Lock-Loop-Jitter aus dem weitergegebenen C/N0 mit einer Formel für unbegrenzte Bandbreite; der Überflug gibt daneben den bandbegrenzten Jitter des tatsächlichen Designs an. (Ergebnis limitations[2])
• Die Stufe der präzisen Punktpositionierung übernimmt das SISRE der Nachricht als LEO-Bahn-und-Uhr-Fehler; ihr Code- und Phasenrauschen bleiben die eigenen Eingaben der Stufe. (Ergebnis limitations[3])
• Ein Satellit, der erste, dessen Band das Design trägt, steht in den Stufen für Überflug und Nachricht für das gesamte LEO-System. (Ergebnis limitations[4])
• MODELLED — die Kette reicht die Ausgabe jeder Stufe an die nächste weiter; die Stufen behalten ihre eigenen Bezeichnungen (die Zeilen leo-signal, leo-pass, leo-navmsg, leo-pvt und leo-ppp der Verifikationsmatrix). (Ergebnis label)
• MODELLED. (Artenkatalog (kshana kinds --json))
• MODELLED: Jede Stufe behält ihre eigene Bezeichnung; die Kette fügt keine Physik hinzu. (Kommentar in der Szenariodatei, Zeile 25)

Siehe auch#

• Familienseite: Low-Earth-orbit navigation
• Alle Arten: KINDS.md
• Themenseite: LEO-PNT.md
• Themenseite: LEO-PASS.md