[time-nuts] Why using HP5370 ext-ref is (maybe) a bad idea
phk at phk.freebsd.dk
Fri Feb 28 16:51:20 EST 2014
A long time ago, I found out that the HP5370 is quite sensitive to
qualities of the external reference signal and after playing around
with it a bit, I decided to run my HP5370 from its own OCXO since
that was both reproducible and eliminated what I suspected was the
While playing around with John's new CPU board, and now having a bit
more kit in my lab, I decided to revisit this detail.
The setup I created is the following:
10 MHz GPS locked "lab-standard" feeds ext-ref on the HP3336.
The HP3336 generates 10MHz/0dBm which feeds ext-ref on the HP5370
The same lab-standard also feeds the start input of the HP5370
which is setup to start-common, TI, 1k samples, output stddev.
And then I step the phase of the HP3336 generated 10MHz through
0...360 degrees relative to the lab-standard.
The result is the attached plot, where for every 18 degrees
the stddev increases by 8-10ps, roughly 40%.
This is evidently because the ext-ref on the HP5370 is multiplied
to 200MHz, which is what drives the counter circuits.
Another way to run this experiment, is to set the HP3336 to
10.0000001 MHz and log the stddev's over time while the
two clocks sweep each other by in phase. Doing it this way
can give you a plot of much higher resolution.
And that scenario is where the trouble starts:
If the HP5370 ref-in clock synchronous to the experimental
signals, you will most likely be lucky, but sometimes you will not
and the noise will be much larger.
If the HP5370 ref is not synchronous, for instance running of its
own OCXO, the two phases will sometimes conspire briefly and you
get a few noisy samples, but the average will almost always be good.
I have not tried to calibrate/trim the HP5370 to see what that
does to these spikes, but it would be an interesting experiment.
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 10782 bytes
More information about the time-nuts