[time-nuts] Brooks Shera

Richard H McCorkle mccorkle at ptialaska.net
Mon Mar 25 22:05:08 EDT 2013

You are preaching to the choir and although Brooks felt that
using an XO and asynchronous gating to improve the resolution
was sufficient and GPS sawtooth correction was not needed with
the long averaging times in his controller that doesn't mean
that I agreed. The early work I did just reduced the glitches
and improved the resolution so there was sufficient gain for
proper damping to discipline an atomic source. As I learned
more the benefits of greater phase accuracy became apparent
and led to the development of the IDC.
  The IDC uses the disciplined source as a stable timebase with
PICTIC interpolation to increase the resolution. The typical
interpolation gain is 400 for 62.5ps/sample resolution but
this is reduced to 1ns to match the GPS resolution. The combined
instabilities in the interpolator are below +/- 4 ADC counts so
after the 16x reduction the 1ns phase data returned is accurate.
The 1PPS stability has no effect on the 1ns TIC resolution so
the accumulated phase data is accurate whether the 1PPS timing
is varying or stationary. The data has the GPS sawtooth correction
applied before filtering, so even if a 1PPS offset is present for
an extended period during a hanging bridge the sawtooth corrected
phase data entering the filter will be accurate. The only place in
the IDC where the sawtooth is used to advantage is over a 2 hour
calibration period there are typically enough min/max variations
due to the GPS sawtooth to accurately determine the interpolator
offset and span.


> Hi
> Using the GPS sawtooth as a source of randomness is dangerous. It can stop moving
> for minutes at a time if the conditions happen to be just right (or in this case
> wrong). Of course lack of randomization isn't your only problem when this happens.
> The (likely substantial) offset in the data is also a significant issue.
> Bob
> On Mar 25, 2013, at 8:35 PM, Bruce Griffiths <bruce.griffiths at xtra.co.nz> wrote:
>> Richard H McCorkle wrote:
>>> Hi Tom,
>>> In the Shera design the instability of the XO timebase is
>>> a key factor in improving the 30-second update resolution.
>>> With the XO drift varying the sample point across the 1PPS
>>> and 312.5 KHz edges the samples are constantly varying and
>>> the average of the samples has a resolution much closer to
>>> (1/CLK)/30 or 1.4ns. If both signals were synchronized
>>> with the clock the start and stop edges of every sample
>>> would fall exactly on a clock. In lock the odds of the
>>> sources having a sample-to-sample variation greater than
>>> 1 clock period (+/- 41.7ns) over the 30 second sample
>>> period is low. So the probability is high that you would
>>> get 30 identical samples with an average resolution much
>>> closer to 41.7ns (+/- 1 clock).
>> The above assertion is not correct if the inputs to the synchroniser(s) are
>> asynchronous to the synchroniser clock.
>> The gate period will have a bounded (neglecting the effect of metastability at
>> the output of the synchronisers) variation of +- 1 count.
>> Provided that the synchroniser (and counter) clock and the divided down
>> disciplined oscillator clock meet the conditions outlined by David Chu in:
>> http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1974-06.pdf
>> In practice these conditions may be difficult to meet without adequate random
>> phase modulation of PPS (and the divided down disciplined oscillator signal).
>> Alternatively phase modulating the synchroniser/counter clock is perhaps simpler.
>> The sawtooth phase modulation of the PPS signal output produced by many timing
>> GPS receivers isnt sufficiently random to be particularly useful.
>>>   The counter clock and asynchronous gate are applied to
>>> an AND gate in the CD4520 that drives all 4 stages so when
>>> an asynchronous gate edge and clock are coincident a short
>>> clock pulse is generated and the setup and hold times of
>>> the CD4520 counter are not met. Under these conditions the
>>> first 4 stages in the 4520 could end up in an indeterminate
>>> state and the input to the 4040 would be questionable. The
>>> counter should settle to some value by the next clock,
>>> but the value could be up to +/- 31 counts different than
>>> it should be. Shera gates multiple samples into the
>>> counter with a single read/reset per 30-second update so
>>> multiple uncertainties can be introduced in the accumulated
>>> count.
>>>   Recognizing the probability of asynchronous gating
>>> resulting in glitches in the data Shera uses a de-glitch
>>> routine in modes 4-7 that detects any 30-second value that
>>> exceeds +/- 30 counts from the previous value as a glitch
>>> and uses the previous value when this condition is detected.
>>> This is far from ideal as multiple errors could be
>>> accumulated with an average value less than +/- 30 counts
>>> per update, but it does handle the occasional glitch when
>>> the gate and XO edges are coincident and a>30 count error
>>> results. The XO stability usually insures coincidence will
>>> be short lived, but multiple 30-second glitched samples
>>> do occur, so a 3 glitched update (90-sec) limit is included.
>>>   During my early work on upgrading the Shera a number of
>>> different counter designs with asynchronous gating were
>>> evaluated. I settled on the AC163 as the clock is not
>>> gated directly so no short clock pulses are ever applied to
>>> the stages. Instead the /Q to D is gated and the previous
>>> Q is passed to the next stage on the clock to determine if
>>> it should advance. The gate to clock setup time is 2.5ns
>>> with a hold time of -3ns, so if the setup time is met the
>>> first stage advances, but if it rises and falls immediately
>>> around the clock no advance occurs. This design reduces the
>>> possible uncertainty with coincident gate and clock to
>>> the first stage only (+/- 1 count) but with the hold time
>>> smaller than the setup time typically no glitch will occur.
>>> A 100 MHz XO driving an AC163 prescaler feeding TMR1 was
>>> used with asynchronous gating. Each sample was read, added
>>> to a software accumulator, and the counter reset after
>>> every sample. In testing this asynchronous gated design it
>>> produced no glitches (+/- 30 counts from the previous
>>> sample) during 1 year of continuous operation but still
>>> has the advantage of good sample averaging over the
>>> 30-second update period for a phase resolution of 330ps.
>>>   Of course the ideal to get the optimum data out of the
>>> GPS is to use a TIC with 1ns resolution and apply GPS
>>> sawtooth correction to reduce the uncertainty in every
>>> sample. To insure the counter value is correct you need
>>> to synchronize the start and stop events to the clock
>>> so only whole clock cycles are counted, but then you are
>>> limited to the resolution of the clock. This is where
>>> interpolation can be used to get the desired resolution
>>> even though the counter resolution is limited to the
>>> clock period. In the Interpolating Discipline Controller
>>> (IDC) the disciplined source is multiplied to 40 MHz for
>>> the TIC timebase and used to produce a 10us delayed
>>> 50 KHz phase detector reference. The GPS 1PPS is
>>> synchronized to the 40 MHz clock to start the counter,
>>> with an interpolator determining the 1PPS to clock delay
>>> with 1ns resolution. The 50 KHz stop signal is also
>>> synchronized to the 40 MHz clock to equalize the start
>>> and stop delays, but since both are derived from the
>>> disciplined source their delay is constant and a stop
>>> interpolator is not required. The sample is read from
>>> the counter, multiplied by 25 to 1ns resolution, the
>>> interpolated start delay is added, and the result is
>>> added to a software accumulator over the update period.
>>> A separate PIC accumulates the sawtooth corrections
>>> over the update period and at update the accumulated
>>> sawtooth correction is added to the accumulator before
>>> the data is passed to the filter. The GPS sawtooth
>>> correction removes the sawtooth variation and provides
>>> stable data into the filter for 33ps resolution phase
>>> data per 30-second update.
>>>   An interesting point of the IDC design is a single
>>> interpolator is used so there are no tracking issues
>>> typically encountered with dual interpolators. Although
>>> a stable timebase is used the GPS sawtooth constantly
>>> sweeps the 1PPS over the clock edge in lock so good
>>> averaging of the samples occurs in the accumulated
>>> data. The sawtooth causes constant interpolator min
>>> to max variations as the 1PPS passes thru coincidence
>>> with the clock during each ramp, providing the offset
>>> and span data needed to automatically keep the system
>>> in constant calibration.
>>> Richard
>>>>> The lack of synchronisers when crossing clock domains is a design flaw
>>>>> that should be corrected.
>>>>> Bruce
>>>>> I think with these it becomes obvious where the problem lies and what
>>>>> the solution is.
>>>>> Attila Kinali
>>>> I realize there are many cases where clock domain considerations are important.
>>>> But
>>>> why does it matter in a device that is simply doing long-term 1PPS statistical
>>>> sampling?
>>>> Could one of you clock domain specialists actually spell out the GPSDO problem
>>>> for
>>>> the rest of us, nanosecond-by-nanosecond?
>>>> Thanks,
>>>> /tvb
>>>> _______________________________________________
>>>> time-nuts mailing list -- time-nuts at febo.com
>>>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>> and follow the instructions there.
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts at febo.com
>>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

More information about the time-nuts mailing list