Was hat das ISS Two Line Element Day of Year-Problem ab dem 24.12.2019 verursacht?

Weiß jemand, was bei NORAD oder der NASA oder wo auch immer die veröffentlichten TLEs ihren Ursprung haben, was in der letzten Woche des Jahres 2019 zu den TLE-Schwankungen der ISS geführt hat? 2018 ist das nicht passiert. Was ist passiert? Der Tag des Jahres wurde nach 365 Tagen (kein Schaltjahr) erhöht, und das Jahr blieb 19 (2019) für berechnete TLE-Sätze, die in die erste Woche des Jahres 2020 und darüber hinaus gingen.

Ich bekomme meine ISS TLE-Sets von hier:

https://spaceflight.nasa.gov/realdata/sightings/SSapplications/Post/JavaSSOP/orbit/ISS/SVPOST.html

und hier:

https://tle.info/data/ISS_DATA.TXT

Mein Code korrigiert jetzt die in meinem Archiv gespeicherten TLE-Daten, nachdem ich zwei Tage lang Code neu geschrieben habe, um ihn beim nächsten Mal zu beobachten (und auf der positiven Seite hat er meine Aufmerksamkeit auf einige meiner eigenen lauernden zukünftigen Probleme gelenkt, die jetzt ebenfalls behoben sind). . Aber ich würde gerne wissen, ob es nur ein Schluckauf war, oder gibt es eine Änderung im Format, die gerade „getestet“ wird? Ab dem 2.1.2020 haben die TLEs, die ich heute erhalten habe, wieder das erwartete Format und werden nicht mehr als Tage von 2019 über 365 hinaus bezeichnet.

Das offizielle Wort?

Verstehen Sie, ich bin sehr dankbar, dass wir all diese wunderbaren Dienste zur Verfügung haben und dass ich nicht mehr auf die Papierberichte von Greenbelt, MD, schielen oder sie manuell eintippen muss, wie es vor so vielen Jahren notwendig war (aber selbst dann, dankbar dafür). Ich würde gerne wissen, ob es Änderungen in den Arbeiten gibt, auf die ich mich im Voraus vorbereiten könnte. Und ein großes Dankeschön an alle, die die Server und Dienste und Softwaretools warten, die hier so sehr geschätzt werden.

Aktualisierung 1-2-2020

Als Antwort auf die Anfrage von uhoh in den Kommentaren sind hier drei Beispiel-TLE-Sets, die am 30.12.2019 erworben wurden, aber das Problem wurde erstmals am 24.12.2019 von den oben genannten Links gesehen. Beachten Sie die erste hier (die nicht die erste TLE auf der Webseite war, aber ich kondensiere). Es ist in Ordnung. Aber die anderen, von denen ich zwei zeige, haben 2019 als Jahr (natürlich wird die führende 20 nicht im Standardformat angezeigt), aber dann ist der Tag des Jahres 366 (kein Schaltjahr), und dann im letzten TLE, der Tag des Jahres ist 372? Und das Jahr ist immer noch 19. Was ich "wackelig" genannt habe.

ISS
1 25544U 98067A   19365.78947330  .00016717  00000-0  10270-3 0  9114
2 25544  51.6407 101.7439 0005315  86.0590 274.1168 15.49502788  5904

ISS
1 25544U 98067A   19366.82137887  .00016717  00000-0  10270-3 0  9129
2 25544  51.6392  96.6358 0005156  88.7140 271.4601 15.49497216  6061

.
.
.

ISS
1 25544U 98067A   19372.17436792  .00016717  00000-0  10270-3 0  9187
2 25544  51.6415  70.1365 0004825 107.1627 253.0051 15.49525362  6890

Ich habe meinen Code geändert, um dies beim Lesen aus meinen Archiven abzufangen und zu korrigieren, wobei ich natürlich auch die Prüfsumme neu berechnet habe, da meine Archive die "wackligen" behalten, wie ich sie zuerst bekommen habe. (Für diejenigen, die die Frage stellen möchten: Ja, ich habe vergessen, die Prüfsumme beim ersten Mal neu zu berechnen.) Hier ist die verarbeitete Version dieses letzten Satzes, die jetzt gut mit Pyephem funktioniert (was ich ehrlich gesagt froh bin, dass mir die falsche Prüfsumme nicht gefallen hat):

ISS
1 25544U 98067A   20007.17436792  .00016717  00000-0  10270-3 0  9184
2 25544  51.6415  70.1365 0004825 107.1627 253.0051 15.49525362  6890

Ich würde gerne weitere Details oder Code zur Verfügung stellen, wenn sie helfen würden, aber in erster Linie frage ich, ob jemand weiß, ob dies nur ein Verarbeitungsproblem am Ende des Jahres war, wie eine Mini-Y2K-Sache, oder ob es einige Änderungen gibt Format in Arbeit, und sie waren noch nicht ganz bereit für die Hauptsendezeit? Wie die meisten Menschen würde ich es vorziehen, für eine bekannte bevorstehende Änderung vorauszuprogrammieren, als mich davon überraschen zu lassen. Und das ist das Teilmotiv meiner Frage.

Aktualisierung 1-4-2020:

Lesen Sie jetzt den Spacetrack-Bericht Nr. 3, um weitere Einblicke zu erhalten. Für Interessierte hier der Link:

https://celestrak.org/NORAD/documentation/spacetrk.pdf

Während ich dies weiter recherchiere, hoffe und begrüße und schätze ich weiterhin mehr Einblicke von anderen.

Obwohl ich meine Antwort noch nicht habe, ist es für andere praktisch, sich bewusst zu machen, dass doy > Zieljahrtage in einer Jahressituation ein mögliches Epochendatum ist, das in TLEs in der letzten Woche davon angetroffen werden kann Jahr oder sogar beginnend mit dem Vorjahr (?!, da wir noch nicht festgestellt haben, ob es ein festes hartes Limit von weniger als 999 gibt, bevor das Jahr erhöht wird und das Doy für dieses Jahresinkrement richtig angepasst wird), und so die eigene Codebasis muss sich damit befassen, wo immer es Probleme verursachen kann, wenn es unerwartet auftritt. IOTW, schreiben Sie Code, um es zu erwarten.

@uhoh als Antwort auf deinen Kommentar habe ich heute ein Update mit einigen Beispielen hinzugefügt.
Was auch immer der Grund für diese speziellen Daten ist – die Datenkonvertierungsfunktionen Ihrer Programmiersprache sollten damit zurechtkommen. Es ist sehr üblich, sich auf Dinge wie „Tag -1“ für den letzten Tag des letzten Monats oder „34. Oktober“ für den dritten Tag im November zu beziehen. Es ist einfach sehr bequem mit Berechnungen.
@asdfex Nachdem ich mehrere Quellen gelesen habe, die einen Schlüssel zum Verständnis der Daten in den verschiedenen Positionen eines Satzes mit zwei Zeilenelementen enthalten, bin ich noch nicht auf Details wie Ihre gestoßen. Es ist sehr üblich, sich auf Dinge wie „Tag -1“ für den letzten zu beziehen Tag des letzten Monats oder „34. Oktober“, um sich auf den dritten Tag im November zu beziehen. . Ich glaube, ich bin nicht der einzige, der es auf den vielen Seiten, die uns informieren sollen, deutlicher und deutlicher und offiziell haben möchte. Vielen Dank, dass Sie mit Ihrem Kommentar dazu inspiriert haben, diese Lücke zu füllen.
Wenn es tatsächlich, wie gesagt, „sehr häufig“ ist, wirft dies die Frage auf: „Wie weit außerhalb der erwarteten Standardbereiche in diesem Zusammenhang kann man vernünftigerweise erwarten, dass das Epochendatum eines offiziellen Titels außerhalb der kulturell üblichen erwarteten Bereiche der Gregorianischer Kalender? Fünf Tage? Neun Wochen? Weniger als 999 Tage?“ Gibt es ein Dokument, das dies verdeutlicht? Es könnte sich als äußerst hilfreich erweisen, wenn Sie Code entwerfen und Tests für diesen Code schreiben.
Mein Kommentar bezog sich auf die Arbeit mit Datumsobjekten in jeder Art von Software, nicht speziell auf TLEs.
@asdfex ok. Verstanden. Mein Code macht ausgiebigen Gebrauch von solchen Funktionen. Was unerwartet war, waren die tatsächlich veröffentlichten Daten, die außerhalb eines vernünftigerweise erwarteten Bereichs lagen, basierend auf Dokumenten, die einen Schlüssel zum Verständnis der Werte lieferten und implizierten, dass die Bereiche in kulturell akzeptierten Grenzen liegen. Ein Tag des Jahres von 372 für das Jahr 2019 ist nicht die normale kulturell akzeptierte Grenze für Tage in einem gregorianischen Kalenderjahr. Daher meine OP. Ist ein Doy von 372 für 2019 tatsächlich besser darin, eine klare und nicht verwirrende Nutzbarkeit der Daten darzustellen? Auch eine Fußnote auf einem Dateiformatschlüssel würde helfen. Ja?
@always_learning Schau dir einfach die Spezifikation an. Io und siehe da, es gibt mehrere. Eine Sache, die sie alle gemeinsam haben, ist, dass die Epoche der Julianische Tag + Bruchteil ist, angegeben als drei Zeichen im Bereich [0-9]. 999 ist also definitiv die größte akzeptable Zahl, negative Zahlen sind nicht erlaubt. STK sagt auch, dass der größte zulässige Wert 366 ist, eine Einschränkung, die in der NORAD-Spezifikation fehlt. Wenn Sie also die NORAD-Spezifikation strikt implementieren, müssen Sie Tage bis zu 999 zulassen.
@polygnome wären Sie so freundlich, uns einen Link zur NORAD-Spezifikation und zur STK-Spezifikation zu geben, damit andere Leser genau lesen könnten, worauf Sie gerade verwiesen haben? Da noch nichts als Antwort gepostet wurde, werde ich dann versuchen, das bisher Gesagte als erstes Posting einer Antwort zusammenzufassen.
@always_learning Werte > 366, die in TLEs nicht verboten sind, beantwortet kaum die Frage, warum sie das tatsächlich getan haben oder warum sie bei 372 aufgehört haben und dann übergelaufen sind. Deshalb habe ich keine Antwort gepostet, dies sind ergänzende Informationen.
@polygnome Ich stimme zu. Ich habe noch keine Schlussfolgerung, aber ich versuche eine Zusammenfassung, nachdem ich morgen ein paar Artikel gelesen habe. Vielleicht zündet es ein paar Ideen. Wenn NORAD seinen Algorithmus seit Jahren nicht geändert hat, könnte man daraus schließen, dass wir einfach sicherstellen müssen, dass unser Code die Situation richtig handhaben kann. Technisch gesehen ergibt der TLE so oder so die gleiche Umlaufbahn, aber das lässt meine Frage noch unbeantwortet. Wenn es gelegentlich ein mögliches Ergebnis von SGP4 oder Julianischen Daten ist ... ist sicher, dass menschliche vertraute Daten zusätzlichen Code benötigen, um sie bei Bedarf zu überprüfen und zu konvertieren.
@always_learning Ich denke, die überzeugendste Frage von Interesse für die Leser der Website wäre eine objektive Frage zu den zulässigen Bereichen von TLEs in verschiedenen Kontexten, und dies würde es Polygnome ermöglichen, eine informative Antwort für alle zu veröffentlichen. Sie könnten Ihren Titel ändern, um dies zu erreichen. Wenn das Wichtigste für Ihre Frage jedoch "Was verursacht ..." bei spaceflight.nasa.gov ist (was möglicherweise schwer herauszufinden und letztendlich trivial und uninteressant ist), können Sie es so lassen, wie es ist.
@uhoh sehr gute Punkte. Ich habe eine Bearbeitung fast fertig. Nachdem ich auch den Spacetrackreport 3 und den Fortran-Code durchgesehen habe, glaube ich, dass ich einen Hinweis auf die Ursache habe. Wie Sie sagen, höre ich möglicherweise nicht direkt von der NASA oder NORAD, aber ich hoffe, dass meine Spekulation ausreicht, damit andere verstehen, dass der Tag des Jahres dies am Jahresende tun kann, je nachdem, wie oft sie zusätzliche Läufe zur Generierung durchführen Die TLEs, die zum Update führen, laufen am 1. oder 2. Januar. Es kommt darauf an, was ihr aufrufendes Programm füttert und wann ein Update-Lauf stattfindet. Ich werde darauf näher eingehen, wenn ich es fertig geschrieben habe.
@uhoh Es gibt bereits Beiträge darüber, wie weit in die Zukunft eine TLE-Epoche genau bleiben kann usw., mit Beiträgen von ... Ihnen. Ich versuche nicht, mehr Punkte zu sammeln, wenn es bedeutet, ein Thema zu wiederholen, also lasse ich die Frage vielleicht so, wie sie ist, und schließe mit der vielleicht trivialen Antwort, aber diese Antwort war ein Juckreiz, den ich kratzen musste. Als ich die Subroutinen, den DRIVER usw. im Bericht sah, begann ich, ihn in den Fokus zu rücken. Vielleicht eine einfache Frage, wie viele TLEs in die Zukunft ab dem Startdatum des Jobs produziert werden, wobei der aufrufende Code dieses Jahresende-Doy-Problem als, ja, trivial ansieht.
Die meisten meiner Kommentare werden verschwinden, wenn ich die zusammenfassende „Antwort“ poste, da sie die relevanten Teile in eine Zusammenfassung einfließen lässt. Bis dahin sind weitere Vorschläge willkommen.

Antworten (1)

Der SGP4-Propagator verwendet nicht wirklich den Tag des Jahres (nur die Zeit seit der Epoche), daher ist ein Wert über 366 in Ordnung. Einige Leute fügen einer TLE möglicherweise einige Überprüfungen hinzu, um dies als Fehler zu melden, aber der Propagator selbst würde darin kein Problem sehen. Wenn Sie auch sehen möchten, wie viel "Zeit seit Epoche" zwischen der TLE-Epoche und einem bestimmten Datum liegt, könnten Sie bei der Verwendung einer solchen TLE in Schwierigkeiten geraten, aber andererseits ist dies weder mit der TLE noch mit ein Problem SGP4.

Ich vermute, dass das Problem bei der TLE-Erzeugungssoftware liegt (die von NORAD nicht offengelegt wird). Sie propagieren wahrscheinlich die ISS-Umlaufbahn mit besseren numerischen Methoden in die Zukunft und passen eine TLE an eine Mischung aus tatsächlichen und propagierten Positionen an, platzieren die Epoche jedoch nahe am Ende des Anpassungsfensters. Abhängig davon, wie lang das Fenster sein soll und wann die TLE generiert wurde, würden sie möglicherweise eine Epoche generieren, die "nächstes Jahr" stattfindet, aber das Jahresfeld wird von der Software nicht berührt, nur der Tag von Jahresfeld.

Ein anderes Skript/Programm könnte es beheben, und möglicherweise wurde die Software/der Server verschoben oder aktualisiert, und vielleicht hat jemand nicht bemerkt, dass es benötigt wird oder dass es nicht läuft. Vielleicht hat es jemand zur Leistungsverbesserung deaktiviert, weil es "nie" benötigt wird, und vergessen, es wieder zu aktivieren.

Beachten Sie, dass dies teilweise Spekulation ist, aber andererseits fragen wir uns, warum eine nicht offengelegte Software ein Ergebnis liefert, das nicht unbedingt ein Problem darstellt (obwohl ich zustimmen würde, dass es behoben werden sollte).

+1"Der SGP4-Propagator verwendet eigentlich nicht den Tag des Jahres (nur die Zeit seit der Epoche) ..." Wow, das habe ich bis jetzt nie ganz realisiert! Ja, eine schnelle Überprüfung von Revisiting Spacetrack Report #3 zeigt nur zonale Harmonische (J2, J3, J4) und keine Tesserale, die dann die Kenntnis der absoluten Zeit und eines Modells für die Rotation der Erde erfordern würden, und die Ausdrücke werden immer erweitert um (t -t_null).
Nun, nachdem ich in letzter Zeit beschäftigt war und das jetzt sehe, sind es ungefähr 3/4 dessen, was ich jetzt ungefähr zum vierten Mal bearbeite. Es sieht also so aus, als wären wir alle im Allgemeinen auf derselben Seite. Ich mache einige grafische Beispiele, um den Punkt weiter zu verdeutlichen, aber es wird möglicherweise eine Woche lang nicht veröffentlicht. Und ich nehme eine ideale TLE-Epoche in Jahre zurück, um den Doy des Jahres auf nahe 999 zu bringen, um zu sehen, wie es funktioniert, und um erneut zu zeigen, dass eine Epoche hauptsächlich eine Momentaufnahme eines Zeitpunkts ist. Wie Spacetrack rpt3 sagt, verwenden einige Komponenten davon für tiefe Umlaufbahnen einen Offset von 1950 Jan 0,0, um die Schwerkraft von Sonne und Mond zu berücksichtigen.
... Und eine wiederkehrende Variable von TSINCE im Fortran-IV-Code der meisten Subroutinen. Ein definierender Moment und die Zeit seit diesem Moment, die dann den aktuellen Moment des Interesses definieren.
Was hat das ISS Two Line Element Day of Year-Problem ab dem 24.12.2019 verursacht?
AntwortenHierDatenschutz-Bestimmungen1y, 0v