On Dienstag, 3. März 2020 14:14:37 CET Attila Kinali wrote:

Well, it probably means that, yes. But I've not characterized the power
consumption fully. I was in a bit of a hurry to get the prototype up and
working so I didn't really make a power or thermal budget before, I just put
everything together and hoped for the best. Since the numbers cannot lie,
either the heat transfer through the thermal vias is much better than
anticipated or the actual power consumption is much less than the estimate :)

I'll know that soon.

That's going to roast the LDO for sure.

Thanks for the pointers, I'll have a look at them.

Hm, the origin of that circuit was a connector board I designed for the LPRO
as a standalone frequency reference. I was a bit afraid to damage the Rb by
connecting an incompatible power supply. I wasn't too worried about surge
protection but actually overvoltage and reverse polarity. I just copied and
pasted that part into the GPSDO.

Thanks, I'll have a look.

In the meantime, I'm thinking of another modification to make: getting rid of
the HC390 ripple counter. I think I might be able to use the STM32 as a
frequency divider. I just have to figure out how to program the timers. What
might work is the following:

• Feed the 10MHz clock into the external trigger input for the timer,
  configure the timer to count the trigger pulses instead of the internal clock
  source.
• Set the timer to auto-reload the desired divisor, e.g. 20 (-1),
• Set the capture/compare register to the same value, set the output mode to
  "toggle"

The result should be a 250kHz signal at the timers output pin. I have no idea
though if the jitter is going to be better than with the HC390. If anything in
the above scheme is linked to the internal AHB clock, the expected jitter will
be around 20ns. That would definitely not improve the situation ;)

BR,
Matthias

Attila,

In your post from October you say,

What, I think, you haven't had a look at is the resolution of your DAC.

I don't understand why you say the DAC should have a resolution of 24-30
bits. I can see that the loop time constant affects the precision needed in
the filter calculations, but what does the time constant have to do with
the needed DAC resolution? We don't have to wait for the whole time
constant before changing the DAC, we can update the filter calculations and
look at its output every second and adjust the DAC whenever the PI filtered
phase error is one DAC step or more.

If the OCXO has a tuning range of 1 ppm and we want frequency control
of 1e-12, wouldn't that require a DAC with 1e6 steps or 20 bits,
assuming the DAC covers the full tuning range of the oscillator?

Thanks for any explanation you can provide.

--Jim Harman

Hi

Ideally in a digital control loop you want at least 2 “extra” bits past the
minimum required to hit your target accuracy. Things like noise, LSB
non-linearity, calculation roundoff, all drive that need. Indeed for a
low noise loop, you would push the margin out even further.

If your OCXO’s EFC is not perfectly linear (they never are) then it’s
“slope ratio” gets into the act. If the highest slope is 2X the lowest
(which is not uncommon), that will add another bit to the total.

Bob

On Tue, 3 Mar 2020 12:14:37 -0500
Jim Harman j99harman@gmail.com wrote:

You do wait the whole time before updating the DAC value.. kind of ish.
The control loop's time constant is exactly that: The time it takes
the control loop for a change in the input to affect the output (very
loosely speaking). Yes, the sample rate at which the loop runs is
much higher, but that doesn't change the fact that the loop is slow
to react. And you want it to be slow to react, as otherwise the high
noise of GPS degrades the performance of your OCXO.

Yes. There is a calculation mistake in there. I corrected it in
the next mail:
http://lists.febo.com/pipermail/time-nuts_lists.febo.com/2019-October/097963.html

		Attila Kinali

--
<JaberWorky> The bad part of Zurich is where the degenerates
throw DARK chocolate at you.

On Tue, 03 Mar 2020 14:42:49 +0100
Matthias Welwarsky time-nuts@welwarsky.de wrote:

Better idea: feed the 10MHz input directly into the clock input
RCC_OSC_IN and let the STM32 derive its internal clock from that.
Doing that, the clock of your timer unit will be phase locked to
the 10MHz signal. Then you can use the timer for both capturing
the incomming PPS and for generating the 250kHz. The capturing
will solve the issue with aliasing. The timer output should have
a jitter in the low ps range. There is a bit more going on than
you would want in the STM32 for a low noise signal, but most
likely not so much as to degrade the output enough to matter.
If you are worried about that, you can still add a 7474, with
D connected to the STM32 timer output and the CLK to the 10MHz
to clean the jitter. But as I said, that's probably not necessary
in this case.

If you want to create a stabilized output PPS from the STM32,
you will need to do some software trickery to align the PPS,
as you cannot hope to shift the phase of the Rb in a reasonable
time to match up.

		Attila Kinali

--
<JaberWorky> The bad part of Zurich is where the degenerates
throw DARK chocolate at you.

On Dienstag, 3. März 2020 18:41:43 CET Attila Kinali wrote:

I have an STM32F042 without FPU and I'm doing a lot of double precision math.
I'm not sure I can spare the 4/5th of the cycles.

That's not very high on my laundry list.

Hi,
How do you optimally tune the control loop time constant ?
(Mine gets quite unstable when the update rate is slow - and the amplitude of the change step low - enough not to degrade the OCXO performance )
Is there a method described somewhere (like the Ziegler–Nichols method for PID) ?
Thx,
Gilles.

Hi

As far as I know there is no “closed form” solution to tuning a GPSDO.
It is very much a measure / tweak / measure / tweak sort of thing.

That said, there are a lot of basic design constraints that are pretty
well known. Your DAC needs to have a pretty small LSB. Updates
are normally done once a second ( = each time the PPS is measured).

Bob

Hi,
I am sure it is theoretically possible to find an optimal control loop
design if you have accurate models of the OCXO and for the behaviour of the
1PPS pulse.
TvB has written a GPSDO simulator which allows to code different PLL and
control algorithms. I have implemented something similar in Matlab.
Basically, if you know the VCO tuning characteristics and the phase
detector constant, then you can use procedures as described in the PLL
books that are out there (I have ond from R. Best).

But I agree that it is perhaps a very difficult problem -  you cannot
simply try out different algorithms because each time it takes days to wait
until everything has settled and stabilised, then you need to record that
data etc.

Maybe the easiest way is indeed using the GPSDO simulator.
If there is some interest, I could perhaps post my Matlab code. It plots
nicely the calculated EFC voltage and simumates the OCXOs frequency
variation as the EFC is varied.

Best
Tobias
HB9FSX

On Sat., 7 Mar. 2020, 12:36 Gilles Clement, clemgill@gmail.com wrote:

On Samstag, 7. März 2020 15:35:22 CET Tobias Pluess wrote:

Funny, that was also my approach. I have no idea about control theory or PLL
design so I'm not able to apply any prior knowledge here, but converting
"gpsim1.c" to Matlab (or Octave, in my case) was pretty much straight forward
and having a math toolkit under the bonnet is much more versatile than a C
compiler and runtime.

The GPSDO simulator is fine for sanity-checking certain design parameters,
like, if the width of your DAC is sufficient for the LO you're targeting. The
question of "how many bits" you need can be visualized nicely with the
simulator. However, you'll need model data for the GPS and the LO and you have
to be aware that whatever optimal filter and control loop design and
parameters you work out, will have to work outside the limited space your
model data presents.

BR,
Matthias