[time-nuts] Picket fence ADEV measurement on 5370 counters

John Miles jmiles at pop.net
Sat May 30 14:32:46 UTC 2009


Further to this:

> I'm not sure it's possible to make continuous stability
> measurements (Allan
> deviation, etc.) directly with a 5370 since they don't support
> running/overlapped measurements between readings.  If you can work with a
> 1-pps output and can provide a divider for your reference, it can be done
> with a picket-fence technique (e.g.
> http://horology.jpl.nasa.gov/papers/picket_uffc.pdf ) which I
> haven't tried
> yet.
>
> If anyone thinks it might be worthwhile, I could throw together a GPIB app
> to implement Greenhall's paper for the 5370B with a Prologix or
> NI board...
> but my guess is that most people have been using other gear for
> that sort of
> thing.

So, having just received and built two TADD-2 dividers (which look and work
great!), I started to look at the Greenhall paper in more detail today, with
an eye towards getting some picket-fence code running for the HP 5370B.  It
seems easy enough to implement, but there are a couple of things I don't
understand about the process.

1) Why all the math?  This should be a trivial algorithm, you just fetch
successive A-B time intervals from the counter and scale the intervals
directly into relative phase between source A and reference B.  Instead,
Greenhall describes a more complex unfolding algorithm that resembles a
forward-differencing technique with a fudge factor (lambda-Z), whose purpose
is ostensibly to "follow large, slow changes in (the beatnote interval
times)."

This makes little sense because if the beatnote ever drifts too close to the
picket phase from the reference, the counter will start to miss edges
regardless of what the software does.  Any practical use of the picket-fence
algorithm with drifting 1-pps sources would be limited to total runtimes
less than the amount of time needed for the sources to drift into phase with
each other.  That wouldn't be a big problem in practice -- two 10 MHz
sources 100 Hz apart would take over one day to complete a phase crossing,
and (presumably) nobody would try to measure reference/DUT sources that far
apart.

2) Something peculiar that my 5370B does: when the A-B time interval is
about 60 milliseconds either side of coincidence, the counter fails to
report a measurement at every other second.  E.g.:

Sat May 30 06:37:47 2009     TI = 9.48645886170E-01
Sat May 30 06:37:48 2009     TI = 9.48645890060E-01
Sat May 30 06:37:49 2009     TI = 9.48645893870E-01
Sat May 30 06:37:50 2009     TI = 9.48645897320E-01
Sat May 30 06:37:51 2009     TI = 9.48645901190E-01
Sat May 30 06:37:52 2009     TI = 9.48656259040E-01
Sat May 30 06:37:53 2009     TI = 9.48756252730E-01
Sat May 30 06:37:54 2009     TI = 9.48856246600E-01
Sat May 30 06:37:55 2009     TI = 9.48956240020E-01
Sat May 30 06:37:56 2009     TI = 9.49056233810E-01
Sat May 30 06:37:58 2009     TI = 9.49256221440E-01
Sat May 30 06:38:00 2009     TI = 9.49861762440E-01
Sat May 30 06:38:02 2009     TI = 9.51787261680E-01
Sat May 30 06:38:04 2009     TI = 9.53785271190E-01
Sat May 30 06:38:06 2009     TI = 9.55783280510E-01
Sat May 30 06:38:08 2009     TI = 9.57781289960E-01

I'd expect some invalid behavior as the edges come into coincidence with
each other, but I wouldn't expect that behavior to show up at time scales in
the milliseconds, since the 5370's minimum time-interval spec is 10
nanoseconds.  This happens in both +TI and +/-TI modes.  Maybe I have a
calibration problem, or maybe I just need to re-familiarize myself with the
5370's interpolator mechanism... but either way, it seems that there are
going to be problems with any picket-fence implementation if the edges are
allowed to approach coincidence.  Whether this happens at margins of 10
nanoseconds or 100 milliseconds, it will hose any attempt at continuous data
collection.

One workaround would be to synthesize the missing values by lerping between
any reports received at two-second intervals... but if I go down that road,
I might as well interpolate between conventional frequency measurements to
simulate a zero-dead-time counter.

So if interpolation between skipped 1-second periods isn't acceptable, the
5370B ADEV program will need to report an error and terminate the
measurement if the time interval readings ever approach the -100 to +100
millisecond zone.  Is that a showstopper for anyone, other than users who
aren't able to tweak the phase of either of their 1-pps sources?

-- john, KE5FX





More information about the time-nuts mailing list