[GPS_Standard] Question about averaging mechanism

[Bob Stewart]

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.

Bob - AE6RV





>________________________________
> From: Dave Platt <dplatt at radagast.org>
>To: Bob Stewart <bob at evoria.net> 
>Cc: GPSDO <gps_standard at mailman.qth.net> 
>Sent: Thursday, July 18, 2013 12:42 PM
>Subject: Re: [GPS_Standard] Question about averaging mechanism
> 
>
>
>> In Summing Mode (haven't looked at voting) I see that the current average is discarded and zeroed when a sampling session ends.  Could someone explain the reasoning behind this to me?  Essentially I'm trying to figure out why each session starts a new averaging count, rather than just applying a change to the DAC and leaving the averaging to run continuously.  I could understand this if there was a coarse correction, but not for a fine correction.
>
>Seems to me that leaving the count intact could result in overcorrection, and an
>oscillation in the DAC control voltage.
>
>In control-system terms, I believe that the VE2ZAZ design is a P (proportional)
>controller... the control correction is (roughly) proportional to the current
>error (as measured over one averaging period).  It has roughly one
>proportionality constant (the coarse/fine threshold).  P controllers never
>quite catch up to the correct control value, but with proper
>control-constant tuning they can be kept from oscillating.
>
>Not resetting the summed error after each averaging period would turn
>it into an I (integral) controller.  An integral-only controller can be
>subject to "wind-up", overshoot, and oscillation... it will dither
>back and forth on either side of the correct value.  That's likely
>what would occur if you reset the error after a coarse correction
>but not after a fine, I suspect.
>
>A more complex control algorithm is PI, which makes its control
>adjustment based on both current error (proportional) and
>accumulated error (integral).  There are separate "weights" for the
>two corrections, and there's usually an "anti wind-up" limit which
>clips the absolute value of the integrated error.
>
>Somebody could certainly rewrite the VE2ZAZ code to be a PI controller,
>perhaps with a larger range of control value adjustments (rather than
>just coarse and fine).  Tuning the P and I proportionality constants,
>the wind-up limit, and averaging period for any given oscillator and
>GPS setup would probably require months of experimenting
>due to the long averaging intervals required.
>
>
>
>
>