2
$\begingroup$

Under @RyanC's answer to How can I plot satellite's trajectory from three different TLEs to detect any deviation on path with time? I wrote:

I think that SGP4 + TLEs is so popular because the TLEs are the only satellite data so readily available. Unless I'm mistaken, getting any better data on state vectors of specific satellites requires some combination of money, permission, and access to tracking or telemetry. Some scientific Earth observation satellites might be the exception; in their data products they may indeed have precise times and positions.

In other words, there may be some publicly available data products where $X, Y, Z, T$ points are included, and I think there may be several scientific Earth observation satellites where this is so.

Question: Suppose I wanted to compare TLEs to actual LEO satellite positions, what data is available? From which may it be easiest to extract X, Y, Z, T points?

For some satellites it may take some serious digging or downloading of other software tools before this kind of metadata can be extracted, but perhaps for others it's pretty easy. I know that the DSCOVR image downloads (at least used to) contain a JSON with such data, but that's in a heliocentric (halo) orbit, not LEO.

Improve this question
$\endgroup$
5
  • 3
    $\begingroup$ One source: ephemerides.planet-labs.com $\endgroup$
    – Chris
    Dec 5, 2021 at 0:32
  • 2
    $\begingroup$ @Chris that is excellent, thank you! I'm terrified of time conversions e.g. in this case how to convert "Epoch in (seconds) since J2000 epoch Terrestrial Time" to UTC for example. I guess that's probably not hard to do approximately, but for trying to make sub km comparisons it needs to be done correctly to tens milliseconds. $\endgroup$
    – uhoh
    Dec 5, 2021 at 0:44
  • 1
    $\begingroup$ @uhoh I was recently also trying to work with Planet Labs very nice combination of real ephemerides/TLEs, and regarding conversion of epoch in seconds since J2000 Terrestrial times, I thought it might be possible to do an accurate conversion by taking the J2000 epoch in UTC ( astro.vaporia.com/start/epoch.html ) and simply adding the seconds . I use R's as.POSIXct , but I believe python has similar functionalities with the datetime library, where you can specify the origin epoch and the number of seconds since then to produce a date-time string in the desired time-zone (UTC)? $\endgroup$
    – Rafa
    Dec 5, 2021 at 1:57
  • 2
    $\begingroup$ @Rafa there's two parts to the challenge. It's one thing to change a J2000 epoch like 691928619.184000 in seconds to another time format, but it's another to be sure it's correct down to the level of ~milliseconds. Just for example How to convert J2000 time to UTC in python? has several answers, but are they correct to order millisecond accuracy? Time is hard; time is confusing! $\endgroup$
    – uhoh
    Dec 5, 2021 at 2:26
  • 1
    $\begingroup$ @uhoh Certainly, I have realized the large pain brought by trying to perform accurate time conversions! (I believe only comparable to converting between frames of reference). I believe the resource provided by Planet Labs is very valuable, so (short of a Time Conversions Exchange) have asked about this at Astronomy Exchange astronomy.stackexchange.com/questions/47712/… $\endgroup$
    – Rafa
    Dec 6, 2021 at 8:57

1 Answer 1

Reset to default
5
$\begingroup$

One central distribution point for all the scientific missions and all the GNSS missions is the Crustal Dynamics Data Information System (CDDIS) at NASA Goddard Space Flight Center.

The data are available here: https://cddis.nasa.gov/Data_and_Derived_Products/GNSS/orbit_products.html

The project is described here: https://earthdata.nasa.gov/eosdis/daacs/cddis

There are many different products, some of which are easier to work with than others. Rafa's recent answer and comments on comparing SDP4 & SGP4 with high-precision orbits mentions parsing RINEX for GPS, GLONASS, and DORIS, so you might try starting there.

Registration for an account is necessary, but the site says "EOSDIS data are openly available to all and free of charge except where governed by international agreements."

For turning TLEs into Cartesian vectors, I advise getting the latest SGP4 library from https://www.space-track.org/documentation#/sgp4 (need to be registered for and logged into your free account for the link to work). Release notes for this software package — version 8.2 (dated 15 November 2021) of the ex-USAF, now US Space Force (USSF) Standard Astrodynamics Algorithms Library (SAAL) — says "Fixed some bugs hindering performance. SGP4 v8.2 is now over twice as fast as v8.1 (over four times as fast as v8.0)", so SGP4 does indeed continue to change, even if not by very much at a time.

The library is implemented in Fortran and C/C++, but there are also wrappers provided for C#, Go, Java, Julia, Matlab, Octave, Python, Tcl, and Visual Basic. This list is growing quickly; it was only about half as long when I started posting it here two years ago. The wrappers aren't particularly elegant or intuitive, unless you learned to program in Fortran, so you may prefer to write your own wrapper around their wrapper to make it more "Pythonic", for example, but it gets the job done.

You also get more than just SGP4. For example, the AstroFunc and TimeFunc libraries handle conversions from UTC to TAI to GHA (Greenwich Hour Angle), Keplerian elements to equinoctial to pos-vel to lat-lon, compute positions of sun and moon, polar wander, determine whether a point in near-earth space is sunlit, and so on. Plenty of other packages do all the same things, but if you have ever worried about whether, for example, you're using the correct definition of TEME (True Equator, Mean Equinox) in your coordinate conversion, using the SAAL is at least a decent way to ensure that all the components of the tool set agree with each other's assumptions.

For me personally, I am required to use them at work, because they come from the US Government and Skyfield does not. Having got used to them at work, I now also use (some of) them at home for hobbyist stuff, and I have over time grown somewhat fond of them, though I am also quite irritated by their continuing preference for confusingly defined, fixed length, hard to parse string formats, of which TLE is by no means the only one: How is an input card for SGP4/other astro standards packages crafted?

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ Thanks! To keep my life simple I use the SGP4 within Skyfield Does the regular SGP4 for traditional TLEs actually change these days, or is your recommendation to "(get) the latest SGP4 library from space-track.org" more forward-thinking, e.g. for the new SGP4-XP? $\endgroup$
    – uhoh
    Dec 5, 2021 at 1:36
  • 3
    $\begingroup$ @uhoh It is hard to tell whether it really changes, or whether we just discover new ways the Vallado-Kelso heritage code never quite matched the real thing. Two years ago a colleague asked me why he was getting imaginary numbers out of propagating GPS TLEs. It turned out the reason was he was using an old, unofficial Matlab version, and when I switched him to the latest official Matlab wrapper, the problem went away. Was that a change in SGP4, or just a long-buried bug that was always waiting to cause a problem? I don't know, but I prefer having the real thing just to be sure. $\endgroup$
    – Ryan C
    Dec 5, 2021 at 2:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.