[Spice_discussion] Re: Spice_discussion Digest, Vol 44, Issue 1
hdewitt at dewitt-assoc.com
Fri Jun 11 14:12:24 PDT 2010
A few comments/questions:
Is the error fairly constant, show some kind of pattern, or is it random?
Are some of the calculations being done in single precision floating
point? This might lead to random errors.
Is there some subtle time error? A time error would lead to a fairly
constant error term (combined Az and El). I think it looks like a 23
second error from the few points you provide, this quite close to the
number of leap seconds in the leap seconds kernel.
DeWitt & Associates, Inc.
spice_discussion-request at naif.jpl.nasa.gov wrote:
> Send Spice_discussion mailing list submissions to
> spice_discussion at naif.jpl.nasa.gov
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help' to
> spice_discussion-request at naif.jpl.nasa.gov
> You can reach the person managing the list at
> spice_discussion-owner at naif.jpl.nasa.gov
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Spice_discussion digest..."
> Today's Topics:
> 1. Problem generating station ephemerides (William Thompson)
> 2. Re: Problem generating station ephemerides (Bogdan Nicula)
> 3. Re: Problem generating station ephemerides (William Thompson)
> Message: 1
> Date: Fri, 11 Jun 2010 12:04:30 -0400
> From: William Thompson <William.T.Thompson at nasa.gov>
> Subject: [Spice_discussion] Problem generating station ephemerides
> To: "spice_discussion at naif.jpl.nasa.gov"
> <spice_discussion at naif.jpl.nasa.gov>
> Message-ID: <4C125E8E.8040804 at nasa.gov>
> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
> 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-radii) / radii
> cspice_georec, lon_r, lat_r, alt, radii, 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
More information about the Spice_discussion