Using OMM in place of TLE #243

Bernmeister · 2022-08-22T00:29:27Z

Bernmeister
Aug 22, 2022

Inspired by the note that Celestrak is providing satellite data formats alternate to TLE, I used sgp4 to read in OMM formatted data and export a TLE for use in PyEphem. Works brilliantly; thanks @brandon-rhodes!

One thing which I added in and wanted clarification: given that TLE only supports a satellite number of character length 5, after I download my OMM data and before I export to TLE, I check the length of the satellite number and if it is greater than length 5, I drop that satellite. Is this the correct path to follow?

Answered by brandon-rhodes

Sep 15, 2022

I check the length of the satellite number and if it is greater than length 5, I drop that satellite. Is this the correct path to follow?

Only if you know that you want to ignore all of the satellites with numbers of greater than length 5, I suppose? It would depend on what you're doing and whether all those satellites are irrelevant to you. If some of them would be useful to you, then probably you'll not want to throw them out but instead rewrite their numbers to lower numbers that PyEphem can accept, and have a Python dictionary or something to keep up with which satellite objects had which numbers originally before you rewrote them.

View full answer

brandon-rhodes · 2022-09-15T13:19:49Z

brandon-rhodes
Sep 15, 2022
Maintainer

I check the length of the satellite number and if it is greater than length 5, I drop that satellite. Is this the correct path to follow?

Only if you know that you want to ignore all of the satellites with numbers of greater than length 5, I suppose? It would depend on what you're doing and whether all those satellites are irrelevant to you. If some of them would be useful to you, then probably you'll not want to throw them out but instead rewrite their numbers to lower numbers that PyEphem can accept, and have a Python dictionary or something to keep up with which satellite objects had which numbers originally before you rewrote them.

1 reply

Bernmeister Sep 16, 2022
Author

Thank you @brandon-rhodes; yes, I should have given more clarification in my question...

I download the 100 (or so) Brightest, cache the data and then run that through PyEphem or Skyfield. To avoid possibly blowing up PyEphem with a future satellite with satellite number of length greater than 5, I decided to simply drop them at the download/cache stage. Sorted and thank you again!

Bernmeister · 2022-09-18T00:53:06Z

Bernmeister
Sep 18, 2022
Author

@brandon-rhodes Your answer got me thinking about not dropping satellites, but rather, swapping the satellite (catalog) number for something less than length five before I request a TLE from exporter.export_tle. So I first tried passing in legitimate data for a satellite and then deliberately swapping in a longer than length five number and got an odd result:

#!/usr/bin/env python3
# -*- coding: utf-8 -*-


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

import io


xmlData = '''<?xml version="1.0" encoding="UTF-8"?>
<ndm xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="https://sanaregistry.org/r/ndmxml_unqualified/ndmxml-2.0.0-master-2.0.xsd">
<omm id="CCSDS_OMM_VERS" version="2.0">
<header><CREATION_DATE/><ORIGINATOR/></header><body><segment><metadata><OBJECT_NAME>ATLAS CENTAUR 2</OBJECT_NAME><OBJECT_ID>1963-047A</OBJECT_ID><CENTER_NAME>EARTH</CENTER_NAME><REF_FRAME>TEME</REF_FRAME><TIME_SYSTEM>UTC</TIME_SYSTEM><MEAN_ELEMENT_THEORY>SGP4</MEAN_ELEMENT_THEORY></metadata><data><meanElements><EPOCH>2022-09-15T19:53:42.305568</EPOCH><MEAN_MOTION>14.03693255</MEAN_MOTION><ECCENTRICITY>.0581082</ECCENTRICITY><INCLINATION>30.3555</INCLINATION><RA_OF_ASC_NODE>51.2495</RA_OF_ASC_NODE><ARG_OF_PERICENTER>113.8122</ARG_OF_PERICENTER><MEAN_ANOMALY>252.4478</MEAN_ANOMALY></meanElements><tleParameters><EPHEMERIS_TYPE>0</EPHEMERIS_TYPE><CLASSIFICATION_TYPE>U</CLASSIFICATION_TYPE><NORAD_CAT_ID>694</NORAD_CAT_ID><ELEMENT_SET_NO>999</ELEMENT_SET_NO><REV_AT_EPOCH>95239</REV_AT_EPOCH><BSTAR>.37949E-3</BSTAR><MEAN_MOTION_DOT>.2988E-4</MEAN_MOTION_DOT><MEAN_MOTION_DDOT>0</MEAN_MOTION_DDOT></tleParameters></data></segment></body></omm>
</ndm>'''


def readSatellite( xmlData ):
    fields = next( omm.parse_xml( io.StringIO( xmlData ) ) )
    satelliteRecord = Satrec()
    omm.initialize( satelliteRecord, fields )
    print( "NORAD_CAT_ID:", fields[ "NORAD_CAT_ID" ] )
    print( "satnum:", satelliteRecord.satnum )
    line1, line2 = exporter.export_tle( satelliteRecord )
    print( "TLE Line 1:", line1 )
    print( "TLE Line 2:", line2 )
    print()


readSatellite( xmlData )
readSatellite( xmlData.replace( "<NORAD_CAT_ID>694</NORAD_CAT_ID>", "<NORAD_CAT_ID>1234567</NORAD_CAT_ID>" ) )

NORAD_CAT_ID: 694
satnum: 694
TLE Line 1: 1 00694U 63047A   22258.82896187  .00002988  00000-0  37949-3 0  9999
TLE Line 2: 2 00694  30.3555  51.2495 0581082 113.8122 252.4478 14.03693255952398

NORAD_CAT_ID: 1234567
satnum: 0
TLE Line 1: 1 00000U 63047A   22258.82896187  .00002988  00000-0  37949-3 0  9990
TLE Line 2: 2 00000  30.3555  51.2495 0581082 113.8122 252.4478 14.03693255952399

You can see that the satnum is now 0 rather than 694, which is unexpected. Aside from that, I wasn't sure what would happen when exporting to a TLE...maybe the satnum would be truncated to length five?

I did a search and noticed in SGP4.cpp:

bool sgp4init( gravconsttype whichconst, char opsmode, const char satn[5], ...

versus SGP4.h

bool sgp4init( gravconsttype whichconst, char opsmode, const char satn[9], ...

Could this somehow be the reason for the truncation? I've somewhat hijacked my own question/discussion. I'm happy to move/refer this to a new issue if need be over at python-sgp4.

1 reply

brandon-rhodes Sep 18, 2022
Maintainer

For the next version, I have added access to the underlying string representation of the satellite number so it's easier for us to see what's going on:

brandon-rhodes/python-sgp4@a421519

And also protection against the predicament you got into:

brandon-rhodes/python-sgp4@56c1c4d

The satellite number you chose was so large that not only did its Alpha 5 representation exceed Z9999, but pushed the leading letter all the way past character 128 and up to the Latin-1 character number 178 "SUPERSCRIPT TWO". Unfortunately SGP4's C++ header file defines the string as char not unsigned char, so that number 178 becomes negative when it's pulled back out of the struct later, creating the odd behavior you saw.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Using OMM in place of TLE #243

{{title}}

Replies: 2 comments 2 replies

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

Using OMM in place of TLE #243

Bernmeister Aug 22, 2022

Replies: 2 comments · 2 replies

brandon-rhodes Sep 15, 2022 Maintainer

Bernmeister Sep 16, 2022 Author

Bernmeister Sep 18, 2022 Author

brandon-rhodes Sep 18, 2022 Maintainer

Bernmeister
Aug 22, 2022

Replies: 2 comments 2 replies

brandon-rhodes
Sep 15, 2022
Maintainer

Bernmeister Sep 16, 2022
Author

Bernmeister
Sep 18, 2022
Author

brandon-rhodes Sep 18, 2022
Maintainer