[time-nuts] GPSDO control loops and correcting quantization error

[SAIDJACK at aol.com]

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?