M Hewitson, K Koetter, H Ward. May 20, 2003

Transcription

1 A report on DAQ timing for GEO 6 M Hewitson, K Koetter, H Ward May, Introduction The following document describes tests done to try and validate the timing accuracy of GEO s DAQ system. Tests were done to investigate the absolute timing accuracy of the current system and to validate the relative timing accuracy during the S run. Gross timing accuracy The question of whether or not the data is correctly time-stamped at the one second level was answered with a simple test: remove a signal during a particular second (by unplugging it and looking at a clock synchronised by the DCF77 time signal) and then check in the data that it is as expected. Figure shows the result. Current timing tests To test the timing accuracy of the current system we injected a ramp signal into the DAQ system (see figure ). The ramp is generated from an HPA signal generator which is triggered by a PPS signal from a Rubidium clock. The ramp frequency is Hz. A linear fit is made to the ramp as it appears in the data and the offset is recorded. Figure shows the ramp as it appears in the data with the linear fit superposed on the plot. Figure shows a histogram of these measured offsets for the case when the injected ramp frequency was Hz. Figure shows the same data as a time series. These experiments show timing residuals after removal of a whole number of samples: in all cases this was taken as 7 samples. This offset can be attributed to delays in the acquisition board as will be discussed later in this text (section.). To seperate the effects of our analysis from the timing offset and scatter inherent to the DAQ system, we repeated the above analysis with different ramp frequencies. It is easy to show that the measured in this way scales inversly with the ramp frequency (linearly with the length of the ramp samples). Figure 6 shows injected ramps of different frequency. The different starting offsets of the

2 StartTime: ::8 (UTC)..... StartTime: ::8 (UTC)..... Figure : The test signal was unplugged between :: and ::. The plot shows this behaviour as it appears in the data stream. The red segments represent the uncertainty in the time of unplugging and re-plugging the signal. The lower plot shows the signal being plugged in again between :: and :: Amplitude (V) DAQ PPS signal Injected ramp Time (µs) Figure : The PPS signal that triggers acquisition in the DAQ system and the injected ramp signal used to measure any timing delays or jumps in the acquisition system. The signals are averaged to show their relative positions more clearly and the ramp signal is shown on a mv scale to allow the slope to be visible. These measurements were made using an oscilloscope, not the DAQ system. Amplitude (mv) ramps can be clearly seen. Figure 7 shows a plot of the mean measured offset versus injected ramp frequency. A linear fit to the data allows us to extrapolate down to zero ramp length (infinite ramp frequency). From the fit we determine the residual timing offset of the DAQ system to be.89 µs (after the 7 gate delay samples are removed). A similar experiment can be done to determine the scatter in the offset measurements. One can easily show that the effect of amplitude noise in the ramp data causes the standard deviation of the measured offsets to vary inversly with the ramp frequency, i.e., the steeper the ramp, the smaller the deviations of the measured zero crossing for small fluctuations about the mean slope of the ramp. Figure 8 shows a plot of the standard deviation of the offset measurements for each ramp frequency. Again we can extrapolate down to infinite ramp frequency and see that the scatter in the measured offset due to timing fluctuations is of the order 6 ns.. ICS gate delay When the ICS board is first initialised, there is some delay between any signal connected to one of its inputs and the sampled output data. The majority of this gate delay ( samples) arises from the digital filter inherent to the ADC chip. The remainder of the measured delay is thought to arise from other clock delays in the ICS ADC board. At the start of the acquisition program, the DAQ software removes as much of the gate delay as possible by dumping a fixed (integer) number of samples that is closest to the length of the delay for the ICS boards in GEO, this is then 7 samples. This still leaves a small delay (around.9 µs) that is smaller than the sample time of 6mus and therefore cannot be compensated by the removal of samples.

3 time: 8:: (UTC) data fit zero crossing segment used for fitting StartTime: 8 8:: (UTC) variance:.8e s count time offset (us) Figure : The injected ramp as it appears in the data stream. Also shown is the linear fit that is made to the data segment shown in red. Figure : A histogram of the timing residuals of the current DAQ system taken over hours in the good state. This is for an injected ramp frequency of Hz.. Timing across reboots Figure 9 shows the timing offsets during hardware and software reboots. A hardware reboot (type I) means recycling the power to the full DAQ crate. A software reboot (type II) is performed using the interface software supplied with the processor board here the processor board operating system is rebooted and the DAQ code is run from the start. During type II reboots, the power to the cards in the DAQ crate is maintained. The results shown in figure 9 show type I and type II reboots. Here we can see that a type II reboot causes a shift in the absolute timing offset of about µs. These tests are performed with an injected ramp frequency of Hz. The reason for the jump after type II reboots has been narrowed down. For some reason, the FIFO interrupt handler of the ICS ADC board does not behave in the same way as after a hardware reboot. Data is read from the ICS onboard FIFO everytime the FIFO-half-full interrupt fires. After a software reboot, the routine that waits for a FIFO-half-full interrupt does not respond correctly on the first call of the function (although this is not the case on a hardware reboot). Calling the function a second time in the start up procedure seems to work and all subsequent calls are then OK. Although this is not necessary on a hardware reboot, it has no adverse effects so we included a second call to this function in the start up section of the code that removes the gate delay. These functions are called from the software driver that is supplied with the ICS board so we have no opportunity to improve this situation in any other way. This fixes the problems seen with type II reboots (if in a somewhat unsatisfactory manner). S timing accuracy During S, a calibration signal was injected into the data stream for the entire time. This signal was a square wave produced by a HPA signal generator and differentiated to give a set of spectral peaks. The signal has now been used to check the timing accuracy of the DAQ system throughout the run. The zero time of all plots is the start of S -8- ::.

4 StartTime: 8 8:: (UTC) time offset trend (slope: 8.6e ). Hz Hz Hz Hz Amplitude (V) Figure : A time series of the timing residuals of the current DAQ system taken over hours in the good state. This is for an injected ramp frequency of Hz. time (µs) Figure 6: A plot showing the relative starting postitions of injected ramps of different frequencies. Each ramp is the result of 6 averages. Each ramp was triggered by the same GPS edge. Figure shows a zoomed in view of this signal. Also shown is a slope fitted to a particular part of the signal. This fit was performed once every seconds for the whole of the S data and the zero crossing of each fitted line was recorded. The upper graph of figure shows the results of the analysis of all the S data. There are three distinct variations in the measured zero crossings: two periods where the values differ significantly, discrete steps in the measured values, and a general linear drift. Since the calibration signal is not related to absolute GPS time, we cannot derive any absolute timing information from it. The absolute value of the data displayed in the top of figure is arbitrary; the offset was removed in subsequent plots. From the current tests, we know that the timing offsets of the DAQ system are in the correct state after a hardware reboot. The two short periods where the measured zero crossing differs significantly represent times when the DAQ system was rebooted via the software interface (type II). This type of rebooting was shown in section to induce a bad state in the timing offsets. These times are highlighted in figure. This we call a faulty state. Since we know from current tests that the DAQ timing does not drift linearly in time, we can associate the linear drift of zero crossing with the fact that the signal generator used to generate the Hz square wave digitally synthesises the signal. The result of this digital synthesis is that the output square wave is not exactly Hz. From the slope of this line we can determine that the output of the generator was actually at a frequency of Hz. Figure shows the timing residuals of the system in the correct state in more detail with the slow linear drift removed. The plot reveals further artifacts of the fitting process that are caused by the imperfect linearity of the data segment used for fitting a straight line to, in conjunction with the drift of the signal with respect to the GPS second boundary. The steps in the data occur each time the boundaries of the data segment used for fitting have to be moved because the drift of the calibration signal has accumulated to the time of one sample. Since the calibration signal used for fitting is only approximately linear this has an effect on the slope of the fitted line. The slope of the segments between the steps is also due to the non-linearity of the data segments being used to fit: the slope of the fitted line changes as the non-linear signal segment drifts with respect to the sampling times. A plot of the boundaries of the data segment used for fitting can be seen in the lower figure. The steps in the timing residuals coincide

5 Measured offset (µs) measured offset linear fit offset = 9.66 / ramp f +.89 Standard deviation of measured offsets (µs) measured offset linear fit σ =. / ramp f Ramp length (/Hz) Figure 7: A plot of mean measured offset versus injected ramp frequency. A linear fit to the data is shown along with the equation of the best fit line. The equation shown has units of µs Ramp Length (/Hz) Figure 8: A plot of the standard deviation of each set of offset measurements against the ramp frequency used to make the measurements. A linear fit to the data is hown along with the equation of the best fit line. Each data point is the result of about measurements. Some ramps were injected with the DAQ PPS edge as the reference, some with the Rubidium PPS edge as the reference. The equation shown has units of µs. with a change of either the upper or the lower data segment boundary. The upper graph of figure shows three small vertical glitches that occur at times when the DAQ system was hardware rebooted. Each DAQ crate has its own GPS card which generates the PPS and MHz clock signals that drive the ADC card. When the GPS powers up it must phase-lock its internal oscillator to the PPS GPS signal. The time constant of such a phase-locked loop is of the order one hour. As the start-up transient decays away, the MHz clock will oscillate around its nominal frequency. Figure shows two of these events in more detail. Summary We determined the data time stamping of the current GEO DAQ system to have an absolute offset of around 6 µs which arises from the residual gate delay of the ICS ADC board that cannot be compensated by full sample shifts of the data. We identified two periods during S where the time stamping of the data was offset from the nominal value. The cause of these offsets has been demonstrated to arise from software rebooting of the DAQ system. The times of these periods are: -8- :: to -8- :: -9-8 :: to -9-8 :6: In the good state we see that the time stamping of the data does not drift more than about 6 ns. We can also see the effect on the time stamping when the GPS card is powered down and back up again.

6 StartTime: 9 8:: (UTC) timing offset (checked against Rb reference clock) time: 9 8 :: (UTC). hardware reboot software reboot hardware reboot software reboot software reboot... 6 time (min) 6 x Figure 9: A time series plot of the timing residuals during hardware (type I) and software (type II) reboots. Figure : A close-up view of the calibration signal injected throughout S. Also shown is the line fit to the falling slope of the signal at a particular time. Software reboots can be performed in future after the additional fix to the DAQ code. It should be noted that cycling the power to the DAQ GPS card causes excess timing fluctuations for about hour after powering up. 6 Notes for analysists For any analysis where timing is an issue at the microsecond level, we recommend that after a hardware reboot of the DAQ system the data is ignored for hour. References [] GEO Labbook pages, 9 [] ICSB user manual [] Crystal CS96 data sheet 6

7 raw data T good state T good state fit of correct state slope:.8e detrended, mean of correct state removed Figure : Time series showing the timing residuals for the S run. Upper graph: Offset around µs represents the correct offset. Lower graph: timing residuals de-trended and offset removed. Figure : A time series showing the timing residuals for the S run. Offset around µs represents the correct offset. samples Hardware reboot Hardware reboot lower limit of fitting window upper limit of fitting window Bad State Hardware reboot Bad State 6 zoomed in on feature from GPS frequency lock servo 6 hardware reboot hardware reboot Figure : Upper graph: timing residuals when DAQ system was in good state. Steps in the values are due to changes in the fitting parameters. The lower graph shows the times when the parameters of the fitting window (start and stop sample) were changed. The vertical lines in the lower graph are the times when the system was in the bad state. Figure : The effect of the phase-locking servo of the GPS card on the timing accuracy of the DAQ system. Prior to the hardware reboot, the DAQ system was in a faulty state. This manifests itself as additional noise on all channels. This can clearly be seen in the timing offset measurements. 7