Why does the same satellite appear over the wrong longitude?
You propagate a satellite from a TLE in MATLAB using SGP4. Then you compare the result with STK.
The altitude looks reasonable. The orbital period looks reasonable. The 3D orbit shape looks reasonable.
The ground track is shifted. The position error grows strangely. The satellite appears over the wrong longitude.
The Same Vector Can Mean Different Things
A state vector [r, v] is not complete information by itself. You must also know the frame, epoch, time scale, Earth model, and units.
TEME, ECI, ECEF, GCRF, ITRF. The numbers only become meaningful after the frame is known.
The exact time the state is valid. Even a small timing offset can create an along-track error.
UTC, UT1, TT, TAI. Orbit tools may use different time standards internally.
Precession, nutation, polar motion, Earth rotation, and Earth orientation parameters affect transformations.
km versus m, km/s versus m/s, degrees versus radians. Unit mistakes can destroy a simulation instantly.
STK, MATLAB, GMAT, SPICE, and custom scripts may name or output frames differently.
TEME, ECI, ECEF, and Local Frames
The table below is the minimum frame literacy needed before comparing MATLAB, STK, TLE, or ground-track outputs.
| Frame | Rotates with Earth? | Common use | Risk |
|---|---|---|---|
| TEME | No, but tied to true-equator / mean-equinox convention | SGP4 / TLE output | Often treated incorrectly as generic ECI |
| ECI / GCRF | No | Inertial dynamics and orbit propagation | Must know the exact inertial definition |
| ECEF / ITRF | Yes | Latitude, longitude, ground stations, Earth-fixed geometry | Cannot propagate two-body motion directly without rotating-frame terms |
| Local ENU / NED | Yes, local surface frame | Antenna pointing, elevation, azimuth, local navigation | Valid only for the selected ground site |
Frame Viewer: Inertial Orbit vs Rotating Earth
Use the controls to see how an inertial-looking satellite position maps to an Earth-fixed ground track. The simplified model is educational: it isolates the Earth-rotation effect instead of implementing a full TEME-to-ITRF pipeline.
Why MATLAB and STK Disagree
A mismatch does not automatically mean one tool is wrong. Toggle the assumptions and inspect the diagnostic card.
TEME may be interpreted as ECEF or generic ECI. Expected symptom: correct orbit shape but wrong longitude or ground track.
Error Symptom Explorer
Select a common mistake and observe the approximate error signature. This does not replace high-fidelity validation, but it teaches what type of symptom each mistake usually creates.
Usually a frame or Earth-rotation problem.
Usually an epoch, mean anomaly, or propagation-start-time problem.
Usually a unit or dynamics problem.
Usually an axis convention or frame definition problem.
How to Debug the Problem Systematically
Is the state from TLE/SGP4, STK, MATLAB, GMAT, SPICE, or another source?
TEME, GCRF, J2000, ITRF, ECEF, LVLH, or local topocentric?
Do not compare states at slightly different times.
Check km/m, km/s/m/s, degrees/radians, and time units.
Never compare TEME directly with ECEF.
Altitude, semi-major axis, period, and inclination.
Position, velocity, RAAN, argument of perigee, and anomaly.
Ground track is highly frame-sensitive.
What the Error Pattern Usually Means
| Symptom | Likely cause |
|---|---|
| Orbit shape looks correct but longitude is shifted | Inertial / ECEF mismatch |
| Altitude is correct but ground track is wrong | Earth rotation not applied |
| Error grows mostly along-track | Epoch or mean anomaly mismatch |
| Orbit appears rotated | Frame convention mismatch |
| Orbit explodes immediately | Unit error |
| STK and MATLAB agree at epoch but diverge later | Propagator or model mismatch |
| Latitude seems reasonable but longitude is wrong | ECI / ECEF conversion issue |
| Ground station access times differ | Frame, Earth orientation, or time-system mismatch |
Python and MATLAB Pseudo-Code
The mistake is usually not in the plotting command. The mistake is treating a vector from one frame as if it already belonged to another frame.
# Wrong idea: # Treating TEME position directly as ECEF lat, lon, alt = ecef_to_lla(r_teme) # Better idea: # Convert TEME -> inertial/reference frame -> ECEF/ITRF first r_ecef = teme_to_ecef(r_teme, epoch, earth_orientation) lat, lon, alt = ecef_to_lla(r_ecef)
% Wrong: lla = ecef2lla(r_teme'); % Correct idea: % 1. propagate TLE with SGP4 % 2. keep track of TEME frame % 3. convert TEME to ECEF/ITRF at the same epoch % 4. then compute latitude/longitude/altitude
Why This Matters in Real GNC and Mission Analysis
Frame mistakes can cause false conclusions about mission performance, sensor pointing, or software validation.
A satellite may appear visible or invisible at the wrong time.
A camera or antenna may point to the wrong Earth location.
Residuals may look like model error when they are actually frame error.
Wrong frame handling can create misleading position differences.
A mismatch does not always mean the propagator is wrong.
The strongest answer is to ask what frame, epoch, time system, and model are being compared.