Angenommen, ich möchte TLEs mit tatsächlichen LEO-Satellitenpositionen vergleichen, welche Daten sind verfügbar? Aus welchen kann es am einfachsten sein, X-, Y-, Z-, T-Punkte zu extrahieren?

Unter der Antwort von @ RyanC auf Wie kann ich die Trajektorie des Satelliten von drei verschiedenen TLEs aus darstellen, um Abweichungen vom Pfad mit der Zeit zu erkennen? Ich hab geschrieben:

Ich denke, dass SGP4 + TLEs so beliebt sind, weil die TLEs die einzigen Satellitendaten sind, die so leicht verfügbar sind. Wenn ich mich nicht irre, erfordert das Erhalten besserer Daten über Zustandsvektoren bestimmter Satelliten eine Kombination aus Geld, Erlaubnis und Zugang zu Ortung oder Telemetrie. Einige wissenschaftliche Erdbeobachtungssatelliten könnten die Ausnahme sein; in ihren Datenprodukten können sie tatsächlich genaue Zeiten und Positionen haben.

Mit anderen Worten, es kann einige öffentlich zugängliche Datenprodukte geben, wo X , Y , Z , T Punkte sind enthalten, und ich denke, es kann mehrere wissenschaftliche Erdbeobachtungssatelliten geben, bei denen dies der Fall ist.

Frage: Angenommen, ich möchte TLEs mit tatsächlichen LEO-Satellitenpositionen vergleichen, welche Daten sind verfügbar? Aus welchen kann es am einfachsten sein, X-, Y-, Z-, T-Punkte zu extrahieren?

Bei einigen Satelliten kann es einige ernsthafte Grabungen oder das Herunterladen anderer Software-Tools erfordern, bevor diese Art von Metadaten extrahiert werden können, aber bei anderen ist es vielleicht ziemlich einfach. Ich weiß, dass die DSCOVR-Bilddownloads (zumindest früher) einen JSON mit solchen Daten enthalten, aber das ist in einer heliozentrischen (Halo-) Umlaufbahn, nicht LEO.

@Chris das ist ausgezeichnet, danke! Ich habe Angst vor Zeitumrechnungen, z. B. in diesem Fall, wie man "Epoche in (Sekunden) seit J2000-Epoche Terrestrial Time" in UTC umwandelt. Ich denke, das ist wahrscheinlich nicht schwer, aber um zu versuchen, Vergleiche unter km durchzuführen, muss es auf zehn Millisekunden genau durchgeführt werden.
@uhoh Ich habe kürzlich auch versucht, mit Planet Labs eine sehr schöne Kombination aus echten Ephemeriden / TLEs zu arbeiten, und in Bezug auf die Konvertierung der Epoche in Sekunden seit J2000 Terrestrial-Zeiten dachte ich, dass es möglich sein könnte, eine genaue Konvertierung durchzuführen, indem ich die J2000-Epoche einbeziehe UTC ( astro.vaporia.com/start/epoch.html ) und addiert einfach die Sekunden . Ich verwende R's as.POSIXct , aber ich glaube, dass Python ähnliche Funktionen mit der datetime-Bibliothek hat, wo Sie die Ursprungsepoche und die Anzahl der Sekunden seitdem angeben können, um eine Datum-Uhrzeit-Zeichenfolge in der gewünschten Zeitzone (UTC) zu erzeugen?
@Rafa, die Herausforderung besteht aus zwei Teilen. Es ist eine Sache, eine J2000-Epoche wie in Sekunden in ein anderes Zeitformat zu ändern 691928619.184000, aber es ist eine andere, sicherzustellen, dass es bis auf die Ebene von ~Millisekunden korrekt ist. Nur zum Beispiel Wie konvertiere ich J2000-Zeit in UTC in Python? hat mehrere Antworten, aber sind sie richtig, um die Millisekundengenauigkeit zu bestellen? Die Zeit ist hart; Zeit ist verwirrend!
@uhoh Sicherlich habe ich den großen Schmerz erkannt, der durch den Versuch verursacht wird, genaue Zeitumrechnungen durchzuführen! (Ich glaube, nur vergleichbar mit der Konvertierung zwischen Bezugsrahmen). Ich glaube, dass die von Planet Labs bereitgestellte Ressource sehr wertvoll ist, also habe ich (kurz vor einem Time Conversions Exchange) bei Astronomy Exchange astronomy.stackexchange.com/questions/47712/… danach gefragt.

Antworten (1)

Ein zentraler Verteilungspunkt für alle wissenschaftlichen Missionen und alle GNSS-Missionen ist das Crustal Dynamics Data Information System (CDDIS) im NASA Goddard Space Flight Center.

Die Daten sind hier verfügbar: https://cddis.nasa.gov/Data_and_Derived_Products/GNSS/orbit_products.html

Das Projekt wird hier beschrieben: https://earthdata.nasa.gov/eosdis/daacs/cddis

Es gibt viele verschiedene Produkte, von denen einige einfacher zu verarbeiten sind als andere. Rafas jüngste Antwort und Kommentare zum Vergleich von SDP4 & SGP4 mit hochpräzisen Orbits erwähnen das Parsen von RINEX für GPS, GLONASS und DORIS , also könnten Sie versuchen, dort zu beginnen.

Die Registrierung für ein Konto ist erforderlich, aber auf der Website heißt es: „EOSDIS-Daten sind für alle offen und kostenlos verfügbar, sofern dies nicht durch internationale Vereinbarungen geregelt ist.“

Um TLEs in kartesische Vektoren umzuwandeln, empfehle ich, die neueste SGP4-Bibliothek von https://www.space-track.org/documentation#/sgp4 zu beziehen (Sie müssen bei Ihrem kostenlosen Konto angemeldet sein, damit der Link funktioniert). Versionshinweise für dieses Softwarepaket – Version 8.2 (vom 15. November 2021) der ehemaligen USAF, jetzt US Space Force (USSF) Standard Astrodynamics Algorithms Library (SAAL) – sagt: „Einige Fehler wurden behoben, die die Leistung beeinträchtigten. SGP4 v8 .2 ist jetzt mehr als doppelt so schnell wie v8.1 (mehr als viermal so schnell wie v8.0)", also ändert sich SGP4 tatsächlich weiter, wenn auch nicht sehr viel auf einmal.

Die Bibliothek ist in Fortran und C/C++ implementiert, aber es gibt auch Wrapper für C#, Go, Java, Julia, Matlab, Octave, Python, Tcl und Visual Basic. Diese Liste wächst schnell; es war nur etwa halb so lang, als ich vor zwei Jahren anfing, es hier zu posten. Die Wrapper sind nicht besonders elegant oder intuitiv, es sei denn, Sie haben gelernt, in Fortran zu programmieren, also schreiben Sie vielleicht lieber Ihren eigenen Wrapper um ihren Wrapper, um ihn beispielsweise "pythonischer" zu machen, aber es erledigt die Arbeit.

Sie erhalten auch mehr als nur SGP4. Beispielsweise handhaben die AstroFunc- und TimeFunc-Bibliotheken Konvertierungen von UTC zu TAI zu GHA (Greenwich Hour Angle), Kepler-Elemente zu Äquinoktialen zu Pos-Vel zu Lat-Lon, berechnen Positionen von Sonne und Mond, Polarwanderung, bestimmen, ob ein Punkt in der erdnahe Weltraum ist sonnenbeschienen und so weiter. Viele andere Pakete tun dieselben Dinge, aber wenn Sie sich jemals Gedanken darüber gemacht haben, ob Sie beispielsweise die korrekte Definition von TEME (True Equator, Mean Equinox) in Ihrer Koordinatenkonvertierung verwenden, ist die Verwendung von SAAL mindestens eine anständige Möglichkeit sicherzustellen, dass alle Komponenten des Toolsets mit den Annahmen der anderen übereinstimmen.

Ich persönlich bin verpflichtet, sie bei der Arbeit zu verwenden, da sie von der US-Regierung stammen und Skyfield nicht. Beruflich gewöhnt, nutze ich sie inzwischen (teilweise) auch zu Hause für Hobbyzwecke und bin mir mit der Zeit etwas ans Herz gewachsen, allerdings irritiert mich auch ihre anhaltende Vorliebe für verwirrend definierte feste Längen , schwer zu parsende String-Formate (von denen TLE keineswegs das einzige ist).

Danke! Um mein Leben einfach zu halten, verwende ich das SGP4 innerhalb von Skyfield. Ändert sich das reguläre SGP4 für traditionelle TLEs heutzutage tatsächlich, oder ist Ihre Empfehlung, "die neueste SGP4-Bibliothek von space-track.org zu holen", zukunftsorientierter, z das neue SGP4-XP?
@uhoh Es ist schwer zu sagen, ob es sich wirklich ändert oder ob wir nur neue Wege entdecken, wie der Vallado-Kelso-Erbecode nie ganz mit der Realität übereinstimmte. Vor zwei Jahren fragte mich ein Kollege, warum er aus der Verbreitung von GPS-TLEs imaginäre Zahlen herausziehe. Es stellte sich heraus, dass er eine alte, inoffizielle Matlab-Version verwendete, und als ich ihn auf den neuesten offiziellen Matlab-Wrapper umstellte, verschwand das Problem. War das eine Änderung in SGP4 oder nur ein lange vergrabener Fehler, der immer darauf wartete, ein Problem zu verursachen? Ich weiß es nicht, aber ich ziehe es vor, das Original zu haben, nur um sicherzugehen.