Maschinelle Übersetzung, nicht von einem Muttersprachler geprüft. Englisch ist die maßgebliche Fassung.

Erste SchritteAuf GitHub bearbeitenQuelle: docs/tutorials/01-first-orbit.md

Tutorial 1 — Meine erste Umlaufbahn: wo die GPS-Satelliten sind

Kind: orbit · Szenario: scenarios/orbit-sgp4-gps.toml (Lehrkopie: scenarios/orbit.toml) · Schwierigkeit: Einsteiger · ~15 min

Am Ende haben Sie die reale operative GPS-Konstellation propagiert, ihre Verfügbarkeit und Geometrie gelesen und eine Tabelle exportiert, wo sich jeder Satellit tatsächlich im Raum befindet — und Sie wissen, dass diese Tabelle gegen eine externe Referenz validiert ist, nicht gegen sich selbst.

Was dieses Szenario ist#

GPS-Satelliten (Global Positioning System) sagen einem Nutzer, wo er ist und wie spät es ist. Zuvor müssen Sie wissen, wo die Satelliten sind und wie viele davon ein Nutzer sehen kann. Das ist Geometrie, und die Geometrie legt die Untergrenze dafür fest, wie genau Sie positioniert werden können (die Verdünnung der Genauigkeit, englisch dilution of precision, DOP). Dieses Tutorial:

  1. nimmt einen echten Schnappschuss gps-ops von Celestrak der GPS-Konstellation (2021-07-28, 30 Satelliten, echte Zweizeilen-Bahnelemente, TLEs),
  2. propagiert jeden Satelliten mit dem validierten SGP4/SDP4-Modell (Simplified General Perturbations 4 / Simplified Deep-space Perturbations 4),
  3. ermittelt in jedem Zeitschritt, welche Satelliten ein Nutzer in niedriger Erdumlaufbahn sehen kann (Sichtlinie, Erdverdeckung und eine Elevationsmaske von 5°),
  4. macht aus dieser Geometrie einen PDOP (Positions-DOP) und eine Positionsgenauigkeit und
  5. exportiert die tatsächlichen erdzentrierten, erdfesten (ECEF) Positionen der Satelliten in eine SP3-Datei (Standard Product 3, das Präzisionsbahnformat des International GNSS Service, IGS; GNSS ist Global Navigation Satellite System).

Das Rückgrat ist: TLE → SGP4-Propagation → ECEF je Epoche → Sichtbarkeit → Zahl sichtbarer Satelliten → PDOP → Positions-Sigma = PDOP · σ_UERE, wobei σ_UERE der äquivalente Nutzer-Entfernungsfehler ist (der 1-σ-Entfernungsmessfehler je Satellit).

Ausführen#

cargo run -- scenarios/orbit-sgp4-gps.toml

Python:

import json, kshana
result = json.loads(kshana.run(open("scenarios/orbit-sgp4-gps.toml").read()))
print(result["geometry"]["best_pdop"], result["geometry"]["best_position_sigma_m"])

Oder öffnen Sie das Studio im Browser und wählen Sie das Orbit-Szenario.

Die einzeilige Zusammenfassung lesen#

Der deterministische Lauf (Seed = 17) gibt aus:

scenario 4c51512369a6 | 345/361 samples GNSS-nominal | best PDOP 1.07 pos 1.07m | quantum holdover 0s p95 2.59e-5ns integrity 1.000 security n/a (no attack) | classical holdover 0s p95 6.7ns integrity 1.000 security n/a (no attack)

Feld für Feld:

  • scenario 4c51512369a6 — der 12-stellige Szenario-Hash. Er ist der Fingerabdruck der genauen Eingaben (Seed, Schwellen, Modellparameter, der TLE-Block). Ändern Sie eine Eingabe, ändert er sich; halten Sie sie gleich, reproduzieren Sie den Lauf bitgenau. Derselbe Hash steht in der Fußzeile des Diagramms und in der Ergebnisdatei im JSON-Format (JavaScript Object Notation).
  • 345/361 samples GNSS-nominal — von den 361 Zeitschritten hat der Nutzer in 345 davon eine brauchbare Lösung (95,6 %). Der Lauf ist ein Durchgang von 12 h (43.200 s) mit einer Schrittweite von 120 s.
  • best PDOP 1.07 — der beste (niedrigste) PDOP über den Durchgang. Ein PDOP nahe 1 ist eine hervorragende Geometrie; je niedriger, desto besser.
  • pos 1.07m — die beste Positionsgenauigkeit: Positions-Sigma = PDOP · σ_UERE. In diesem Szenario gilt sigma_uere_m = 1.0, daher sind die beiden Zahlen hier numerisch gleich — aber die Regel lautet PDOP × UERE, nicht „Position = PDOP“. Bei einem UERE von 3 m läge das Positions-Sigma bei ~3,2 m. (Siehe den Fallstrick am Ende.)
  • Die Uhrenangaben (holdover, p95, integrity, security) kommen mit, weil das Orbit-Paket während des Durchgangs auch eine Uhr führt; sie stehen im Mittelpunkt von Tutorial 2, nicht dieses. (security lautet n/a (no attack), weil kein Angriff konfiguriert ist.)

Der Geometrieblock im JSON enthält die zugrunde liegenden Zahlen:

"geometry": {
  "samples_total": 361,
  "samples_with_fix": 345,
  "sigma_uere_m": 1.0,
  "best_pdop": 1.0713624151805556,
  "median_pdop": 2.318376881311817,
  "best_position_sigma_m": 1.0713624151805556,
  "median_position_sigma_m": 2.318376881311817
}

Wo sind die Satelliten? (der Ertrag)#

Die Geometrie ist gut, weil die Satelliten wirklich in der GPS-Schale stehen. Beweisen Sie es — exportieren Sie ihre erdfesten Positionen:

cargo run -- scenarios/orbit-sgp4-gps.toml --export-sp3 gps.sp3

Die ersten drei Satelliten im ersten Abtastschritt, ECEF in km (die SP3-Datei enthält eine vierte Spalte für die Uhr, geschrieben als Marker „kein Wert“ 999999,999999):

PG01   9771.575585  24612.128830      0.003744 999999.999999
PG02  20449.643959 -11875.958365 -12379.457079 999999.999999
PG03  26467.367408     45.510223   4010.411755 999999.999999

Nehmen Sie den geozentrischen Radius von PG01:

|r(PG01)| = sqrt(9771.575585^2 + 24612.128830^2 + 0.003744^2) = 26480.9 km

Die nicht zirkuläre unabhängige Referenz: ist das wirklich eine GPS-Umlaufbahn?#

Ein Tutorial, das die Engine gegen sich selbst prüft, beweist nichts. Hier ist der externe, nicht zirkuläre Anker für jede obige Aussage.

1. Die Satelliten liegen auf der realen mittleren Erdumlaufbahn-Schale (MEO) des GPS. Die nominelle große Halbachse von GPS beträgt a = 26.560 km, die Höhe ≈ 20.180 km über dem mittleren Erdradius von 6.378 km (IS-GPS-200, die GPS-Schnittstellenspezifikation; der GPS Standard Positioning Service (SPS) Performance Standard, US-Verteidigungsministerium (DoD); Misra & Enge, Global Positioning System, 2. Aufl.). Der momentane Radius von PG01 von 26.480,9 km liegt wenige hundert km von a entfernt — genau das, was die reale GPS-Exzentrizität (~0,005–0,02) erzeugt. Der Test tests/tutorials.rs::tutorial1_satellites_are_in_the_gps_meo_shell prüft 26000 km < |r(PG01)| < 27200 km gegen dieses veröffentlichte a, das extern zu Kshana ist.

2. Die Länge des Durchgangs ist ein GPS-Umlauf. Das dritte Keplersche Gesetz liefert die Umlaufzeit T = 2π√(a³/μ) mit a = 26,560 km und μ = 398,600.4418 km³/s² (World Geodetic System 1984, WGS-84; technischer Bericht NIMA TR8350.2 der National Imagery and Mapping Agency): T = 43,078 s = 11.967 h, ein halber Sterntag. Die Szenariodauer von 43.200 s („~ein GPS-Umlauf“) stimmt damit auf unter 0,3 % überein, und die GPS-Bodenspur wiederholt sich laut IS-GPS-200 jeden Sterntag (zwei Umläufe).

3. Die propagierten Positionen sind validiert, nicht selbstkonsistent. Der SGP4/SDP4-Propagator, der diese ECEF-Tabelle erzeugt hat, stimmt mit allen 666 Verifikationsvektoren AIAA (American Institute of Aeronautics and Astronautics) 2006-6753 im ungünstigsten Fall auf 4,12 mm überein (tests/sgp4_verification.rs, docs/SGP4-VALIDATION.md) und stimmt mit der unabhängigen Crate sgp4 im Submikrometerbereich überein. Die exportierte Tabelle ist also gegen eine externe Referenzimplementierung geprüft, nicht gegen die eigene Arithmetik von Kshana.

Ein Hinweis zu den SP3-Daten. Der SP3-Epochenkopf zeigt ein Platzhalter-Kalenderdatum (2000-01-01); die Propagation läuft tatsächlich ab der eigenen Epoche jedes TLE (2021). Lesen Sie die Tabelle als „ECEF-Positionen im ersten Abtastschritt“, nicht als „am 1. Januar 2000“.

Was der Test festschreibt#

tests/tutorials.rs macht jede obige Zahl zu einem CI-Vertrag:

  • tutorial1_orbit_headline_holds — best_pdop ≈ 1.071, best_position_sigma_m == best_pdop (weil sigma_uere_m = 1.0), samples_total == 361, und die Zusammenfassung enthält 345/361.
  • tutorial1_satellites_are_in_the_gps_meo_shell — der Radius von PG01 liegt im Band der GPS-Schale, geprüft gegen das veröffentlichte a = 26,560 km.

Wenn die Engine jemals aufhört, eine reale GPS-Schale zu erzeugen, wird der Build rot.

Fallstricke und Einheiten#

  • Positions-Sigma ist PDOP × UERE, nicht PDOP. Die beiden sind nur gleich, weil hier sigma_uere_m = 1.0 gilt. Ändern Sie das UERE, und sie gehen auseinander.
  • Die Zeitgebungsangaben sind in Nanosekunden, die Positionsangabe in Metern. Vermischen Sie sie nicht.
  • holdover_s ist rasterquantisiert (eine untere Schranke bei der Schrittweite des Zeitrasters). In diesem Durchgang hat der Nutzer im Wesentlichen immer eine Lösung, daher ist der Holdover 0 s (kein Ausfall zum Überbrücken) — das ist der gute Fall.

Wie es weitergeht#

  • Verengen oder erweitern Sie die Elevationsmaske (mask_deg) und beobachten Sie, wie sich die Verfügbarkeit ändert — das ist eine Übung der Stufe 2.
  • Tauschen Sie mit scripts/fetch_tles.sh einen frischen TLE-Schnappschuss ein (Stufe 2, „frische Daten verwenden“).
  • Weiter mit Tutorial 2 — Uhren-Holdover, wo das GNSS-Signal weggenommen wird und die Borduhr durchhalten muss.