Sali Tobias,

On Thu, 17 Jul 2025 11:51:39 +0200
"Pluess, Tobias via time-nuts" time-nuts@lists.febo.com wrote:

Would you mind sharing what kind of issues you had?
Your design looked very nice, as far as I remember.

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.

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.

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)

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.

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.

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

Hi Attila,

On 2025-07-25 19:32, Attila Kinali via time-nuts wrote:

You want your systematic noise, such as TIC resolution to be burried in
the noise, as that noise overcomes the resolution limit for the TiC by
smudging out the steps as you average. I did a crap paper and
presentation on that once, but the background simulation was good. I
should revisit that topic to illustrate it better.

The HP5328A Option 40 and HP5328B used this technique and ADEV plots was
pretty good as I measured the measurement limit.

I implemented a very simple "inverse PWM spectrum" interpolator in VHDL
that without too much worry gave me three additional bits. The focus was
to improve hold-over steering, as the 16 bit DAC was a bit coarse for
that. It worked. Just doing a single sigma-delta helps too. You really
want to avoid PWM though, as it puts the highest amplitude at the lowest
frequency, making it hard to filter out. My inverse PWM spectrum put the
MSB of interpolation at highers frequency, every other bit, and then
similar rate. All I was doing was muxing the DAC values. A sigma delta
also moves the major component up in frequency, making it easier to
filter out. You want that. PWM is the worst of alternatives. My
inverse-PWM was the same complexity as PWM, but improved spectrum
performance.

More importantly, I never had to revisit the design, it just worked.
Keeps doing that in it's hardware revisions.

The drift of the oscillator makes the frequency need to take additional
steps to correct it. Now these can be estimated and predicted (to some
degree) and the way to do that is to do a third degree control-loop with
P, I and I^2. The I^2 is a second integrator, for linear frequency
drift, feeding into the first integrator, which holds the frequency
state. As the loop converges the linear drift estimation will steer the
frequency correct and minimize the detector phase error due to linear
drift. Now, the danger of going this route is that not all combination
of parameters are stable, The dull thing is that it's not very complex.
You will however enjoy the improved resolution of dithering for this.

However, very little data needs to be stored in addition. Focus on that
for analysis/traceability records instead. That will be great benefit in
debugging and understanding things.

100 MHz is becoming more common for higher frequency stuff in RF domain
etc. It makes sense for that use, but if you are not into it, it will
not show up on your radar.

Cheers,
Magnus

Hello Attila,

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.

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?

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?

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.

thanks for this hint. I will implement this.

point-of-load

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@lists.febo.com> wrote:

Hi Tobias,

On 2025-07-28 14:16, Pluess, Tobias via time-nuts wrote:

Several small problems that all sounds like fun! :)

Well, if you get the sawtooth correction, which tells you how far off
the PPS pulse was forced to be compared to where the GNSS module wanted
it to be from the GNSS time solution, and you get your TIC to tell you
how far away your 10 MHz oscillator was, you can use the PPS as a
transfer oscillator to get the difference between the GNSS solution and
the oscillator, and now the TIC resolution compared to GNSS sawtooth
corrected resolution becomes relevant.

So, using the sawtooth correction helps considerably. The TDC7200 is
still most likely sufficient thought.

PWM will put you in the worst possible situation. You want to push the
noise up to as high frequency as possible, and the sigma-delta option is
for sure a good way of doing that to simplify the analog filtering to
ensure good performance.

Makes sense. The higher the oversampling, the higher up you can push
noise from the modulation and make the filtering easier.

Doing the modulation right, and fancy filtering can be relieved to
simple RC-link, with relatively high cut-off frequency, which is what
you want.

Already a PI-loop controler is really a state-variable filter which
state-estimates. The Kalman filter modelled for a phase and frequency
linear model is really the same thing, but it auto-tunes the
time-constant depening on the noise. The somewhat tricky part is to
ensure that the noise model for the oscillator matches up with the
actual oscillator, and secondary that the tuning of the Kalman does not
create an unnecessarily resontant loop. As the Kalman converges, it ends
up being the same as the PI-loop controller. The "optimal" part is how
it settle it's parameters and gets there, not steady state performance.

Already the Wikipedia page for Kalman filter helps you and very simple
state model for phase and frequency.

For each time-event, record phase and frequency. These are the estimated
states and they will give you lot's of information. For Kalman Filter,
the P matrix is kind of interesting.

Cheers,
Magnus

All this begs the question of whether using a different GNSS module, like a LEA-M8F that disciplines the vcxo/vctcxo bias to zero, is a better alternative.

The 30.72MHz, while not particularly low phase noise could either be used as a reference on a sigma delta fractional N synthesizer to get a 10MHz directly, or an inverse loop where the 10MHz is disciplined from the 30.72.

Using the exact PPS ought to allow shorter loop time constants with less jitter. Using a derived 10MHz and cleaning it up ought to have the same merits.

I want to experiment and see how well that works out now that I think I have have most of the required hardware to implement and quantify the result.

From: Magnus Danielson via time-nuts time-nuts@lists.febo.com
Sent: Tuesday, July 29, 2025 8:53:37 AM
To: Discussion of precise time and frequency measurement time-nuts@lists.febo.com
Cc: Pluess, Tobias tpluess@ieee.org; Magnus Danielson magnus@rubidium.se
Subject: [time-nuts] Re: My new GPSDO design

Hi Tobias,

On 2025-07-28 14:16, Pluess, Tobias via time-nuts wrote:

Several small problems that all sounds like fun! :)

Well, if you get the sawtooth correction, which tells you how far off
the PPS pulse was forced to be compared to where the GNSS module wanted
it to be from the GNSS time solution, and you get your TIC to tell you
how far away your 10 MHz oscillator was, you can use the PPS as a
transfer oscillator to get the difference between the GNSS solution and
the oscillator, and now the TIC resolution compared to GNSS sawtooth
corrected resolution becomes relevant.

So, using the sawtooth correction helps considerably. The TDC7200 is
still most likely sufficient thought.

PWM will put you in the worst possible situation. You want to push the
noise up to as high frequency as possible, and the sigma-delta option is
for sure a good way of doing that to simplify the analog filtering to
ensure good performance.

Makes sense. The higher the oversampling, the higher up you can push
noise from the modulation and make the filtering easier.

Doing the modulation right, and fancy filtering can be relieved to
simple RC-link, with relatively high cut-off frequency, which is what
you want.

Already a PI-loop controler is really a state-variable filter which
state-estimates. The Kalman filter modelled for a phase and frequency
linear model is really the same thing, but it auto-tunes the
time-constant depening on the noise. The somewhat tricky part is to
ensure that the noise model for the oscillator matches up with the
actual oscillator, and secondary that the tuning of the Kalman does not
create an unnecessarily resontant loop. As the Kalman converges, it ends
up being the same as the PI-loop controller. The "optimal" part is how
it settle it's parameters and gets there, not steady state performance.

Already the Wikipedia page for Kalman filter helps you and very simple
state model for phase and frequency.

For each time-event, record phase and frequency. These are the estimated
states and they will give you lot's of information. For Kalman Filter,
the P matrix is kind of interesting.

Cheers,
Magnus

time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com