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

Didier Juges didier at cox.net
Tue Dec 26 17:14:45 EST 2006


Dr Bruce Griffiths wrote:
> Didier Juges wrote:
>   
>> 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
>>
>>   
>>     
> Didier
>
> The last paragraph should have started with As you say, in the absence 
> of noise, ......
>
> In effect the 10MHz oscillator will track the smoothed PPS frequency.
> However pulse by pulse the computed PPS signal timing will vary with 
> respect to the position of the smoothed PPS signal, consequently when 
> quantised there will be some variation of the timing of the PPS edge 
> with respect to the edge of the smoothed PPS pulse position. Thus some 
> evidence of quantisation will be seen in the PPS pulse output. The rate 
> at which such steps occur depends on the noise in the computed PPS 
> transition time. If the noise is significantly less than 100ns such 
> steps will be infrequent.
> Even if the rms noise were around 100ns the resultant PPS timing error 
> plot will not exhibit the short term correlations evident in the Oncore 
> timing receiver sawtooth correction plot. The corresponding correction 
> plot should be more random.
>
> The other complication is that the Thunderbolt noise spec was 
> derived/measured when SA was turned on. It may be significantly smaller 
> now that SA has been turned off.
>
> Your plots show little or no evidence of any 50ns quantisation steps or 
> even 20ns steps.
> This means that the internal receiver timing noise is significantly 
> smaller than the quantisation step.
> The 20ns rms probably refers to the the receiver's internal 
> (prequantisation) timing noise in the presence of SA.
>
> Bruce
>   
Thank you Bruce, that's very encouraging.

Regarding the jam-sync mode, I am not sure how much the GPS_PPS and 
HW_PPS need to be separated by before the jam-sync mode in engaged. I 
believe it takes more than one pulse because typically this mode is only 
used when recovering from holdover or after startup, so it should not be 
engaged as long as the receiver has a valid fix, even when satellites 
come in and out. So I would not expect to see phase jumps unless the GPS 
signal went completely away. I need to write another logging program to 
log the serial data from the Thunderbolt and see how often, if at all, 
it goes into holdover with my currently marginal antenna situation. I 
have not seen it happen since I moved the antenna in its current 
location though.

When reading the data sheet for the Thunderbolt, and reading all the 
pitfalls associated with non-integrated GPSDO designs using stand alone 
GPS receivers, such as sawtooth correction and quantization noise, it 
seems like the integrated approach used in the Thunderbolt is the best 
way to go. Not only it is cheaper and simpler, and therefore should be 
more reliable, but it avoids an entire class of problems and should 
perform better, everything else being equal (receiver sensitivity and 
internal noise, OCXO quality). In this case, simplicity goes with better 
performance, which is not always the case.

Yet, I am surprised that so many of the OEM timing receiver solutions 
use the *conventional* approach. For instance, the Lucent receiver John 
just bought seems to have a discrete, independent GPS receiver (the 
darker board on top), and many companies still build stand alone GPS 
receivers specifically for timing application without embedding the 
GPSDO logic and an OCXO. That does not seem to make much sense to me.

In the mean time, I keep forgetting the Thunderbolt specs were written 
when SA was turned on, and therefore better performance should be 
expected today from the same hardware.

Tom said he was planning a comparison test session of various GPSDO 
designs in January or February I believe. If he does not have one, I'll 
be glad to send him my Thunderbolt for comparison. Tom, if you are 
interested, please speak up.


Thanks again.

Didier



More information about the time-nuts mailing list