[GPS_Standard] Question about averaging mechanism

[Bob Stewart]

I'm looking at it more as a long term cumulative phase error.  Let's say that you are developing an azimuth control system for an aircraft and you input 200 degrees as the desired azimuth.  During a test run, after an hour it determines that it is off by +1 degree and corrects back to 200 degrees.  After another hour it determines that it's off by +1 degree and corrects back to 200 degrees.  You are back on 200 degrees azimuth after both corrections, but you are no longer on your desired flight path.  I see the potential for hunting, but with a reasonably sized sampling period that should be eliminated, I would think.

I'll give it a try and see what happens.

Bob





>________________________________
> 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.
>
>
>
>
>