[time-nuts] Software Sawtooth correction prerequisites?
brooke at pacific.net
Fri May 11 19:36:01 EDT 2007
The size of the sawtooth error depends on which GPS receiver you are using.
The older 6 and 8 channel Motorola receivers were a little over 50 ns and the
newer 12 channel receivers are around 10 ns.
But it's my understanding that there's a bug in the sawtooth output on all the
6 channel units and all but the very newest firmware versions of the 8 channel
units so that you increase the errors by attempting to correct their sawtooh
errors, better to just average them.
The 12 channel receivers have working firmware and so applying the correction
works. If you use the HP 53131 or 53132 counter and the TAC32 software (join
TAPR to get it at the ham discount price) then the correction is done in that
software for you. It's nothing fancy just subtracting the offset error from
CNS who sells TAC32 also has a box that includes the hardware correction built
in. But the first versions of that box did not work as well as they should and
there's a firmware update that helps.
Whether you need the hardware approach would depend on your use. For data
logging like when comparing a source to GPS the post processing method costs
much less and the result is identical with the hardware approach. But for
disciplining a Rb of Cs standard the hardware approach would be better.
There's been quite a bit of discussion about the deficiencies the current home
brew GPSDO designs have when used with the 12 channel Motorola (whatever the
new name is) chips and there's some preliminary work on a phase detector up to
the stability needs of that receiver. Sawtooth correction will be a part of
Brooke Clarke, N6GCE
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
> time-nuts mailing list
> time-nuts at febo.com
More information about the time-nuts