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
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
