[time-nuts] GPSDO control loops and correcting quantization error
SAIDJACK at aol.com
SAIDJACK at aol.com
Fri Sep 14 18:36:29 UTC 2012
Hi M.
welcome to the world of GPSDO optimization, one thing you will find is
that there never is a time when there is no chance to improve something :)
On the 1PPS sawtooth correction, the usual convention is for the following
1PPS.
The easiest thing to do rather than trying to guess the GPS unit's behavior
is to try it out on both pulses, and also try adding and subtracting the
number from your raw phase measurement, then you get four streams of values,
and it will be instantly obvious which one is the one that reduces the
noise most. The other three will increase the noise over your raw,
uncorrected measurements.
On the DAC resolution, it depends on the OCXO control range, and the ADEV
performance you want to achieve. For example if your OCXO has +/-2Hz control
range, then a 16 bit DAC will only give you an LSB resolution of about 61
microhertz, or 6.1E-012 (4Hz divided by 2^16). This may or may not be
acceptable to you.
If your OCXO has a more typical +/-20Hz control range, then this would go
up to 6.1E-011 per LSB, which will definitely affect your ADEV. Usually,
GPSDO's use at least 20 bit control range due to this quantization effect.
But in the end it may also be limited by your time-interval-counter
resolution, because every tick in your counter will equal to so many steps in
your DAC (depending on what gains you use for your loop prediction).
Also, make sure to put filtering for errand pulses into your code, every
GPS WILL generate an errand pulse from time to time in my experience, and
these can be off by 10's of microseconds.. if you don't filter these
properly, they will lead to jumps in your frequency.
Hope that helps,
Said
In a message dated 9/14/2012 11:21:57 Pacific Daylight Time,
gxti at partiallystapled.com writes:
First off a technical question. I'm using a Trimble Resolution SMT as
the pulse-per-second source. It sends a supplemental timing packet that
contains an estimate of the quantization error in its pulse output. But
the manual isn't clear on whether that applies to the next pulse or to
the previous one. I've seen people correct the delay by using a
programmable delay line which seems like it would only be possible if
the measurement was for the next pulse. But on the other hand there is a
"pulse was not generated" alarm that definitely applies to the previous
(non)-pulse which suggests that maybe other fields refer exclusively to
the previous pulse. I can handle either way since the pulses are
timestamped asynchronously and can be post-processed at any time but
from some preliminary data collection it's not clear which way it's
meant to go. Does anyone know for sure whether the quantization error is
for the next or preceding pulse?
More information about the Time-nuts_lists.febo.com
mailing list