[time-nuts] GPS orthodontics: time averaging theory

Dr Bruce Griffiths bruce.griffiths at xtra.co.nz
Sat Dec 23 18:04:26 EST 2006


Brooks Shera wrote:
>
> ----- Original Message ----- From: "Dr Bruce Griffiths" 
> <bruce.griffiths at xtra.co.nz>
> To: "Brooks Shera" <ebs at mailaps.org>
> Sent: Friday, December 22, 2006 20:52
> Subject: Re: [time-nuts] GPS orthodontics: time averaging theory
>
>
>> Brooks Shera wrote:
>>>
>>>
>>> ----- Original Message ----- From: "Dr Bruce Griffiths"
>>> <bruce.griffiths at xtra.co.nz>
>>> To: "Brooks Shera" <ebs at mailaps.org>; "Discussion of precise time and
>>> frequency measurement" <time-nuts at febo.com>
>>>
>>>> Brooks
>>>>
>>>> Stop fooling yourself try reading:
>>>>
>>>> /Time Interval Averaging: Theory, Problems, and Solutions/, David Chu,
>>>> HP Journal June 1974 pp12-15.
>>>>
>>>>
>>>> Bruce
>>>
>>> Bruce
>>>
>>> Thanks for pointing out the interesting article by Dave Chu.  It 
>>> presents
>>> a nice statistical analysis of the uncertainties associated with time
>>> averaging, especially as it applies to his HP5345A counter design.  His
>>> analysis seems to support my controller design as well.
>>>
>>> The "pitfalls" Dave mentions are:
>>>
>>> PARTIAL PULSE BIAS:  very narrow gated clock pulses are not counted,
>>> thereby introducing a bias as computed in his eq(1).   Note that all 
>>> the
>>> parameters on the right side of eq(1) are constant, thus the bias is
>>> constant.  A constant bias is important for a frequency counter or a 
>>> TIC
>>> since all measurements will be slightly off, but for phase locking it
>>> makes no difference, it just moves the phase setpoint a tiny bit.  
>>> Forget
>>> the synchronizer.
>>>
>> This analysis neglects the problem of metastable states. Whilst these
>> cannot be eliminated a simple shift register synchroniser can be 
>> employed
>> to reduce the metastable state rate to less than once in the age of the
>> universe or less if required.
>
> I don't see that metastable states are involved since the 4520 counter 
> has
> no setup time that would compete with the 24 Mhz clock. - the 4520 input
> gate either passes a very narrow pulse or it doesn't.
>
The behaviour of real circuits isn't quite so simple.
>> If one also wishes to produce output pulses in lock step with GPS time,
>> these relatively large temperature dependent "constant: offsets are not
>> negligible. This "constant" offset should be particularly large with the
>> relatively slow 4000 series CMOS counters employed.
>
> The 4520 is a sync counter, not a ripple counter, the tempco should be 
> quite
> small.
>
In fact a ripple counter (in the same technology) should have a better 
performance and a lower associated offset tempco.
The response of a counter to short pulses has little to do with the 
propagation delay from stage to stage.
The propagation delay of 4000 series CMOS and its associated tempco is 
not insignificant. HCMOS, ACMOS devices and other fast CMOS logic 
families have lower propagation delays and associated tempcos.
>
>>> COHERENCE:   if time intervals are repeated at a rate coherent with the
>>> clock frequency, statistical averaging is impaired.  Dave's 5375A 
>>> design
>>> uses random clock phase modulation via a Zener diode noise source to
>>> avoid coherence.  I used a cheap 24 MHz xtal drifting clock which is
>>> surely incoherent with GPS.
>>>
>>> When I designed my phase detector I was, of course, aware of the
>>> coherence issue and I considered various clock randomizing 
>>> approaches: a
>>> VCXO driven by a random number generator (but randomness is hard for an
>>> VAX, early Bell Labs UNIX, clearly too much for a PIC),  a Geiger 
>>> counter
>>> modulated VCXO (requires a high voltage PS), etc. The cheap xtal won 
>>> out.
>>> Forget the coherence issue.
>>>
>> This is wishful thinking, the same reasoning could be applied to the
>> equally inexpensive crystal used in the Motorola M12+ GPS timing
>> receivers, however the hanging bridges are a manifestation of near
>> coherence. If this occurs with the M12+ timing receiver, why should your
>> phase detector be magically immune to this?
>
> The problems are not comparable.  I guess you don't believe Dave Chu's HP
> counter should work either.
Please explain why you believe they are not comparable.

>>> COMPUTE THE QUANTIZATION ERROR:  for me, this is the most interesting
>>> part of Dave's paper . His results are summarized in eq(5) in the 
>>> box on
>>> p.15. For the worst case, when the time interval being measured falls
>>> midway between 2 clock pulses, the rms uncertainty is T/(2 x sqrt(N)),
>>> where T is the clock period, and N is the number of measurements.  For
>>> the 30 sec counter readout interval in my design this gives a 
>>> worst-case
>>> rms uncertainty of 3.8 nsec.  For a more realistic integration time of
>>> 1000 sec the rms worst-case quantization uncertainty is expected to be
>>> 0.66 nsec.
>>>
Sound impressive until one realises that the phase detector TDEV is 
actually somewhere around 20ns at tau = 1000 sec whereas the TDEV for 
the M12+ timing receiver can be as low as 5ns at the same tau, in other 
words the performance of your phase detector limits the achievable 
performance with a modern GPS timing receiver. The phase detector 
performance needs to be better by a factor of 10 or more to ensure that 
the timing receiver noise dominates. In other words the phase detector 
clock frequency should be 100 MHz or greater to achieve this.
>>> Dave's eq(5) predicts a much smaller uncertainty when the average time
>>> interval duration is near an integral number of clock pulses.  In fact,
>>> the uncertainty is zero when the averaged time interval is exactly an
>>> integral number of clock pulses.  As it turns out, that is exactly the
>>> situation the phase lock loop is trying to achieve, an average phase
>>> equal to the phase setpoint - an integer! Dave didn't mention this
>>> interesting fact (he was building a counter, not a PLL).  Of course, 
>>> the
>>> PLL does not achieve a phase distribution whose average sits exactly 
>>> on a
>>> integer, but it's probably fairly close and the quantization 
>>> uncertainty
>>> should be significantly smaller than the worse-case values.
>>>
>> You've gone a little astray here, the clock pulses of interest are the
>> 24MHz pulses counted by your phase detector, whilst the phase lock loop
>> attempts to lock the phase of the divided down OCXO output to the GPS
>> derived PPS pulse it doesn't lock the 24MHz phase detector clock to
>> anything.
>
> That's right, it doesn't phase lock the 24 MHz  clock.  But it does 
> tend to
> center the phase count symmetrically around the 800-count integer 
> setpoint.
> This is ideal for minimizing the quantization the error.
This would be fine if the 24MHz oscillator frequency didn't wander about 
in response to temperature changes.
>
> If you still think my controller design is buggy have a look at Brian
> Kirby's recent ADEV plot.
>
> Brooks
>
The exact measurement setup used in obtaining these plots is not stated.
Without such detail the plots are of little value.
Labelling both chart axes would also be helpful.
>
>>> In most cases you can... Forget the quantization error.
>>>
>>> Brooks
>> Bruce
>
>
The performance of your circuit is still several orders of magnitude 
worse than has been done when disciplining an OCXO to the GPS signals.

Part of the problem is the inferior performance of most timing receivers.
The other part of the problem is that your phase detector is too noisy.

Bruce
 



More information about the time-nuts mailing list