#38 Requested TLE files from Celestrak

Charles Suprin

If one requests a Special Data Request file from Celestrak, when it arrives, it is not currently importing correctly. It provides some information about the satellite and the launch information and some number of TLEs depending on what was requested.

This was detected in testing decayed satellites and used this feature to get the most recent TLE for a decayed satellite.

The file format (for humans) is:

catnum internationalID nickname
Launched: date Start Date: date
Decayed: date Stop Date: date
TLE line 1
TLE line 2
TLE line 1
TLE line 2
<End of file>


  • I don't think this is a problem for Gpredict, and certainly not a bug since importing anything else than standard 2-line tle is not an existing function. The bug/missing feature in Gpredict is that it does not offer an easy way to remove obsolete objects from the database.

    What are you trying to do with decayed satellites? SGP/SDP is seriously limited for such objects.

  • Charles Suprin
    Charles Suprin

    Whether is a bug is probably a function of what document is the definition of a TLE. According to Spacetrack Report #3 (available at http://celestrak.com/NORAD/documentation/spacetrk.pdf\) pages 80-83 and then on paget 88 there is no need to include the satellite nickname in the TLE format. This is in agreement with the TLE FAQ at <http://celestrak.com/columns/v04n03/> . However this is not in agreement with <http://celestrak.com/NORAD/documentation/tle-fmt.asp> which introduces the name field on a third line before the two defined in the other two pages.

    In terms of what I am doing with decayed satellites:
    1) Make sure that a decayed satellite does not results in 100% condition. (Examples can be provided)
    2) Make sure that graphical always gets reasonable values. (Errors can results in NAN being passed to plotting routines.)
    3) Checking that the time used in decayed() is consistent with the re-entry time from <http://www.aero.org/capabilities/cords/reentries.html>

  • The TLE file format for gpredict is pretty clear regardless of what different FAQs and standards say. The format that includes the name was chosen since this is how data is provided by both Celestrak and Amsat. Even if gpredict could read the nameless TLE it wouldn't be sufficient for the data you described, since that appears to be something special for decayed satellites.

    Concerning the other things, I think you will find it hard to find a general solution since the SGP algorithm (which includes the TLE data) can not be trusted when a satellite starts to decay. For the same reason, the decayed() function is a mistake and I doubt that it will produce the same results as any other algorithm.

  • Charles Suprin
    Charles Suprin

    • milestone: 875296 -->
    • labels: 1141377 -->
  • Charles Suprin
    Charles Suprin

    SVN commit 899 will process "bare" two line elements as shown in the description. It should also recognize AMSAT files that have header text and ignore that text regardless of the number of lines.

    It creates a separate copy of the last "unprocessed" three lines in the file. It uses the checksums to determine which line is from a tle and placement to guess if it is a three or two line element.

    If there is a new satellite in the tle, it will be given a name of yyyy-nnnaaa as is consistent with celestrak. This will also be overridden if another name is ever obtained else where.