Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.astro.louisville.edu/software/xmtel/archive/xmtel-3.1/algorithms/abstime.txt
Дата изменения: Fri Aug 26 03:59:38 2005
Дата индексирования: Mon Oct 1 21:28:45 2012
Кодировка:

Introduction to Absolute Time on ARGOS/USA


Paul Ray


March 27, 2002

------------------------------------------------------------------------


Outline

* Introduction To Time Coordinate Systems <#timecoord>
* USA Event Times <#eventtime>
* GPS Operation on ARGOS <#gps>
* Correcting USA Event Times <#correct>
* Conclusions <#conclude>

------------------------------------------------------------------------


Introduction To Time Coordinate Systems

The fundamental time system for precise timing applications is
International Atomic Time (*TAI*). TAI is a continuous time standard
based on the SI second and is kept by an ensemble average of a large
number of atomic clocks around the world and has been counting
continuously (/i.e./ no leap seconds are applied) since its origin time
on January 1, 1958.

Coordinated Universal Time (*UTC*) uses the same definition of the
second as TAI and differs from TAI by an integer number of seconds. This
number is adjusted approximately every 500 days (by adding a leap second
at the end of June or
December) to keep UTC within 0.9 seconds of UT1 (the time standard based
on the length of the mean solar day). The list of all leap seconds and a
table of TAI-UTC appears at ftp://maia.usno.navy.mil/ser7/tai-utc.dat.

*GPS* Time is based on the same time standard as TAI and differs only in
that it labels time as weeks and seconds of week since the GPS Epoch of
Jauary 6, 1980 UTC. GPS time was equal to UTC at first, but since GPS
time is not adjusted for leap seconds, it accumulates a difference with
UTC. Note that the GPS Week counter is only 10 bits wide and thus rolls
over every 1024 weeks. This happened for the first time at 23:59:47 UTC
on 21 August 1999.

Terestrial Dynamical Time (*TT* or *TDT*) is an atomic timescale also
based on TAI, but set to maintain continuity with the Ephemeris Time
that it replaced. Thus TT is, and will always be, TT = TAI + 32.184 seconds.

Finally, Barycentric Dynamical Time (*TDB*) is just TT transformed to
the solar system barycenter and differs from TT by only periodic terms.

As of 1 January 1999:

* TT is ahead of TAI by 32.184 seconds (constant)
* TAI is ahead of GPS by 19 seconds (constant)
* TAI is ahead of UTC by 32 seconds
* GPS is ahead of UTC by 13 seconds (the number of leap seconds
since Jan 6, 1980)

The second two of the above conversions change each time there is a new
leap second.

See the RXTE Time Tutorial
, or the
/Explanatory Supplement to the Astronomical Almanac/ (P. K. Seidelmann,
ed., University Science Books, 1992, ISBN 0-935702-68-7) for more
information.


Time Systems Used in USA Data

The fundamental time reference for USA events is UTC. This is the
coordinate system used for the NAV message times sent from the space
vehicle. Sometimes these times are confusingly called GPS times since
they are referenced to the GPS receiver time, but (normally) the leap
second correction has been applied by ARGOS before the NAV message is
sent to USA so the times are truely UTC times. The GPS to UTC correction
is 13 seconds for all USA data because there was no leap second
introduced during the mission.

The times in USA FITS files are also in UTC time as specified in these
header items:

* TIMESYS = 'UTC ' / Instrument timing system
* MJDREF = 50454. / MJD corresponding to time 0.0
* TIMEUNIT= 's ' / Unit for time-related keywords
* TIMEZERO= 0. / Time Zero

This specifies that the time in the TIME column are measured in UTC
seconds since the reference time of 50454.0 MJD(UTC), which is June 1,
1997 00:00:00 UTC. TIMEZERO should be added to all times, but it is
currently 0.0 for all USA files. Times referenced from MJDREF are
sometimes called *mission elapsed times* or *MET*.

One other time system that comes up when viewing data is also
confusingly called "*utc*". This is the time used by picktelemII and
dat2fits to index into the USA data archive. This time is indeed based
on UTC, but is measured in the same way as Unix time, that is as seconds
since Jan 1, 1970. In this system, May 1, 1999 00:00:00 UTC is 925516800
and Nov 17, 2000 00:00:00 is 974419200 so all of the USA mission should
fall between these "utc" times.


USA Event Times

USA?s event timer is built into the Detector Interface Board (DIB). It
counts microseconds into the second based on an internal time standard
and records those counts in the event word. The event timer is cleared
each second by a direct hardware pulse from the S/V. Thus, event times
in USA data are measured as the number of microseconds since the last 1
Hz pulse from the S/V.

The 1 Hz pulse from ARGOS can be synchronized to one of two oscillators:
(1) the internal oscillator in the ARGOS IEU, or (2) higher quality 11
MHz temperature-controlled crystal oscillator (TCXO) internal to the GPS
receiver. The TCXO does not require GPS to be in lock, but the receiver
must be on and working.

Each 1 Hz pulse is associated with a time in the corresponding NAV
message sent from the S/V over the 1553 bus. When GPS is on and locked
this time is from the GPS receiver and accurate to 1 µs or better
depending on quality of the solution, number of satellites being tracked
and the current GPS constellation geometry. When GPS falls out of lock,
S/V just adds 1.0 s to the time tag each second, so you will see an
unchanging µs tag and the accuracy of the time stamps will degrade with
time at about 0.1 µs/s.

When making FITS files, dat2fits combines the time for the 1 Hz pulse
from the NAV message with the number of microseconds from the event word
to get the full event time to record in the FITS file.


GPS Receiver Operation on ARGOS

During most of the USA mission (Epochs B & D, see below <#epoch>), the
GPS receiver on ARGOS was initialized about every 6 hours,
preferentially over the North Pole to minimize the impace on USA operations.

When the following conditions are true, ARGOS will accept the GPS time
solution as true and start using GPS times for the NAV message and to
update its internal time propagator:

* (JFOMFLAG <= 4), meaning that the internal GPS reciever
figure-of-merit (FOM) is 4 or lower which means that the
time/position solution is converging to an accuracy of 50 m or
better.
* AUTCVAL is true. (UTC is valid according to the GPS receiver).
* GPS Receiver in Navigation mode (as opposed to Acquisition mode or
off)
* AGPSNSRJ = 0 (GPS solution has not been rejected)

Note that it is possible for the GPS output to be incorrect even in
Navigation mode when the receiver locks on to a false solution
temporarily due to the low redundancy of our 5 channel receiver system.
Early in the mission this caused an ARGOS sunsafe and one of the fixes
made in the FACP (flight software) upload in August 1999 was to tell
ARGOS to never accept the GPS position solution and always use the
propagated position solution. Thus, after that the output of the GPS
reciever is only used for /time/ on ARGOS, not /position/.

GPS typically drops out of NAV mode 2?16 hours following an init (or
less if the IEU temperature is cooler).

When GPS succeeds in getting lock, time jumps to correct time at first
lock While in lock or just starting to drop in and out of lock, times
are usually good to a few microseconds, but larger excursions are
possible. Once lock is lost for good, time drifts off at about 1 µs per
10 s so. So, corrections build up to a few hundred µs before the next
init. When GPS fails to get lock at all, time may not be usable until
the next init. More investigation is needed to see what accuracy can be
salvaged in these cases.

WARNING: Occasionally, a GPS init vector will be mistyped or the wrong
RAM buffer will be executed. This causes transient (a few minutes up to
6 hours) problems with the time reported to USA by ARGOS.

There is a new command, USATRAMRng, available that allows you to see the
times of each GPS init that occurred during a time interval. It is used
like this:

|xeus : 183>USATRAMRng 943747200 943833600
||00:03:40 11/28 DOY: 332
05:59:24 11/28 DOY: 332
11:55:06 11/28 DOY: 332
17:50:49 11/28 DOY: 332
23:46:21 11/28 DOY: 332
|

The name comes from the fact that GPS inits are found in the spacecraft
SOH data by looking at the TRAM telemetry items which hold the status of
the RAM buffers used in GPS inits.


GPS Time Epochs

Following are descriptions of the timekeeping status of ARGOS/USA at
various points during the mission:

1. April 29, 1999 to June 22, 1999: GPS receiver off. Daily state
vector inits were performed at 06:00 UT each day.
2. June 22, 1999 to July 7, 1999: GPS tests. Watch out for ugly
handling of leap second correction!
3. July 7, 1999 to August 18, 1999: No GPS. Same situation as Apr
29?Jun 22.
4. August 18,1999 to November 17, 2000: GPS initialized every 6
hours, over the North Pole to minimize impact on USA observations.


How Bad Are Pre-Reprogram Times (Epochs A & C)?

This questions needs further study. Many times may be as good as 1.0 s,
but some may be farther off and the quality may be very difficult to
determine.


Correcting USA Times


Boeing Time Correction Tool and the Corrected Times Database

To try to recover timing accuracies of a few microseconds during the
periods when GPS is being regularly initialized, Boeing produced a
post-processing tool called P91GPSLS. This tool processes the ARGOS
state-of-health (SOH) telemetry files and generates corrected times for
each second. It does this by analyzing blocks of time from one GPS init
to the next. For each block, it determines a time solution based on
filtering the time data when GPS is in lock and extrapolating the
solution through the time when GPS is not in lock. It takes into account
the clock variation with IEU temperature and filters out small time
jumps caused by the GPS cross-correlation problem.

We are in the process of building a complete database of time
corrections using P91GPSLS. We have some of the database currently
populated, but there are some difficulties getting the rest of the data
in because of some issues with some SOH files. We hope to have this
resolved soon and have corrected times available for all of Epochs B and D.


Corrected times from dat2fits

When dat2fits is run (without the -c option), it attempts to extract the
time corrections from the SQL database and apply them. In this case, the
times in the FITS files will be fully corrected to the extent that we
know how. Unfortunately, dat2fits does not put any indication in the
file header that the corrections have been done or what their magnitude
was. This would be a very desirable feature since it will allow users to
select which FITS file to use based on the time corrections applied.
Currently, you need to capture the output of dat2fits in a file and
inspect it manually to see exactly what corrections were applied.


How good was time during your observation?

This is a key question and is where the main effort will go now that the
basic tools for time correction are in place. What we need to have is a
way to easily retreive the status for each USA observation. This would
include the

* GPS FOM during the observation
* Time since last good GPS init
* Status of last GPS init (Did it fail? Time to first fix? How long
with FOM <= 4? Observed time jumps?)
* Other information?

We are in the process of building a database that will help answer these
questions, and then will make some tools to extract and report the
relevant information.


Comparison with the Crab

To test the timing accuracy of USA, we used a set of observations of the
Crab taken in late November, 1999. The observations were cut with
mktimeusa, then channels 1-8 were extracted using fselect, the files
were barycentered using usabary, and profiles were generated using
fpsrfold. These profiles were turned into TOAs by prof2toa and the
arrival times were compared to the Jodrell Bank Monthly Crab Ephemeris
.


Residuals to the Crab radio ephemeris with NO time corrections

USA Crab Residuals with no time corrections.


Residuals to the Crab radio ephemeris with time corrections applied


The uncorrected data shows three points which drift away from the radio
ephemeris. These were taken after GPS had fallen out of lock and the
times were going bad. The time corrections move them back into line with
the other points. The residuals to the best fit (absolute phase is the
only free parameter) are 57 µs. These data were taken in a mode with 32
µs resolution event times. The Crab radio ephemeris is only good to 100
µs RMS so we are reaching the limits of testing with this technique.


Position error limits accuracy

One final note: With GPS and the Boeing time correction tool, the timing
accuracy on the events may be approaching the 2 µs resolution of USA's
fastest timing modes. In this case, one has to start to worry about
other factors limiting the final timing precision. In particular, the
barycentering code, usabary, uses position data from the NAV message to
correct the observed times to TDB (barycentric dynamical time). If there
are errors in the position determination, they will affect the
barycentered times at the level of up to 1 µs per 300 m of position
error. Mike Wolff has done some comparisons between the NAV message and
the post-processed orbit data and found residuals of the order 3?5 km,
so I would be wary of trusting our barycentered times to better than
about 10 µs.


Conclusions and Future Directions

We have described the time measurement systems on ARGOS and in USA data
processing. With post-processing time corrections, USA event times can
be good to at least 50 µs and probably quite a bit better. The primary
tasks outstanding are to completely populate the time correction
database and develop tools to allow easy characterization of the timing
accuracy achieved for any given observation.

------------------------------------------------------------------------
Last Updated: Tue, Mar 26, 2002

Paul Ray