[time-nuts] Re: My new GPSDO design

[Magnus Danielson]

Hi Attila,

On 2025-07-25 19:32, Attila Kinali via time-nuts 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 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.

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.

>> 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)

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.

>
>> 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.

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.

>> 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.

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