[GPS_Standard] Question about averaging mechanism

[Dave Platt]

On 07/19/2013 08:02 PM, Bob Stewart wrote:
> Hi again Dave,
> 
> I've been playing with this in PLL mode for awhile and I've been thinking about your comment on "hunting" as I've seen it from time to time.  I think the risk of hunting is greatest when the op-amp gain is highest - i.e. when the DAC stays in the mid-range, as in below 02000.  This is because with a gain that is too high, the dither increment isn't small enough and it can shoot back and forth over the desired value.  So, I'm experimenting with lowering the gain on my setup.  My VRef is around 6.25 volts, and I originally figured on a gain of 1.25 with R7 at 100k and R8 at around 25K.  Right now I'm experimenting with an R8 of 15K, and if the DAC still converges below 02000, I'm going to reduce it to 10K.
> 
> I've come to the conclusion that the error doesn't need to be reset.  It will converge quickly enough in "coarse" steps, and then a combination of coarse and fine, and then finally in fine steps only.  But, the one thing that I an aggravation is that I need to add some "first time" code to the CCP1 interrupt handler (LOWINT) so that it clears the phase error count (ACCUM FREQ DIFF) at the first CCP1 interrupt.  As it is, anytime I power off, I have to manually go through a D, E, A sequence to clear things up so it will start without an extremely large phase error to deal with.

Well, I think I can suggest a "thought experiment" which will show
why accumulating the error will, in fact, be a problem.

Let's say that you power up, and reset the accumulated error to
zero, and the oscillator is running distinctly too fast or
too slow (as it may be if it's been sitting for a few
days or weeks without power).

During each sample interval, you'll accumulate a bunch
of error (let's say without loss of generality that it's
a positive error).  At the end of each averaging period,
your logic will see the positive error, step the control
voltage downwards (coarsely), and leave the positive error
unchanged.  And, so, the accumulated error will continue
to accumulate and will grow larger and larger.

After enough sampling/averaging periods, and control voltage
adjustments, the oscillator will finally slow down enough
to be correct... the additional error per averaging cycle
will be zero.  HOWEVER, you still have a (large!) positive
value in the error accumulator, and so the controller will
step the voltage down further... slowing the oscillator to
*below* its desired speed.  This will happen repeatedly...
the oscillator will keep slowing down more and more, with
each averaging period, for as long as the total accumulated
error remains positive.  Eventually, the accumulated error
count will end up decrementing to zero, but by the time
this happens the oscillator will be running much too
slowly... very roughly, it'll be just as much too-slow
as it started out too-fast.

Now, the same thing will happen in reverse!  The accumulated
error will become increasingly negative (more so with each
averaging period), the controller will begin increasing the
DAC voltage, and the oscillator will being speeding up...
but until it reaches the correct speed the error counter
will continue "heading for the basement".  Once again,
the controller will continue bumping the DAC voltage
upwards for quite some time, until the oscillator has
been "running fast" for long enough to increment up
to zero... and at this point, the oscillator will be
"running fast" by almost the same amount it was at the
very beginning!

The whole system will behave like a swing, going back
and forth on either side of the correct speed.  Instead
of corrections slowing down to a crawl as the oscillator
speed approaches FLL with the GPS signal, the corrections
will be happening as coarsely and fast as possible when
the speed "swings through" the lock point.

This is a fundamental problem with an "integral only"
algorithm such as you are suggesting.  It can be
reduced in severity by using smaller correction steps
(either reducing the DAC voltage gain via analog
techniques, or using only "fine" corrections from the
controller) but this will not eliminate the oscillations...
and either of these tweaks will also reduce the speed
at which the system can actually correct for real drift
in the oscillator speed.


You're welcome to try it, of course, but I truly believe
you'll find that you've introduced more problems than you
have solved.

You might want to try throwing together a small program
(C or Python or whatever) to simulate this sort of
situation... have two "oscillators" (one controllable, and
one running at a constant rate plus or minus a random
"jitter" number during each cycle) and simulate the
approach you're considering.  You could probably simulate
a day's worth of sampling intervals in a second or so, and
see what happens when you do, or do not reset the error
accumulator after each averaging period.

My suggestion is, instead, to leave the "zero out the error
after each averaging interval" logic alone.  Instead, play
around with the coarse/fine and "no change" threshold values..
set the latter quite low, so that the controller is making
at least a fine change after every averaging period.  This
should behave like "dither" in an audio signal quantization...
it'll allow the system to track FLL errors of less than
one count per averaging period, over a sufficiently long
period of time.

Your idea of resetting the accumulated error count after
a coarse adjustment but not a fine adjustment might be
workable... but, as I said above, even this approach is
inherently subject to the "swinging back and forth across
the correct value" problem.  It'll be a resonant system
with no damping and I don't expect that the oscillations
would ever settle down.

Best regards,

	Dave AE6EO

(For what it's worth, my own VE2ZAZ with the stock code
 matches up very nicely against a couple of Datum
 rubidium oscillators... the drift is at worst one
 cycle per two minutes or so, and that's with an indoor
 GPS antenna).