[time-nuts] Brooks Shera

Bob Camp lists at rtty.us
Tue Mar 26 07:01:05 EDT 2013


One very important thing to consider when looking at this design - it was done in the era of selective availability. That provided a lot dither all by it's self.


On Mar 25, 2013, at 10:05 PM, "Richard H McCorkle" <mccorkle at ptialaska.net> wrote:

> Bob,
> 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.
> Richard
>> 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.
> _______________________________________________
> 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