Alpha5 support

[dmopalmer]

The format of TLEs has changed because the space fence is going to rapidly overwhelm the 5-digit numbers available in the old format. This needs to be supported by all the satellite libraries that support TLEs.

For example, catalog number 270000 (which is an analyst object seen by the space fence) has a catnum field of T00000 as in:

1 T0000U          20341.14572529  .00000446  00000-0  15605-2 0  9998
2 T0000  90.2902 300.0888 0031941  22.1325 338.1165 12.95152933 48676

This range is in given by the RESTFUL link https://www.space-track.org/basicspacedata/query/class/gp/EPOCH/%3Enow-30/NORAD_CAT_ID/270000--339999/orderby/NORAD_CAT_ID/format/tle

From space-track:

Alpha-5 is a stopgap object numbering schema from the United States Space Force that increases the satellite catalog’s capacity to display up to 339,999 objects in the GP/GP_History API classes using legacy fixed-width Two and Three Line Element Set (TLE/3LE) formats.

Replacing the 1st digit of the 5-digit object number with an alphanumeric character makes it possible to represent 240,000 more numbers. Objects less than 100,000 are unaffected by Alpha-5, as are users who download elsets from the GP and GP_History API classes in other formats like XML, JSON, KVN, and CSV. In order to preserve legacy operations that depend on 5-digit integers, our legacy API Classes tle, tle_latest, and tle_publish will not change to Alpha-5.

Only capital letters and numbers are used in Alpha-5. The letters “I” and “O” are omitted to avoid confusion with the numbers “1” and “0”.

[brandon-rhodes]

Interesting! Have you done any tests of what the library does when there's letters in that field?

[dmopalmer]

It sticks a zero in the field:

In [4]: from sgp4.api import Satrec

In [5]: sat = Satrec.twoline2rv(
   ...: "1 T0000U          20341.14572529  .00000446  00000-0  15605-2 0  9998",
   ...: "2 T0000  90.2902 300.0888 0031941  22.1325 338.1165 12.95152933 48676")

In [6]: sat.satnum
Out[6]: 0

[brandon-rhodes]

Oh! It doesn’t crash. Nice.

My guess is that we want to keep returning 0 here as long as the underlying C++ library does so? I'm not sure whether Vallado has plans to supplement the C++ at this point, or whether we should just direct folks who need high-numbered objects to the new OMM support at gh-65 — which I hope to finish up soon and get closed.

[dmopalmer]

Crashing would be better. Instead it seems to fill all fields with zero, so it is silently gives completely bogus satellite.

In [7]: sat.no
Out[7]: 0.0

In [8]: sat.elnum
Out[8]: 0

In [9]: sat.epochyr
Out[9]: 0

You (or I) should contact Vallado to see whether he plans to update, or would accept a pull request.

[dmopalmer]

The latest version of SGP4.cpp on Vallado's website has:

• current :
• 12 mar 20 david vallado
• chg satnum to string for alpha 5 or 9-digit

This has not been propagated to GitHub. Where does your setup.py load the libraries from?

[brandon-rhodes]

This has not been propagated to GitHub. Where does your setup.py load the libraries from?

The libraries are maintained inline in this repository, as there's no official presence on GitHub, and I want CI systems to be able to build the library without a download from a 3rd party website (which would both increase load on that website, and also could break at any time our ability to build).

I'll try upgrading to the new C++ code — thanks for checking his changelog for me!

[dmopalmer]

It would be nice if the python interface didn't change, so sat.catnum for the "T0000" TLE gives 27000 (and vice versa for your TLE generating routines). And so that when you have historical TLE satellite elements and new OMM elements for the same satellite, you can tell that they are the same.

Is this possible without any changes in the .cpp files?

[brandon-rhodes]

Is this possible without any changes in the .cpp files?

Yes! I agree that the Python interface cannot change, because so much code will already expect an integer for that field. The new string that Vallado provides will have to have a different attribute name, like .satnum_str, and a bit of wrapper compatibility code will have to be provided (alas, in both the C++ and the Python fallback cases) to translate that string into an integer .satnum. While doing that, it hopefully won't be too traumatic to recognize and translate strings that start with letters.

[brandon-rhodes]

To more directly answer your question: here’s where C++ code can live without our having to modify Vallado’s C++.

https://github.com/brandon-rhodes/python-sgp4/blob/master/extension/wrapper.cpp

[brandon-rhodes]

I’ve just committed Vallado’s new code to the repository, along with minimal changes to the Python wrapper to (hopefully) properly translate Python integers to and from the new string in Vallado’s C++ structure.

The code passes a basic set of tests suggested in the Alpha-5 description itself.

I’ll think about making a release tomorrow — though it’s always dicey whether the code will compile and work under all platforms until I actually try running it through the universal build process. We’ll see what happens.