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
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
