[time-nuts] Software Sawtooth correction prerequisites?

Brooke Clarke brooke at pacific.net
Fri May 11 19:36:01 EDT 2007

Hi Jim:

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 
the measurement.

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 
that design.

Have Fun,

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?
> tnx
> jim miller
> ab3cv 
> _______________________________________________
> time-nuts mailing list
> time-nuts at febo.com
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts

More information about the time-nuts mailing list