5.0

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

Convert ECEF to ECI Coordinates

by

 

18 Jul 2010 (Updated )

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

| Watch this File

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)
Tags for This File   Please login to tag files.
Please login to add a comment or rating.
Comments and Ratings (3)
11 Aug 2012 Darin Koblick

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

03 Aug 2012 John

Correction: JDate above should be: 2455728.92361111

03 Aug 2012 John

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.

Updates
01 Mar 2012

Added the acceleration term to inputs and outputs

Contact us