Code covered by the BSD License

### Highlights from Convert ECEF to ECI Coordinates

5.0
5.0 | 1 rating Rate this file 29 Downloads (last 30 days) File Size: 3.79 KB File ID: #28234 Version: 1.1

# Convert ECEF to ECI Coordinates

### Darin Koblick (view profile)

18 Jul 2010 (Updated )

Take any vector or series of vectors in the ECEF Coordinate frame and convert them to ECI.

File Information
Description

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);

Where
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]

Acknowledgements

Julian Date To Greenwich Mean Sidereal Time inspired this file.

MATLAB release MATLAB 7.5 (R2007b)
25 Mar 2016 Maider

### Maider (view profile)

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.

Comment only
25 Mar 2016 Maider

### Maider (view profile)

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
http://media.wiley.com/product_data/excerpt/59/04713714/0471371459.pdf
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.

Comment only
11 Aug 2012 Darin Koblick

### Darin Koblick (view profile)

John,

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).

-Darin

Comment only
03 Aug 2012 John

### John (view profile)

Correction: JDate above should be: 2455728.92361111

Comment only
03 Aug 2012 John

### John (view profile)

Hello Darin,
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.