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

Michael Tharp gxti at partiallystapled.com
Fri Sep 14 18:21:18 UTC 2012


Greetings nuts,

I've been working on a simple GPSDO as a starting point for further 
experimentation. I'm using a STM32 microcontroller running at 72MHz as 
the heart, with the input capture peripheral comparing the phase of the 
pulses-per-second and a 16 bit PWM DAC to drive the VFC. It's all 
working quite well from a functional standpoint although I'm sure the 
performance will be quite terrible by time-nuts standards, unfortunately 
I don't yet have the equipment to characterize precisely how terrible it 
is, but that will come later. So now that the basic functionality is 
there I've got a few questions about improving it.

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?

Secondly, a more general design question. Right now the feedback is done 
through a relatively fast PI controller. For example, here's a chart 
showing convergence at various integration coefficients:
http://partiallystapled.com/~gxti/circuits/2012/09/13-pid-ki.png
The Ki coefficient units are somewhat arbitrary due to the fixed-point 
math, but the X axis is seconds and the Y axis is number of counts at 
72MHz (13.89ns). Right now I'm using Ki=1 because it converges quickly 
enough and also don't oscillate, but these parameters are only 
particularly interesting on startup. Something much, much slower seems 
more suitable for continuous operation. But I'm thinking that the best 
solution might be to start out with fast convergence like this, then 
switch to slower parameters (for PI controller and smoothing) once some 
desired level of stability is reached. Any thoughts on this change of 
parameters, or PI tuning in general, or perhaps an entirely different 
control topology?

Finally, do people think a 16 bit DAC is adequate or should I consider 
building a 32-bit one? I looked at a few designs when putting this 
together but decided to keep it simple until things were up and running. 
There is some room for expansion if I want to replace the DAC or add a 
third oscillator input for holdover. In fact, this board seems to have 
more connectors than ICs:
http://partiallystapled.com/~gxti/trash/2012/09/08-serafine.jpg

Cheers,
-- m. tharp



More information about the time-nuts mailing list