Open ErikBsly opened 4 weeks ago
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?
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
.
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.
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:Whether or not this value was intended by the file creators, a solution might be necessary in the near future anyways.