# Accuracy of ECI (J2000) to ECEF (WGS84) for a LEO satellite only accounting for Earth Rotation

I am working on developing a simple J2 orbit propagator for a project I am working on and am at the stages of converting from ECI to ECEF. Looking at this reference document in section 2.4, what magnitude of errors will I encounter if I simply utilize only earths rotation (calculate GMST/GAST and do a single rotation about the axis), instead of also accounting for nutation, precession, and polar motion?

I am utilizing J2000 time frame and the simulations are for LEO (400-600km altitudes) that occur in near term (2015-2020) and only last maybe 2-4 months in length.

***** Added the following outline of my simulation to help give some insight after seeing some of the initial responses.

1. User defines a start and end date & time (d-m-y hh:mm:ss.sss) 2)
2. User defines a desired time step (seconds)
3. User defines satellite orbit using traditional orbital elements and an epoch (RAAN, inclination, eccentricity, etc.)
4. The simulation generates an array of time steps.
5. Vehicle location is propagated at each time step using the normal method of mean anomaly and back solving for true anomaly using newton iteration.
6. The reference frame is converted from perifocal to ECI.
7. Next solve for GMST/GAST at each time step.
8. this is where i am at with this question....converting from ECI to ECEF to eventually get WGS84 LAT/LON of sub-satellite point
• What is the goal of this simulation and what is the required accuracy? I will suggest you compare your current simulation with a professional software and see if the errors are within your requirements. You can pick a software from this list Nov 20, 2018 at 20:36
• It honestly is a personal project for access optimization and generating some data for AI. It’s not extremely high fidelity but the only major thing besides tradition propagation is just accounting for j2 effects. Nov 20, 2018 at 23:16
• If you use an equation to predict the orientation of Earth's axis in 2015 or 2020 (rather than 2000) then it should be quite close. There is a nice Q & A in Astronomy SE about a polynomial model for this but I can't find it now.
– uhoh
Nov 21, 2018 at 2:02

## 1 Answer

Are you modeling drag? If you are not, you don't even need to model the Earth's rotation because the J2 effect depends on latitude only. This is a low fidelity simulation (there are lots of effects other than J2; e.g., drag, third body effects, higher order gravity terms, solid body and ocean tides, solar radiation pressure, relativistic gravity, ...)

But if you are modeling drag, you'll need the satellite's geodetic location (geodetic latitude, longitude, altitude) and the local apparent solar time at that latitude and longitude to compute the atmospheric density at the satellite's altitude. That raises the ante on the infrastructure you need by quite a bit. At a minimum, you'll need a semi-realistic model of the Earth's rotation, both for the ECEF information (latitude and longitude) and for time.

And you'll need a model of time. Time measured according to how the Earth rotates and time measured according to the ticks of an atomic clock are two different things. You'll need to model this, at least to some extent. If you are using physics-based equations of motion, time in your simulation should be in sync with time according to that atomic clock. Effects from the Earth (non-spherical gravity, drag, ...) and where the satellite is with respect to the rotating Earth should be in sync with time according to the Earth's rotation.

An easy, low fidelity model of time: UT1 is within 0.9 seconds of UTC; for a low fidelity model you can ignore that (i.e., assume UT1=UTC). UTC is currently 37 seconds behind TAI, which in turn is 32.184 seconds behind Terrestrial Time (i.e., assume UTC=TT-69.184 seconds). Terrestrial Dynamic Time deviates from TT by a tiny fixed offset (~7e-5 seconds, which you can ignore) and by a couple of sinusoids whose magnitude is in the millisecond range (e.g., assume TDB=TT).

An easy, low fidelity model of Earth orientation: This is a bit tougher, especially since the Standards Of Fundamental Astronomy (SOFA) code makes it so easy to use a high fidelity model, often much higher fidelity than you need. (The computation of precession and nutation is easy to code but it is not cheap computationally.)

What follows is complete heresy: (1) Use the above simple model of time to compute UT1 and TT, (and also TDB if you want third body effects). and (2) replace the polar motion terms in the SOFA models with zero. (One term has already been zeroed out, ΔUT1, by assuming UT1=UTC). With ten, maybe twenty, lines of code, plus the SOFA library, you have just bumped your rather low fidelity model to moderate fidelity. If you want third body effects, use C-SPICE to compute the location of the Moon and the Sun with respect to the Earth. C-SPICE uses TDB as its time base, but TT will suffice for a moderate (not low) fidelity simulation. Note very well: For third body gravitation, you want C-SPICE to not compute aberration effects.

Aside #1: At 400-600 km altitude, you really do need to model drag if you want to have any hope at realism.

Aside #2: At some point in time (and four to six months for a satellite at 400-600 km altitude is well beyond "some point"), it doesn't matter how high fidelity one makes ones simulation. There is no hope for a realistic projection of a 400-600 km altitude satellite's ECEF position six months into the future. You might get the altitude right. Latitude & longitude: Not really. One burp from the Sun can make the Earth's upper atmosphere increase in density by orders of magnitude, and those burps are unpredictable. That said, those solar burps are less likely for the next few years given the Sun's currently weird quiescent state.

• As for the considerations I am only really taking into account J2 perturbations due to earth's flatness. I understand that "realistically" with a LEO vehicle drag causes a whole other realm of problems. I have added some more detail to the bottom of my original question into my simulation process that may give some light. Nov 21, 2018 at 15:35