Mick, this is a fairly common issue with TLE propagation libraries (including the SGP4/SDP4-based satellite.js) when you try to propagate to a time that is
before the TLE's epoch. The SGP4 model
can mathematically propagate both forward and backward from the TLE epoch, but in practice, several factors can cause errors to blow up when you go backward in time.
Here's a formal breakdown of why that often happens:
A TLE is essentially a snapshot of a satellite's orbit at a specific reference time (the "epoch"),
plus some parameters (like drag term B*) that approximate the satellite's motion going forward. It was never really designed as a fully reversible ephemeris—especially
far before or
far after its epoch.
- Forward vs. Backward Accuracy: The model's built-in drag parameters (and other approximations) are tuned for the time after the epoch. If you go too far backward, the model might introduce large errors, because actual atmospheric drag or maneuver changes prior to the TLE epoch aren't accounted for.
Many operators release TLEs daily or even more frequently. Each TLE is valid in a window (often ± a few days at best) around its epoch, with best accuracy
closest to that epoch.
- If your simulation time TTT is earlier than the TLE epoch:
- You are effectively pushing SGP4 in a direction the orbit solution was not primarily fitted for.
- Small numerical differences or mismatched drag conditions can cause surprisingly large position errors, even with just a few hours of backward propagation.
- If your simulation time TTT is later than the TLE epoch:
- You'll usually see more stable results because that's precisely what TLEs are used for: forward prediction from the epoch. The error might grow over time, but it usually grows in a more predictable way.
Under the hood, satellite.js (which implements SGP4) simply takes your input time, calculates Δt=(time - epoch)\Delta t = \text{(time - epoch)}Δt=(time - epoch) in minutes, and plugs that into the SGP4 equations. If Δt\Delta tΔt is negative, it will do a backward propagation.
Mathematically, that's allowed, but it's more prone to instability for the reasons discussed:
- Atmospheric Drag is Forward-Looking
The single ballistic coefficient (B*) in a TLE is an average approximation of drag for some future period. Going backward might not reflect the real drag history.
- Maneuvers or Other Orbit Perturbations
If the satellite made a maneuver before the TLE epoch, the TLE would not reflect that if you propagate backward—leading to large position and velocity mismatches.
- Model Limitations
SGP4 is a simplified analytic model, not a precise numerical integrator over extended times. Short backward windows can be fine, but you might see rapidly increasing errors as you go further back.
- Use a TLE Epoch Before or Very Close to the Time of Interest
- For times prior to the TLE epoch, try to obtain an older TLE that covers that time.
- If you must propagate backward, be aware of reduced accuracy and keep the backward interval as short as possible.
- Check Multiple TLEs
- If you have TLEs for multiple days, use the one with an epoch closest to (but not after) your desired time TTT.
- Consider a Higher-Fidelity Orbit Propagation If Accuracy Is Crucial
- For serious historical orbit analysis, you might need a more rigorous orbital ephemeris or a numerical integrator that accounts for actual drag events, maneuvers, etc., rather than a single TLE snapshot.
- Yes, satellite.js can interpolate backward (i.e., it tries to propagate the orbit backward in time), but TLE-based SGP4 solutions are inherently less accurate the farther you get from the epoch, especially in reverse.
- It "suddenly goes wrong" because the TLE was never intended to be used for times prior to its epoch—the simplifications and drag approximations that make SGP4 convenient become very inaccurate backward in time.
Hence, if you want consistent results at time TTT, you should use a TLE with an epoch
before or very close to TTT. That will usually solve the sudden inaccuracies you're seeing.
