Lars DIY GPSDO with Arduino and 1ns resolution TIC

[MIS42N]

Is there anybody willing to share their implementation for 'sawtooth' correction? This has come up several times in this Blog, but never with an example.

I have an implementation but don't use the Lars system. So just passing it on in case it helps someone.

The 1PPS is timed to the nearest 25ns. The arrival times are attributed an odd number: -75ns to -50ns is -5, -50 to -25ns is -3, -25ns to 0 is -1, 0 to 25ns is +1, 25ns to 50ns is +3 etc.

Arrival times are accumulated over a period of 2ⁿ seconds (without altering the control voltage). The best results seem to come from 256 or 512 seconds. Calculations are done after 2 successive periods and a control voltage adjustment is calculated and applied. The aim is to reduce the averages to zero.

The jitter becomes a necessary part of the equation, as it randomises the arrivals so ideally half arrive in the -25ns to 0 period and half arrive in the 0 to 25ns period. The technique wouldn't work if there isn't jitter. And because the control voltage is altered infrequently, it is relatively insensitive to 'suspension bridge' and other shorter term artifacts caused by the jitter.

If the accumulations for successive periods are values A and B, then a frequency error is proportional to A - B, and a phase error at the end of the second period is proportional to A-3B. If the exact pulling Hz per V slope is known (it is determined for the OCXO in a calibration process) then it is simple to compute a change of control voltage that corrects the frequency, and a voltage offset to null out the phase error over a chosen period.

Someone mathematically inclined can work out the statistics. I think most errors created by using this method is 25ns / sqrt(measurement period) so in the region of 1 or 2ns. Which when applied to a oscillator period of 100ns (10MHz) is not much.

[thinkfat]

The "sawtooth" is an aliasing effect. GNSS receivers will inevitably output their timing pulse relative to an edge of their own, fixed, internal clock. This clock will not have any defined relation to the time signal received. Therefore, the time pulse is always slightly "wrong", because it is quantized through the internal clock. This "wrongness" is an error introduced by the quantization of "time" inside the GNSS receiver.

Fortunately, the GNSS receiver knows quite precisely how much error this quantization introduces, and can publish that information before outputting the time pulse, making it possible for e.g. a GNSSDO program to correct for it. It is a simple matter of subtracting (or adding) the published quantization error to the TIC measurement.

[Dbldutch]

@thinkfat:
The way I understand it from the ublox documentation, the qErr information is available for the next 1PPS pulse.

This is the little bit of information in this document: u-blox-M8_ReceiverDescrProtSPec_UBX-13003221.pdf

On page 71:

19.1 Introduction
u-blox receivers include a time pulse function providing clock pulses with configurable duration
and frequency. The time pulse function can be configured using the UBX-CFG-TP5 message. The
UBX-TIM-TP message provides time information for the next pulse, time source and the
quantization error of the output pin.

On page 432: Time Pulse time data:

This message contains information on the timing of the next pulse at the
TIMEPULSE0 output.

[thinkfat]

@thinkfat:
The way I understand it from the ublox documentation, the qErr information is available for the next 1PPS pulse.

That's correct.

[FVCTVP]

TDC7200 is quite viable (I've done it myself), but not sensible if you don't implement "sawtooth correction".

Hi Thinkfat, I didn't know the phenomena you have described (and I appreciate it so much).
But why the TDC7200 needs the sawtooth correction and not the Lars solution? I mean, the problem you described seems inherent to any GPSDO, doesn't it?

I have a question about the TDC7200 approach: this device only measures time difference between START events and STOP events, right? Let's suppose that the phase difference has been reduced progressively until 1ns, but at certain time, the second signal comes first (for example the STOP triggers 1ns before), how is this managed? because the TDC72000 does not measure negative phase difference, right?
If we are using a 500kHz as the STOP signal, that would mean the time difference would jump to 1.999us aprox. (1ns-2us). How does the algorithm should manage this?

Thank you again for yor help

[thinkfat]

TDC7200 is quite viable (I've done it myself), but not sensible if you don't implement "sawtooth correction".

Hi Thinkfat, I didn't know the phenomena you have described (and I appreciate it so much).
But why the TDC7200 needs the sawtooth correction and not the Lars solution? I mean, the problem you described seems inherent to any GPSDO, doesn't it?

I have a question about the TDC7200 approach: this device only measures time difference between START events and STOP events, right? Let's suppose that the phase difference has been reduced progressively until 1ns, but at certain time, the second signal comes first (for example the STOP triggers 1ns before), how is this managed? because the TDC72000 does not measure negative phase difference, right?
If we are using a 500kHz as the STOP signal, that would mean the time difference would jump to 1.999us aprox. (1ns-2us). How does the algorithm should manage this?

Thank you again for yor help

The TDC7200 can measure down to a 56ps single-shot resolution. But without correcting for quantization error, this makes no sense at all. 56ps will be completely drowning in the quantization noise.

Correcting qErr will make sense with Lars' design, too. The best case resolution of 1ns of Lars TIC can benefit from it. But the original design has no way to connect to a GNSS receiver. Instead, it is all down to the filtering and time constant choices.

For your other questions, I think I'd like point you to my own GPSDO design, which uses the TDC7200. If you read through this thread, I started the project sometime late in  2019, I think.

Direct link to first post:
https://www.eevblog.com/forum/projects/diy-gpsdo-project-w-stm32-tdc7200/

Best regards

[FVCTVP]

Thank you, I will take into account the qErr (I have to check if my receiver gives me that information, which I guess it does).

I have already read all the post (there is a lot of information and I will need days to process everything, as I am new in the timekeeping world )
I have just two questions about your design:

Did you need to invert the 500kHz signal before inputting it to the TDC STOP pin?

It seems you implemented also a local PPS output. Did you generate it from the OCXO or did you generate it directly from the microcontroller (from a digital pin)? In the second case, did you need to compare the PPS phase difference with another TIC?
In my case I'm planning to use the 10MHz OCXO as the microcontroller main clock, and then generate the local PPS and output it to a digital pin once I know the 10MHz are locked to the GPS PPS.

Regards!

[thinkfat]

Both If you read the end of the thread, I explain  how to get a zero-drift GNSS synchronized NTP and PTP time service. Stratum 1.

[PCB.Wiz]

But why the TDC7200 needs the sawtooth correction and not the Lars solution?
I mean, the problem you described seems inherent to any GPSDO, doesn't it?

See also https://www.eevblog.com/forum/projects/gpsdo-question-378182/
where a 1us Analog TIC is used, without any MCU step at all.

The way I look at it is, if the GPS unit has a 20.833ns granularity, per second, it can resolve/average to 2ns in 10s and 1ns in 20s.
ie a time constant of 20s can make use of a ~1ns TIC.
You rely on the OCXO taking care of stability inside that 20 second average window.

A digital TIC is not mandatory, but if you plan to use a MCU anyway, it does give you extreme number of digits, you can decide how many matter
If you want to work in absolute time (not just GPSDO ), a digital TIC and qErr makes more sense.

Meanwhile, I'm pondering small MCUs with faster timer/capture, as a mid-ground.

Generic MCUs with sysclk timers, are a bit coarse, being the same ballpark (or worse) as the GPS.

Full precision TIC of sub 1ns, are easily able to see a single GPS granularity step, but are probably excessive.
MCUs with Config Logic cells can be used to swallow the XOR Time -> Ramp -> ADC, someone posted a PIC design using Config Logic.

Newer MCUs (STC, Megawin etc) have 150~250MHz capture PLLs, which is quite a bit finer than the GPS, and likely now enough to sense every GPS correction if you want to do that.
The parts are relatively new, which is a minus, but they can offer an entirely digital capture side.

[Dbldutch]

Before you dive in with the TDC7200, there is an even better alternative, the AS6501.
The reason I bring this up is because I started a project last year to see if I could build a counter that could measure my main GPSDO, that is based on small improvements on the Lars design.

I found a few very promising reciprocal counter designs from a developer (Michael Nowak) that is also published on this Forum, and started to experiment with them. Michael build counters based on the TDC7200, but his latest and currently best performing counter uses the AS6501.

Any (reciprocal) counter needs a very good reference frequency, so I also experimented with variations of the Lars design and also an analog (no cpu) alternative.
Needless to say, my conclusion was (duh) that I needed an external reference clock for the counter that was al least as good as (or ideally 10x better) than the GPSDO it is measuring.

This lead me to further improvements on the Lars design that I'm actually still working on. (BTW, I will add the qErr feature to it)
I choose to continue to use the Lars design for my improvements and not deviate too much from it, just to see how far I could get with that design. That's why I did not yet swap to a completely different GPSDO architecture, but who knows...

Describing my design process is difficult to do on this Forum, so if you're interested, here are links to my Blog where I describe my attempts.
https://www.paulvdiyblogs.net/2023/01/a-high-resolution-reciprocal-counter.html
https://www.paulvdiyblogs.net/2023/05/a-new-gpsdo-design-v3.html
https://www.paulvdiyblogs.net/2023/06/gpsdo-version-4.html

Have fun...

[FVCTVP]

Before you dive in with the TDC7200, there is an even better alternative, the AS6501.

Thank you, I will check that component, I have heard that Part Number before at this forum.

Any (reciprocal) counter needs a very good reference frequency, so I also experimented with variations of the Lars design and also an analog (no cpu) alternative.

Did you implement an analog GPSDO? My first approach was to build basically a PLL with 7 decade counters connected in order to compare two 1PPS signals. Th problem of this approach was that the signal error outputed by the 4046 JK comparator had a very small Duty Cycle (compared to the 1s cycle) and its mean value (introduced into the OCXO) is basically 2,5V (the error signal is uncapable to "move" that value when phase difference is small.

See also https://www.eevblog.com/forum/projects/gpsdo-question-378182/
where a 1us Analog TIC is used, without any MCU step at all.

The way I look at it is, if the GPS unit has a 20.833ns granularity, per second, it can resolve/average to 2ns in 10s and 1ns in 20s.
ie a time constant of 20s can make use of a ~1ns TIC.
You rely on the OCXO taking care of stability inside that 20 second average window.

A digital TIC is not mandatory, but if you plan to use a MCU anyway, it does give you extreme number of digits, you can decide how many matter
If you want to work in absolute time (not just GPSDO ), a digital TIC and qErr makes more sense.

Meanwhile, I'm pondering small MCUs with faster timer/capture, as a mid-ground.

Generic MCUs with sysclk timers, are a bit coarse, being the same ballpark (or worse) as the GPS.

Full precision TIC of sub 1ns, are easily able to see a single GPS granularity step, but are probably excessive.
MCUs with Config Logic cells can be used to swallow the XOR Time -> Ramp -> ADC, someone posted a PIC design using Config Logic.

Newer MCUs (STC, Megawin etc) have 150~250MHz capture PLLs, which is quite a bit finer than the GPS, and likely now enough to sense every GPS correction if you want to do that.
The parts are relatively new, which is a minus, but they can offer an entirely digital capture side.

Thank you very much for the ideas

I am not especially interested in using a microcontroller, it's just that the solutions I see over here lead me down that road. I'm trying to implement a GPSDO that is capable to output a disciplined PPS signal, and that has a maximum drift of 1ms over a day  or less in holdover mode. So I do not really need a phase difference of picoseconds, but to have a controlled and stable phase difference and, in case the GPS switches off or does not has PVT, the GPSDO can give me a reliable PPS signal to bring to the NTP server (making some temperature compensations if needed).

Thank you again for all the information youre bringing, it is really useful for me

[MIS42N]

I am not especially interested in using a microcontroller, it's just that the solutions I see over here lead me down that road. I'm trying to implement a GPSDO that is capable to output a disciplined PPS signal, and that has a maximum drift of 1ms over a day or less in holdover mode. So I do not really need a phase difference of picoseconds, but to have a controlled and stable phase difference and, in case the GPS switches off or does not has PVT, the GPSDO can give me a reliable PPS signal to bring to the NTP server (making some temperature compensations if needed).

1ms a day is a little more than 0.1Hz error with a 10MHz signal. That should not be a problem. Most GPSDO will hold the OCXO better than 0.01Hz. It is a matter of choosing a good OCXO and a bit of care with the control voltage, and has very little to do with the quality of the GPS side. My experience is the OCXO is not affected much by temperature, but the control voltage can be (depending on where it comes from). A variation of my design buffers the control voltage in such a way it is derived from a MAX6350 precision 5V source, very little temperature effect.

But why a day of holdover? I have recorded GPSDO output for weeks and not seen any significant outage of the GPS signal. It triggers a reboot if there is a long GPS outage (I think 60 seconds, I'd have to look at the code), and it has never happened. And that is with an antenna in a place with poor reception. The current test has been running 5 days with no signal loss. There are counters in the program to keep stats, up 445492 sec 0 loss.

[PCB.Wiz]

My first approach was to build basically a PLL with 7 decade counters connected in order to compare two 1PPS signals. Th problem of this approach was that the signal error outputed by the 4046 JK comparator had a very small Duty Cycle (compared to the 1s cycle) and its mean value (introduced into the OCXO) is basically 2,5V (the error signal is uncapable to "move" that value when phase difference is small.

The link I gave above uses a sample and hold phase detector, that can work with 1pps update rates, and paulv has an example in those links above of a Micro-GPSDO, that uses analog-loop (no MCU), but does boost the 1pps to 100kHz first.
A 1pps update is slow, and relies on long hold times for short update impulses.

You do need some divider, from 10MHz, in that link the poster has issues with the divider just too small for the wide control range of the OCXO, so more than one edge is in range.
ie your OCXO control range should help decide the 10Mhz divider /10/20/50/100... you do not need 7 decade ctr, that just buys trouble as you have to walk one pps to match the other !
Pick a minimal divider to avoid errant locks, and that means much less phase walk is needed to lock.

I am not especially interested in using a microcontroller, it's just that the solutions I see over here lead me down that road. I'm trying to implement a GPSDO that is capable to output a disciplined PPS signal, and that has a maximum drift of 1ms over a day  or less in holdover mode. So I do not really need a phase difference of picoseconds, but to have a controlled and stable phase difference and, in case the GPS switches off or does not has PVT, the GPSDO can give me a reliable PPS signal to bring to the NTP server (making some temperature compensations if needed).

If you add in a requirement for a day hold-over, that's getting beyond a MCU-less solution, as you need to hold the OCXO control voltage at last-voltage for a very long time, when a break is sensed.
A lot of logic is needed there, so simplest to use a MCU to manage the DAC.

[FVCTVP]

1ms a day is a little more than 0.1Hz error with a 10MHz signal. That should not be a problem. Most GPSDO will hold the OCXO better than 0.01Hz. It is a matter of choosing a good OCXO and a bit of care with the control voltage, and has very little to do with the quality of the GPS side. My experience is the OCXO is not affected much by temperature, but the control voltage can be (depending on where it comes from). A variation of my design buffers the control voltage in such a way it is derived from a MAX6350 precision 5V source, very little temperature effect.

But why a day of holdover? I have recorded GPSDO output for weeks and not seen any significant outage of the GPS signal. It triggers a reboot if there is a long GPS outage (I think 60 seconds, I'd have to look at the code), and it has never happened. And that is with an antenna in a place with poor reception. The current test has been running 5 days with no signal loss. There are counters in the program to keep stats, up 445492 sec 0 loss.

Very interesting, of course if I can get more than 1 day of holdover I will go for it!!
Did you generated the disciplined PPS from dividing down the 10MHz OCXO freq or did you generated it directly from the controller?
Thank you for the info

[MIS42N]

Very interesting, of course if I can get more than 1 day of holdover I will go for it!!
Did you generated the disciplined PPS from dividing down the 10MHz OCXO freq or did you generated it directly from the controller?
Thank you for the info

The GPSDO does not generate a 1PPS, output is a disciplined 10MHz. However, the design is minimal (the original aim was lowest cost GPSDO with a guaranteed accuracy of ±0.01Hz). There were not enough pins on the CPU to have another output. I have been thinking of using a more recent CPU (one with more pins), to drive a small OLED screen in addition to what it does now (OLED screen currently in the mail).

It would be simple to add a 1PPS output. The CPU is clocked by the 10MHz OCXO, and the arrival time of 1PPS from the GPS is captured by gating a 16-bit timer clocked at 40MHz. Which is why the design is nothing like Lars, it is a 25ns TIC and uses no extra components. At the moment the actual gated time is not important, as long as it is the same every pulse (within a couple of counts). The counter and gate operation are independent of the CPU, so it would be possible to arrange a pulse be generated at a particular time, and adjust that time by requiring that the 1PPS from the GPS be gated at a particular count thereby aligning the output 1PPS to the average of the input 1PPS (within 25ns). The interrupt from the gate would be delayed by the interrupt to produce the 1PPS, but that wouldn't be an issue because the timer has stopped and can be read any time later.

[Dbldutch]

Going back to the qErr topic that UR8US provided.
I managed to make that work in my setup.

Afterall, the hardware changes turned out to be really easy to do.
I did found that I had to fix an error in his provided sketch but that was quite simple as well.

The results are such that in my setup, up to +/-10nS of qErr data is now added/subtracted from the NS result and eliminates that particular source of "error".
More details can be found on my Blog, go towards the end for the description.

https://www.paulvdiyblogs.net/2023/06/gpsdo-version-4.html

Note that this is not a solution to the "sawtooth" issue. The NS values are now cleaner, because devoid of the NEO internal clock/1PPS timing errors, but that overall challenge remains.

My next step is to figure out a way to eliminate or reduce the remaining sawtooth effect without changing too much to Lars' code.
The trick is where and how to do that in his code so I don't mess with his intended and already provided functionality.
That may be a real challenge for me because his code is not so easy to understand.
Any help to address this is welcome...

[thinkfat]

The "sawtooth" effect typically refers to the quantization error only. Whatever other effect you're seeing, it's not that

However, it's known that the qErr doesn't perfectly compensate the quantization error. I remember reading somewhere, that at least with the LEA/NEO 6/7/8 receivers, the qErr is represented through too few bits to completely compensate the aliasing.

But other measures should be taken first, to improve the performance. For example, if you use a timing-type receiver (like, LEA/NEO M8T), make sure you have done a proper survey-in. This will allow the receiver to operate in "overdetermined clock" mode. It will greatly reduce the uncertainty on the timing signal.

BTW - the better your TIC data, the less sense it makes to go for super-long TC. Increasing the TC mainly does two things: The contribution of each measurement gets smaller, and the correction steps are becoming smaller and less frequent. The downside is that the control loop will be unable to compensate for environmental upsets. If you have a smaller measurement uncertainty, you can go for shorter TC without sacrificing performance.

In my own GPSDO, I typically run with a TC of 500 or so and my frequency offset over 500 seconds is in the tens of nano-Hz territory.

[Dbldutch]

The following graph is also on my Blog.
Here is a small sample of the combination or raw_ns, qErr and the resulting (new) ns.

The qErr values are always in the +/- 10ns range, the raw_ns excursions are larger so there is not a complete correction.

I found that the raw_ns excursions are also a factor of the OCXO stability, they are not only GNSS related.
I just switched from a CTI OC5SC25 to an IsoTemp 143-141 OCXO to see what is different.

BTW, I'm also running with a TC of 500 and gain of at least that amount so that I have small PPM/changes per PWM bit.

[MIS42N]

A place to look for sawtooth type behaviour is the DAC. The sensitivity of an OSC5A2B02 is around 0.1V/Hz. A 16 bit 5V DAC delivers around 1300 steps for 0.1V. So the frequency is varied in steps of 0.8mHz. The system will flip between 2 DAC values to keep the average frequency accurate. The problem is less with better OCXO, they have a smaller pulling range.

[Dbldutch]

The voltage output range of the DAC can be greatly reduced by using only three resistors.
Two to "clamp" the output to the sweet-spot of the OCXO and a third series resistor to reduce the DAC output voltage effect.

So instead of having a DAC where the output ranges from 0..5V, you can create an output that only moves say +/- 100 mV around the sweet-spot over the full 16-bit range.
Of course that's also how you can get to very high gains.

[MIS42N]

The voltage output range of the DAC can be greatly reduced by using only three resistors.
Two to "clamp" the output to the sweet-spot of the OCXO and a third series resistor to reduce the DAC output voltage effect.

So instead of having a DAC where the output ranges from 0..5V, you can create an output that only moves say +/- 100 mV around the sweet-spot over the full 16-bit range.
Of course that's also how you can get to very high gains.

True. There are a few designs I've seen with a coarse adjustment like that. Just means you have to manually adjust around the sweet spot. I was just offering another place to look for sawtooth behaviour.

I avoided the problem by synthesising the equivalent of a 24-bit DAC.

[Solder_Junkie]

I am about to make a GPSDO based on the design by Lars. I have a query about the 4046 “Tic” circuit.
This version by Murray Greenman differs from the Lars one, plus it has a duplicate pin 10 and just looks wrong with additional grounding (grounding pin 10, an output).
https://www.qsl.net/zl1bpu/PROJ/NGPSDO/TIC.htm

I guess there is nothing much wrong with the Lars version.

Your thoughts are appreciated.

SJ

[AndrewBCN]

I am about to make a GPSDO based on the design by Lars. I have a query about the 4046 “Tic” circuit.
This version by Murray Greenman differs from the Lars one, plus it has a duplicate pin 10 and just looks wrong with additional grounding (grounding pin 10, an output).
https://www.qsl.net/zl1bpu/PROJ/NGPSDO/TIC.htm

I guess there is nothing much wrong with the Lars version.

Your thoughts are appreciated.

SJ

Hi, I can assure you the TIC 4046  circuit as originally designed by Lars works fine, so you can follow Lars´ schematic and you'll have zero problems. Another variant of the TIC circuit that uses a simple 74HC74 flip-flop (which is slightly easier to obtain, compared to the 74HC4046) was designed by Erik Kaashoek, also works fine. And you can also replace the Schottky diode with a 1N4148.

[Solder_Junkie]

Thanks Andrew, there are a few changes to the circuit by Murray and anyone who uses his Arduino code (the display version) may also wonder why there is reference to an Si5351 synth in the code...

Sadly we can't ask Murray, as it appears he has also died, SK is amateur radio speak for "silent key" (Morse key). See:
https://www.nzart.org.nz/news/break-in/break-in-awards

SJ

[thinkfat]

I am about to make a GPSDO based on the design by Lars. I have a query about the 4046 “Tic” circuit.
This version by Murray Greenman differs from the Lars one, plus it has a duplicate pin 10 and just looks wrong with additional grounding (grounding pin 10, an output).
https://www.qsl.net/zl1bpu/PROJ/NGPSDO/TIC.htm

I guess there is nothing much wrong with the Lars version.

Your thoughts are appreciated.

SJ

Moreover, pin 10 is connected to both +5V and GND, which makes no sense at all. I guess pin 5 was meant to be connected to +5V to turn off the demodulator and vco and pin 10 was meant to be NC. The circuit is then pretty much identical to Lars'. However, pin 9 it not an output and therefore doesn't look right to me either. Obviously, one of the phase comparators was meant to be connected to the sample/hold circuit.