[GPS_Standard] Bob's PLL modifications

[Dave Platt]

I've been running Bob's PLL code on my VE2ZAZ for about a week now.
The initial results are (I think) very positive.  I'm tempted to start
hacking on the code myself a bit, to deal with some of the
characteristics of my GPSDO that Bob apparently isn't facing, but
some additional thought about this will be needed.

You can see an analysis of this month's GPSDO data output at

  http://snulbug.mtview.ca.us/dave/fll.png

Up thorough the 13th, I was running VE2ZAZ's current code version.
On the 13th, I flashed Bob's 0.7 code, ran for a couple of
days, then flashed 0.8 and have been running that version since.

Legend:

-  The red dots/lines are the "per sampling interval" error -
   16-second samples for the VE2ZAZ code, 1-second samples for
   Bob's code.  Right-axis legend, measured in counts per interval.

-  The green line is the DAC control voltage.  Left-axis legend.

-  The purple line is a 1-hour average of the red dots, scaled
   so that the right-axis numbers correspond to "parts per billion
   average error."

-  The blue line near the top indicates the lock status... LOCKED
   at 12 on the right axis, "HOLDOVER" at 11, and "UNLOCKED" at 10.

My own impressions of what this plot shows:

My GPSDO is in my garage (poorly insulated, low thermal mass) and the
ambient temperature changed over a range of 10-15 degrees F or more
over each 24-hour period.  This results in a change of several
millivolts in the 5-volt regulated supplies inside the GPSDO (a 7805
has a tempco of about -0.8 mV / degree C).  You can see the
effect of this temperature change very clearly in the DAC voltage
curve, as the controller tweaks the DAC to compensate for the changes
occurring in its own reference voltages.  The average-error curve
shows similar hills and valleys - this is inevitable with a
"proportional" control algorithm, since the controller can't adjust the
DAC voltage until after some amount of error accumulates.

Bob's decision to run the CPU at a higher clock frequency, to reduce
the "counter capture" time uncertainty, definitely helps matters a lot.
There are very few captures with errors outside of the range +/- 1.

Overall, Bob's algorithm is keeping the one-hour error average
sigiificantly closer to zero than the best tuning of the VE2ZAZ FLL
I had managed to achieve.

Bob's code (now) uses only 'fine' adjustments when locked, and does
them as often as necessary to correct for drift.  This results in a
much smoother DAC voltage curve than the original code, which uses a
fixed sampling interval and has to use some "coarse" corrections to
keep up with thermal drift in my installation.

If you look at the peaks and valleys of the green DAC curve
over the last few days, you can see a bit of roughness on
the tops and bottoms.  I suspect that this is the "sawtooth curve"
jitter that Bob has spoken of.  During times when the room
temperature is drifting and the DAC voltage is trying to track it,
the sawtooth-related error is (I believe) lost in the weeds...
it's completely dominated by the temperature shift.

The plot shows some anomalies which occurred in the GPS PPS timing...
some definite "glitches".  I'm fairly sure that local RF interference
(microwave-oven) occasionally causes the GPS receiver to lose lock
on the satellites... and despite my having configured the UT+
receiver for Time RAIM mode 3 ("turn off PPS if not confident that
timing is within the following tolerance") I do occasionally see
hiccoughs in the PPS timing that cause mistracking.  I strongly
suspect these were occurring even with the older VE2ZAZ code but
were not as clearly noticeable.

You can see the effect of a couple of these pretty clearly on 9/14
and 9/15 - a "spike" of high sample errors, and a sudden coarse
adjustment in the DAC voltage which was then fine-tuned out over
the next several hours.  There's another (smaller) glitch of the same
sort on 9/15.

In version 0.8 of his firmware, Bob changes the algorithm to use only
"fine" adjustments when locked.  I also changed the default setting of
the "holdover threshold" parameter to 3 - so, if there's any significant
glitch in the PPS timing, the controller will go into HOLDOVER state,
and defer making any DAC voltage changes until it either returns to LOCK
state, or unlocks completely.

This combination of changes worked out nicely yesterday - there was a
fairly major GPS glitch, the controller went into HOLDOVER, the
glitchingness continued for several minutes and the controller went
into UNLOCKED, and then re-locked a few seconds later with only a
minor adjustment.  The DAC voltage remained stable throughout.

I've compared my GPSDO running 0.8, with my rubidium standard.  With
the rubidium well warmed up, and the two units compared during a time
when the garage temperature is remaining stable, it took about 4m30s
for the outputs of the two devices to drift apart by one cycle.
I don't know which of two was the more accurate that that point!

At this point, it's clear that my own GPSDO's error is strongly
dominated by temperature-change drift.  If I can eliminate or
mitigate this, I ought to be able to get a significant improvement
in accuracy and stability (guessing 2x to 10x).

I've thought of two ways of doing this:

-  The obvious:  eliminate the temperature shifts.  This would require
   stabilizing the temperature of the entire GPSDO case and contents...
   either with an internal heater and thermostat, or with an external
   (insulated) case with a heater or (Peltier) cooler.

-  The subtle:  modify the control algorithm for more accurate tracking.
   This would involve changing from a purely proportional control, to
   a proportional-and-integral (PI) algorithm.

I *think* that doing the latter would not be terribly difficult.  The
"integral" would simply be the sum of the per-sample errors since the
integral was last reset... i.e. the total number of cycles of error
that have accumulated.  One byte would be enough to store an accumulated
error count from [-128,127] which is more range than would be needed.

What I'd probably do (if I do this) is to track the integrated error
whenever the controller is locked (and zero it whenever lock is lost).
A small fraction of the integrated error would be added to a running
accumulator... and whenever this accumulator wraps around past
+/- 1, a fine adjustment in the correct direction would be performed.

The choice of the "small fraction" multiplier would be an important
tuning parameter.  If too small, the behaviour would be as it is
today - the controller would "lag behind" systematic drift in one
direction or the other.  If too large, the controller would tend to
oscillate - overcorrecting for accumulated error and overshooting.

In PI controllers, the multiplier value is usually set by experiment...
with no drift applied, turn the multiplier up until the control
variable starts oscillating, then reduce it until the oscillation just
stops.  Kinda like tuning an old-style regenerative radio receiver :-)

I'm not sure whether I can fit a PI algorithm change on top of Bob's
0.8 code version, and still fit into the code space of an 18F2220.
Might need to order a couple of 18F2320s, which have twice as much
program flash.