[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