[time-nuts] Software Sawtooth correction prerequisites?

Dr Bruce Griffiths bruce.griffiths at xtra.co.nz
Sat May 12 00:10:31 UTC 2007


Jim Miller wrote:
> My first post...newbie...be gentle...
>
> I spent the last several evenings reading the archives and saw mention of 
> sawtooth error correction in software. Since the corrections to be applied 
> are on the order of 1e-9 seconds it would seem that the phase detector 
> outputs to which these are applied must be similar in resolution.
>
> That would seem to require a pretty hefty phase detector and a pretty 
> substantial computing resource. Doesn't sound inexpensive. Is there a way 
> around this?
>
> OTOH, the Dallas Semi delay line pushes the "computation" out into the input 
> of the phase detector at the cost of a $17 chip (1k qty) which in small 
> quantities is likely $50 or so. This would seem to allow for a wider variety 
> of phase measurement techniques.
>
> Do I have this right?
>
> tnx
>
> jim miller
> ab3cv 
>   
Jim

Your conclusions are somewhat astray.



The Dallas delay lines aren't all that accurate, you need to calibrate 
them to acheive 1ns accuracy (read the specs) and then you have to worry 
about temperature variations.
To use them you need to decode the sawtooth correction message from the 
GPS timing receiver.
If you've decoded this message then you have all the information needed 
to make a software correction to the measured phase error.
Why add the cost of a programmable delay line when the additional cost 
of correction is a few lines of code?
They also don't remove the requirement for subnanosecond phase 
measurement resolution and accuracy.
Whilst an analog phase lock loop can have the necessary resolution they 
are somewhat impractical for the relatively long averaging times 
required when optimally disciplining a good OCXO.

The computational load isnt that severe as you only make one phase 
measurement per second.

One of the simplest ways of achieving subnanosecond phase measurement 
resolution is to feed a quadrature phase 10MHz sinewave into a pair of 
simultaneous sampling ADCs (MAXIM have suitable devices prices seem 
reasonable). The sinewaves are sampled at the leading edge of the GPS 
receiver PPS signal.
The ADC outputs can then be used to determine where in the cycle the PPS 
edge occurred. This in effect is a subnanosecond resolution phase 
detector with a range of 100nsec. The range can easily be extended by 
using a small CPLD which incorporates a couple of synchronisers (one 
clocked by the positive slope transition of the 10MHz signal and the 
other clocked by the negative slope xero crossing transition of the 
10MHz signal) The output of both synchronisers samples the value of a 
synchronous counter which is clocked by the positive slope zero crossing 
of the 10MHz sinewave. Software then sorts out which latched count is 
most reliable (the synchroniser whose clock edge is furthest from the 
PPS transition). This sounds complex but it isnt, especially if you 
select the right PIC (or other micro) with built in counters 
(PIC18F4550?) that can be sampled by an external transition (output of a 
synchroniser). The counter need only be an 8 bits counter.

Another technique is to start a ramp on the leading edge of the PPS 
signal from the GPS receiver and stop it at the corresponding output 
transition of a synchroniser (clocked at 10MHz) whose output samples an 
(8bit) counter (also clocked at 10MHz - your local OCXO standards 
frequency). The final value of the ramp is sampled by an ADC and 
combined with the sampled count to resolve the 1 count ambiguity at the 
synchroniser output. The ramp is then reset for the next PPS pulse. 
Calibration of the ramp generator is required but calibration cycles are 
easily interleaved between PPS pulses.
Although it may seem that a fast opamp is required for the ramp 
generator, this isnt so as you can wait for any opamp (and/or ADC input) 
to settle to before sampling the ramp output.
With careful design curvature correction isn't required (don't slavishly 
copy the Linear technology Application note, you can do better with 
less). The ramp generator needs a range of  300ns or greater with a  
10MHz synchroniser clock. A 10-12 bit ADC will provide subnanosecond 
resolution. The ADC need not be fast (10us per conversion is adequate), 
however a sigma delta ADC is unsuitable.

Synchronisers can easily be built from shift registers.



Bruce




More information about the Time-nuts_lists.febo.com mailing list