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