[time-nuts] Software Sawtooth correction prerequisites?
Dr Bruce Griffiths
bruce.griffiths at xtra.co.nz
Fri May 11 20:10:31 EDT 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?
> jim miller
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.
More information about the time-nuts