[time-nuts] Re: My new GPSDO design
Pluess, Tobias
tpluess at ieee.org
Mon Jul 28 12:16:22 UTC 2025
Hello Attila,
> Would you mind sharing what kind of issues you had?
> Your design looked very nice, as far as I remember.
sure. Indeed my design was working nicely, but it lacks a good interface
for easily adding a Raspberry (or similar device) for ethernet
connectivity. Further, it also lacks connectivity for the 1PPS serial
output, and the DAC output has no filter circuit, so if some kind of
oversampling would be used on the DAC, it could not be filtered properly.
Besides that, I wanted to use one of the newer u-Blox modules as they offer
even better 1PPS performance.
> The noise in the sawtooth corrected PPS is still several orders of
> magnitude larger than resolution of the TDC7200. The only important
> bit here is that the uncertainty contribution (noise, bias, etc)
> of the TDC is below that of the PPS output of the GPS, which holds
> for the TDC7200, as far as I am aware of.
actually, you are right here. The TDC7200 claims to have 55ps uncertainty.
Let it be 10 times worse, 550ps, and it is still much better than what the
GPS module can provide. So in this regard, it is probably sufficient and it
will not make much sense to aim for higher TDC resolution, right?
> I am pretty sure that's not just a PWM but a delta-sigma modulator.
> I would go with the same on the DAC. Implement a second oder delta-
> sigma modulator on your µC and filter your output. This would give
> you log_2(sampling rate / BW) * 2.5bits additionally to the 16bit
> you have from the DAC8551. I.e. If you sample at 100ksps and have
> an output filter bandwidth of 100Hz, you'll get log_2(100k/100)*2.5bits
> which is about 24 bits. Realistic would be some 5-15 bits more, depending
> on the exact behaviour of the DAC. Please note that this approach
>only works because the non-linearity due to the DAC's behaviour
> will be compensated by the control loop. We can't easilly build
> DACs with an ENOB of more than 20bits (there are ways, but they
> become expensive very quickly and have lots of caveats)
in fact, there is two possible solutions. What I call the "PWM DAC" I did
somewhat copy from the commercial GPSDO. They use some kind of analog
switch that is controlled by a PWM signal from an FPGA, and it switches the
input of the analog lowpass filter either to +5V or 0V. The filter then
averages and creates the actual analog output voltage. I aimed here for a
similar solution. As I am not using a FPGA but a normal microcontroller
instead, it has no hardware solution for pulse density modulation
(delta-sigma modulation). So I would try it with PWM.
The other method is modulating the DAC output. In my case, the DAC has 16
bits, but I imagine I can increase this (by how much I am not yet 100%
sure) by modulating the DAC in a delta-sigma style. For example, I would,
instead of just once per second, update the DAC 100 times per second. Then,
if I want to output the digital code 1000.5, I would output alternating
1000 and 1001, and the DAC's output would then swing between the two
voltages. The Sallen-Key lowpass filters out the harmonics and settles to
the average voltage. Makes sense?
> An easy way to do this, both estimating temperature dependence and
> aging, is to use a Kalman filter. This will give you a decent estimate
> with low memory and computational effort. Start first with a linear
> aging estimator and, once you got it stable, use a quadratic one.
indeed, this would be very interesting! I am familiar with state space, but
I have not employed Kalman filtering for a long time and would have a
though start with this. Can you give a couple hints?
As for the data collecting, yes, I am not even sure what kind of data needs
to be collected, as the environment temperature also has an effect. On the
other hand, it seems like it is possible as commercial GPSDOs also do this.
There are data flash chips that can store 8Mbyte of data in a SOIC-8
package, I estimate this would be sufficient to collect TDC and temperature
data for a couple weeks.
> The buffer inverter used for the 10MHz clock is biased by a
> resistive divider. Use a 100k-1M resistor feeding back from the
> output to the input instead, to self-bias the inverter. This way
> you eliminate changes in the threshold voltage of the inverter
> due to temperature changes, which would give you a slow drift
> in the apparent delay through the inverter.
thanks for this hint. I will implement this.
> You are using quite a few ferrite beads in the power path of
> components. Be careful with them. for low frequencies (below 1-10MHz)
> they act purely inductive with almost no resistive component.
> I.e. you get a nice, high-Q resonator with the capacitors. Make
> sure your design does not accidentally excite any of the resonances
> in your system that these ferrite beads introduce. Better use
point-of-load
> regulators whenever you need low noise or high PSRR for senstive
components.
Indeed. I was thinking a lot about the pros and cons of the ferrite beads
vs. point of load converters. In fact, I am also not 100% sure how much I
can gain with the beads, so I thought I add them and in case they don't
work I can replace by 0Ohm bridges.
For example, the DAC has the problem that it wants 3.3V but has no separate
connection for analog and digital supply. So I figured that the noisy 3.3V
supply could introduce additional noise to the DAC output, and I want to
prevent this. Maybe I should spend indeed a small voltage regulator there?
Same problem for the analog switch, it also has no separate pin for the
analog supply so digital noise could creep into my analog signals. Indeed I
am not yet sure what is the best option there.
Thanks for your hints,
Greetings from Bern
Tobias
On Fri, Jul 25, 2025 at 7:50â¯PM Attila Kinali via time-nuts <
time-nuts at lists.febo.com> wrote:
> Sali Tobias,
>
> On Thu, 17 Jul 2025 11:51:39 +0200
> "Pluess, Tobias via time-nuts" <time-nuts at lists.febo.com> wrote:
>
> > I am in the process of designing a new GPSDO. As my previous one worked
> > very nice, but had several small design issues, I want to make a new one
> > that is a bit improved. So I have drawn a new schematic that is in the
> > attachment.
>
> Would you mind sharing what kind of issues you had?
> Your design looked very nice, as far as I remember.
>
>
> > I use again the Oscilloquartz / "UTC" branded oscillator and an
> integrated
> > dual buffer / distributor and a TDC7200 as interpolator. I did not find
> any
> > other time to digital converter that has both, higher resolution as well
> as
> > a package that can be hand soldered, so I stick to the 7200. I am happy,
> > however, if someone can give me a hint for a possibly even better TDC.
>
> I don't think you'll get much better results using a different TDC.
> The noise in the sawtooth corrected PPS is still several orders of
> magnitude larger than resolution of the TDC7200. The only important
> bit here is that the uncertainty contribution (noise, bias, etc)
> of the TDC is below that of the PPS output of the GPS, which holds
> for the TDC7200, as far as I am aware of.
>
>
>
> > Also, with this new GPSDO, I want to add a serial connector that connects
> > also the 1PPS signal, such that it could be used by a PC with GPS/NTP
> > software, such as chrony. I was also thinking about PTP, but I found no
> > elegant solution for this.
>
> The canonical way is to use pin 1 (DCD). and then use the PPS subsystem
> of your OS to get accurate timestamping. All ntp clients I am aware of
> support this.
>
>
> > Also, I would like to increase the resolution of the DAC that I use to
> > steer the OCXO. For this, I have 2 optional solutions. One is the PWM
> DAC,
> > that I copied from the Oscilloquartz STAR4+ GPSDO I have. The other one
> is
> > the classic 16-bit DAC, and here, I would like to use later some kind of
> > delta-sigma modulation to increase the resolution. For this reason, there
> > is this low pass filter after the DAC.
>
> I am pretty sure that's not just a PWM but a delta-sigma modulator.
> I would go with the same on the DAC. Implement a second oder delta-
> sigma modulator on your µC and filter your output. This would give
> you log_2(sampling rate / BW) * 2.5bits additionally to the 16bit
> you have from the DAC8551. I.e. If you sample at 100ksps and have
> an output filter bandwidth of 100Hz, you'll get log_2(100k/100)*2.5bits
> which is about 24 bits. Realistic would be some 5-15 bits more, depending
> on the exact behaviour of the DAC. Please note that this approach
> only works because the non-linearity due to the DAC's behaviour
> will be compensated by the control loop. We can't easilly build
> DACs with an ENOB of more than 20bits (there are ways, but they
> become expensive very quickly and have lots of caveats)
>
>
> >
> > Also I would like to add something new to this, if the computing power of
> > the microcontroller is sufficient. I would like to collect some
> statistical
> > data about the OCXO aging, store this data in the flash memory that I
> added
> > for this purpose, and then try to extrapolate the aging. Then, in the
> case
> > of holdover, use the extrapolated aging data to steer the OCXO such that
> > its aging is compensated. Not sure if this is even possible, but I would
> > like to try. With my current design of the GPSDO, this is not possible,
> as
> > there is not enough storage for some statistical data.
>
> That's a very nice idea, but I think your major limitation will be
> the amount of data you can store, if you want to do long term analysis.
> If your goal is just to estimate the aging, than that's a much simpler
> problem. But you will need to remove all confounding factors first.
> At the very least, you need to estimate your linear temperature dependence.
> I doubt that the quadratic component of the temperature dependence is
> significant for the 8663 clones, though I have not measured them.
>
> An easy way to do this, both estimating temperature dependence and
> aging, is to use a Kalman filter. This will give you a decent estimate
> with low memory and computational effort. Start first with a linear
> aging estimator and, once you got it stable, use a quadratic one.
>
>
> > What do you guys think about my design? Would it be a nice GPSDO or
> > complete crap ideas.
>
> The ideas are very nice and I wholeheartedly support you.
>
> Some small nitpicks on the schematic:
>
> The buffer inverter used for the 10MHz clock is biased by a
> resistive divider. Use a 100k-1M resistor feeding back from the
> output to the input instead, to self-bias the inverter. This way
> you eliminate changes in the threshold voltage of the inverter
> due to temperature changes, which would give you a slow drift
> in the apparent delay through the inverter.
>
> You are using quite a few ferrite beads in the power path of
> components. Be careful with them. for low frequencies (below 1-10MHz)
> they act purely inductive with almost no resistive component.
> I.e. you get a nice, high-Q resonator with the capacitors. Make
> sure your design does not accidentally excite any of the resonances
> in your system that these ferrite beads introduce. Better use point-of-load
> regulators whenever you need low noise or high PSRR for senstive
> components.
>
>
> > Also, I was thinking about adding a 100MHz output. But I am not sure if
> > this really adds value to it, as I see that 100MHz are used by some
> > instruments, but only rarely, and I am not yet aware of good, obtainable
> > 100MHz oscillators.
>
> We kind of standardized on 10MHz for most things, so having a 100MHz
> output,
> if you don't have a need for it, does not add much benefit. At least, I
> don't
> know of many instruments that use 100MHz reference inputs. If you need to
> have a frequency locked 100MHz, I would do that as an additonal board.
> This way you can optimize it for whatever you need it for.
>
> I hope this helps.
>
> Es schöns Wuchenend no und Gruess
>
> Attila Kinali
>
>
> --
> Science is made up of so many things that appear obvious
> after they are explained. -- Pardot Kynes
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe send an email to time-nuts-leave at lists.febo.com
>
More information about the Time-nuts_lists.febo.com
mailing list