Convert WGS 84 (CTS, ECEF) Coordinates to ECI (CIS, Epoch J2000.0) Coordinates. This function has been vectorized for speed. The associated error in converting between coordinate frames is on the order of 1.2*10^-11 km when compared to STK ephemeris output.
To run this function type the following command in a MATLAB prompt:
>> [r_ECI v_ECI a_ECI] = ECEFtoECI(JD,r_ECEF,v_ECEF,a_ECEF);
JD is a Julian Date Vector [1 x N]
r_ECEF is the position vector in ECEF coordinates [3 x N]
v_ECEF is the velocity vector in ECEF coordinates [3 x N]
a_ECEF is the acceleration vector in ECEF coordinates [3 x N]
r_ECI is the position vector in ECI coordinates [3 x N]
v_ECI is the velocity vector in ECI coordinates [3 x N]
a_ECI is the acceleration vector in ECI coordinates [3 x N]
Is this code good for converting any ECEF vector to ECI vector other than position, velocity and acceleration?
For e.g., I want to convert IGRF Magnetic Field vector from ECEF to ECI.
I though it was included when calculating the sidereal time but I didn't see the term with the product by omega_e. Check http://earth-info.nga.mil/GandG/publications/tr8350.2/tr8350.2-a/Appendix.pdf
page 24-26 for a similar development to yours.
I came across this function after checking the equation for position between ECEF and ECI from the book Aircraft Control and Simulation By Brian L. Stevens, Frank L. Lewis Page 39, see pages 35-39 for full context
They have in their formula multiplying omega_e with THETA for position too. Which your formula does not have. This make sense since we want to correct for Earth rotation.
35 leap seconds since 1972 sounds like that is indeed what you are seeing in STK. As you know, ECEFtoECI.m takes in a Julian date, so the correction would not be internal to this particular conversion routine.
In fact, I don't think Mathworks attempts to address this issue with their juliandate.m routine. You would more than likely want to make the leap second correction when converting UTC to Julian date.
Are you able to check for the estimated position differences using Julian date in STK instead of UTC? Perhaps this should make the comparisons a little more accurate as well.
Truthfully, unless you are trying to use this routine in high-precision satellite mission operations, as long as you are consistent with your coordinate frame conversions (i.e. always using these conversion routines), it really shouldn't matter if there are minor discrepancies with STK (it is all relative motion anyway).
Correction: JDate above should be: 2455728.92361111
I was comparing the results to STK for the simple case of ECEF positon:
r_ECEF = 6378.137, 0, 0
Which is 0,0,0 Lat / Long /Alt. At a time of 6/16/2011 10:10:00 UTC (JDate = 2455728.61111) I am seeing:
STK: ECI: 3503.040, 5330.040, -3.964
ECEF2ECI: 3488.874, 5339.325, 0.0
I noticed that if I offset my time by 35 sec. in your function I get a much better agreement. That looks like it may be a leap second issue?
The Z coordinate discrepancy I was wondering about - never see Z=0 in STK for ECI J2000 coordinates.
The function is very useful - any comments you have would be great. Thanks.
Added the acceleration term to inputs and outputs