Lars DIY GPSDO with Arduino and 1ns resolution TIC

[AndrewBCN]

...
Is 1.25E-10 (125 picoseconds) is a correct result, or did I forget to divide it by 2?

These are extremely interesting experiments you are performing.

My understanding is that 125ps is the theoretical resolution of your TIC device, but as in any time measuring experiment, theoretical does not mean real, you have to take into account various sources of uncertainty.

For example, the 74HC390 has a typical propagation delay of around 15ns per decade counter at 5V at 25C, but this varies with temperature and supply voltage. If you are using the two decade counters in series you effectively have a typical propagation delay of 30ns and even a 1% change in this means 300ps which is more than double your theoretical 125ps resolution.

...
At least, I have not found any significant difference in the output signal of the GPSDO, with and without the qErr correction (ADEV from the GPSDO itself was showing the difference, of course). I made a lot of experiments, receiving QO-100 and telemetry beacons from Es'hail-1 and -2 sats, using my GPSDO for clocking the receiver. I had to pause two months ago, but I hope to continue soon.
...

(my emphasis)

That is because your improvements to Lars' TIC only have an effect at tau<1000s, where the ADEV of Lars' DIY GPSDO is essentially determined by the inherent stability of the OCXO.

...
The reason for the preferrably long time constant is the uncertainty (noise) of the timing reference signal. If you can remove uncertainty from the measurement you can use a shorter time constant.
...

I have a different opinion about this. Clearly to me the reason why the time constant in Lars' DIY GPSDO is set in the range 100~1000s is because as in any GPSDO we are trying to combine the stability of the inexpensive OCXO with the stability of the PPS from the inexpensive GPS receiver, and we only want to start "disciplining" the OCXO at around the point where the two ADEV curves from the OCXO and PPS intersect.

In other words, in an inexpensive DIY GPSDO (using inexpensive OCXOs and inexpensive GPS receivers with inexpensive antennas), there is nothing to be gained by using a shorter time constant, on the contrary: if we "discipline" the OCXO at shorter intervals we are essentially introducing instability in the system and worsening the ADEV of the GPSDO in the region tau < 1000s.

A zero-cost improvement to the TIC with an order of magnitude better resolution is indeed a significant achievement but it won't change the ADEV curve for a typical Lars' DIY GPSDO build using an inexpensive OCXO and an inexpensive u-blox GPS receiver.

[UR8US]

Here is a description of my 4-output, SI5338-based frequency synthesizer, which converts 10 MHz to different frequencies, such as 28.8 MHz (for RTL-SDR), 24 and 25 MHz for  satellite LNB, and so on.

Silabs (SKYWORKS) ClockBuilder PRO sofrware is used to calculate registers for the SI5338. Out task is to upload the register map into the chip by using Arduino Nano. Four frequency profiles are now supported, and may be switched from a front panel. The OLED shows output frequencies at each output.

The synthesizer has its own 10 MHz OCXO, but, of course, may be switched to external 10 MHz source, such as GPSDO (by using a simple jumper). I had a spare small PC board with an SI5338 chip already installed, so I just connected four cables with SMA connectors to it. The whole device is assembled in a 100x100mm breadboard and installed into a suitable enclosure.

What about the quality of the output signal? Well, I do not see any spurs by using an old HP spectrum analyzer (dynamic rage is limited to 80-90 dB). But I _do_ see the spurs on the waterfall of the SDR sofware, using Es'hail satellites as signal sources, and using a cheap LNB with 25 MHz injected, as well as a RTL-SDR (one of XTAL contacts is desoldered and 28.8 MHz is injected via this XTAL). The level of such spurs is better than -40 dBc at 10 GHz, so I believe this means that at 10 MHz the spurs should be -90 dBc or better.

The cheap LNBs and RTL-SDRs are junk; in spite of this I could clearly see the difference between Lars' GPSDO and Leo Bodnar's one. Practically, we will need a signal which is 1) low-noise at 1..10 Hz from the carrier (at 10 GHz!!!) , and 2) low-drift, so to be able to receive FT8 at 10 GHz, the frequency drift should be less than 5 Hz in 15 seconds (0.33 Hz/sec at 10 GHz - which means 0.33 milliHz/sec at 10 MHz!).

The firmware is attached.

P.S. Bugfix: replace 14 with 22 here:
    case 58:
    case 69:
    case 80:
    case 91:

[UR8US]

The photos to the previous post.

P.S. The white stuff is a polyethylene covering TCXO. I later replaced it with OCXO.

[UR8US]

I found better photos.

[AndrewBCN]

Amazing work! Thank you for sharing!

[UR8US]

To compare OCXO-based (Lars' with M6N GPS, IMG_5455) and TCXO-based (Leo Bodnar's with M8T, IMG_5454) GPSDOs, a beacon from one of Es'hail sats was received. (The mirror image is from the SDR software, please ignore). In both cases, an SI5338 converter was uses to get clocks for the LNB and for the SDR. Same GPS antenna. Same scale on the SDR software!

In both cases, the frequency drift was of the same order (theoretically acceptable to receive FT8). However, there is a noticeable difference in the noise (almost nil - or - 100% copy of any FT8 signal).

This is why I highly recommend taking a look at QO-100 and other sats, which in our case are inexpensive "magnifying glasses" for exploring GPSDOs. Important: you even do not need a dish to be able to receive beacons; just point your LNB in the sky.

[AndrewBCN]

To compare OCXO-based (Lars' with M6N GPS, IMG_5455) and TCXO-based (Leo Bodnar's with M8T, IMG_5454) GPSDOs, a beacon from one of Es'hail sats was received. (The mirror image is from the SDR software, please ignore). In both cases, an SI5338 converter was uses to get clocks for the LNB and for the SDR. Same GPS antenna. Same scale on the SDR software!

In both cases, the frequency drift was of the same order (theoretically acceptable to receive FT8). However, there is a noticeable difference in the noise (almost nil - or - 100% copy of any FT8 signal).

This is why I highly recommend taking a look at QO-100 and other sats, which in our case are inexpensive "magnifying glasses" for exploring GPSDOs. Important: you even do not need a dish to be able to receive beacons; just point your LNB in the sky.

These are very impressive results, and very interesting experiments. Do you have any recommendation for an inexpensive LNB ?

[UR8US]

Hi Andrew!

I used to experiment with different types of LNBs, but later I bought a dozen of Eurosky UTP-5 Twin, and tried different methods to inject 25 MHz into the LNB, comparing the results.

Please do not inject 25 MHz into the same wire which is used for RF, as many people recommend. Instead, use one of the LNB's sockets for RF and power, and the other to injecting 25 MHz.

First, disassemble the LNB and power it up from 12V. By using an oscilloscope with 1:1 input (more capacitance than 1:10), find a pin of the XTAL, which has higher amplitude of 25 MHz signal. This is the output of the generator. Cut the trace, and then feed 25 MHz from external source through the XTAL. A 75 Ohm resistor to ground is recommended. Of course, the second socket should be disconnected from the existing circuit in the LNB.

Now you will need two cables to connect your LNB, but this will pay back. If you wish to be able inject 24 MHz, as well, just add another 24 MHz XTAL in parallel to 25 MHz.
 

[AndrewBCN]

Hi Andrew!

I used to experiment with different types of LNBs, but later I bought a dozen of Eurosky UTP-5 Twin, and tried different methods to inject 25 MHz into the LNB, comparing the results.

Please do not inject 25 MHz into the same wire which is used for RF, as many people recommend. Instead, use one of the LNB's sockets for RF and power, and the other to injecting 25 MHz.

First, disassemble the LNB and power it up from 12V. By using an oscilloscope with 1:1 input (more capacitance than 1:10), find a pin of the XTAL, which has higher amplitude of 25 MHz signal. This is the output of the generator. Cut the trace, and then feed 25 MHz from external source through the XTAL. A 75 Ohm resistor to ground is recommended. Of course, the second socket should be disconnected from the existing circuit in the LNB.

Now you will need two cables to connect your LNB, but this will pay back. If you wish to be able inject 24 MHz, as well, just add another 24 MHz XTAL in parallel to 25 MHz.
 

Thank you UR8US!  This will certainly keep me busy experimenting this summer. 

[thinkfat]

...
The reason for the preferrably long time constant is the uncertainty (noise) of the timing reference signal. If you can remove uncertainty from the measurement you can use a shorter time constant.
...

I have a different opinion about this. Clearly to me the reason why the time constant in Lars' DIY GPSDO is set in the range 100~1000s is because as in any GPSDO we are trying to combine the stability of the inexpensive OCXO with the stability of the PPS from the inexpensive GPS receiver, and we only want to start "disciplining" the OCXO at around the point where the two ADEV curves from the OCXO and PPS intersect.

In other words, in an inexpensive DIY GPSDO (using inexpensive OCXOs and inexpensive GPS receivers with inexpensive antennas), there is nothing to be gained by using a shorter time constant, on the contrary: if we "discipline" the OCXO at shorter intervals we are essentially introducing instability in the system and worsening the ADEV of the GPSDO in the region tau < 1000s.

A zero-cost improvement to the TIC with an order of magnitude better resolution is indeed a significant achievement but it won't change the ADEV curve for a typical Lars' DIY GPSDO build using an inexpensive OCXO and an inexpensive u-blox GPS receiver.

Let's have a look at this claim. I've made some simulations in octave using GPS 1PPS data from Leapsecond.com. Find attached three ADEV plots.

One uses an uncorrected 1PPS as input, the second one uses a 1PPS that is "sawtooth"-corrected. Those plots use a time constant of 800 seconds.
The third plot uses the uncorrected 1PPS but with a timeconstant of 2000 seconds.

The simulated GPSDO is spec'd similar to Lars design, 1ns TIC resolution, 16 bit DAC, PI regulator.

The oscillator is synthetic. It's made to be reasonable in performance but not stellar. Only white noise, no temperature dependence.

Legend:
cyan: oscillator phase
red: gpsdo output
magenta: GPS 1PPS
black: DAC values

[AndrewBCN]

...
Let's have a look at this claim. I've made some simulations in octave using GPS 1PPS data from Leapsecond.com. Find attached three ADEV plots.
...
The simulated GPSDO is spec'd similar to Lars design, 1ns TIC resolution, 16 bit DAC, PI regulator.
...

Very interesting but two points:

1. Does your simulation apply any filter to the PPS readings ?

2. As one can see from the simulation, the sawtooth correction essentially shifts down the PPS ADEV curve. However, a similar "correction" effect is achieved by Lars' TIC "pre-filter" (and in the STM32 GPSDO FLL, by the gate time averaged frequency readings). The sawtooth error is deterministic in nature so it is quite simple to deal with in practice. That explains why UR8US did not notice any real improvement in the overall Lars DIY GPSDO operation with the quantization error correction patch when tau > around 1000s.

Quoting Lars:

At short time constants (10-100secs) sawtooth correction probably is very useful for a GPSDO. At long time constants (1000-10000secs) a pre-filter probably is nearly as efficient I think.
...
My own rule of thumb is also that AT cut OCXO´s (and good VCTCXO as DOT050V) need time constants in the GPSDO of about 10-100secs, SC cut OCXO 100-1000secs and Rubidium 5000-20000secs to match good GPS receivers.

(my emphasis)

from this thread: https://www.eevblog.com/forum/projects/ocxo-stable-reference-and-control-voltages/50/

Lars' rules of thumb are probably based on his years of perfecting his GPSDO design with various oscillators but they make perfect sense when one looks at the ADEV curves of the various oscillators he mentions and where they would intersect the ADEV straight line of the PPS from modern GPS receiver modules. As usual there is no "secret magic" that can improve the ADEV curve of a well-designed GPSDO.

[thinkfat]

Alright, some more simulation results, then.

I made a completely new set with a slightly enhanced oscillator model that now also incorporates flicker noise, which I think is more prominent in crystal oscillators than pure white noise. The effect of it is visible in the cyan curve, it is less steep because flicker noise doesn't average out like white noise.

Looking back at the my previous results, I'm pretty sure I made a mistake with the tc=2000 plot, it is considerably worse than you'd expect.

The colors are the same as before, I just added the ADEV of the TIC measurements in "green", it shows the effect of filtering most prominently.

First graph is without qerr correction, no filtering and tc=1000, which should be fairly optimal for this oscillator.

Second graph is identical but includes a 60 second EMA filter on the TIC measurements. See how the green curve gets flatter. Also notice that the effect for tau < 100s is almost negligible, there's a slight improvement between 100s and 1000s but the stability around 1000s is slightly worse.

Third graph is with qerr correction, no filter, tc=1000. There's a visible advantage for tau > 100s, but one can also see that the performance for tau > 1000 is worse than it could be. The time constant is too long already for this combination of GPS and oscillator.

Fourth graph is again no qerr correction, no filter but tc=2000, which gives a better result which almost matches the result from the sawtooth corrected GPS, but not quite. Of course such long time constants comes at a cost: you better have a really well controlled environment because the control loop will basically do nothing to counter any such effects.

I think this shows that there is definitely an advantage in using quantization correction, not particularly for short tau but for medium to long term stability starting with tau = 100s. Why UR8US didn't see any advantage, well, his requirements were for very short tau, well below 100s. This area is completely dominated by the oscillator.

[UR8US]

Hi!

To study the qErr, I plotted it (in picoseconds) in TimeLab, and the ADEV looks quite smooth.

Idea: what if I feed qErr (instead of the TIC output) to the prefilter and so on, and then look at the DAC values in TimeLab? Will I see the difference with different time constants? I will do this experiment soon.

[thinkfat]

Hi!

To study the qErr, I plotted it (in picoseconds) in TimeLab, and the ADEV looks quite smooth.

Idea: what if I feed qErr (instead of the TIC output) to the prefilter and so on, and then look at the DAC values in TimeLab? Will I see the difference with different time constants? I will do this experiment soon.

I'm not sure what you're getting at with this. The "qErr" is the difference between the "true" GNSS top-of-second time signal in relation to the externally visible 1PPS pulse. It doesn't contain time information, as it is not referenced to absolute time. It is referenced to the 1PPS pulse. It is just the quantization noise. By itself it is useless.

[UR8US]

I think of the qErr (in fact, "the absence of qErr correction") as a phase noise added to the noise of GPS itself (caused by atmospheric effects, etc), as well to the noise of the circuit of the GPSDO (temperature drifts, etc.).

If I see frequency drift of +=10Hz (+-1ppb) on the screen of the SDR software, receiving Es'hail beacons (the trace is almost identical to what I see at DAC), I am just curious: how much of this drift is caused by qErr? Can I efficiently reduce the drift by changing the time constant of the PI filter?
 
P.S: More phase noise is added when there is no qErr correction. With qErr correction, the quantization error is only ~10% compared to no correction.

[UR8US]

Hi!

Here is the result of experimenting with turning qErr on or off. I used time constant of 64 seconds for the graphs not to be too smooth.

The blue line is qErr-corrected output of the GPSDO. I do not have an SDR right now to check the trace, but I believe the DAC values reflect the output frequency nicely. Similarly to previous experiments, there was a frequency swing of about  +-3e-10 (+- 3 Hz at 10 GHz). However, A completely different hardware is used now; geographical position and height are also different. 

The purple line is plotted with qErr correction turned off. There is no noticeable difference in the amplitude of the swing, although the line is not as smooth as the blue one.

Now, how much of the uncorrected qErr gets through the digital filters of the GPSDO? I simply fed the qErr read from the GPS module (instead of the TIC output) to the input of the pre-filter.

The qErr signal is periodical with period changing from 2 to 60 seconds. It looks like the more the period is, the more of the qErr leaks through the digital filters. However, the leakage is quite small even for a 64-second filter (green line).

Unfortunately, all three graphs were made at different time, so I can not add or subtract them.
 

[thinkfat]

Two remarks:
1- ADEV for all data sets would be nice
2- 600 seconds is not really a lot to make a meaningful statement.

[UR8US]

Two remarks:
1- ADEV for all data sets would be nice
2- 600 seconds is not really a lot to make a meaningful statement.

Sure! More data is always better, but, I am too impatient. :-)

[UR8US]

I definitely need to run the plots for 24 hours or so to get smooth graphs at t~1000sec.

[Mike99]

Hi everyone, it's been 2 years since I built my Lars GPSDO and I haven't been here for quite a while.

Recently my Bliley OCXO starting drifting badly so I replaced it with a Vectron I found on eBay for just £9. I established the gain and linearization then set it running with no temperature compensation. This resulted in the attached graphs and I have a couple of questions about diff_ns.

What causes the periodic sudden swings?

You can see that diff_ns tracks the change in temperature. I know how to calculate tempRef but am not having much luck understanding how to get tempCoeff from the constantly changing DAC values. Can anyone help please?

Mike

[MIS42N]

What causes the periodic sudden swings?

How long have you run it? OCXOs that haven't been run for a while, and bounced around in transit, need time to settle. A week maybe?

[0xFFF0]

3 or 4 hours should be enough, otherwise the OCXO is not good.

[thinkfat]

3 or 4 hours should be enough, otherwise the OCXO is not good.

Or 3 to 4 weeks. I'm sure it's been a while since it was powered on and it has been banged around quite a bit.

[Mike99]

It's been running for about a week. I wasn't expecting much for such a cheap device that's 15 years old, but I thought the MDEV looked OK?

I just want to understand what causes those jumps in diff_ns.

Mike

[thinkfat]

It's been running for about a week. I wasn't expecting much for such a cheap device that's 15 years old, but I thought the MDEV looked OK?

I just want to understand what causes those jumps in diff_ns.

Mike

Looking at the MDEV and the raw data graphs I'd say, it's working fine. I believe the diff_ns jumps are just quantization artifacts. The raw phase error data does not suggest any particular problem like phase jumps. Also, no excessive drift or similar.