GPSDO control loops and correcting quantization error
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
On Fri, Sep 14, 2012 at 11:21 AM, Michael Tharp
gxti@partiallystapled.com wrote:
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.
Having a 32-bit DAC would give you enough range so that you could drop
in any OCXO you might have. But if you can have trimmer resisters to
selected for your specif OCXO then 16-bits should be enough. If it
were me, I'd want the DAC steps to be smaller than what the phase
detector can measure. Said another way a 32-bit DAC might
eliminate the need for scale and offset trimmer resistors.
Chris Albertson
Redondo Beach, California
Also you need a super ultra fantastic voltage reference for a 32bit DAC.
Anyway, yes, in my GPSDO the controller has 3 levels: at startup is fast,
then slow and then very slow. The levels trigger when the precision
estimate is 10E-9 and 10E-11. If you have a resolution of 10nS then take 10
averages and your resolution will be 1nS and so on. When I switch level,
the number of averages is increased too but this leads to a slower DAC
update rate. This is the problem: now I'm trying to figure out if the
corrective action can be "predicted" (Kalman filtering) and applied at the
same speed.
On Fri, Sep 14, 2012 at 8:52 PM, Chris Albertson
albertson.chris@gmail.comwrote:
On Fri, Sep 14, 2012 at 11:21 AM, Michael Tharp
gxti@partiallystapled.com wrote:
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.
Having a 32-bit DAC would give you enough range so that you could drop
in any OCXO you might have. But if you can have trimmer resisters to
selected for your specif OCXO then 16-bits should be enough. If it
were me, I'd want the DAC steps to be smaller than what the phase
detector can measure. Said another way a 32-bit DAC might
eliminate the need for scale and offset trimmer resistors.
Chris Albertson
Redondo Beach, California
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Azelio Boriani wrote:
Also you need a super ultra fantastic voltage reference for a 32bit DAC.
Not really, the reference only needs to have low noise and good short
term stability.
Long term drift in the reference voltage will be corrected by the
feedback loop.
Anyway, yes, in my GPSDO the controller has 3 levels: at startup is fast,
then slow and then very slow. The levels trigger when the precision
estimate is 10E-9 and 10E-11. If you have a resolution of 10nS then take 10
averages and your resolution will be 1nS and so on.
However the noise associated with the timing resolution doesn't average
down so quickly.
If such noise is random than at best it is reduced by SQRT(10) by
averaging 10 measurements.
There is no real substitute for lower noise, higher resolution measurements.
When I switch level,
the number of averages is increased too but this leads to a slower DAC
update rate. This is the problem: now I'm trying to figure out if the
corrective action can be "predicted" (Kalman filtering) and applied at the
same speed.
Bruce
On Fri, Sep 14, 2012 at 8:52 PM, Chris Albertson
albertson.chris@gmail.comwrote:
On Fri, Sep 14, 2012 at 11:21 AM, Michael Tharp
gxti@partiallystapled.com wrote:
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.
Having a 32-bit DAC would give you enough range so that you could drop
in any OCXO you might have. But if you can have trimmer resisters to
selected for your specif OCXO then 16-bits should be enough. If it
were me, I'd want the DAC steps to be smaller than what the phase
detector can measure. Said another way a 32-bit DAC might
eliminate the need for scale and offset trimmer resistors.
Chris Albertson
Redondo Beach, California
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Will this be able to discipline a rubidium oscillator as well as a OCXO?
Maybe you could switch in a divider network to close in the trim range as
the oscillator precision improves.
Hope someone makes a PC board available. Count me in for some.
----- Original Message -----
From: "Azelio Boriani" azelio.boriani@screen.it
To: "Discussion of precise time and frequency measurement"
time-nuts@febo.com
Sent: Friday, September 14, 2012 3:33 PM
Subject: Re: [time-nuts] GPSDO control loops and correcting
quantizationerror
Also you need a super ultra fantastic voltage reference for a 32bit DAC.
Anyway, yes, in my GPSDO the controller has 3 levels: at startup is fast,
then slow and then very slow. The levels trigger when the precision
estimate is 10E-9 and 10E-11. If you have a resolution of 10nS then take 10
averages and your resolution will be 1nS and so on. When I switch level,
the number of averages is increased too but this leads to a slower DAC
update rate. This is the problem: now I'm trying to figure out if the
corrective action can be "predicted" (Kalman filtering) and applied at the
same speed.
On Fri, Sep 14, 2012 at 8:52 PM, Chris Albertson
albertson.chris@gmail.comwrote:
On Fri, Sep 14, 2012 at 11:21 AM, Michael Tharp
gxti@partiallystapled.com wrote:
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.
Having a 32-bit DAC would give you enough range so that you could drop
in any OCXO you might have. But if you can have trimmer resisters to
selected for your specif OCXO then 16-bits should be enough. If it
were me, I'd want the DAC steps to be smaller than what the phase
detector can measure. Said another way a 32-bit DAC might
eliminate the need for scale and offset trimmer resistors.
Chris Albertson
Redondo Beach, California
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Yes, you are right: but actually I have a 2.5nS simple time interval
counter in the FPGA and the only way to go beyond is the average. The
sophisticated way would be to implement a tapped delay line or vernier
delay line time-to-digital converter in a bigger FPGA than the XC3S50. And,
yes, I have recently started my first GPS disciplined Rb with the same
hardware. I have eliminated the fast and slow steps from the processing,
using only the slowest one.
On Fri, Sep 14, 2012 at 9:50 PM, Bruce Griffiths <bruce.griffiths@xtra.co.nz
wrote:
Azelio Boriani wrote:
Also you need a super ultra fantastic voltage reference for a 32bit DAC.
Not really, the reference only needs to have low noise and good short term
stability.
Long term drift in the reference voltage will be corrected by the feedback
loop.
Anyway, yes, in my GPSDO the controller has 3 levels: at startup is fast,
then slow and then very slow. The levels trigger when the precision
estimate is 10E-9 and 10E-11. If you have a resolution of 10nS then take
10
averages and your resolution will be 1nS and so on.
However the noise associated with the timing resolution doesn't average
down so quickly.
If such noise is random than at best it is reduced by SQRT(10) by
averaging 10 measurements.
There is no real substitute for lower noise, higher resolution
measurements.
When I switch level,
the number of averages is increased too but this leads to a slower DAC
update rate. This is the problem: now I'm trying to figure out if the
corrective action can be "predicted" (Kalman filtering) and applied at the
same speed.
Bruce
On Fri, Sep 14, 2012 at 8:52 PM, Chris Albertson
On Fri, Sep 14, 2012 at 11:21 AM, Michael Tharp
gxti@partiallystapled.com wrote:
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.
Having a 32-bit DAC would give you enough range so that you could drop
in any OCXO you might have. But if you can have trimmer resisters to
selected for your specif OCXO then 16-bits should be enough. If it
were me, I'd want the DAC steps to be smaller than what the phase
detector can measure. Said another way a 32-bit DAC might
eliminate the need for scale and offset trimmer resistors.
Chris Albertson
Redondo Beach, California
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Hi
In the case of some systems, "long term" may only cut in past a few hours.
In the case of a Rb, it may be a few days.
If the reference "sees" room temperature, it's going to need very good
temperature stability for full 32 bit resolution. Something in the 0.2 ppb
/ C range...
Bob
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Bruce Griffiths
Sent: Friday, September 14, 2012 3:50 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] GPSDO control loops and correctingquantization
error
Azelio Boriani wrote:
Also you need a super ultra fantastic voltage reference for a 32bit DAC.
Not really, the reference only needs to have low noise and good short
term stability.
Long term drift in the reference voltage will be corrected by the
feedback loop.
Anyway, yes, in my GPSDO the controller has 3 levels: at startup is fast,
then slow and then very slow. The levels trigger when the precision
estimate is 10E-9 and 10E-11. If you have a resolution of 10nS then take
10
averages and your resolution will be 1nS and so on.
However the noise associated with the timing resolution doesn't average
down so quickly.
If such noise is random than at best it is reduced by SQRT(10) by
averaging 10 measurements.
There is no real substitute for lower noise, higher resolution measurements.
When I switch level,
the number of averages is increased too but this leads to a slower DAC
update rate. This is the problem: now I'm trying to figure out if the
corrective action can be "predicted" (Kalman filtering) and applied at the
same speed.
Bruce
On Fri, Sep 14, 2012 at 8:52 PM, Chris Albertson
albertson.chris@gmail.comwrote:
On Fri, Sep 14, 2012 at 11:21 AM, Michael Tharp
gxti@partiallystapled.com wrote:
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.
Having a 32-bit DAC would give you enough range so that you could drop
in any OCXO you might have. But if you can have trimmer resisters to
selected for your specif OCXO then 16-bits should be enough. If it
were me, I'd want the DAC steps to be smaller than what the phase
detector can measure. Said another way a 32-bit DAC might
eliminate the need for scale and offset trimmer resistors.
Chris Albertson
Redondo Beach, California
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Michael: Actually implementing a 16 bit DAC to its 1-bit minimum
resolution will be headache enough. You will gain a real education in
good grounding practice, shielding, power supply stability and noise,
and other Murphy intrusion. A 32 bit DAC IMHO, is impossible, and that's
the name of that tune.
Don
Chris Albertson
On Fri, Sep 14, 2012 at 11:21 AM, Michael Tharp
gxti@partiallystapled.com wrote:
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.
Having a 32-bit DAC would give you enough range so that you could drop
in any OCXO you might have. But if you can have trimmer resisters to
selected for your specif OCXO then 16-bits should be enough. If it
were me, I'd want the DAC steps to be smaller than what the phase
detector can measure. Said another way a 32-bit DAC might
eliminate the need for scale and offset trimmer resistors.
Chris Albertson
Redondo Beach, California
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
--
"Neither the voice of authority nor the weight of reason and argument
are as significant as experiment, for thence comes quiet to the mind."
De Erroribus Medicorum, R. Bacon, 13th century.
"If you don't know what it is, don't poke it."
Ghost in the Shell
Dr. Don Latham AJ7LL
Six Mile Systems LLP
17850 Six Mile Road
POB 134
Huson, MT, 59846
VOX 406-626-4304
www.lightningforensics.com
www.sixmilesystems.com
---------- Forwarded message ----------
From: Don Latham djl@montana.com
Date: Fri, Sep 14, 2012 at 2:01 PM
Subject: Re: [time-nuts] GPSDO control loops and correcting quantization error
To: Discussion of precise time and frequency measurement time-nuts@febo.com
Michael: Actually implementing a 16 bit DAC to its 1-bit minimum
resolution will be headache enough. You will gain a real education in
good grounding practice, shielding, power supply stability and noise,
and other Murphy intrusion. A 32 bit DAC IMHO, is impossible, and that's
the name of that tune.
I think the step size would be close to the same with the 32 bit DAC
but the reason you use it is so you can control just about any OCXO,
Rb or other things you drop in. In other words I'd use the extra bits
to extend the voltage range. But while in use, I doubt you'd ever
change the highest 16 or 18 bits
Also if you are building a general purpose controller for OCXOs and
Rb, remember that some Rb oscillators use RS-232 control to set the
frequqecy. It might be good to build in an RS232 port. The firmware
in the uP can always be changed but hard to add the DB9 connector
later.
One otherthing I was doing when I was working on a design like this
was to discipline both an XO and an Rb from the same GPS. Almost like
building two controllers but you save some because you can use one uP
and one GPS interface. Now that you have a disciplined Rb it can be
used for hold over in case the GPS goes away. I thought it would be
unlikely for GPS to actually fail but allowing for hold over would
make the entire unit portable.
Chris Albertson
Redondo Beach, California
On 09/14/2012 05:31 PM, Chris Albertson wrote:
Michael: Actually implementing a 16 bit DAC to its 1-bit minimum
resolution will be headache enough. You will gain a real education in
good grounding practice, shielding, power supply stability and noise,
and other Murphy intrusion. A 32 bit DAC IMHO, is impossible, and that's
the name of that tune.
Probably true, luckily as others have mentioned the long-term stability
of the DAC and its voltage source are less important.
I think the step size would be close to the same with the 32 bit DAC
but the reason you use it is so you can control just about any OCXO,
Rb or other things you drop in. In other words I'd use the extra bits
to extend the voltage range. But while in use, I doubt you'd ever
change the highest 16 or 18 bits
Also if you are building a general purpose controller for OCXOs and
Rb, remember that some Rb oscillators use RS-232 control to set the
frequqecy. It might be good to build in an RS232 port. The firmware
in the uP can always be changed but hard to add the DB9 connector
later.
One otherthing I was doing when I was working on a design like this
was to discipline both an XO and an Rb from the same GPS. Almost like
building two controllers but you save some because you can use one uP
and one GPS interface. Now that you have a disciplined Rb it can be
used for hold over in case the GPS goes away. I thought it would be
unlikely for GPS to actually fail but allowing for hold over would
make the entire unit portable.
I had this idea as well, although not for disciplining the Rb (which
unfortunately mine cannot, it's a less popular Efratom model clearly
pulled from telecom application and has no external control that I can
see) but just as a backup timing source for holdover. I've mentioned it
here before, but the gist would be to estimate its frequency while GPS
was working, then if GPS fails use the Rb instead either by dividing it
by the last known frequency or by adding the error to the measurement
loop. That said, I would like the holdover performance with just the
OCXO to be as good as possible in its own right.
I'm planning to make a future version of this project available but this
first revision is mainly an experimentation platform and wouldn't be of
much use to someone who doesn't have the same equipment as me. Stay tuned...
-- m. tharp