Propagation models: SGP4 vs J2 vs two-body
An orbit propagator predicts where a satellite will be at a given time. Two-body propagation models gravity from a point-mass Earth only; a J2 secular model adds the average drift caused by Earth's equatorial bulge; SGP4/SDP4 is the operational model TLEs are fitted for, including drag and deep-space effects.
Two-body: the ideal ellipse
Two-body propagation solves Kepler's problem: one point-mass Earth, one satellite, nothing else. The orbit is a perfect, fixed ellipse — no drag, no oblateness, no third bodies. In the Orbit Visualizer's own words: an “ideal Keplerian ellipse; no perturbations,” and its honesty disclaimer is blunt:
“Idealized two-body propagation — educational geometry only; real orbits diverge within hours.”
Use it for: learning orbital geometry, quick mission sketches, demonstrating how the six orbital elements shape an orbit. Don't use it for: predicting where a real satellite actually is.
J2 secular: adding Earth's bulge, on average
Earth is not a sphere — its equatorial bulge (the J2 term of the gravity field) makes orbital planes precess. A J2 secular model layers the long-term average of that effect onto the Keplerian ellipse: the ascending node (Ω), argument of perigee (ω), and mean anomaly (M) drift at constant rates that depend on the orbit's size, shape, and inclination. This is what makes sun-synchronous orbits work and why the ISS's orbital plane swings westward about 5° per day.
What it still leaves out is most of reality, per the app's disclaimer:
“J2 secular model: mean RAAN/ω/M drift only — no drag, no higher-order gravity, no resonance effects.”
Use it for: visualizing plane precession, nodal drift, and constellation geometry over days to weeks. Don't use it for: anything where drag matters (LEO decay) or where meter-to-kilometer accuracy matters.
SGP4/SDP4: the operational TLE model
SGP4 is the analytic model that TLEs are fitted against — using one without the other makes no sense, which is why the Orbit Visualizer selects SGP4 automatically for TLE input and describes it as an “operational TLE model with drag and deep-space terms (Vallado).” It models Earth-oblateness harmonics, atmospheric drag through the TLE's B* term, and — in its SDP4 deep-space branch, which engages automatically for orbital periods of 225 minutes or longer — lunar/solar perturbations and resonance effects relevant to GEO and Molniya-class orbits.
Its accuracy statement, quoted from the app:
“SGP4/SDP4 (Vallado reference algorithm). Operational TLE propagation; accuracy degrades with TLE age (≈1–3 km at epoch, growing per day).”
Two constraints follow directly from how SGP4 works:
- It consumes TLE mean elements only. Classical elements you type in are osculating, so SGP4 is not offered for them (“SGP4 requires TLE mean elements; classical elements are osculating.”).
- Its accuracy is bounded by the TLE's age — a fresh TLE is a kilometer-level model, a month-old one is not. See why TLE age matters.
Use it for: real satellites with reasonably fresh TLEs — pass prediction, ground tracks, conjunction screening. It is the right default whenever your input is a TLE.
One honest paragraph about frames
SGP4's native output frame is TEME (True Equator, Mean Equinox) — a frame peculiar to the TLE ecosystem, not the J2000 frame most tools display in. Software must convert TEME states before mixing them with J2000 data; the Orbit Visualizer does this with the standard Vallado transformation, using a truncated nutation series whose frame error is at the arcsecond level — a few meters at LEO radius, well below SGP4's own kilometer-level physical accuracy. Exports label the frame explicitly (REF_FRAME = EME2000 with the native TEME noted for SGP4 objects).
Accuracy expectations, verified
Model claims are only as good as their verification. The Orbit Visualizer's SGP4/SDP4 port is checked against the published Vallado reference ephemerides: every fixture timestep must match within |Δr| ≤ 10−4 km (0.1 m) and |Δv| ≤ 10−6 km/s per component, and a full-coverage check runs every state row in the published output — 33 runs, 666 states. Methodology, per-case tables, and error-code behavior are on the validation page — the single source of truth for these numbers.
Verification proves the port matches the reference algorithm. Real-world prediction accuracy is still governed by TLE age and the model's physics — that is what the disclaimers above are for.
Which model should I pick?
| Your input | Your goal | Model |
|---|---|---|
| TLE | Real-world positions, passes, conjunctions | SGP4 (the app's default for TLEs) |
| Classical elements / state vector | Watch plane precession & nodal drift | J2 secular |
| Classical elements / state vector | Pure geometry, teaching, quick sketches | Two-body (the app's default for elements) |
Propagating a TLE with the two-body model is possible but flagged in-app for a reason: “TLE mean elements propagated as osculating — expect divergence.”
See it live
This link loads an ISS-class orbit from classical elements with the J2 secular propagator selected via the prop parameter — play the scenario at a high time step and watch the ascending node drift westward:
▶ Open the J2 drift demo in the Orbit Visualizer
To choose a propagator in the app itself: every object's Propagator selector offers all three models — open the Orbit Visualizer and pick per object, or set it in links with the prop URL parameter.
Related
Mini-FAQ
Is SGP4 the same thing professional operators use?
SGP4 is the standard model for the public TLE catalog, used industry-wide for catalog-level work. Operators also use higher-fidelity numerical propagators with owner ephemerides for precision tasks; SGP4's role is fast, catalog-scale prediction at kilometer-level accuracy.
Why does the app default to two-body for typed-in elements?
Typed-in classical elements are osculating values, which is exactly what a Keplerian propagator expects — and SGP4 can't legitimately consume them at all, since it requires TLE mean elements. You can switch such objects to J2 secular to add plane drift.