Timing of galfa time stamps
03nov04
The galfa spectrometer uses a 1 second tick interrupt
to time stamp the data samples. The interrupt occurs, a flag is set, and
then a thread is run to record the ntp time. The time is recorded in the
variable g_time[2] with the first number being the seconds from 1970 (gmt)
and the second number the useconds since the tick. The time stamp can be
off because the ntp time has drifted and/or the thread that records the
time stamp does not run immediately after the one second tick. To get the
start
time of each integration, the double precision number g_time[0] + g_time[1]*1d-6
should be rounded to the nearest integral second. This will work as long
as the delay from hardware tick to time stamp recording is less than .5
seconds (and the ntp time has not drifted too much).
Galfa data was examined to see what the spread in
these time stamps were. Files from 29,30,31Oct04 were used to measure the
spread in the time stamp. Each file had 600 contiguous 1 second samples
(except for one
file that had a jump in time). For each file the processing was:
-
input the 600 time stamps (g_time[0] + g_time[1]*1d-6).
-
Compute the difference of (timeStamp - tickSecond) using the integral second
of the first sample as the starting place. This gives the error in the
time Stamp.
-
compute the mean, median, rms and maximum of this residual.
The plots
show the variation of the time stamps (.ps) (.pdf)
for the 30 files measured on the 29 (black), 30(red), 31(green) of oct04.
-
Fig 1 top: This has the residual mean (solid lines) and median (dashed
lines) times for the 30 files and 3 days. All of these files started about
the same time (2 am AST). The drift at the beginning of each night may
be from the ntp drift (although 50 to 100 millisecs seems like a lot of
drift for ntp). The large jump for the first file of 30oct04 occurred because
that file lost two data samples in the middle of it. The negative
offset at the beginning of some nights must come from the ntp time drifting
earlier than gmt causing the difference to be negative.
-
Fig 1 mid: The rms of the time stamps for each 600 second file.
-
Fig 1 bot: This is the maximum time deviation measured for
each file. It peaks at around 600 milliseconds in some files.
It is interesting that some of the jumps occurred at the same relative
file number night to night. It may have something to do with the network
activity (backups??) done at the same time of night. The drifting of the
time stamp over a night may be do to the ntp drift (although the drift
seems large for ntp). The 600 millisecond peaks mean that you can not just
round the g_time[0] + g_time[1]*1d-6 to the closest integer and assume
you are within .5 seconds of the correct value.
processing: usr/a1943/timing/chktime.pro
home_~phil