[time-nuts] TIC resolution impact on GPSDO's performance

Wed Dec 27 09:14:28 UTC 2006

Didier,

looking at your plots, i see that your 'Tau'on the main page is set to
0.5 instead of 2 as it should be with your measurement arrangement.  I
understand that due to the unity '/s' you were fooled into thinking that
you need to compute a '1/2' sample rate from your measurement
arrangemant. This is due to my mistake to mix the both terms 'sample
rate' and 'tau' into one text field. I will have to check how to name
the field best without any ambiguity. As long as this bug is there you
should simply exchange the 0.5 by 2.

After this correction your Allan plot will start with 3.06 E-9 @ 2 s.
This is VERY close to the effect of the 2 ns resolution of your counter,
so probably 

> The Trimble app note you pointed to says the 1 PPS output is not 
> quantized, so I believe that means there should not be sawtooth error.

is correct. Note however, that with 1 s dead time between measurements
we need a dead time correction that Plotter is currently not being able
to compute. The results will not be worlds apart but there will be
subtle differences. 

In order to display two plots into one with the two having largely
different scales give the second plot a different vertical scale by

1) Open chart editor

2) In the left upper part choose the series that you want to give a new
vertical axis

3) In the right window open the 'General' parameter page

4) At 'vertical axis' choose 'right' and close the chart editor to see
the result

5) Note that you may introduce as many new vertical axes as you want in
the 'chart' 'axis' part of the chart editor (see the '+' sign?). Using
the method 1/2/3 you may assign series to new created axes. Note also
that the new axes may be shifted horizontical against their original
position to give every axis its own gorizontal position in the plot.

I wish I had the time to write a user manual!

73 de Ulrich, DF6JB

> -----Ursprüngliche Nachricht-----
> Von: time-nuts-bounces at febo.com 
> [mailto:time-nuts-bounces at febo.com] Im Auftrag von Didier Juges
> Gesendet: Dienstag, 26. Dezember 2006 16:40
> An: Discussion of precise time and frequency measurement
> Betreff: Re: [time-nuts] TIC resolution impact on GPSDO's performance
> 
> 
> Dr Bruce Griffiths wrote:
> > Didier Juges wrote:
> >   
> >> This discussion is fascinating, and as always it has prompted a 
> >> number
> >> of other questions for me.
> >>
> >> I understand the sawtooth correction is provided to allow 
> correction 
> >> of
> >> 1 PPS timing errors when the processor clock is 
> non-coherent with the 
> >> GPS signal (at least not intentionally), because the 
> processor clock is 
> >> running at a finite frequency and provides granularity to the PPS 
> >> adjustment capability.
> >>
> >> I wanted to know if this was available in my Trimble Thunderbolt 
> >> GPSDO.
> >>
> >> I have looked over the entire Thunderbolt manual and I 
> have not seen 
> >> a
> >> mention about sawtooth correction, so I am not sure if it 
> is available.
> >>
> >> Then I realized the Thunderbolt is different from most GPSDO that 
> >> have
> >> been discussed, in that it uses the 10 MHz from the OCXO 
> as the clock 
> >> for the GPS receiver, so in theory, the sawtooth 
> correction should not 
> >> be necessary on this type of receiver since the processor 
> clock and the 
> >> GPS signals are coherent (maybe I should not use that 
> term...) when the 
> >> receiver is tracking.
> >>
> >> Yet, the Thunderbolt spec for timing accuracy  on the 1 
> PPS output is
> >> +/- 20 nS at 1 sigma, just like an *ordinary* GPSDO with 
> stand alone
> >> receiver and what would be about a 25 MHz clock (please confirm).
> >>
> >> The Trimble software also displays values referred to as "Timing 
> >> Output"
> >> for the 1 PPS and the 10 MHz. The PPS value is currently 
> hovering around 
> >> -1.xx to -2.xx nS and the 10 MHz value is around +/- 0.0x 
> ppb. I am not 
> >> sure what that is based on. The manual simply refers to those as 
> >> "Estimate of UTC/GPS offset", but does not give any detail 
> of how they 
> >> are computed or what they mean.
> >>
> >> The Thunderbolt User's Manual says that the 1 PPS output is the 
> >> OCXO's
> >> 10 MHz divided down. Yet, the block diagram shows the 1 
> PPS coming from 
> >> the CPU and support circuit, not directly coming from the 
> 10 MHz. I 
> >> believe the 1 PPS is the 10 MHz divided down, except when 
> the receiver 
> >> is doing jam-sync (after power up or recovery, when the 
> GPS_PPS and 
> >> HW_PPS are far away from each other)
> >>
> >> Going back to what Poul-Henning just said, I believe that for the
> >> Thunderbolt, there actually may be three PPS signals:
> >>
> >> GPS_PPS: what the receiver thinks the PPS should be (a theoretical 
> >> signal)
> >> HW_PPS: the best approximation of the GPS_PPS that the 
> receiver can do
> >> OCXO_PPS: the 10 MHz divided down
> >>
> >> In jam-sync mode, the Thunderbolt forces the HW_PPS to 
> within 100nS 
> >> of
> >> GPS_PPS (the closest it can get using software delays and 
> programmable 
> >> dividers I guess, using a 10 MHz clock) without touching 
> the OCXO, so in 
> >> that mode, HW_PPS and OCXO_PPS are obviously not the same. 
> Once the two 
> >> are within 100 nS, the Thunderbolt switches to discipline 
> mode and fine 
> >> tunes the OCXO to get the HW_PPS as close to GPS_PPS as 
> possible (20nS 1 
> >> sigma by specification.) It would appear that the receiver 
> should be 
> >> able to adjust its OCXO as close to GPS_PPS as the DAC will allow, 
> >> without the artificial limit of the processor clock 
> period. So, there 
> >> should not be a need for sawtooth correction and there 
> should be no 
> >> hanging bridges either.
> >>
> >> Then, what are the "Timing Outputs"?
> >>
> >> Does this make any sense?
> >>
> >> Didier KO4BB
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> time-nuts mailing list
> >> time-nuts at febo.com 
> >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> >>
> >>   
> >>     
> > Didier
> >
> > Look at: http://trl.trimble.com/docushare/dsweb/Get/Document-8425/
> >
> > There is little evidence of sawtooth corrections in graph 
> in the above
> > document, however the data were taken when SA was switched on.
> > To confuse matters further the document actually talks about pulse 
> > position quantisation.
> >
> > http://trl.trimble.com/docushare/dsweb/Get/Document-8424/
> > Shows differences between 2 Thunderbolts, again there is little 
> > evidence
> > of quantisation but data may have been smoothed.
> >
> > Have you any reasonably stable crystal oscillator that can 
> be used to
> > log the time interval between the Thunderbolt PPS output 
> and the divided 
> > down oscillator output?
> > Plotting these results should quickly show evidence of any 
> sawtooth error.
> >
> > As you say there shouldn't be any sawtooth error if the receiver 
> > timing
> > is derived from the 10MHz clock which is in turned locked 
> to the PPS output.
> > However there are other sources of noise in a GPS timing 
> receiver which 
> > could, in an older receiver design like this, easily be as 
> much as 20ns rms.
> >
> > Bruce
> >
> > _______________________________________________
> > time-nuts mailing list
> > time-nuts at febo.com 
> > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> >
> >   
> Bruce,
> 
> The Trimble app note you pointed to says the 1 PPS output is not 
> quantized, so I believe that means there should not be sawtooth error.
> 
> Look at the bottom of this page http://www.ko4bb.com/Timing/FAQ-1.html
> 
> The last picture is the Thunderbolt PPS output against a free 
> running HP 
> 10811 divided by 256 with two 74F161.
> 
> The plot was obtained after removing steps, outliers (few, 
> mostly due to 
> my acquisition software that puts some garbage in the output) 
> and drift, 
> using Ulrich's Plotter program.
> 
> Since I was using the HP 5334, data is taken every 2 seconds.
> 
> How can I determine from this if sawtooth error is present?
> 
> Do I need to collect data differently?
> 
> Thanks
> 
> Didier
> 
> Note: my home brew GPIB data logging software records ambient 
> temperature at the same rate as the TI, which I believe would 
> be a very 
> useful information. Unfortunately, I have not found yet how 
> to display 
> both curves in a meaningful way using Plotter, so I have to strip the 
> temperature from the dataset before feeding it to Plotter. Also, 
> collecting data from two instruments causes my program to sometimes 
> insert garbage in the output file, which causes outliers and which I 
> need to fix before I put this software on my web page.
> 
> _______________________________________________
> time-nuts mailing list
> time-nuts at febo.com 
> https://www.febo.com/cgi-> bin/mailman/listinfo/time-nuts
> 