Hoi Tobias,

On Mon, 7 Oct 2019 21:06:37 +0000
Tobias Pluess tobias.pluess@xwmail.ch wrote:

I think, you are optimizing for the wrong thing.
While temperature coefficient is important, it is not as important as you
think. Unless you want to operate your GPSDO outside or where you expect
large temperature swings. Instead, what you do is give your whole GPSDO
enough thermal mass, such that you don't see a significant temperature
change at time scales shorter than the loop time constant. Worst case,
I'd rather heat up the PCB using some simple resistive heater (ie have
a thin meander line on one layer, coupled with an NTC thermistor and some
cheap, opamp based PI control loop)

What, I think, you haven't had a look at is the resolution of your DAC.
You get, including your resistive divider a 17bit resolution. But this
is not enough. You want to be able to control the OCXO such, that at
the loop time constant, you have less than 1LSB offset in frequency.
Usualy people aim for something in the order of 1000s as loop time constant,
often even longer than that. Assuming your GPS receiver gives you approximately
1ns RMS jitter (probably worse than that, but it makes it easy to calculate)
that would mean frequency control of the level of 1e-12 is required. Assuming
your OCXO has a tuning range of 1ppm (I've seen 0.1 to 20ppm for OCXOs)
that would mean you have to controll the EFC voltage better than parts in 1e-9
or 30 bits. Yes, this is kind of unreallistic, but that's what the design
should aim for. If you acheive something around 24bits, you will be probably
close enough. (Note: that's 24bit resolution and stability over the
loop time constant. It is not 24bit absolute resolution)

Attached is my take on how to do this, from an old attempt on designing
a GPSDO. As reference an LTC6655 is used (mostly for its low noise, not
for its high stability). An LTZ1000 would be better, but also much more
expensive. The AD5060 acts as a (reasonably) low noise DAC with 16bit.
The DAC is supposed to be dithered using software control and the ADG633
is meant to 1) supress the DAC's glitch (both digital-to-analog and code)
and 2) provide stable timing of when the DAC output is applied. The whole
thing is followed by a filter. The structure is kind of weird, but made
such to give selectable range: 0-5V, 0-10V, -5-+5V, -10-+10V. The LTC2057
is probably overkill in this application. But it's reasonably cheap
and rail-to-rail input and output, which simplifies the design quite
considerably.

One thing I would differently, though, would be to replace the DAC and
the CMOS switch by an AD5542. The glitch of the DAC is usally in the order
of what can be acheived with an CMOS switch, so there is little to be
gained there. The digital-to-analog glitches should be high enough in
frequency that they probably shouldn't cause much degradation after
passing through the low-pass filter. The load pin of the AD5542 would
serve to give appropriate timing precision for the dithering to work.
It also has much lower low frequency noise. With the DAC replaced and
the CMOS switch gone, this design should, at least on paper, lead to
approximately 24bits of noise free bits.

As a design guideline to select DACs for this kind of application:
Ignore INL, it will not matter as the control loop will take care
of that. DNL must be below 1LSB as otherwise the control loop
has to deal with sudenly inverted loop gain. the lower DNL, the better
for applications where you dither. The DAC output should be as low
noise as possible, as this noise will dominate all other noise (safe
for the reference noise). And the important noise is the low frequency
noise, not the white noise density. Only after these comes temperature
coefficients (offset and gain).

And the dithering algorithm to use should be a delta-sigma modulator.
At least a second order, better a 3rd or 4th order to keep idle tones
low. Or use additional dithering techniques to reduce idle tones.
There are also techniques to reduce effects due to DNL but going into that
would make this mail even longer than it already is. So I just point
at the delta-sigma modulator book: "Understanding Delta Sigma Data
Converters" by Schreier, Pavan and Temes.

BTW: If anyone has an idea how to get more noise free bits for this
kind of application, I would very much like to hear them. I've been
thinking about this for quite some time, but cannot come up with a
better solution.

		Attila Kinali

--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neal Stephenson

On Tue, 15 Oct 2019 18:57:30 +0200
Attila Kinali attila@kinali.ch wrote:

Err.. correction: 1e-12 frequency control resolution with 1ppm EFC tuning
range results in 1e-6 required EFC voltage control. Which in turn is 20bits.
This is much saner requirement.

I thought something was off when I wrote this, but I was apparently not
awake enough to realize that my calculation was wrong. Sorry about that.

			Attila Kinali

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

Consistency of the glitch independent of DAC output is more important than its size. A constant amplitude glitch occurring at the dac update rate is more benign in its effect than a glitch whose amplitude varies with DAC output.

Brruce

On Wed, 16 Oct 2019 15:04:31 +1300 (NZDT)
Bruce Griffiths bruce.griffiths@xtra.co.nz wrote:

Yes. But it's actually not that bad. The glitch in the DAC is due to
the CMOS switches in the DAC switching. Due to symmetry of the operation
the glitch going from code A to code B will be the (almost) inverse of going
from code B to code A. Which means they should (almost) cancel.

I can't find my notes from when I calculated this, but I remember that
using an external CMOS switch had the same order of magnitude of uncertainty
as using the DAC itself. And a few other effects would be also very close
in magnitude. My conclusion was, considering that the back-of-envelope
calculation of errors would result in a few bits more than necessary,
the added complexity of using an external CMOS switch was probably not
worth it. Of course, to be sure one would need to build both variants
and measure them. Unfortunately, I don't have the means to do that.

Also, my guesstimate would be that using two DACs with metal-foil
resistors for weighting would probably result in lower non-linearity.
But the problem here is that the resistors add quite a bit of noise
which in turn has to be accounted for.

		Attila Kinali

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

If the DAC update rate isn't excessive a 2nV-sec glitch is unlikely to produce a significant perturbation at the output of the lowpass filter following the DAC.

Bruce

Hi

You (sort of) have run into two problems:

1. The GPSDO takes forever and ever to lock ( = the gain is to low / the time constant it to long)

2. The GPSDO has to much jitter ( = the gain is to high / the time constant is to short)

Obviously, you can’t solve both of these problems by adjusting a single parameter. :)

The “common” solution is to run in one mode (high gain) to get things into lock. Then knock
the gain down (likely in steps) as the lock settles in.

While it may seem like a one way street, it may not be. The same “forever to lock” issue also
impacts the ability to deal with a “bump in the road”. If something changes (maybe temperature)
you want to deal with that before there is a major impact.

Bob

Tobias Pluess writes:

I don't know in detail about the particular part you are using, but I
doubt that it is actually using an asynchronous clock into the hardware
counter.  The more typical arrangement is that it gets registered to
some internal clock before the timer hardware deals with the signal
(often via two stages to get metastability issues out of the way).

Regards,
Achim.

+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Hoi Tobias,

On Mon, 14 Oct 2019 11:49:29 +0000
Tobias Pluess tobias.pluess@xwmail.ch wrote:

One important and probably obvious point to notice here is, these
filters produce some considerable amount of noise. In order to get
out best performance, the noise should be limited by the opamp.
To achieve this, the resistors have to be small (this is the reason,
why my design uses 2k2 resistors). But in order for small resistors
to have the desired corner frequency, the capacitors have to be large.
Unfortunately, large capacitors have drawbacks: high eqivalent series
resistance (ESR), high dielectric absorption (DA), high leakage, and
high microphonics.

While the ESR in itself is not of much concern in a low frequency
application like this, it might shift the corner frequecy if a
electrolytic capacitor with high ESR is used. In the first stage,
low ESR capacitors should be used anyways, to prevent heating from the
PWM induced ripple current, which increases aging and changes capacitance
slightly. Worst offeder are elecrolytic capacitors.

DA will be something you have to look out for. For short time constants,
DA will only give a slight offset in integrated voltage (and thus total
phase variation when looking at the output of the OCXO). But with capcitors
that have long time-constant DA, this will be indistinguishable from drift,
but with a non-constant amplitude and sign. This might cause problems with
the drift removal algorithm if not handled properly. In case the voltage
steps are always kept small over a few 100 to 1000s, then DA should have
negligible effect. Worst offenders here are electrolytic capacitors,
followed by ceramic.

Leakage adds two problems: One is temperature dependend offset and the other
is additional noise with a high flicker component. The offset is due to
leakage being a temperature dependent resistance. This will inject current
into places where no current should flow and thus change the output voltage
slightly. Additionally, due to the high resistance involved in leakage,
its noise is very high. Fortunately, the capacitor itself acts as a low-pass
filter of it and it is usually negigible in a lot of cases. But for us, this
means that the low frequency component is larger than the low frequency
component. Something we already don't want to. Additionally, due to the
way leakage current flows, it has a high flicker noise component, which
exacerbates the problem. Worst offenders here are electrolytic capacitors.

Microphonics is the capacitor exhibiting changes in capacitance and thus
voltage (charge stays the same), due to changes in dielectric constant
of the insulator or changes in the distance of the plates, due to mechanical
strain. While all capacitors exhibit this to some extend, ceramic capacitors
are quite bad at this.

Summa sumarum: if you can, use low leakage film capacitors, if not use
ceramic. Microphonics can be mitigated a bit by using ceramic capcitors
with high rated voltage. But don't expect magic from that.

You came up with the exact same solution as I did :-)

The only difference I can see is that I added more extensive filtering
than you did (yes, I'm a bit paranoid).

For the people listening in and comparing this to the TICC:
Using a 10MHz signal instead of an 1MHz signal as the TICC does
has the advantage that the TDC7200 has a lower uncertainty for
short measurement periods (see figure 17 in the datasheet).
This should potentically get the timing uncertainty RMS down to 70ps.
(probably even lower, as for 100ns the uncertainty is in the order
of 40ps)

You will need to have a 32bit timer unit for this. So yes, you will have
to use an STM32F40x or similar.

It does. You will have to asign the edge you capture unambigously to the
reference edge of the 10MHz. The only way to do this is to use the signal
out of the half-nutt-interpolator and feed it to the uC, which in turn
derives its clock from the 10MHz. Additionally, the timer unit has to
run at a higher frequency, so you can avoid problems due to metastability.
My solution was to run the timer at 80MHz, which separates the clock
ticks far enough that each captured instance can be unambigously matched
to a 10MHz edge. Fortunately, some of the timers of the F40x are just fast
enough to manage this.

There are two steps involved: outputing the pulse on the STM32 and
making sure it is low jitter and well aligned.

Step one is done by either using the timer you used for the PPS capture
above or, if you have used all C/C units, by slaving a second one to the
first and using this to generate the output. By capturing PPS pulses, you
will know when to output the pulse  (+/- one TIM clock cycle).

The second step is to have some D-FF's at the output to synchronize
this pulse to the 10MHz of your OCXO (see attachement).

By selecting the realtive phase of the PPS output from the STM32 to
the 10MHz signal, you will be able to keep clear of the setup and hold
times of the FF and thus avoid metastability.

Ah! I love it when people do not ignore metastability! :-D

In this case, the probability of metastability is quite low.
You use a two-step synchronizer (or half nutt-interpolator).
The probability of getting the ALVC74 into such a deep
metastability such that it lasts 100ns is tiiiiiiiny. I don't
have numbers at hand, but I would expect this to happen maybe
once in the life time of the universe. Nevertheless you should
keep the wire from the first FF to the second short and far away
from ground to keep its capacitance low.

If you really want to be sure that you don't get into trouble, you
can steer the OCXO such, that you are about 20-30ns off from the
edge of the 10MHz signal. This way the PPS, even with the spread
from the GPS, will never be close to the clock edge.

		Attila Kinali

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

On Mon, 14 Oct 2019 20:46:14 +0000
Tobias Pluess tobias.pluess@xwmail.ch wrote:

This does not really work with the STM32F40x. The timer clocks are derived
from the APB clock, which in turn is derived from the AHB clock which
defines the core clock speed. So, unless you are willing to clock the
whole uC (safe for the USB interface) with 10MHz, you will end up
with the PLL in there.

Unfortunately, you will need to run the timer at higher speed (see
my previous mail).

An alternative would be to lock a 40MHz crystal to the OCXO
and use this to clock the STM32F40x (max input clock freq is 50MHz).
The added noise due to the 40MHz crystal and PLL should be negligible
compared to the noise/jitter from the uC itself.

			Attila Kinali

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