[Spice_discussion] Re: Spice_discussion Digest, Vol 44, Issue
1
Henry DeWitt
hdewitt at dewitt-assoc.com
Fri Jun 11 15:25:56 PDT 2010
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
>>
>
More information about the Spice_discussion
mailing list