Wie erhält man UTC der Epochenzeit in einem Satelliten-TLE (Zwei-Linien-Element)?

Ich möchte die Epochenzeit einer TLE in UTC umwandeln. Ich interessiere mich im Moment weniger für Erklärungen und Geschichte - ich möchte nur quantitativ sicher wissen, wie man konvertiert.

Ich bin verwirrt, weil ich Verweise auf UT und JD auf NASA- und Celestrak-Sites sehe, wie unten gezeigt. Da Julian Date derzeit mit ungefähr 68,184 Sekunden (sowie einem Versatz von 0,5 D) vor UT liegt, stecke ich fest.

Die Epochenzeit in der TLE wird auf mindestens zwei Arten verwendet. Erstens - es ist die Zeit, in der die Vorhersage des TLE am genauesten ist. Zweitens – (glaube ich) ist es der Zeitpunkt, der dem mittleren Anomaliewert in Zeile 2 des TLE entspricht, der in diesem Beispiel 66,7566 Grad beträgt:

TLE = """
1 25544U 98067A   16031.25992506  .00006019  00000-0  97324-4 0  9994
2 25544  51.6430  25.8646 0006733  62.5910  66.7566 15.54344726983528
"""

Meine Frage: Wie ist die genaue Beziehung zwischen der Epochenzeit in einem TLE und der entsprechenden Zeit in UTC?

Die aktuelle Differenz kann auch mit Skyfield angezeigt werden :

from skyfield.api import JulianDate

jd = JulianDate(utc=(2016,1,1))

print jd.tt, "days"
print jd.tt % 1, "day fraction"
print ((jd.tt % 1) - 0.5) * 24. * 3600, "seconds"

gibt

2457388.50079 days
0.500789166894 day fraction
68.1840196252 seconds

Diese NASA -Seite nennt die Fraktion "Julian Day Fraction":

NASA TLE 2line.gif

NASA TLE-Screenshot

aber auf dieser Celestrak- Seite steht das

Celestrak TLE-Screenshot

"Beachten Sie, dass der Epochentag um UT Mitternacht (nicht Mittag) beginnt und dass alle Zeiten in mittleren Sonnen- und nicht in Sternenzeiteinheiten gemessen werden (die Antwort auf unsere dritte Frage)."

Ich habe hier nach der Konvertierung von Python in Computerzeit gefragt: "Sekunden seit Epoche" .

Antworten (4)

Gegeben: 16031.25992506

Die 16 entspricht 2016. Da 1957 das erste Jahr war, in dem Satelliten gestartet wurden, wäre 57 1957, und 2057 könnte sich dies ändern, da es ein Problem geben wird.

Die 31 bedeutet den 31. Tag des Jahres (31. Januar)

0,25992506 ist der Bruchteil des Tages ab Mitternacht. Dies bedeutet 6,2382 Stunden, 14,292 Minuten, 17,52 Sekunden, im Grunde genommen durch Multiplizieren mit 24 zuerst, dann Entfernen der Stunden, dann 60, dann Entfernen der Minuten, dann wieder 60, um die Sekunden zu erhalten.

Schaltsekunden sind nicht wirklich definiert. Die NASA hat angegeben, dass der praktizierte Standard ist :

In der Praxis hält es im Allgemeinen UTC-Zeiten, aber Schaltsekunden werden auf die erste Sekunde des nächsten Tages überladen.

Das Fazit ist also, dass die Konvertierung Ihnen die Zeit in UTC geben sollte. Schaltsekunden sind ärgerlich, aber die Zeit sollte immer noch UTC sein.

Das Wort „Julian“ auf der NASA-Seite – warum steht es dort? Sie sagen, dass die Dezimalstelle nur "Tagesbruchteil" in UTC ist, richtig? Warum fügen sie "Julian" zu "Day Fraction" hinzu?
Julian bezieht sich auf den julianischen Kalender und bezieht sich auf den Tag des Jahres. Siehe en.wikipedia.org/wiki/Julian_day

Die beste Vermutung über die in TLE-Dateien verwendete Zeitskala stammt aus dem epischen Revisiting Spacetrack Report #3 -Bericht von Celestrak, den sie hier online gestellt haben:

https://celestrak.org/publications/AIAA/2006-6753/

Sie nahmen die alte SGP4-Software, sammelten jeden einzelnen Patch und jede Verbesserung, die sie in den Dutzenden von Versionen finden konnten, die online und in verschiedenen Labors herumgereicht wurden, und veröffentlichten eine neue, bereinigte Version des Algorithmus (tatsächlich die in Skyfield verwendete).

In „Abschnitt E“ des Berichts vermuten sie, dass die Zeit entweder in UTC oder UT1 angegeben ist, und kommen zu dem Schluss, dass der Unterschied nicht wirklich wichtig ist, weil SGP4 einfach nicht genau genug ist, um Satellitenpositionen für <1 Sekunde vorherzusagen. (Der Unterschied zwischen UTC und UT1 beträgt immer weniger als eine Sekunde.) Sie sagen:

Die Zeiterfassung innerhalb von SGP4 wird auf die Epoche der TLE-Daten referenziert. … Das Zeitsystem wird hier als UTC angenommen, aber es existiert keine formale Dokumentation und UTC, wie es derzeit definiert ist, wurde erst 1972 eingeführt. UT1 wird benötigt, um GMST für die im Anhang diskutierten Koordinatentransformationen zu berechnen, aber es ist nicht bekannt, ob UT1 oder UTC wird von der Software benötigt, obwohl wir für dieses Dokument von UT1 ausgehen. Der mit der Annäherung von UT1 an UTC verbundene Fehler liegt innerhalb der theoretischen Unsicherheit der SGP4-Theorie selbst. Mit Ausnahme der GMST-Berechnung gehen dieses Dokument und dieser Code davon aus, dass die Zeit als UTC realisiert wird.

Sie können also TAI, TT und TDB ignorieren, wenn Sie mit Satelliten arbeiten. Alle Zeiten, mit denen Sie es zu tun haben, werden wahrscheinlich UTC sein.

Das ist wichtig und wird sehr geschätzt. Es ist gut, diese Informationen in diese Diskussionen einfließen zu lassen. Vielen Dank, dass Sie Space SE und Skyfield im Auge behalten! All dies über ein paar Zeilen Python-Skript erreichen zu können, ist fantastisch!

Der Begriff "julianischer Tag" (oder Datum) hat drei sehr unterschiedliche Bedeutungen. Für Historiker bedeutet es normalerweise ein Datum, das im Julianischen Kalender ausgedrückt wird, im Gegensatz zum gregorianischen Kalender. Beispielsweise ist das julianische Datum 3. September 1752 derselbe Tag wie das gregorianische Datum 14. September 1752. Für Astronomen bedeutet es die Anzahl der Tage seit Mittag (in einigen Zeitskalen, typischerweise TT oder UT) am 1. Januar 4713 v. Chr. ( Julianisch). Beispielsweise bezieht sich JD 2357569 auf Mittag UT am 14. September 1752.

Die dritte Bedeutung ist die Tagesnummer des Jahres, wobei 1 den 1. Januar bedeutet. Diese dritte Bedeutung ist die Bedeutung, die auf der zitierten NASA-Seite gemeint ist.

Ah ich sehe! Ok, ich lasse mich also nicht länger von der Verwendung von „Julian“ auf der NASA-Seite abschrecken. TLE-Epochen sind in UTC (innerhalb von etwa einer Sekunde, wie oben erwähnt). Vielen Dank!

Celestrak gibt an, dass die Zeit UT ist.

"https://celestrak.org/columns/v04n03/#FAQ03"

UT ist die astronomische (genauer Rotations-) Zeit. Sie wird durch Beobachtungen in Abhängigkeit von der Erdrotation bestimmt und wird üblicherweise mit der scheinbaren Sternzeit in Beziehung gesetzt. Die Konventionen werden gewählt, um UT mit der Sonne zu synchronisieren.

Das United States Naval Observatory http://aa.usno.navy.mil/faq/docs/UT.php sagt Folgendes über UT:

Im astronomischen und Navigationsgebrauch bezieht sich UT oft auf eine bestimmte Zeit namens UT1, die ein Maß für den Rotationswinkel der Erde ist, wie er astronomisch beobachtet wird. Es wird durch kleine Variationen in der Rotation der Erde beeinflusst. UT1 ist eine moderne Form der mittleren Sonnenzeit auf dem Greenwich-Meridian. Zeiten, die in Daten, die von der Abteilung für astronomische Anwendungen des US Naval Observatory bereitgestellt werden (z. B. in den jährlichen Almanachen), als "Universal Time" oder "UT" bezeichnet werden können, entsprechen dieser Definition.

Im gebräuchlichsten zivilen Sprachgebrauch bezieht sich UT jedoch auf eine Zeitskala namens "Coordinated Universal Time" (abgekürzt UTC), die die Grundlage für das weltweite System der zivilen Zeit bildet.

Der Offset zwischen UT und UTC liegt immer im Bereich von -0,9 bis 0,9 Sekunden. UT läuft langsamer als UTC, so dass positive Schaltsekunden (die einzige Art, die bisher verwendet wurde) UT eine Chance geben, aufzuholen. Wenn UTC mehr als etwa 0,5 Sekunden vor UT liegt, wird eine Schaltsekunde eingefügt, wonach UT UTC um etwa eine halbe Sekunde vorauseilt. Keine Sorge, UTC wird in etwa neun Monaten aufholen. https://www.nist.gov/pml/time-and-frequency-division/atomic-standards/leap-second-and-ut1-utc-information

Die von NORAD zum Aktualisieren eines TLE verwendeten Regeln lauten, dass, wenn die aktuelle Position eines Satelliten basierend auf den letzten Messungen von der SPG4-Vorhersage basierend auf dem letzten Satz veröffentlichter TLE um mehr als 5 Kilometer abweicht, das TLE aktualisiert wird. Die Genauigkeit von SPG4/TLE-Vorhersagen ist ein weiteres Thema.

Die Orbitalkinematik ignoriert Schaltsekunden. Man sollte die Position eines Satelliten unter Verwendung von SI-Sekunden in SPG4 verbreiten. Wenn die Zeit zwischen der in der TLE angegebenen Epoche und der Vor- oder Nachdiktion eine Schaltsekunde umfasst, müssen die Benutzer dies berücksichtigen können.

Vielen Dank! Stimmt Ihre Antwort in irgendeiner Weise mit dieser Antwort nicht überein ?
Ich denke, die Verwendung des Begriffs „Julian Day“ in Beschreibungen von TLE ist verwirrend und unnötig. 1.) Bleiben Sie beim Begriff „Tag des Jahres“, wobei der 31. Dezember 2017 00:00 Uhr der Tag 0.0 von 2018 ist. 2.) Siehe Originalbeitrag zur Behandlung von Schaltsekunden. TLE und SPG4 ignorieren Schaltsekunden. Verwenden Sie sie nur für die Übersetzung der Epoche in DoY in UT1 und die Übersetzung der Vorhersage in UT1 in UTC für Ihre Anwendung. FWIW, ich habe Radardaten analysiert, die aus der Kollision eines Kosmos-Satelliten mit einem Iridium resultierten, und meine "Nachdiktion" für den Punkt der engsten Annäherung war 70 Meter, wenn ich meinen Ansatz verwendete.
Für ein nicht erdgebundenes Objekt wäre die mittlere Bewegung 0,0. TLE kann nur keplersche (elliptische) Umlaufbahnen modellieren. Humanity Star (grausame Fehlbezeichnung!) zieht mehrmals am Tag überall auf der Erde über uns hinweg. Sie können es nur in der Dämmerung sehen, wenn der Satellit von der Sonne beleuchtet wird und die Sonne unter dem Horizont steht. Gehen Sie hier: n2yo.com/?s=43166
Du solltest den Kommentar auch unter dem anderen Post machen, nicht nur hier. Wenn Sie sich das, was ich dort geschrieben habe, genauer ansehen und über die Mathematik nachdenken, würde ein negatives Vorzeichen in der mittleren Bewegung ausreichen, zumindest für hyperbolische Vorbeiflüge. Ich glaube, es gibt sogar ein Leerzeichen dafür; Spalte 52. Ich bin mir noch nicht sicher, ob es so ein offener und geschlossener Fall ist.