|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.atnf.csiro.au/research/pulsar/timing/clockhistory.html
Дата изменения: Unknown Дата индексирования: Sun Dec 23 05:54:57 2007 Кодировка: Поисковые слова: п п п п п п р п р п р п р п |
The schemes used for referring measurements made using the Parkes observatory clock ("UTC(PKS)") to Universal Coordinated Time (UTC) are as follows:
From MJD 48111 until 50840, the offset between the Parkes clock and the clock at the NASA Deep Space Tracking Station at Tidbinbilla was monitored using a microwave link. The offset between this clock and UTC was also monitored.
Beginning on MJD 50844, regular monitoring of the offset between the Mark IV Parkes clock and the time standard of the Global Positioning System (GPS) was performed. The latter was provided by the Totally Accurate Clock system. On MJD 52311 the 1 PPS was switched to that provided by the Mark VI Parkes clock, for which monitoring relative to GPS time is available using version 2 of the TAC. Transfer from GPS time to UTC is possible using the monitoring of this offset made at the Paris observatory of le Bureau International des Poids et Mesures (BIPM), disseminated in the so-called Circular T. Diurnal variations in the recorded values UTC(PKS)−UTC(GPS) have been noted, and attempts were made to reduce their amplitude by fine-tuning the assumed position of the GPS receiver, however it is likely that some error remains.
The implementation of a new scheme has borne fruit in two main ways: the facilitation of a direct comparison of the GPS-clock-based UTC tie versus the UTC(AUS) common-view tie, and the detection and correction of errors in the previous scheme.
As noted above, the tie of the Parkes clock to UTC via the GPS clock is subject to an unknown error including a diurnal component. Although the diurnal component is largely removed by making daily averages, little confidence is instilled about the basic accuracy of the transfer. On the other hand, common-view GPS should have a very high accuracy. So, how do they compare?
The figure on the right shows the value of UTC−UTC(PKS) as produced via the common-view system (and Circular T), minus the value produced using the GPS clock data (and Circular T). The variation in this value is quite red, with a rougly power law spectrum of index ~−1.2 (estimated from a periodogram, not shown here). The standard deviation of the plotted points is 16 ns. By considering only the data after the "kink" at MJD 52700 the spectrum is whitened for frequencies less than 1/(30 days), and the standard deviation drops to 6.7 ns. These statistics apply to the data as provided to tempo2: daily samples, produced by averaging in the case of GPS clock monitoring, and by interpolation in the case of common-view (which already includes averaging in the sense that the data provided derives from a low-order polynomial fit of the 48-hours of data surrounding each point). It is unclear which transfer route dominates the difference errors. The observed systematic trend bears no obvious resemblance to trends in the difference between pairs of clocks in either correction chain. In any case these results show that both have very good accuracy (unless the errors are correlated). It is suggested that both routes be trialed on multi-pulsar timing data.
In the course of developing the new clock correction procedures, it was discovered that the previous scheme was in error. Firstly, the program (pkstime) that processed the UTC(PKS)−UTC(GPS) monitoring log files incorrectly interpreted the values as UTC(GPS)−UTC(PKS). Secondly, the same program produced what it took to be UTC(PKS)−UTC(NIST) and output this to the third column of (time.dat), which tempo takes to be UTC(NIST)−UTC(PKS). Although the second error corrects the first, the net result is that the UTC(NIST)−UTC(GPS) correction was applied in reverse, resulting in an error term equal to twice this offset. This term varies with a peak−to−peak of ~100 ns. The standard deviation of the points is 29 ns (working with daily samples from Circular T for UTC−GPS and interpolating between samples of UTC−NIST spaced at 5−day intervals: this is also how tempo and tempo2 derive the term).
At two points in the past, the Parkes GPS clock monitoring system has been adjusted to improve its accuracy, resulting in a step in the reported values of UTC(GPS)−UTC(PKS). The Parkes clock itself was unaffected: the step merely reflects the fact that reported values of the offset taken prior to these corrections were in error by a constant offset (in addition to roughly diurnal zero−mean modulation). The first step occurred on MJD 51835 (2000 October 18) and decreased the reported value of UTC(GPS)−UTC(PKS) by 92 ns. The second step occurred on MJD 52241 (2001 November 28) and increased the value of UTC(GPS)−UTC(PKS) by 40 ns. Both the new and old clock correction procedures compensate for these steps by adding an appropriate offset to all data that precede them. However, for unknown reasons, as of August 2004 the Marsfield and Parkes copies of the time.dat file used by tempo failed to compensate for the 40 ns step. It is suspected that the corrected version was overwritten by an older, uncorrected version at some (unknown) point in time.
In summary, timing data processed under the old scheme are likely to be contaminated by two terms:
These errors would inflate the RMS timing residual by at most 35 ns (however some proportion of this would be absorbed by the timing model). The value UTC(NIST)−UTC(PKS) as tabulated in time.dat minus the value as calulated in the new clock correction is shown in the figure on the right (red points). The blue points in this figure show the same quantity after correcting for the two terms noted above. The low−level scatter in this quantity results from the different bin boundaries and sampling points in the two schemes. The narrow 'spikes' (many of which extend far outside the domain of the plot) typically correspond to sharp steps in the Parkes clock, which were generally not performed on the same day as pulsar timing observations.