Convert ECI (CIS, Epoch J2000.0) Coordinates to WGS 84 (CTS, ECEF) Coordinates. This function has been vectorized for speed.

Example Function Call:
>> [r_ECEF v_ECEF a_ECEF] = ECItoECEF(JD,r_ECI,v_ECI,a_ECI);

Where:
JD is the Julian Date vector [1 x N] (units are in days)
r_ECI is the position vector [3 x N] (any units are permitted)
v_ECI is the velocity vector [3 x N] (any units are permitted)
a_ECI is the acceleration vector [3 x N] (any units are permitted)

Darin,
I have been importing some ECI data from the OrbitTools C++ library and have stumbled upon some weird behavior.

In MATLAB I am using your functions to transform ECI to ECEF and then using the MATLAB function, ecef2geodetic to transform into normal azimuth/elevation/height coordinate space.

The weird behavior is that despite having smooth ECI data (smooth as in no jumps in the data) as inputs, I am getting discontinuous ECEF data (graph for r_ECEF(1,:) and r_ECEF(2,:) looks like saw). This is happening for GOES-8 and GOES-15 satellite data.

What is weirder is that on a macro scale (ignoring variations, including the sudden discontinuities), the position of the satellite in the mapa mundi seems to be correct.

J2000 is factored into the ECI to ECEF conversion routine through the call to JD2GAST.m (converts Julian Date to Greenwhich Apparent Sidereal Time). In order to do this, the effects of nutation are considered, and depend on the correct number of Julian centuries since J2000.

It seems that this code considers the rotaion about Z-axis, or the earth's rotation axis only. However, the most commonly used ECI frame is J2000 which is defined at 1 January 2000, so I believe the effects of precession and nutation should be considered in the conversion between ECI(J2000) and ECEF.
Please let me know your opinion.

You are correct, thank you for spotting that mistake. I should have left everything in degrees since the mean obliquity of the ecliptic is referenced directly in the final computation.
The new parameters for the mean obliquity should be:

This function is great.
Although i think i found a mistake in your JD2GAST file.
When calculating the EPSILONm shouldn't the first number be 84381.448 and not 84381448 to make sure EPSILONm is calculate in arcseconds.
Shouldn't you convert EPSILONm from arcseconds to degrees like you did with dPSI and dEPSILON?

The MATLAB function juliandate.m should be fine. Can you please post the epoch, the position/velocity vector in ECI coordinates, and your ECF solution?

Thanks Darin for your reply.
I am using matlab function 'juliandate' to convert my time to julian date format. I have searched whether it is a J2000 format but could not find anything on Mathworks page. Can you please help me for this as well.

I am having some problems in calculating ECEF data. In my calculations, the satellite positions are calculated at the wrong side of Earth (globe) in the same plan they are now being calculated. Can you guide me for this please? Note, the data I am giving to the function is verified and I can easily say that my calculations can wrong, the data can't be. Please help.

I am facing problem in converting 1441 values of position and velocity vectors from ECI to ECEF. It seems that function works fine. When 93 out of 1441 values were passed to the function it gave values for x,y & z components which I thought are correct but when 186 out of 1441 values were passed to the function, the initial 93 x & y values were different from the one that I got by passing only 93 values, z components were the same. similarly when more values were passed the x&y were different except the z-component.
can you please guide what could be the problem?