Satellite analysis for Sat with no TLE

[muondude]

I'm a skyfield newbie and trying to understand if I can create a satellite object (earth orbiting) for a satellite that is not yet flying so there is no TLE available. I have the classical elements (really simple case of inclined, circular LEO). I am aware that the TLEs are generated from satellite observations. Does the skyfield api have the ability to use classical elements or is there a utility to generate a TLE from classical elements?

TIA

[davidmikolas]

Some potentially helpful information on how to do it yourself. A TLE or two line element set (also in Celstrak and in references therein) is just two lines of text with a very specific format (i.e. where the numbers go, where the decimal points go, etc.

• https://space.stackexchange.com/questions/26117/how-to-generate-tle-file

• https://space.stackexchange.com/questions/58869/how-to-update-the-epoch-in-a-fake-tle-while-maintaining-relative-position

• https://space.stackexchange.com/questions/32725/how-to-correctly-make-a-fake-counter-propagating-tle

• https://space.stackexchange.com/questions/49863/computing-a-new-tle-following-a-delta-v-impulse

• https://space.stackexchange.com/questions/33964/how-to-convert-data-from-glonass-almanac-agl-to-the-two-line-element-set

I think that it would not be hard programmatically to add a TLE builder method in Skyfield using period or semimajor axis, inclination, etc. with non-zero drag terms as optional inputs. That would for example allow someone to build a model constellation of Starlink satellites quickly as discussed in a recent post. #756

But there may be a downside to it. There would have to be some trapping for unphysical inputs for example, things that would mess with the SGP4 propagator because it was never meant to handle crazy inputs.

@brandon-rhodes what do you think? If you're interested in entertaining the idea I could write a method that outputs a tuple of strings (a TLE in text form) for discussion purposes.

Longer term, there could even be a "DIY Earth Satellite" object that could have methods like DIY.propogate_RK45(times) and DIY.propuslive_impulse()and DIY.solar_storm_event() and DIY.get_magnetic_field(times) and DIY.get_pressure(solar_activity) using a somewhat realistic gravitational field like GM + J2, J22, J3, J4 for modest DIY satellite investigations, though there's always that scary, ambiguous ITAR issue

• https://space.stackexchange.com/questions/21050/what-computer-programs-does-itar-say-i-can-or-can-not-write-or-share-or-use-in

[muondude]

Thank you for the reply.
I have read some of the links you provided and some were new.
Some "strong" opinions expressed. :-)
I think it really depends on one's goals, so caution is always advisable.
However, if one is trying to use skyfield to study "new missions" then the TLE doesn't exist.
I didn't see a propagator in the module that used classical elements so I figured I would need a "simulated" TLE.

After writing my original post I came across this recent paper by some folks from MITRE: https://arxiv.org/abs/2203.04204v1
They propose what seems to me to be a reasonable approach.

Following your comment about "new feature" for skyfield, perhaps adding another propagator that accepts classical elements would the the best way to go?

Oh yes I probably should say what attracted me to skyfield was how easy it is to computer range and range rate.
The range rate is what I'm primarily interested in as I want to compute the Doppler shift for a transponder and the range rate makes that really easy.

[davidmikolas]

@muondude yes after telling people not to make "fake TLEs", I later myself asked how to make retrograde ones :-)

I think you are well on your way, that arXiv paper you linked to seems excellent at first glance! I especially like their terminology:

Simulated notional TLEs

Skyfield doesn't currently have SciPy as a dependency to the best of my knowledge, but a variable step size RK45 (4/5 order Runge-Kutta) is both pretty good and pretty easy to script and adding a limited number of gravitational harmonics would not be hard either.

In fact if you don't need Skyfield and are comfortable with a little programming, you might enjoy just scripting everything in Python using scipy.integrate.solve_ivp Here's a hacky n-body relativistic integration I did years ago for the solar system (I would do it more nicely today). Here's another.

The advantage of doing it yourself is that you can continue to add exactly the features and reporting you need while keeping it fast by avoiding things you don't need.

SGP4 is permanently approximate. It is guaranteed to introduce errors that can be easily avoided with direct integration.

btw you might consider adding your arXiv link to this discussion as well, it seems to be relevant there #756

[brandon-rhodes]

I think that it would not be hard programmatically to add a TLE builder method in Skyfield using period or semimajor axis, inclination, etc. with non-zero drag terms as optional inputs. … brandon-rhodes what do you think? If you're interested in entertaining the idea I could write a method that outputs a tuple of strings (a TLE in text form) for discussion purposes.

Instead of turning numbers into text that then gets turned into numbers again, would it be possible to supply the numeric orbital parameters directly to the sgp4 library as described in the documentation?

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

Or would the TLE builder you are thinking of perform additional steps, besides assigning each supplied element to the correct satellite parameter?

Does the skyfield api have the ability to use classical elements…

@muondude, the orbital elements named in the above link are classical orbital elements—would building a new satellite using that code give you an object with elements and behavior like you want? Or do you want the propagation to be very strictly Keperian and ignore all the perturbations that SGP4 tries to model? Skyfield does have a simple Kepler model, but so far the API isn't quite stable (and it's a bit slow) so it's only documented so far for comets and asteroids:

https://rhodesmill.org/skyfield/kepler-orbits.html

But it's not limited to objects that orbit around the Sun, and can be used to model objects in a classical orbit around the Earth as well. If that's what you need, we could work out what code would be needed for you to supply elements directly instead of through a dataframe derived from a comet or asteroid input file.

[brandon-rhodes]

Oh—and, another quick thought:

There would have to be some trapping for unphysical inputs for example, things that would mess with the SGP4 propagator because it was never meant to handle crazy inputs.

If we do see users opening issues because they supply invalid parameters that aren't flagged, we might want to add some kind of "sanity-check-this-satellite" routine to the sgp4 module itself, since it might have a wider audience than just folks who use Skyfield. It's likely, though, that we should wait and see how common such problems really are, rather than try to guess.

[muondude]

@brandon-rhodes
Sorry I missed your comments about about exposing the Kepler elements as inputs for an Earth orbiting satellite. It isn't too much trouble to have a satellite object creation that uses the classical orbital elements that would be fantastic -- and I would use that immediately. My current need doesn't require this to be "fast". I'm interested in finding the Doppler shifts for some satellite concepts and your software makes that very straight forward.

TIA