Ephemeridenzeit und Uhrkorrekturen in RINEX-Navigationsdateien

Was genau sind$T_{SV}$Und$T_{OC}$?

Die erste ist jede Zeit (z. B. die Zeit, zu der die Nachricht gesendet wurde), ausgedrückt in dem Zeitsystem, das von einem bestimmten Satelliten (Raumfahrzeug) verwaltet wird. Die Sekunde ist die Referenzzeit für die Uhrkorrektur, ausgedrückt im gleichen Zeitsystem. Die Korrektur wird benötigt, damit jede von einem beliebigen Satelliten angekündigte Zeit in ein gemeinsames GPS-Zeitsystem (auch GPST genannt) umgewandelt werden kann. Daher ist Gl. 2 der GPS-Referenzspezifikation (IS-GPS-200M, Seite 95 - die Sie oben in den Kommentaren erwähnt haben) ermöglicht es einem Empfänger, die Uhrfehler in einem bestimmten SV aus den von diesem SV gesendeten Navigationsdaten zu korrigieren, um zu den gemeinsamen zu gelangen Zeitreferenz. Diese Sendedaten werden vom GPS Operation Center berechnet und regelmäßig aktualisiert. Diese Erklärung aus der GPS-Spezifikation (IS-GPS-200M, Abschnitt 20.3.3.3.3.1) ist klarer:

Könnte die Formel um einen quadratischen Term erweitert werden, so etwas wie$af_2 * (T_{SV} - T_{OC})^2$, Wo$af_2$wäre die Driftrate der Uhr auch in der ersten Zeile jeder Nachricht enthalten?

Es könnte, da das Feld in den Spezifikationen vorhanden ist. Es ist möglich, dass dieser quadratische Term selten verwendet wird. Sein Wert ungleich Null würde bedeuten, dass die Borduhr auch in der Frequenz driftet. Wahrscheinlich würden sie auf die Ersatz-Atomuhr umsteigen (es sei denn, beide Uhren leiden darunter).

Wären auch relativistische Korrekturen erforderlich, um eine UTC-Zeit korrekt zu erhalten?

Ich denke, die relativistische Korrektur ist anwendungsabhängig. Zum Zwecke der Lokalisierung benötigen Sie meines Erachtens keine UTC, nur um 4 gemessene Zeitdeltas mit derselben gemeinsamen Zeitreferenz (GPST) zu synchronisieren.

• Formel im RINEX-Dokument

Die Formel im RINEX-Dokument, Abschnitt 5.4.1 (hier wiedergegeben) ist etwas verwirrend.

Es sieht so aus, als wäre es eine unvollständige Formel, bei der ausgelassene Begriffe durch "..." ersetzt wurden (Aufhängungspunkte, die Sie in Ihrer Frage nicht wiedergegeben haben). Die GPS-Spezifikation, Abschnitt 20.3.3.5.2.4 ist viel klarer. Es liest:

A0 und A1 haben also eine ähnliche Rolle wie af0 und af1. Zusammen mit den Schaltsekunden dienen sie dazu, die Drift von GPST in Bezug auf UTC zu korrigieren, ähnlich wie af0, af1 (und möglicherweise af2) dazu dienen, die Drift von zu korrigieren$T_{SV}$in Bezug auf GPST.

Beachten Sie, dass die Bezugszeit für die Berechnung des Korrekturterms gilt$T_{UTC}$Ist$T_{OT}$(und nicht die Referenz$T_{OC}$für den Korrekturterm für$T_{SV}$)

Ich habe die GLONASS-Spezifikationen nicht gelesen, aber ich denke, dass alle GNSS-Uhrkorrekturen (Galileo, Beidou, ...) dem gleichen Ansatz folgen, nur mit Unterschieden in der Notation der Begriffe. Eine gute Übung wäre es, die gleichen Abschnitte in ihren Spezifikationen zu lesen (dafür bin ich zu faul!).

Dank der sehr aufschlussreichen Erklärung von @NgPh konnte ich endlich herausfinden, wie Uhrkorrekturen an UTC für GPS- und GLONASS-RINEX-Navigationsdateien korrekt durchgeführt werden. Ich habe jetzt meine eigene Implementierung abgeschlossen und dachte, es wäre eine gute Idee, eine Zusammenfassung des Prozesses zu hinterlassen, da ich glaube, dass sie hier richtig ist. Beachten Sie, dass sich die hier beschriebenen Prozesse darauf beziehen, wie die Zeit von Ephemeriden korrigiert wird (um es in einfachen Worten auszudrücken, die Zeit, zu der der bereitgestellte Zustandsvektor des Satelliten gültig ist).

GPS

Hier sind 2 Schritte erforderlich: Konvertierung der individuellen GPS-Satellitenzeit in systemweites GPST und Konvertierung von GPST in UTC.

1. Abrufen$T_{OC}$, die, wie in IS-GPS-200M, Abschnitt 20.3.3.3.3.1 beschrieben, die Referenzzeit zum Durchführen der Korrektur der individuellen GPS-Zeit auf das systemweite GPST ist. Dies wird durch die Felder 2 bis 7 (Epoch Year, Month, Day, Hour, Minute und Second) der 1. Zeile jeder Nachricht angegeben (Anmerkung: Eine einzelne RINEX-Datei enthält einen Header und mehrere Nachrichten), wie in Tabelle A4 hier beschrieben
2. Konvertieren Sie die abgerufenen$T_{OC}$zur GPS-Woche und Sekunden der aktuellen GPS-Woche, indem berechnet wird, wie viele Sekunden seit Mitternacht zwischen dem 5. und 6. Januar 1980 es entsprechen. Das Ergebnis kann modulo 604800 unterzogen werden, um die Sekunden der aktuellen GPS-Woche zu erhalten, und seine ganzzahlige Division durch 604800 ergibt die aktuelle GPS-Woche (in kontinuierlicher Skalierung, dh nicht modulo 1024, wie es sowieso der Fall ist, wie sich GPS-RINEX-Navigationsdateien zu verteilen scheinen GPS-Wochen)
3. Rufen Sie die aktuelle GPS-Woche und die aktuellen Sekunden der GPS-Woche für die Ephemeridenzeit ab. Diese werden jeweils in Feld 3 von Zeile 5 und Feld 1 von Zeile 3 jeder Nachricht gespeichert. Beachten Sie, dass die GPS-Woche für die Ephemeridenzeit kontinuierlich skaliert ist, nicht modulo 1024.
4. Berechnen Sie die Sekunden des Unterschieds zwischen der Zeit der Ephemeriden und$T_{OC}$. Beachten Sie, dass die Differenz in Sekunden auf einen Bereich zwischen -302400 und +302400 gebracht werden sollte, um potenzielle GPS-Wochenkreuzungen zu berücksichtigen.
5. Berechnen Sie einen relativistischen Korrekturterm. Die Formel findet sich auch bei IS-GPS-200M, Abschnitt 20.3.3.3.3.1. Bitte beachten Sie, dass die Typografie in der Datei, auf die ich zugreifen konnte, zu Verwirrung führen kann, da sie zu zeigen scheint, dass die Quadratwurzel der großen Halbachse der Exponent für die Exzentrizität zu sein scheint, während sie in Wirklichkeit nur ein weiterer multiplikativer Faktor ist . Beachten Sie auch, dass die Berechnung eines solchen relativistischen Terms die Berechnung der exzentrischen Anomalie erfordert. Dies kann nach den in Tabelle 20-IV des IS-GPS-200M-Dokuments beschriebenen Schritten erfolgen.
6. Subtrahieren Sie von der individuellen Satellitenzeit die zuvor berechneten Sekunden der Differenz zwischen GPST und individueller Satellitenzeit und den relativistischen Term.
7. Berechnen Sie eine Korrektur von GPST zu UTC. Dies ist eine weitere Polynomkorrektur mit Bezugszeit$T_{OT}$die in der Kopfzeile als GPS-Wochennummer/Sekunden des GPS-Wochenpaars angegeben ist. Die Terme nullter Ordnung (Bias) und erster Ordnung (Drift) für die Korrektur sind ebenfalls in der Kopfzeile angegeben, die als A0- und A1-Parameter bezeichnet werden, wie in Tabelle A3 dieses Dokuments beschrieben . Außerdem müssen wir die seit dem 6. Januar 1980 eingeführten Schaltsekunden abziehen. Diese sind ebenfalls im Header der Datei angegeben.
8. Durch Anwenden der obigen Korrekturen erhalten wir eine korrigierte Anzahl von Sekunden der aktuellen GPS-Woche, die zu der Anzahl von Sekunden addiert werden kann, die aus der aktuellen GPS-Woche berechnet wurde, um die Anzahl von Sekunden seit Mitternacht des 5. bis 6. Januar 1980 zu erhalten Diese kann dann direkt in eine UTC-Datum-Uhrzeit umgewandelt werden.

GLONASS

Bei GLONASS-Dateien scheint die Situation einfacher zu sein, obwohl es immer noch ein paar Dinge gibt, bei denen ich mir nicht 100% sicher bin. Es sollte beachtet werden, dass die GLONASS-Zeit an die UTC-Zeit gebunden ist und es zu jedem Zeitpunkt nur einen kleinen Offset gibt (normalerweise im Bereich von einigen hundert Nanosekunden und in jedem Fall immer unter 1 ms, wie auf Seite 15 von angegeben die GLONASS-Spezifikationen ). Darüber hinaus liefern RINEX GLONASS-Navigationsdateien Ephemeriden direkt in kartesischen Koordinaten im ECEF-Frame. Ich glaube, das richtige Verfahren zum Erhalten der genauesten UTC-Zeit ist:

1. Erhalten Sie die Ephemeridenzeit in GLONASS-Zeit des einzelnen GLONASS-Satelliten. Es sollte beachtet werden, dass dies anscheinend durch die Zeitparameter in der ersten Zeile jeder Nachricht in der Datei für den Fall von RINEX GLONASS-Dateien gegeben ist. Dies ist ein entscheidender Unterschied zu GPS-Dateien, die entsprechende Felder bereitstellen$T_{OC}$, die Referenzzeit zum Durchführen einer Korrektur von der individuellen Satelliten-GPS-Zeit zur systemweiten GPST. Dies wird durch die Tatsache unterstützt, dass Tabelle A11 in der Beschreibung von RINEX-Formaten besagt, dass solche Zeitparameter in der 1. Zeile jeder Nachricht die "Epoche der Ephemeriden" sind. Vergleichen Sie dies mit Tabelle A4 desselben Dokuments, das GPS-Dateien entspricht, wo die Zeitparameter als "Epoche: Toc - Time of Clock" beschrieben sind.
2. Abschnitt 8.2 der erwähnten Beschreibung der RINEX-Formate besagt, dass die Zeitkorrektur für GLONASS-Satelliten wie folgt berechnet werden sollte:$T_{UTC} = T_{SV} + Tau_N - Gamma_N * (T_{SV} - T_b) + Tau_C$. Ich verstehe$T_{SV}$ist die Zeit des Satellitenfahrzeugs, die auf UTC korrigiert wird, aber ich war verwirrt, was genau$T_b$Ist. Es gibt keine andere Erwähnung von$T_b$in der Beschreibung der RINEX-Formate. Wenn Sie jedoch die GLONASS-Systemspezifikationen erneut im Detail überprüfen, scheint dies der Fall zu sein$T_b$definiert den Zeitpunkt, für den die Ephemeridenparameter gültig sind. Dafür spricht beispielsweise die Tatsache, dass in Tabelle 4.6 dieses Dokuments eine Notation für die Position, Geschwindigkeit und Beschleunigung des Satelliten verwendet wird, die sie als Funktionen von definiert$T_b$. Daher gehe ich davon aus$T_b$in der Formel, die in dem Dokument gefunden wird, das RINEX-Formate beschreibt, ist tatsächlich die Zeit von Ephemeriden. Für den Fall der Korrektur der Ephemeridenzeit gilt also:$T_{SV} = T_b$, und damit das Produkt mit$Gamma_N$ist ebenfalls 0, wodurch die Konvertierung auf die Anwendung einer Taktvorspannung auf die systemweite GLONASS-Zeit reduziert wird (bereitgestellt von$Tau_N$, das im 8. Feld der ersten Zeile jeder Nachricht angegeben ist), und dann ein Offset zur UTC-Zeit (bereitgestellt von$Tau_C$, die im Header jeder Datei angegeben ist und für alle Nachrichten in der entsprechenden Datei gilt).
3. Es gibt einen weiteren Zeitparameter in RINEX GLONASS-Navigationsdateien,$t_k$, angegeben im 10. Feld der 1. Zeile jeder Nachricht. Es scheint auf Seite 22 der GLONASS-Systemspezifikationen definiert zu sein , aber ich verstehe seine Bedeutung noch nicht vollständig. Ich bin mir nicht sicher, wie/ob es verwendet werden sollte, um überhaupt Uhrkorrekturen durchzuführen. Wäre super, wenn das jemand klären könnte!
4. Außerdem gibt es keine explizite relativistische Korrektur für GLONASS-Zeiten. Dies liegt daran, dass es implizit in enthalten ist$Tau_N$Und$Gamma_N$, wie hier auf Seite 18 beschrieben .