[Spice_discussion] Problem generating station ephemerides

William Thompson William.T.Thompson at nasa.gov
Fri Jun 11 09:04:30 PDT 2010

SPICE experts:

I generate ephemerides of the two STEREO spacecraft for volunteer antenna 
stations collecting low-rate beacon telemetry outside of the normal DSN 
contacts.  Recently it's come to my attention that the ephemerides that I 
generate may be off by as much as 0.1 degrees, mainly in the direction of 
ecliptic longitude.  I would like to go over the procedure that I use to see if 
anybody can suggest what the problem might be.

I will use as an example a station in Bochum, Germany, because this can be 
directly compared to ephemerides generated by the JPL Horizons website at


This website generates the following ephemeris entries for the STEREO Behind 

  Date__(UT)__HR:MN     Azi_(a-appr)_Elev            delta      deldot

  2010-Jun-18 15:24 *m  179.5797  52.2818 1.17021276739671   0.8852056
  2010-Jun-18 15:25 *t  179.9768  52.2822 1.17021312270827   0.8864513
  2010-Jun-18 15:26 *m  180.3738  52.2815 1.17021347851951   0.8876971

However, the ephemeris entries that I generate are slightly different.

Date/Time                      Azimuth        Elevation        Doppler
(UTC)                           (deg.)          (deg.)          (km/s)

2010-06-18T15:24:00.000       179.48305       52.282704      0.88506974
2010-06-18T15:25:00.000       179.88011       52.283347      0.88631548
2010-06-18T15:26:00.000       180.27718       52.282909      0.88756124

You can see that the azimuth values are about 0.1 degrees smaller in my 
calculation than in the Horizons calculation, while the azimuth values are about 
the same.  Values near maximum elevation are shown to highlight the direction of 
the error.

The first question to ask is whether the difference is due to different 
spacecraft ephemerides being used in the two calculations.  In fact, there is a 
slight difference in the predictive ephemerides being used, but this seems to 
only change the calculation in the last signficant digit.  Here's a complete 
list of all the loaded kernels in my calculation.


The .depm.bsp files are definitive ephemeris files based on measurements, and do 
not cover future dates such as 18-June-2010.

The procedure I use to generate the station ephemerides is as follows.  First, I 
generate a frame definition kernel from the geodetic coordinates of the station. 
  The coordinates of the Bochum station are 7°11'33.4''E, 51°25'37.0''N, and 
with an altitude of 207.33 m.  My frame definition file is as follows:


    FRAME_BOCHUM_TOPO                     = 1451007
    FRAME_1451007_NAME                    = 'BOCHUM_TOPO'
    FRAME_1451007_CLASS                   = 4
    FRAME_1451007_CLASS_ID                = 1451007
    FRAME_1451007_CENTER                  = 399

    TKFRAME_1451007_RELATIVE          = 'IAU_EARTH'
    TKFRAME_1451007_SPEC              = 'ANGLES'
    TKFRAME_1451007_UNITS             = 'DEGREES'
    TKFRAME_1451007_AXES              = ( 3, 2, 3)
    TKFRAME_1451007_ANGLES            = ( -7.192566, -38.57301, 180.00 )


Therefore, my first question is whether there's something subtly wrong about the 
way I define the frame file.

Next, I calculate the position of the spacecraft in the Earth's reference frame 
using the following command:

     cspice_spkezr, sc, et, 'IAU_EARTH', 'lt+s', 'Earth', state, ltime

I considered whether that should be 'xlt+s', but that didn't seem to make much 

Next, I calculate the position of the spacecraft relative to the station via the 
following commands:

     cspice_bodvar, 399, 'RADII' , radii
     flat = (radii[0]-radii[2]) / radii[0]
     cspice_georec, lon_r, lat_r, alt, radii[0], flat, origin
     origin = [origin, 0, 0, 0]
     state = state - origin

Next, I convert to the station frame

     cspice_sxform, 'IAU_EARTH', strupcase(station) + '_TOPO', et, xform
     state = transpose(xform) # state

Finally, I convert into azimuth and elevation

     cspice_reclat, state[0:2], distance, azimuth, elevation
     azimuth   = -azimuth  * (180.d0 / !dpi)
     elevation = elevation * (180.d0 / !dpi)
     if azimuth lt 0 then azimuth = azimuth + 360.d0

The complete code can be found at


I'd appreciate any suggestions that might help explain the 0.1 degree discrepancy.

Thank you,

Bill Thompson

William Thompson
NASA Goddard Space Flight Center
Code 671
Greenbelt, MD  20771

William.T.Thompson at nasa.gov

More information about the Spice_discussion mailing list