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

William Thompson William.T.Thompson at nasa.gov
Fri Jun 11 15:30:21 PDT 2010


Ed Wright at JPL found the problem.  Why I tried testing using the ITRF93 
reference frame instead of the IAU_EARTH reference frame, I only changed the 
software.  Ed pointed out that the bochum.tf file also had a reference to the 
IAU_EARTH frame.  When I changed IAU_EARTH to ITRF93 in both places, and loaded 
the appropriate PCK file, it solved the problem.

I'm totally amazed that there could be a 0.1 degree difference between the 
IAU_EARTH and ITRF93 reference frames.  Maybe it has something to do with 
precession.

Bill


Henry DeWitt wrote:
> Bill:
> 
> Could the Stereo kernel be in a different reference frame from the time 
> used as an earth reference?   If one used J1950 and the other used 
> J2000, that could explain the difference.  I know that when I worked 
> with JHU/APL to tracked STEREO on their 18 Meter antenna, a .1 degree 
> difference would not have been noticed
> 
> Without doing the math, I would say that the plot is consistent with a 
> fixed time offset.  The elevation error would be minimized at noon and 
> maximized at STEREO rise/set.  The azimuth error would be maximized at 
> noon and minimized at STEREO rise/set.
> 
> You can get the time offset (if that is the problem ) by dividing the 
> error (about .0967 degrees) at noon by the earths rotational rate (360 
> degrees per 23.9344 hours).  The answer is about 23 seconds.
> 
> I am not sure exactly what one needs to do in SPICE to compensate for 
> different time reference frames.
> 
> Henry
> 
> William Thompson wrote:
>> 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


More information about the Spice_discussion mailing list