Hi all, I’m an indie developer in Maine who’s been digging into the catalog-number migration, and I’d like a sanity check from people who actually run ground stations.
On 11 July 2026 the US catalog assigned its first six-digit number (100000, SARAMAGO). Every object catalogued since then has a number that doesn’t fit the TLE’s five-character field, and it shows in the public feeds:
As of 21 September, CelesTrak’s TLE request for the last-30-days group returns HTTP 404 (“No GP data found”). Everything in that window is six-digit, so there’s nothing to render as TLE. The same group in CSV/JSON/XML is complete.
The same day, the analyst group had 565 records in CSV but only 219 in TLE, and 563 of the 565 have an empty OBJECT_ID in XML.
python-sgp4 can’t load nine-digit NORAD_CAT_IDs from OMM (#169, fix in progress in #170) and crashed on those empty OBJECT_IDs (#171, fix submitted in #172).
CelesTrak and Space-Track render the same element set into different TLE bytes (zero second-derivative sign; eccentricity rounded vs truncated), which matters if you byte-compare TLEs.
To test this, I built a conformance corpus: 16 cases from real CelesTrak responses plus the published Alpha-5 and CCSDS spec vectors, with a small runner you point at your own parser. A deliberately naive five-digit parser fails 13 of the 16.
It redistributes no provider data; a fetch script rebuilds the raw files on your machine. It was audited before release (see AUDIT.md in the corpus).
My question: which parts of the SatNOGS stack still ingest TLEs (python-satellitetle, the network scheduler, client-side tooling?), and has anyone checked how they handle objects above 99,999? I haven’t tested any SatNOGS component and don’t want to guess. If it helps, I’m happy to run the corpus against specific parsers or add an adapter.
Currently none of the SatNOGS components support orbital data with NORAD ID >99999.
We are working on this and in the next couple of weeks there will be supported.
Support will come in two forms, we will try to be compatible with both alpha-5 and OMM (JSON for now) formats. Depending on the sub-project there will be different support level.
For more details stay tuned in the forum as there will be announcements about the changes. If you want to see more technical details, you can take a look in gitlab repositories of each sub-project.
Thanks, Fredy, that’s really helpful, and good to hear it’s in progress.
Since you’re doing both Alpha-5 and OMM JSON, the corpus should line up well: it has Alpha-5 spec vectors and real CelesTrak OMM JSON cases, including six- and nine-digit IDs. When the changes land (or sooner, if there’s a branch), I’d be glad to run it against them and report back, either here or as GitLab issues on the relevant sub-project. If there’s one parser or repo you’d want checked first, point me to it and I’ll start there.
I’ll also note SatNOGS as “support in progress” on the migration tracker, linking back to this thread, unless you’d rather I didn’t.
Hi Fredy, following up as promised. Has any of the SatNOGS Alpha-5 / OMM JSON work landed yet, or is there a branch I could run the corpus against? If you point me at the sub-project you’d want checked first, I’ll run it and post what comes back here or as a GitLab issue, whichever you
prefer.
A few things changed on my side since September, in case they’re useful: it now installs with pip install gpconf, there are 18 cases rather than 16, and a first-time fetch is 46 requests to CelesTrak, about 3 MB, once. Results for the libraries I’ve run so far, and which maintainers have fixed things, are at Library status · gpconf.neogy.dev