[GPS_Standard] Interesting paper

[Dave Platt]

On 11/18/2013 11:25 AM, Bob Stewart wrote:
> "Make sure that you understand that all frequencies he is referencing are multiplied by 250, so when he says the "ZAZ" GPSDO is off by a constant 2.7 Hz, he means multiplied to 2500 MHz, which corresponds to an error of 0.0108 Hz at 10 MHz."

This is consistent with what I've seen.  It's a frequency-locked loop
which uses a "proportional" control algorithm.  This means that if it's
significantly "off" in frequency (due e.g. to temperature drift) it will
converge towards the correct frequency but will have a tendency to "lag"
behind.  If the VCXO is stable, it will usually converge eventually but
if there's a continual VCXO drift (due to aging or temperature change)
it will lag behind for as long as this drift continues.

> Thanks for clarifying that.  I missed it as I skimmed through the paper and the 2.7Hz figure made no sense.
> 
> As to whether Bert's code is an FLL.  I don't think it is.  My understanding of it is that it is a Frequency Averaging System.

Well, depending on your strict definitions, maybe yes and maybe no.
I sorta think you're splitting hairs here.

It's definitely a closed-loop system.  It's measuring the frequency, and
using error in the frequency to provide feedback which attempts to servo
the frequency error to zero and thus "lock" on the correct frequency.
Hence, it's a frequency-locked loop.

> It's been so long since I looked at nothing but Bert's code, but I
believe that it loses samples between sampling periods, which is what
got me interested in rewriting it.

As I recall, it's simply leaving the capture process running at all
times.  The only sense in which it loses samples, is that it
deliberately discards the data from the first 16-second sampling period
after it makes a change in the DAC value, on the assumption that the
change to the dithering might have caused a hiccough in the DAC voltage
for the first second or so.

I could be wrong about what I remember, though.

>     Of course, I may have been misled by my testing at the time.  I
have never tested it for phase accuracy.  Too little time.  But I can
say that my current code, which does not throw samples away, does not
carry phase corrections forward.  This has to do with the way phase
errors are encountered and the extremely long dead zone between phase
points.

Yes, and (as I understand it) that's the big difference between Bert's
hardware design, and other GPSDOs such as the Brooks Shera design (which
showed up again in this month's QEX, as a controller for a rubidium
standard).

The Shera design uses a free-running higher-speed oscillator (typically
24 MHz or so) to generate pulses.  If I remember correctly it divides
down the 10 MHz signal by a convenient factor, and measures the number
of pulses of the high-speed oscillator between the PPS and the next
transition of the divided-down 10 Mhz signal.

Because the pulse oscillator is free-running and isn't synchronized with
either the PPS or the 10 Mhz signal, the residue pulse count can be
expected to dither +/-1 on any given one-second period, and the average
value of this residue (over a period of some number of seconds) actually
has a fractional part that's meaningful.  It lets you "see" the phase
shift between 10 Mhz clock and PPS, to a resolution of less than one
cycle of the 24 MHz oscillator.

This, I believe, is what gives the Shera design the ability to
phase-lock as well as it does.  After each averaging period (20
seconds?) it has a new measurement of the relative phase offset between
PPS and 10 MHz signal, good down to a resolution of a few nanoseconds
(or a few tens of degrees).

Bert's FLL hardware design doesn't let us access things this regularly.
 We can't reliably "see" phase drift except when it wraps around at 360
degrees - our "error signal" is limited to quanta of one cycle.

The technical advantage isn't all one way, though.  As I understand it
(from the technology and from reading Shera's original QST article) the
PLL approach comes along with one fairly stern requirement:  you have to
manually tune the oscillator to within a gnat's whisker before it can
phase-lock.  It has a narrow capture range.  My guess is that if you
haven't already tuned the oscillator to within a fraction of one cycle
per sample-averaging period, it won't lock... in Shera's design this
means to within a few mHz (one cycle every couple of minutes or better).
 I recall that Shera's design has an analog meter readout (fed from a
PWM on the PIC) which shows the phase offset... if it drifts more than
one full cycle every few minutes you have to re-tune manually.  This
also suggests that oscillators which are vulnerable to
temperature-induced drift would tend to fall out of lock pretty easily.
 I could be wrong about all of this, but that's my impression... and the
"manual tune" requirements were a big part of why I never build Shera's
design.

Bert's design has a very broad capture range... basically, if the
oscillator's correct frequency lies anywhere within the DAC voltage
range, it'll converge and frequency-lock.

It'd be neat to have a design which could do both - a FLL-based "fast
convergence" for initial lock-seeking, switching over to a Shera-style
de-correlated-oscillator PLL when "on target".

I did find the comparisons in the paper between disciplined oscillators
and the cesium standard to be *very* interesting.

The comments about the VE2ZAZ design leaking processor noise into the 10
Mhz signal were quite intriguing.  I wonder whether Bob's (required)
modification to the board would resolve much of this, as it locks the
processor speed to a multiple of the 10 Mhz clock?

In my own recent experiments... I think I'm approaching the point of
diminishing returns for my own setup.  I'm currently running a modified
version of Bob's code, which implements a dual phase accumulator /
integrator system rather than his second state machine.  I've also
installed the small thermostatically-controlled heater module I built,
and wrapped the whole box in 1.5" foam insulating board (except for the
rear panel, which now is the primary heat-radiating sink for the
device).  This appears to have reduced the range of excursion of the DAC
voltage over the course of a day by about 3:1, with much more gentle
changes at dawn and sunset, and the hourly-average error value is
hovering very close to zero at all times.  I think it's about time for
me to haul out the rubidium standard and DSO again, and run another set
of phase-comparison plots between the two to see how stable it actually is.

I might build a slightly larger foam-board wrapper for it, and add a big
plate of metal or a sheet of rock inside the wrapper (on top of the
case) to add thermal mass, and slow down temperature change even more.