Darin Koblick

Brandon,

Also, if you are trying to compare the Solar Apparent Time, (SAT) be sure to input the longitude in degrees (W < 0, E > 0).

You can see that this function will match the solutions (almost exactly ... depending on the year) to those solutions in Example 4 of the ASTRONOMICAL INFORMATION SHEET No. 58 http://astro.ukho.gov.uk/nao/services/ais58.pdf

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

Johan,

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:

EPSILONm = 23.439291-0.0130111.*T - 1.64E-07.*(T.^2) + 5.04E-07.*(T.^3);

This corresponds to the estimates contained in Vallado, Fundamentals of Astrodynamics and Applications, Second edition, (EQ 3-53). 2001.

Thank you again for double checking my work.

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.

Brandon,

Also, if you are trying to compare the Solar Apparent Time, (SAT) be sure to input the longitude in degrees (W < 0, E > 0).

You can see that this function will match the solutions (almost exactly ... depending on the year) to those solutions in Example 4 of the ASTRONOMICAL INFORMATION SHEET No. 58 http://astro.ukho.gov.uk/nao/services/ais58.pdf