[GPS_Standard] [Fwd: VE2ZAZ]

Wed May 26 20:22:02 EDT 2010

Greetings Bob,

I never have to touch anything on my system after a power outage. With a
long sampling period in effect (I use one hour), the OCXO has plenty of
time to warm up and reach its original position before many coarse
adjustments are made by the FLL. A few hours are sufficient to reach the
nominal accuracy. Suspect a bad OCXO.

73,

Bert, VE2ZAZ
http://ve2zaz.net

Bob Bownes wrote:
> Dave,
> 
> That would certainly help avoid the dithering problem.
> 
> I _think_, if I read you right, it would also help my drift after
> unlock problem, in which, unless I crank the Sample Size (S) down, it
> won't lock again because the DAC delta is less than the drift delta.
> 
> An alternate might be an 'Initial Lock mode' in which the value of
> correction is proportional to the freq difference, much as you say.
> 
> Bob
> 
> 
> On Tue, May 25, 2010 at 5:03 PM, Dave Platt <dplatt at radagast.org> 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
>> ______________________________________________________________
>> GPS_Standard mailing list
>> Home: http://mailman.qth.net/mailman/listinfo/gps_standard
>> Help: http://mailman.qth.net/mmfaq.htm
>> Post: mailto:GPS_Standard at mailman.qth.net
>>
>> This list hosted by: http://www.qsl.net
>> Please help support this email list: http://www.qsl.net/donate.html
>>
> 
> 