Time-stamps in the November 1994 data-set

0 There is a serious problem in the original data format used in November 1994. To understand the nature of this problem, remember that the individual data samples (fast channels) are taken at about 10kHz, so that the time between samples is about 100 $\mu$sec. Ideally, the time-stamps of the individual blocks should be recorded with a precision which is substantially greater than this, i.e. a few $\mu$sec at the most. However the November 1994 time stamps are recorded in two ways: as an integer number of seconds and msec (with 1000 $\mu$sec resolution) and as a floating point elapsed time. This latter quantity has a resolution of less than one $\mu$sec at early times, but a resolution of about 2000 $\mu$sec at late times (say 15,000 sec into a run).

Thus, in translating the November 1994 data into frames (which have 1 nanosec resolution time-stamps), a reasonable effort was made to ``correct" these time-stamps as much as possible, and to specify the time at which each data block begins as precisely as possible. After some research, we believe that the each block of old-format data is precisely $76/15=5.0666666 \cdots$ seconds long. So we have corrected the time stamps accordingly. One can show that in general, our time stamps agree with those in the original data, when they are expressed as floats, i.e. with the precison recorded in the original data set. There are some blocks where there is an error in the least-significant bit of the cast-into-float quantity; we do not understand this as well as we would like.

Please, be warned that the absolute time indicated by these stamps is not correct! These time stamps were not taken with a modern GPS clock system, or even with an old-fashioned WWV system. Our understanding is that the real-time computer system on which these data were originally taken had its clock set by wristwatch, with an accuracy of perhaps $\pm 5$ minutes.. Indeed the computer system crashed on November 15, 1994 and the clock was subsequently reset again, so even the time difference can not be trusted between November14 and November18 data. It appears that the computer clock was not reset after November15th, so the relative times in the remaining data may be trustworthy with somewhat better than $\pm 1$ msec accuracy.

In any data anaysis work (such as pulsar searching) where it is important to have precise time-stamps, these shortcomings must be taken into account. If you really want to determine the times more precisely than a millisecond, our only suggestion is to examine the seismometer data channel and correlate it with similar data taken by a system with good time-stamps. We don't know where to find such data, but it might exist, somewhere, in the public domain. If you do go to this trouble, please write to us and tell us the conclusions of your study. We would be delighted to correct the absolute offset error in these November 1994 time-stamps, if someone could show us how to do it!