2
$\begingroup$

I am using Orekit to generate TLEs. I am then propagating those elements out and comparing it to the ephemeris used to generate them. This results in a residual error in excess of 20 km. I am not exactly sure why my answers are so off. Is there any general way I can improve my answer?

$\endgroup$
3
  • 2
    $\begingroup$ how far are you propagating, and using what? even under good circumstances, if you try to go a couple of days from epoch, 20 km could well be the best you're going to be able to do, because of the many weirdnesses and errors baked into the TLE format and its SGP4 propagator. $\endgroup$
    – Ryan C
    Dec 1, 2022 at 1:39
  • $\begingroup$ A mere 20 km error after a few days is pretty good for a TLE. The primary intent of the SGP4 propagator is to be fast, and to do so using what is essentially single precision floating point arithmetic. (While the algorithm has since been converted to double precision, the data format has not. TLEs only provide six or seven digits of precision, which is single precision floating point accuracy.) You're not going to get high accuracy with TLEs and the underlying SGP4 algorithm. $\endgroup$ Dec 1, 2022 at 10:27
  • $\begingroup$ I am propagating 1 day out. I feel like 20km is extremely high for just a day of propagation $\endgroup$
    – tarcin
    Dec 1, 2022 at 17:11

1 Answer 1

4
$\begingroup$

This results in a residual error in excess of 20 km.

A mere 20 km error after a few days is pretty good for a TLE. The primary intent of the SGP4 propagator is to be fast, and to do so using what is essentially single precision floating point arithmetic. (While the algorithm has since been converted to double precision, the data format has not. TLEs only provide six or seven digits of precision, which is single precision floating point accuracy.) You're not going to get high accuracy with TLEs and the underlying SGP4 algorithm.

A long time ago (40+ years ago), I worked for a company (which no longer exists) that built ground stations using a tracking antenna to process data from meteorological satellites in LEO and GEO. My employer promised 2 km mapping accuracy in the contract. In hindsight, that was incredibly stupid. A 20 km error is pretty good. We regularly saw 100 km errors, sometimes more, using government issued TLEs.

I was tasked with fixing that.

What I did was to use non-linear ANOVA (analysis of variance) techniques. I linearized the effects of the highly non-linear TLE elements at each observation point. I only used a selected set of TLE elements to be analyzed. (More on this later.) The selected set resulted in a modified TLE. Rinse and repeat. (I rinsed and repeated multiple times, both here and in the selection process.) Eventually, this outer rinse & repeat resulted in no statistically significant improvement. That was the end point.

Now I had a choice: Either throw out the one element that appeared to be least correlated with the observations, or accept the one element that appeared to be most correlated with the observations. (I don't recall whether I eventually settled on rejection or acceptance.) Rinse & repeat. Eventually, this inner correction algorithm got to the point where all of the chosen elements appeared to be statistically significant and none of the rejected elements appeared to be statistically significant. This involved linearization, which is why I wrote "appeared to be" instead of "were". The result of this inner loop correction became the new TLE used in the outer rinse & repeat loop.

The end result was a sub 2 km error that held for a day or so.

$\endgroup$
3
  • 1
    $\begingroup$ Note well: I didn't know about Kalman filters at the time I did this work. It was 40+ years ago. I might well have used a Kalman filter had I know about that technique at that time. That said, the double loop with a batch least squares filter with acceptance or rejection (which is essentially what I was using) worked quite nicely. $\endgroup$ Dec 1, 2022 at 11:41
  • $\begingroup$ One of the first things I did was to expand the internal representation of a TLE into double precision. The single precision format that is implicit in the TLE elements is responsible for a good chunk of the error, and there is no correcting those elements if left in single precision format. $\endgroup$ Dec 1, 2022 at 11:51
  • $\begingroup$ So fascinating result! I tested my same TLE generation routine with another OEM. Turns out the agreement was very good, within 1 km. I'm not sure why that specific OEM led to such wonky results. I generated a TLE from freeflyer using the same weird OEM and still had similar results. I think the issue might be due to the use of keplerian elements instead of equinoctial elements $\endgroup$
    – tarcin
    Dec 2, 2022 at 16:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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