[time-nuts] Glitches in data

[Magnus Danielson]

Hal Murray wrote:
> I've got an HP 5334B collecting data via a Prologix USB setup.  It's been 
> running for months.
> 
> Mostly, it's doing what I expect.  But then I got 2 glitches in the last two 
> days.
> 
> Here is a graph:
>   http://www.megapathdsl.net/~hmurray/time-nuts/Drift-ocxo3mhz-d.gif
> 
> Here is the raw data:
> 
> It's the 2.999... column.  The second column is seconds in the day day.  They 
> are 5 minutes apart.
> 
> 55019 65824.624 F +2.9999996881E+06 F +3.2768070130E+04
> 55019 66124.710 F +2.9999996881E+06 F +3.2768070725E+04
> 55019 66424.796 F +2.9999996880E+06 F +3.2768071164E+04
> 55019 66724.882 F +2.9999997045E+06 F +3.2768071592E+04 <==
> 55019 67024.968 F +2.9999996878E+06 F +3.2768072178E+04
> 55019 67325.054 F +2.9999996878E+06 F +3.2768072586E+04
> 55019 67624.140 F +2.9999996880E+06 F +3.2768073011E+04
> 55019 67924.226 F +2.9999996881E+06 F +3.2768073466E+04
> 
> 55020 61924.265 F +2.9999996883E+06 F +3.2768068930E+04
> 55020 62224.351 F +2.9999996884E+06 F +3.2768069393E+04
> 55020 62524.437 F +2.9999996882E+06 F +3.2768069919E+04
> 55020 62824.523 F +2.9999997030E+06 F +3.2768070314E+04  <==
> 55020 63124.609 F +2.9999996885E+06 F +3.2768070508E+04
> 55020 63424.695 F +2.9999996885E+06 F +3.2768070907E+04
> 55020 63724.781 F +2.9999996878E+06 F +3.2768071254E+04
> 55020 64024.867 F +2.9999996879E+06 F +3.2768071523E+04
> 
> 
> Does anybody have any suggestions for what is causing things like this?  Or a 
> checklist of things I should consider?
> 
> Everything is plugged into the same outlet.  The OCXO is powered by a wall 
> wart.
> 
> I wasn't near it at either time.
> 
> My UPS didn't see any power glitches at either time.  (They are not running 
> off the UPS.  For this, I'm just using it to monitor power.)

I would consider the possibility that you see start-channel slips where 
your start channel miss to trigger on a cycle and measures the next instead.

It would really have helped if the binary raw-data was used, since then 
the event counter and time counter would have been available separately, 
which aids in analysis, along with the interpolator data, which forms 
the real raw-data from the counter-engine.

Since f = events/time I can see if events = f*[guessed time] cranks out 
something usefull. Assuming that f should be somewhere close to 
2,9999996880 MHz for the first sample, and that we can see that 60 
second of time gives 179999981.28 and 179999982.27 events respectively, 
which seems sane. Assuming that the event counter now hit 179999982 (for 
starters, what times did we really have?
time = events/f gives 60.00000024 s for the ...6880 sample and 
59.99999991 s differing with about 330 ns, which seems to be exactly one 
period of the measured signal.

If we have had the event counter and time-counters available separately, 
we could have hidden these slips by playing some tricks with the values 
before letting them produce the frequency or period values.

Reciprocal counters are nice, but there is no reason to be hasty to mash 
the numbers together, it can help you in the initial post-processing.

Cheers,
Magnus