[time-nuts] Brooks Shera

Bob Camp lists at rtty.us
Mon Mar 25 20:02:43 EDT 2013


The gotcha with using the XO as a "spreading source" is the hanging bridge issue. As long as temperature (or what ever) is constantly changing the XO all the averaging stuff works out. A GPS with a sawtooth output (and no correction) is doing the same thing. The problem comes in when the XO settles down and runs at one frequency. That may sound impossible, but it's not. Injection locking is one way to make it happen. There are a couple of others. When the averaging stops, you get a dead spot. You don't get a glitch, you just loose resolution. The practical effect is a step in the input rather than a smooth transition. Not easy to spot….


On Mar 25, 2013, at 6:41 PM, Richard H McCorkle <mccorkle at ptialaska.net> 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 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.

More information about the time-nuts mailing list