Say that I wanted to propagate a real-life satellite based on an initial position in space. However, the only source of data I can get is from a tracking website like CelesTrak or Space-Track, where the output is in a TLE format (I might be wrong about this being the only option from Space-Track, but I digress.) Alternatively, I may be able to obtain information like orbital elements, for example using the NASA Horizons page.

The TLE is designed to be used for SGP4, but the propagator that I would be using doesn't take orbital elements like an TLE; rather, it uses cartesian state vectors (ECI X,Y,Z in both position and velocity) directly to propagate.

I know it is possible to convert an TLE to cartesian state vectors via a long/convoluted process. However, in doing so, I would be introducing errors into the system from the TLE/SGP4 system, which is less accurate than the propagator I would use from that point forward; that being said, the conversion would only be used for the initial state, not for any other part of the propagation. Similarly, it's possible to convert from orbital elements to Cartesian State Vectors, but those orbital elements are also mean values and as such are also inaccurate.

What kind of accuracy loss is incurred by converting a TLE or Orbital Elements into cartesian state vectors, for the sole use of being an input to a more-accurate propagator? Does it mainly depend on the length of the simulation, or is there greater error from the conversion process alone?

  • $\begingroup$ If you are interested in asking "What would be the best way to try to do this.." I'll be happy to write an answer. Maybe you can ask that separately? $\endgroup$
    – uhoh
    Jul 29, 2020 at 11:16
  • $\begingroup$ @uhoh perhaps, although i've seen there are papers detailing instructions on converting from SGP4 to Cartesian - are you talking about 'the best way to do this' meaning 'the most accurate way to convert TLE to XYZ'? $\endgroup$
    – jos
    Jul 30, 2020 at 11:13
  • 1
    $\begingroup$ yes I think; what I've always wanted an excuse to try is to use TLE+SGP4 to generate an ensemble of state vectors at say 1 or 5 minute intervals for one period around the TLE's epoch, then switch to a normal cartesian propagator and propagate each one into the future. This generates a "cloud" of positions at some future epoch. I was curious if this average orbit would be more reliable than just choosing one point in time and getting only one state vector from SGP4. The more I think about it though the more I realize this may be a lot of work that ends with ambiguous results... $\endgroup$
    – uhoh
    Jul 30, 2020 at 11:23
  • 1
    $\begingroup$ @uhoh I think your suggestion is the answer to "What kind of accuracy loss": i.e. do that process for the object of interest and see how far the future cloud differs from the next TLE. Obviously the object could be station-keeping or changing attitude so repeat a few times to get a better overview. $\endgroup$
    – Puffin
    Aug 3, 2020 at 14:00
  • $\begingroup$ @Puffin ya I see what you mean. Whether the TLE is representative of the spacecraft's actual state is a separate question though. Here I'm only talking/thinking about using a TLE at face value. How predictive it is of the next TLE or how closely it matches what's going on at the moment are great questions though! $\endgroup$
    – uhoh
    Aug 3, 2020 at 16:02

2 Answers 2


If a two line element represented the exact state of a satellite at the epoch time of the element set, there would be zero penalty in applying the SGP4 algorithm to cartesian coordinates, which are in the True Equator, Mean Equinox (TEME) frame. From there it would be simple matter of a coordinate transformation to convert those TEME coordinates to something sane such as the J2000 frame (better said, a semi-simple matter; TEME is not well defined).

A two line element set does not however represent the exact state of a satellite at the epoch time of the element set. It instead represents the two line element set that minimizes a weighted scalar error metric over a span of observations, with states propagated via the SGP4 algorithm. The inherent limitations of the SGP4 algorithm means that the cartesian coordinates computed from a two line element set will have a significant error, even at the epoch time of the element set.


Edited in response to very constructive criticism from @DavidHammen and @CallMeTom. I agree with them, but I didn't say those things in my initial answer, and I should have.

If the only source of data you have is a TLE, then you are starting from a low-quality initial state, which you should expect to be wrong by several kilometers. All a high-quality propagator can do from there is tell you where something that actually was where the TLE claimed your satellite of interest was will go. You don't know where your satellite actually was, so nothing can tell you where it will actually go. The other propagator will do a better job than SGP4 of estimating where an imaginary object at the TLE's initial state will end up, but that doesn't mean the imaginary object will evolve into a state closer to the state of the real satellite. The error built into the very approximate nature of a TLE is not recoverable without a better source of data. If you have something else, then use it instead, because TLEs are terrible.

However, with all that in mind, if all you have is a TLE, and you are interested in what happens to a notional satellite that really was where the TLE claimed something was, then yes, that is the best you're going to be able to do. TLEs exist for the purpose of being easily distributed. SGP4 exists for the purpose of turning TLEs into something more useful, like Cartesian position and velocity. Once you have those as the initial state at your desired times, handing them to a different propagator with better models for gravity, drag, solar pressure, and everything else is the best way to proceed, as long as you remember that trusting the TLE to begin with may well be your biggest source of error.

I do this routinely at work, but only in design studies to model sensor performance on a moderately realistic simulated satellite environment. In that case, propagating years into the future is not my goal. I just use a bunch of TLEs to give me a lifelike distribution of initial states, because being off by tens or even hundreds of kilometers in-track at the starting point doesn't matter to the simulation results; all that matters is how the states evolve from their imaginary starting conditions, for which I would never use SGP4. If I am doing anything with a currently operational satellite, I always have something much better than a TLE to start with.

If you have not just another propagator, but also an orbit determination tool, then you can play with using the SGP4 output to simulate observations, and determine your own orbit from that. I stress "play", because the only question this answers is "I wonder what would happen if..." You're not going to make a TLE-derived orbit better without real data; but if simulation is all you're after, then it can be interesting to explore this option. Real data is available from several commercial vendors, but it's not cheap -- except perhaps in comparison to the painfully expensive commercial orbit determination tools.

The process of converting out of TLE & TEME seems long and convoluted if you plan to type it all in yourself, but you don't have to. You can download SGP4 from https://www.space-track.org/documentation#/sgp4 and use it to process a bunch of TLEs into long lists of position and velocity; osculating Keplerian elements; latitude, longitude, and altitude; or a variety of other formats. Then you can do whatever you want with them.

@uhoh: Never take a TLE at face value! Its components are mean elements, and so is part of the definition of its coordinate system. At face value, they describe the motion of a fictional satellite with respect to a fictional equinox. However, everything is carefully arranged to combine and cancel in just the right way to get something reasonable out, but only if you use SGP4 to do it. In the words of Spacetrack Report #3,

The NORAD element sets are “mean” values obtained by removing periodic variations in a particular way. In order to obtain good predictions, these periodic variations must be reconstructed (by the prediction model) in exactly the same way they were removed by NORAD.

The point cloud approach might produce some interesting results, but I think the main flaw is we're missing some important data that space-track does not provide, namely the covariance. If we had that, we could replace each point in time with not a single state vector, but rather a large ensemble normally distributed around that point, and see how a particular confidence volume grows over time.

  • 1
    $\begingroup$ If one wants precision orbit propagation, starting with a TLE is exactly what one is not supposed to do. What would be nice would be the raw data that went into the formation of a TLE. Those data are not available to the public. Range, range rate, azimuth, and elevation data from a ground station might be available to the owner / operator of a satellite, as may be position and velocity vectors from a space-qualified GPS receiver onboard the satellite. It's those kinds of data that are needed for precision orbit determination. $\endgroup$ Sep 3, 2020 at 5:33
  • $\begingroup$ TLE/SGP4 is supposed to give a fast and easy way to get a position in near future with acetable but low accuracy. You will NEVER gain the accuracy you already lost but instaed make it bigger. There are cases, where converting TLEs to SV is resonable, but in this cases you should not propagate with SGP4 but use the SV for the TLE-Epoch and you always have to know that you are starting with a estimation, not a real position! I couldn't find a good paper on TLE-accuracy, yet. But a good estimation is an error up to 5km in in-track direction and within 1 km in most cases! (-1 b/c you are wrong!) $\endgroup$
    – CallMeTom
    Sep 3, 2020 at 6:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.