Hi 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.
Bob On Mar 25, 2013, at 10:05 PM, "Richard H McCorkle" <[email protected]> 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 <[email protected]> >> 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 -- [email protected] >>>>> To unsubscribe, go to >>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>>>> and follow the instructions there. >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> time-nuts mailing list -- [email protected] >>>> To unsubscribe, go to >>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>>> and follow the instructions there. >>>> >>>> >>> >>> _______________________________________________ >>> time-nuts mailing list -- [email protected] >>> To unsubscribe, go to >>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>> and follow the instructions there. >> >> _______________________________________________ >> time-nuts mailing list -- [email protected] >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> > > > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
