(ANSWERED) Is there a way to directly hand over TLE parameters directly instead of "tle lines"?

[hornig]

Hi everybody,

I am currently using TLE lines as input to skyfield. It works well :).
But that means that I need to use raan, inc, and the other input parameters by converting them to the TLE format and the put them into skyfield.

I am using skyfield for orbit determination and generting the R and V states ober time like this. But converting the onputs to string is not fast and I want to avoid that.

So is there a direct way maybe?

Best regards, Andreas

[brandon-rhodes]

There's a section of the documentation that might describe what you want:

https://rhodesmill.org/skyfield/earth-satellites.html#build-a-satellite-from-orbital-elements

If it does match what you're trying to accomplish, is there a way it could be made easier to find? Where were you looking instead?

[hornig]

@brandon-rhodes ahh, thanks! :)

I already tried this and compared the results

satrec = Satrec()
satrec.sgp4init(
    WGS72,           # gravity model
    'i',             # 'a' = old AFSPC mode, 'i' = improved mode
    5,               # satnum: Satellite number
    (time1-time_ref)/(24*3600.0),       # epoch: days since 1949 December 31 00:00 UT
    0.48881e-5,      # bstar: drag coefficient (/earth radii)
    6.969196665e-13, # ndot: ballistic coefficient (revs/day)
    0.0,             # nddot: second derivative of mean motion (revs/day^3)
    0.0002793,       # ecco: eccentricity
    12.8653 / 180.0 * np.pi, # argpo: argument of perigee (radians)
    51.6432 / 180.0 * np.pi, # inclo: inclination (radians)
    56.5670 / 180.0 * np.pi, # mo: mean anomaly (radians)
    15.48959405 * np.pi * 2.0 / (24.0 * 60.0), # no_kozai: mean motion (radians/minute)
    230.1082 / 180.0 * np.pi, # nodeo: right ascension of ascending node (radians)
)

I compared it with this

ts = load.timescale()
name = "ISS (ZARYA)"
line1 = '1 25544U 98067A   21045.38657216 -.00000180  00000-0  48881-5 0  9994'
line2 = '2 25544  51.6432 230.1082 0002793  12.8653  56.5670 15.48959405269562'
satellite = EarthSatellite(line1, line2, name, ts)

it is ALMOST the same result for positions. and I don't know yet why there is a small difference.
for unix time = 1613287016.0
I get this with the tle [-5428538.22456663 -2768070.70589829 -3018173.46268474]
and this with the satrec [-5428538.2246691 -2768070.70336631 -3018173.46482739]

I already checked with WGS72, WGS72OLD and WGS840 but the WGS72 has the closest result.
Maybe I oversee something or it is an option I miss.

Maybe you have a hint?

Best regards, Andreas

[brandon-rhodes]

Maybe you have a hint?

That's a fairly small difference — you might check into whether your application will be able to detect a difference in position that small; it’s possible that the two vectors are equivalent from the point of view of your antenna or camera.

If the difference is indeed crucial, then as a next step, try narrowing the question down to: which individual satellite parameters are coming out different? Here’s a quick Python routine I just wrote that should show what's different between two satellites:

def compare_sats(sat1, sat2):
    for attr in sorted(dir(sat1)):
        try:
            value1 = getattr(sat1, attr)
        except AttributeError:
            continue
        if not isinstance(value1, (str, int, float)):
            continue
        value2 = getattr(sat2, attr)
        verdict = '==' if (value1 == value2) else '!='
        print('{:18} {!r:24} {} {!r:24}'.format(attr, value1, verdict, value2))

What does it show for your two satellites?

[hornig]

your code shows this
__array_priority__ 0.0 == 0.0 itemsize 8 == 8 nbytes 24 == 24 ndim 1 == 1 size 3 == 3

Update:

__doc__            "An Earth satellite loaded from a TLE file and propagated with SGP4.\n\n    An earth satellite object is a Skyfield vector function, so you can\n    either call its ``at()`` method to generate its position in the sky\n    or else use addition and subtraction to combine it with other\n    vectors.\n\n    Satellite parameters are generally only accurate for a week or two\n    around the *epoch* of the parameters, the date for which they were\n    generated, which is available as an attribute:\n\n    ``epoch``\n        A Skyfield :class:`~skyfield.timelib.Time` giving the exact\n        epoch moment for these satellite orbit parameters.\n    ``name``\n        Satellite name\n\n    When building a satellite, use the arguments ``line1`` and ``line2``\n    to provide the two data lines from a TLE file as separate strings.\n    Optional ``name`` lets you give a name to the satellite, accessible\n    later through the ``name`` attribute.  ``ts`` is a\n    :class:`~skyfield.timelib.Timescale` object, used to generate the\n    ``epoch`` value; if it is not provided, the satellite will use a\n    built in ``Timescale`` object.\n\n    If you are interested in the catalog entry details, the SGP4 model\n    parameters for a particular satellite can be accessed through its\n    ``model`` attribute:\n\n    ``model.satnum``\n        The unique satellite NORAD catalog number given in the TLE file.\n    ``model.classification``\n        Satellite classification, or else ``'U'`` for “Unknown”\n    ``model.intldesg``\n        International designator\n    ``model.epochyr``\n        Full four-digit year of this element set's epoch moment.\n    ``model.epochdays``\n        Fractional days into the year of the epoch moment.\n    ``model.jdsatepoch``\n        Julian date of the epoch (computed from ``epochyr`` and ``epochdays``).\n    ``model.ndot``\n        First time derivative of the mean motion (ignored by SGP4).\n    ``model.nddot``\n        Second time derivative of the mean motion (ignored by SGP4).\n    ``model.bstar``\n        Ballistic drag coefficient B* in inverse earth radii.\n    ``model.ephtype``\n        Ephemeris type (ignored by SGP4 as determination now automatic)\n    ``model.elnum``\n        Element number\n    ``model.inclo``\n        Inclination in radians.\n    ``model.nodeo``\n        Right ascension of ascending node in radians.\n    ``model.ecco``\n        Eccentricity.\n    ``model.argpo``\n        Argument of perigee in radians.\n    ``model.mo``\n        Mean anomaly in radians.\n    ``model.no_kozai``\n        Mean motion in radians per minute.\n    ``model.revnum``\n        Revolution number at epoch [Revs]\n\n    " == "An Earth satellite loaded from a TLE file and propagated with SGP4.\n\n    An earth satellite object is a Skyfield vector function, so you can\n    either call its ``at()`` method to generate its position in the sky\n    or else use addition and subtraction to combine it with other\n    vectors.\n\n    Satellite parameters are generally only accurate for a week or two\n    around the *epoch* of the parameters, the date for which they were\n    generated, which is available as an attribute:\n\n    ``epoch``\n        A Skyfield :class:`~skyfield.timelib.Time` giving the exact\n        epoch moment for these satellite orbit parameters.\n    ``name``\n        Satellite name\n\n    When building a satellite, use the arguments ``line1`` and ``line2``\n    to provide the two data lines from a TLE file as separate strings.\n    Optional ``name`` lets you give a name to the satellite, accessible\n    later through the ``name`` attribute.  ``ts`` is a\n    :class:`~skyfield.timelib.Timescale` object, used to generate the\n    ``epoch`` value; if it is not provided, the satellite will use a\n    built in ``Timescale`` object.\n\n    If you are interested in the catalog entry details, the SGP4 model\n    parameters for a particular satellite can be accessed through its\n    ``model`` attribute:\n\n    ``model.satnum``\n        The unique satellite NORAD catalog number given in the TLE file.\n    ``model.classification``\n        Satellite classification, or else ``'U'`` for “Unknown”\n    ``model.intldesg``\n        International designator\n    ``model.epochyr``\n        Full four-digit year of this element set's epoch moment.\n    ``model.epochdays``\n        Fractional days into the year of the epoch moment.\n    ``model.jdsatepoch``\n        Julian date of the epoch (computed from ``epochyr`` and ``epochdays``).\n    ``model.ndot``\n        First time derivative of the mean motion (ignored by SGP4).\n    ``model.nddot``\n        Second time derivative of the mean motion (ignored by SGP4).\n    ``model.bstar``\n        Ballistic drag coefficient B* in inverse earth radii.\n    ``model.ephtype``\n        Ephemeris type (ignored by SGP4 as determination now automatic)\n    ``model.elnum``\n        Element number\n    ``model.inclo``\n        Inclination in radians.\n    ``model.nodeo``\n        Right ascension of ascending node in radians.\n    ``model.ecco``\n        Eccentricity.\n    ``model.argpo``\n        Argument of perigee in radians.\n    ``model.mo``\n        Mean anomaly in radians.\n    ``model.no_kozai``\n        Mean motion in radians per minute.\n    ``model.revnum``\n        Revolution number at epoch [Revs]\n\n    "
__module__         'skyfield.sgp4lib'       == 'skyfield.sgp4lib'      
center             399                      == 399                     
center_name        '399 EARTH'              == '399 EARTH'             
name               'ISS (ZARYA)'            != None                    
target             -125544                  != -112345                 
target_name        'ISS (ZARYA) catalog #25544 epoch 2021-02-14 09:16:40 UTC' != 'catalog #12345 epoch 2021-02-14 09:16:40 UTC'
vector_name        'EarthSatellite'         == 'EarthSatellite'  

what does it tell me?

[brandon-rhodes]

Try making the comparison between the two Satrec objects, not the two Skyfield EarthSatellite objects — I should have been more specific! You would pass it your satrec object and the satellite.model object.

[hornig]

Om                 4.023326412248162        != 4.023326412248595       
__doc__            'High-speed computation of satellite positions and velocities.' == 'High-speed computation of satellite positions and velocities.'
__module__         'sgp4.wrapper'           == 'sgp4.wrapper'          
a                  1.0658932393212506       == 1.0658932393212506      
alta               0.06619094330299302      == 0.06619094330299302     
altp               0.06559553533950813      == 0.06559553533950813     
am                 1.0658932598794404       == 1.0658932598794404      
argpdot            4.461252114000656e-05    == 4.461252114000656e-05   
argpo              0.22454184425682647      == 0.22454184425682647     
bstar              4.888100000000001e-06    == 4.888100000000001e-06   
classification     'U'                      != '\x00'                  
ecco               0.0002793                == 0.0002793               
elnum              999                      != 0                       
em                 0.0002793040856820445    != 0.0002793040856820453   
ephtype            0                        == 0                       
epochdays          45.38657216              != 45.38657216000502       
epochyr            21                       == 21                      
error              110                      == 110                     
gsto               4.9529694277559315       == 4.9529694277559315      
im                 0.9013438762659356       == 0.9013438762659356      
inclo              0.9013438762659356       == 0.9013438762659356      
intldesg           '98067A'                 != ''                      
j2                 0.001082616              == 0.001082616             
j3                 -2.53881e-06             == -2.53881e-06            
j3oj2              -0.002345069720011528    == -0.002345069720011528   
j4                 -1.65597e-06             == -1.65597e-06            
jdsatepoch         2459259.5                == 2459259.5               
jdsatepochF        0.38657216               != 0.3865721600050165      
mdot               0.06758611175999966      == 0.06758611175999966     
method             'n'                      == 'n'                     
mm                 -0.8216615225107731      != -0.8216615229989959     
mo                 0.9872803979756324       == 0.9872803979756324      
mu                 398600.8                 == 398600.8                
nddot              0.0                      == 0.0                     
ndot               -5.45415391248228e-12    != -1.8e-06                
nm                 0.06757860125029262      == 0.06757860125029262     
no                 0.06758610399245579      == 0.06758610399245579     
no_kozai           0.06758610399245579      == 0.06758610399245579     
nodedot            -5.997370789175431e-05   == -5.997370789175431e-05  
nodeo              4.016145725837616        == 4.016145725837616       
om                 0.21920354551582888      != 0.2192035455155039      
operationmode      'i'                      == 'i'                     
radiusearthkm      6378.135                 == 6378.135                
revnum             26956                    != 0                       
satnum             25544                    == 25544                   
t                  -119.73057703462325      != -119.73057704184703     
tumin              13.446839696959309       == 13.446839696959309      
xke                0.07436691613317342      == 0.07436691613317342 

[brandon-rhodes]

Excellent! You can now see precisely the differences between the TLE-built and elements-built satellites, that lead to the tiny differences in position you observed. The documentation lists the meaning of all the attributes; most of the differences are in output attributes:

https://pypi.org/project/sgp4/#attributes

It looks like the important difference in the input attribute involves time: since sgp4init() takes only a single float number for the time, there are a final few digits of precision that are missing compared to when it's read from a TLE. You can try setting the epoch attributes yourself after calling sgp4init() if you want to create an exact match for the TLE satellite.

I'll add a note to the documentation about the difference.

[brandon-rhodes]

So!

I went to update the docs to try to describe the problem where sgp4init() is given an epoch with 8 decimal places like a TLE, but that gains more decimal places when the numbers are stored as wider-precision binary floats internally, and so then the user has to go fix them up.

But the prospect of having to explain everything was so terrible, that an idea struck me, and I realized it would be easier to just go fix the problem instead!

brandon-rhodes/python-sgp4@544f919

So with the next release of SGP4, while I'll try to do in the next couple of days, this problem will hopefully go away! If you'd like to try it yourself, you could try:

pip install -U https://github.com/brandon-rhodes/python-sgp4/archive/master.zip