[GPS_Standard] VE2ZAZ

[Bert, VE2ZAZ]

Dave,

If the FLL does frequent coarse adjustments, it may be that the F 
parameter is set too low. If the correction is always in the same 
direction and is significant, The behavior you are describing represents 
more of a re-tracing (or defective) OCXO than of a stable system.

I spent a lot of time running this firmware before releasing it. I made 
sure it would converge to the sweet spot every time. The design 
objective was to meet an accuracy of better than 10e-9. It took months 
of design and observation (a full year, if I recall). When I met the 
design objective, I considered the mission to be accomplished (at that 
point I was anxious to move on). I actually expected some of the users 
to make mods to the firmware to improve it and suit their needs. But 
little was ever done. Unfortunately, I am not willing at this point to 
spend any more time spinning the firmware. My list of things to do is 
endless (and I am only referring to my electronics list, not my personal 
life one!)

There is no doubt in my mind that the firmware algorithm could be 
improved. For example, a cold start acquisition could be implemented so 
that a ball park DAC value is found faster. What I have found though is 
that within a few hours following a power outage, the system reverts to 
its nominal accuracy. Your scheme of fine-modulating the adjustment may 
improve the stability (wander). You have to make sure though that you 
are not creating more jumping around the sweet spot than there is 
already. It seems obvious at first, but trying it would prove it. In the 
end, there are so many factors that come  into play in getting a "tuned 
up" system:

- The parameters settings,
- The tuning slope of the OCXO,
- The GPS 1PPS stability and accuracy
- Voltage regulators' regulation vs. load and vs. temperature
- The OCXO quality (some units are clear defects, even HP's)
- The amount of noise that reaches the OCXO tuning pin...
- ...

Finding the right combination is the challenge! Using Montrol's built in 
stats window will help you find a more stable combination without having 
to revert to spreadsheets or such. Of course, the tool will not reveal 
anything on accuracy, though. Allan Deviation studies can help measure 
short term stability and adjust the system for optimum stability, but 
you need an atomic reference better than what you are trying to measure 
in order to make it mean something.

All in all, an endless topic! So much fun...

Thanks and 73,

Bert, VE2ZAZ
http://ve2zaz.net



Dave Platt wrote:
> In looking at the design, and code, and behavior of the
> current controller firmware, I had an idea which might
> allow for greater flexibility and accuracy in the
> oscillator tracking, without requiring too much effort
> to implement.
> 
> Currently, the controller has only two quanta of adjustment
> for the DAC:  fine, and coarse (the latter being 16x the
> former), with a single error threshold being used to select
> between the two (and lower "negation" threshold being used to
> suppress any change at all).  This allows the correction
> increment to be proportional to the amount of error... but
> only roughly so.  There's no way to get an intermediate
> correction step, or one larger than the "coarse" step...
> the effect of both can be achieved by making more frequent
> corrections (shorter averaging period) but as you've noted
> this comes at the expense of greater jitter sensitivity and
> thus reduced accuracy.
> 
> In looking at the tracking reports from my controller, I
> notice a pattern during periods of temperature change:
> 
>    F+ F+ C+ F+ F- F+ C+ F- F+ F+ F+ C+
> 
> or something of that sort... the controller is fairly
> consistently changing the control voltage in the same
> direction, and is alternating between "fine" and "coarse"
> adjustments.  Apparently, the desired rate-of-change is
> averages out to somewhere between "fine" and "coarse", and
> the controller is forced to dither between these two adjustments
> to create the correct average.  This would lead to poorer accuracy,
> over this period, than would be the case if the adjustments were
> made at the ideal step sizes (somewhere between coarse and fine).
> 
> It seems to me that it might be possible to change the logic
> a bit, by redefining turning the "fine threshold" parameter
> into a "fine/coarse scaling" value.  Currently, the logic
> has the effect of (something like):
> 
>   if |error| < negate then
>     correction = 0
>   else if |error| < fine then
>     correction = 1 * sign(error)
>   else
>     correction = 16 * sign(error)
> 
> The revision would be along the lines of
> 
>   if |error| < negate then
>     correction = 0
>   else
>     correction = (error * fine) / 4 [with logic to handle overflows
>                                      by setting "correction" to the
>                                      maximum reasonable step]
> 
> In other words, the "fine" value would act as a scaled
> proportion.  A value of "8", for example, would have the
> effect of meaning that a 2-count error in the sample would
> result in a voltage correction of 4 finesteps (or 1/4
> coarsestep).  A value of "2" would mean that a 2-count error
> would result in a 1-finestep adjustment.
> 
> [I chose the scaling value of 4 - i.e. a 2-bit right signed
>  shift - out of a hat.  Larger values such as 8 or 16 would
>  allow for more precision in setting the proportion, but would
>  tend to limit the maximum correction step.]
> 
> This sort of change might allow for more rapid initial
> acquisition during initial turn-on - rather than having to reduce
> the sample averaging period, you could just make larger adjustments
> after each individual period.  It could also allow for better
> accuracy during steady-state operation, by reducing the number
> of unnecessarily-large "coarse" adjustments.
> 
> On many micros, this might be too expensive/bothersome to
> implement... but it looks as if the PIC18F2220 has a reasonably
> decent hardware multiplier which might be used to do the
> multiply quite quickly, and the divide-by-4 would be a
> two-byte signed right shift.
> 
> Another tweak would be to an an "error integral" to the
> calculation... keep some sort of scaled or IIR-filtered
> sum of the accumulated errors over the last N averaging
> intervals, clip this value to some |maximum| to avoid
> excessive-windup problems, scale it, and add it to the
> correction value as calculated above.  This would allow the
> controller to start making even larger adjustments when it's
> consistently fast or consistently slow.  This would come
> at the cost of some additional code complexity, and
> (depending on the "fine scaling" and "integral scaling"
> factors) there could be some overshoot.
> 
> Comments?  Suggestions?  Dirty remarks?
> 
> This is a *really* fun little project - Bert, thanks
> immensely for developing and publishing it!
> 
> 73,
> 
> 	Dave AE6EO
> 
>