sgp4init() satellite number limitation exceeded

[ErikBsly]

Hey folks,
the most recent Starlink satellites ( https://celestrak.org/NORAD/elements/supplemental/sup-gp.php?FILE=starlink&FORMAT=csv ) seem to carry unusual high NORAD catalog numbers like 799501299 which causes sgp4init() to raise the following error:

ValueError: satellite number cannot exceed 339999, whose Alpha 5 encoding is 'Z9999'

Whether or not this value was intended by the file creators, a solution might be necessary in the near future anyways.

[brandon-rhodes]

Well — drat. Skyfield uses the official SGP4 implementation for generating satellite positions, as distributed here:

https://celestrak.org/publications/AIAA/2006-6753/

And that routine only allows 6 characters of satellite catalog number:

typedef struct elsetrec
{
  char      satnum[6];
...

Do you know what any other satellite tools are doing with entries like this new one you have run across? That is indeed a very large satellite number, and I would guess that other implementations are running into trouble too. I wonder if I should just truncate all but the lowest 6 digits, so that you can at least proceed to generate positions for the satellite?

[Bernmeister]

I cannot recall if I saw this issue/situation mentioned here on skyfield or python-sgp4 (or perhaps pyephem),however I ended up performing a sleight of hand. In short, for the XML data I download from Celestrak, if the value for the field NORAD_CAT_ID > 339999, I pass a value of 0 instead (0 is not used so I felt safe for this step) to get the data to initialise.

Something like this:

from sgp4 import alpha5, exporter, omm
from sgp4.api import Satrec

satellite_record = Satrec()
xml_fields_from_omm = get_data_from_celestrak_in_xml_format( .... )

# Satellite record does not hold the name.
name = xml_fields_from_omm[ "OBJECT_NAME" ]

number = xml_fields_from_omm[ "NORAD_CAT_ID" ]
if float( xml_fields_from_omm[ "NORAD_CAT_ID" ] ) > float( "339999" ):
    xml_fields_from_omm[ "NORAD_CAT_ID" ] = '0'
    omm.initialize( self.satellite_record, xml_fields_from_omm ) # The satellite record now has a satnum = 0.
    xml_fields_from_omm[ "NORAD_CAT_ID" ] = self.number

else:
    omm.initialize( self.satellite_record, xml_fields_from_omm )

Hopefully there is no differencewhether the data format is xml or csv.

[EndlessDex]

There is no error here (yet). That nine digit number is a temporary designation until it gets an official satcat id.

The supplemental data on celestrak is provided by space-track by starlink. Starlink reports satellite position by the format specified here: https://www.space-track.org/documents/SFS_Handbook_For_Operators_V1.7.pdf

In today's datadump there were files listed like this:

Which is defined by this spec (from SFS Handbook):

It looks like celestrak did an autoimport and barfed a bit on the data. SATCAT ID will continue to be assigned sequentially until 99999. THEN we will have a problem. (The problem OMM was designed to fix see https://celestrak.org/NORAD/documentation/gp-data-formats.php)

Hopefully Valledo gets us a nice update before then otherwise it will be the wild west haha.