[Spice_discussion] Re: Spice_discussion Digest, Vol 44, Issue 1

William Thompson William.T.Thompson at nasa.gov
Fri Jun 11 14:59:23 PDT 2010


Henry:

All calculations are done in double precision.

That was a good suggestion about looking for patterns in the error.  The error 
has a very definite pattern to it, as shown in the attached plot.  This is 
probably a valuable clue as to what is going on, but I don't know how to 
interpret it.  The dominant error is in the azimuth angle, and this is largest 
at 180 degrees azimuth.

I thought about the possibility of a timing error, but I don't really see how 
that is possible.  The ASCII UTC timestamps that appear in the file are 
converted into ephemeris time via cspice_str2et to pass into the SPICE routines. 
  This command includes all leapsecond factors via the naif0009.tls kernel.  No 
further manipulations are applied to the time beyond that point.

Bill



Henry DeWitt wrote:
> Bill:
> 
> 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.
> 
> Henry DeWitt
> 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
>> 	http://naif.jpl.nasa.gov/mailman/listinfo/spice_discussion
>> 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
>>
>> 	http://ssd.jpl.nasa.gov/horizons.cgi
>>
>> This website generates the following ephemeris entries for the STEREO Behind 
>> spacecraft:
>>
>>   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.
>>
>> /solarsoft/stereo/gen/data/spice/gen/naif0009.tls
>> /solarsoft/stereo/gen/data/spice/gen/de405.bsp
>> /solarsoft/stereo/gen/data/spice/gen/pck00008.tpc
>> /solarsoft/stereo/gen/data/spice/gen/heliospheric.tf
>> /solarsoft/stereo/gen/data/spice/gen/stereo_rtn.tf
>> /solarsoft/stereo/gen/data/spice/sclk/ahead/ahead_science_06.sclk
>> /solarsoft/stereo/gen/data/spice/sclk/behind/behind_science_06.sclk
>> /solarsoft/stereo/gen/data/spice/epm/ahead/ahead_2009_050_definitive_predict.epm.bsp
>> /solarsoft/stereo/gen/data/spice/epm/ahead/ahead_2010_155_01.epm.bsp
>> /solarsoft/stereo/gen/data/spice/epm/behind/behind_2009_049_definitive_predict.epm.bsp
>> /solarsoft/stereo/gen/data/spice/epm/behind/behind_2010_148_01.epm.bsp
>> /solarsoft/stereo/gen/data/spice/depm/ahead/ahead_2006_350_01.depm.bsp
>> /solarsoft/stereo/gen/data/spice/depm/ahead/ahead_2008_037_01.depm.bsp
>> /solarsoft/stereo/gen/data/spice/depm/ahead/ahead_2008_078_01.depm.bsp
>> /solarsoft/stereo/gen/data/spice/depm/ahead/ahead_2010_155_01.depm.bsp
>> /solarsoft/stereo/gen/data/spice/depm/behind/behind_2007_021_01.depm.bsp
>> /solarsoft/stereo/gen/data/spice/depm/behind/behind_2007_053_01.depm.bsp
>> /solarsoft/stereo/gen/data/spice/depm/behind/behind_2008_037_01.depm.bsp
>> /solarsoft/stereo/gen/data/spice/depm/behind/behind_2008_078_01.depm.bsp
>> /solarsoft/stereo/gen/data/spice/depm/behind/behind_2010_148_01.depm.bsp
>>
>> 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:
>>
>> \begindata
>>
>>     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 )
>>
>> \begintext
>>
>> 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 
>> difference.
>>
>> 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
>>
>> http://sohowww.nascom.nasa.gov/solarsoft/stereo/ssc/idl/spice/ssc_write_station.pro
>>
>> I'd appreciate any suggestions that might help explain the 0.1 degree discrepancy.
>>
>> Thank you,
>>
>> Bill Thompson
>>
>>   
> 
> _______________________________________________
> Spice_discussion mailing list
> Spice_discussion at naif.jpl.nasa.gov
> http://naif.jpl.nasa.gov/mailman/listinfo/spice_discussion
> 

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

301-286-2040
William.T.Thompson at nasa.gov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ephem_error.gif
Type: image/gif
Size: 8431 bytes
Desc: not available
Url : http://naif.jpl.nasa.gov/pipermail/spice_discussion/attachments/20100611/2f08d3ac/ephem_error-0001.gif


More information about the Spice_discussion mailing list