[time-nuts] GPS orthodontics: sawteeth & hanging bridges - theeffect of time averaging

Brooke Clarke brooke at pacific.net
Fri Dec 22 15:02:21 EST 2006


Hi Ulrich:

Your M12+T plot ends at a little over a day (100k seconds) and the 
stability is on the order of 4E-13.
But Cesium and other oscillators can be better than this.  So how do you 
check them, use longer averaging time?

Have Fun,

Brooke Clarke

w/Java http://www.PRC68.com
w/o Java http://www.pacificsites.com/~brooke/PRC68COM.shtml
http://www.precisionclock.com



Ulrich Bangert wrote:

>Brooks,
>
>  
>
>>Excel computed that the unaveraged correction data had a 
>>standard deviation 
>>of 8.4 nsec, which is consistent with the actual measured 9.5 
>>nsec rms 
>>jitter reported by Rich Hambly (Dec 06, PTTI paper by Clark 
>>and Hambly, p. 
>>15).
>>    
>>
>
>Even if this scientifical improvement has not found its way into Excel:
>A certain Mr. Allan has shown that the standard deviaton is NOT the
>appropiate measure for noise processes in oscillators. Therefore he had
>to find a new statitistics on its own. If you don't own a software to
>calculate ADEV and other relevant statistical measures with you may
>download one for free from my homepage:
>
>http://www.ulrich-bangert.de/plotter.zip
>
>  
>
>>But the question remains "what time averaging is needed to reduce the 
>>sawtooth/bridge jitter from a typical +/-15 nsec to something 
>>negligible, 
>>perhaps +/-1 nsec?
>>    
>>
>
>Have a look to
>
>http://www.ulrich-bangert.de/html/photo_gallery_44.html
>
>If you can read it it will immediatly give you the answer to your
>questions: in order to get to a certain precision draw a horizontal line
>at this precisision on the vertical axis and at the two crossing points
>read the necessary time for SAW corrected and uncorrected data on the
>horizontal axis.
>
>Nevertheless, pardon to contradict you: One simply has NO choice to
>average this long or to average that long. You have to set the
>regulation loop time constant up to exactly where the OCXO's
>tau-sigma-diagram meets the receiver's tau-sigma. Every loop time
>constant different from that is a faulty design and nothing else. The
>regulation loop dynamics may be improved a bit by pre-averaging the
>phase data before they are fed into the loop but not by computing the
>arithmetic mean over a time but by a gliding exponential average as is
>explained in detail in the PRS-10's handbook. Due to stability reasons
>even this time constant of this pre-filter is more or less fixed to abt.
>1/3 the main loop's time constant. 
>
>Regards
>Ulrich Bangert,DF6JB  
>
>
>  
>
>>-----Ursprüngliche Nachricht-----
>>Von: time-nuts-bounces at febo.com 
>>[mailto:time-nuts-bounces at febo.com] Im Auftrag von Brooks Shera
>>Gesendet: Donnerstag, 21. Dezember 2006 18:50
>>An: Discussion of precise time and frequency measurement
>>Betreff: [time-nuts] GPS orthodontics: sawteeth & hanging 
>>bridges - theeffect of time averaging
>>
>>
>>Recently there has been some mention of the influence of 1pps 
>>sawtooth and 
>>hanging bridges jitter on the performance of a GPSDO.
>>
>>It would seem to me that the jitter must average to zero in 
>>the long run, 
>>for if it did not the 1pps signal would drift away from its 
>>relation to UTC.
>>
>>But the question remains "what time averaging is needed to reduce the 
>>sawtooth/bridge jitter from a typical +/-15 nsec to something 
>>negligible, 
>>perhaps +/-1 nsec?"
>>
>>To explore this I used TAC32 to record the 1 pps sawtooth 
>>correction message 
>>from a Motorola M12+ receiver for about 1 hour, during which 
>>time many 
>>bridges occurred (1).  Excel's statistical toolbox was then 
>>used to examine 
>>the data.
>>
>>Excel computed that the unaveraged correction data had a 
>>standard deviation 
>>of 8.4 nsec, which is consistent with the actual measured 9.5 
>>nsec rms 
>>jitter reported by Rich Hambly (Dec 06, PTTI paper by Clark 
>>and Hambly, p. 
>>15).
>>
>>Averaging the sawtooth/bridge correction data for several 
>>averaging times 
>>produced the following results (2):
>>
>>Avg Time    Standard Deviation     Residual Jitter
>>none           8.4 nsec                     +/- 15 nsec
>>30 sec        1.53                            +/- 4.3
>>100 sec      0.79                            +/- 2.2
>>300 sec      0.33                            +/- 0.7
>>
>>It is evident that jitter is greatly reduced with a bit of 
>>time-averaging. 
>>In addition, the hanging bridges quickly disappeared into the 
>>residual 
>>jitter of the smoothed data.
>>
>>It appears to me that a typical GPSDO, which has an 
>>integration time in the 
>>range of 100's to many 1000's of sec is not likely to be 
>>impaired by the 
>>sawtooth/bridge noise of a GPS rcvr.  A GPS-based clock is a 
>>different story 
>>since a precise 1pps timing signal without time averaging would be 
>>desirable.
>>
>>In summary, it appears that 1pps sawtooth/bridge noise can be 
>>ignored for a 
>>GPSDO.  In some designs it may even be helpful by introducing further 
>>deterministic randomness to the phase measurement process.
>>
>>Regards,  Brooks
>>
>>(1) the M12+ correction-message resolution is 1 nsec and this 
>>seems adequate 
>>for a jitter statistics investigation.  But as a check, I 
>>compared the 
>>correction message data with the actual 1 pps jitter measured 
>>with a 5370B 
>>TIC, a PRS10 and a M12+ .  This approach has higher 
>>resolution but does not 
>>change the conclusions.
>>
>>(2)  I choose 30 sec as the shortest averaging time because 
>>30 sec is the 
>>summation time of the phase-measuring circuit of my GPSDO 
>>design and hence 
>>the shortest integration time available.  Of course, the PLL filter 
>>configuration switches can extend the integration to many 
>>hours if desired.
>>
>>
>>
>>
>>
>>
>>
>>_______________________________________________
>>time-nuts mailing list
>>time-nuts at febo.com 
>>https://www.febo.com/cgi-> bin/mailman/listinfo/time-nuts
>>
>>    
>>
>
>
>_______________________________________________
>time-nuts mailing list
>time-nuts at febo.com
>https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>
>  
>


More information about the time-nuts mailing list