Lars DIY GPSDO with Arduino and 1ns resolution TIC

[iMo]

With aging the required OCXO's control voltage may drift off the limits (thus the control voltage level is a good indicator of the OCXO's state).. For example with 7V ref voltage the voltage for 10MHz with new OCXO could be somewhere around 3.5V, after years of aging it drops to, for example, 1.2V - that could be too low for the internal circuits to regulate properly.
Also some OCXOs need weeks to settle after long power off, afaik.

[W3AXL]

Also some OCXOs need weeks to settle after long power off, afaik.

Seems you were spot on with this point. Here's 6 days of running. It's super satisfying to see a real-world asymptotic curve.

[0xFFF0]

Do you have no thermal influences at all? You only need to open the window for a moment, then the curve drifts away. Sure, over a long period of time, almost every series of measurements tends towards zero.

[JOFlaherty]

I built this project this week, only to discover that I don't have a 4046 with the right phase detector. I ordered some from Mouser, but North Texas is frozen over, so I found some old chips in a drawer, and they work alright in place of the 4046. They even leave a JK flip flop and a couple of gates left over: 

[0xFFF0]

chatgpt:

A replacement for the 4046 PLL would depend on the specific requirements of the application. Some newer PLL integrated circuits that are compatible with the 4046 PLL and can be used as replacements include:

    74HC4046: This is a modern CMOS version of the 4046 PLL that offers improved performance and lower power consumption.

    LMX2594: This is a high-performance, wideband PLL with integrated VCO that offers improved phase noise and frequency stability.

    ADF4351: This is a wideband PLL and frequency synthesizer that can generate output frequencies from 35 MHz to 4400 MHz.

It's important to note that these are just a few examples and that the best replacement for the 4046 PLL will depend on the specific requirements of the application. It's always a good idea to carefully review the datasheets for the PLLs being considered to ensure that they meet the requirements of the application.

[JOFlaherty]

The ones I used work well enough, given the "Locked" indication, at least until my Mouser order with the 74HC4046's  gets here.

[Dbldutch]

Thanks for posting the alternative chips and circuits.

Here is another replacement circuit that I'm going to try myself.
It's using a 74HC74 FF.

https://github.com/erikkaashoek/Arduino_SI5351_GPSDO

[Dbldutch]

I tried the 7474 replacement today, and it works great. I tried all the variations I had in stock, the 7474, the 74F74, the 74LS74, the 74AHC74 and the 74HC74.

[N4OGW]

Here's another variant of the Lars GPSDO. I ported it to PIC (PIC18F27Q84). My approach has one main difference: instead of using external ICs (4046 and HC390) to divide the 10 MHz to 1MHz and measure the phase difference, I implemented those functions using PIC Configurable Logic Cells (CLC). The divide by 10 is made up with 4 CLC flip-flops, and the phase detector using 2 CLC flip flops. This seems to work really well.

https://github.com/n4ogw/n4ogw-gpsdo

BTW thanks for all the information posted in this thread, it helped me a lot!

[MIS42N]

Here's another variant of the Lars GPSDO. I ported it to PIC (PIC18F27Q84). My approach has one main difference: instead of using external ICs (4046 and HC390) to divide the 10 MHz to 1MHz and measure the phase difference, I implemented those functions using PIC Configurable Logic Cells (CLC). The divide by 10 is made up with 4 CLC flip-flops, and the phase detector using 2 CLC flip flops. This seems to work really well.

Nice. Could you add a picture of the KiCad schematic, saves unpacking etc. I did it for my GPSDO (also PIC based) https://github.com/ajcashin/budget-gpsdo

[N4OGW]

Sure- I put a copy of the schematic in the kicad directory.

[Dbldutch]

Unfortunately, I must come back on my earlier report that all versions of the 7474 replacement circuit for the 4046 works well.
The SN74AHC74 doesn't.

While researching other phase detection measurements, I noticed a strange behavior with the 7474. To investigate it further, I breadboarded the 74AHC74 circuit next to a 74HC4046 and fed them both with my GPSDO 10Mhz and 1PPS signals, and observed both outputs on my DSO.

The pictures show the problem. Normally, both circuits are in agreement and follow each other through the NEO sawtooth cycle.
Several times per minute though, the SN74AHC74 circuit produces a glitch. Some times just one, sometimes several in succesion during the sawtooth cycle, and then reverts back to following the 4046.

Also the SN74HC74 has the same problem and also a "normal and old" SN7474NV.
I also tried a much slower 74LS74 or even a 74F74, same problem.

I reported it to the inventor, Erik Kaashoek on his Github, but is there anybody else here that can shed some light on this behavior?

[N4OGW]

If you are feeding 10 MHz directly into the circuit, then the first image might actually be ok. At 10 MHz the maximum phase difference is 100 ns. If the actual phase difference is very close to 100 ns, one circuit might show a pulse of ~100 ns, and the other a very short pulse. The actual phase error between the two would be very small even though they look very different on the scope.

I'm using the same flip-flop circuit in my PIC version, except the flip-flops are implemented in PIC CLC logic. Although I never compared to a 4046, as far as I can tell it works well. I did the test described by Lars of feeding the pps using a picdiv which can phase shift by 400 ns- I get that shift within a few ns.

[Dbldutch]

Good hunch.
When I was testing older 7474 technologies (7474, LS and even F), they could not handle the "glitch", it is too low in amplitude.
Not surprizingly, this means that only the fasttest and newer technologies can be used with a 10MHz signal.
In most applications I've seen, including Lars' design of course, the 10Mhz is divided down to get a 1MHz input frequency, so that may not show the problem.

[LADmachining]

Here's another variant of the Lars GPSDO. I ported it to PIC (PIC18F27Q84). My approach has one main difference: instead of using external ICs (4046 and HC390) to divide the 10 MHz to 1MHz and measure the phase difference, I implemented those functions using PIC Configurable Logic Cells (CLC). The divide by 10 is made up with 4 CLC flip-flops, and the phase detector using 2 CLC flip flops. This seems to work really well.

https://github.com/n4ogw/n4ogw-gpsdo

BTW thanks for all the information posted in this thread, it helped me a lot!

Thank you for sharing this design with us!

Would it be possible for you to put a copy of the hex file for the PIC in your Github?  I am getting odd results from the circuit that I think may be down to the hex file I am producing from MPLAB.

The first version of the MPLAB project I compiled in February '23 resulted in a load of odd characters on the LCD and serial output that the terminal program could make no sense of.  I then compiled the Apr '23 update and that doesn't seem to do anything at all - no activity on the LCD data lines or serial output.

Thanks,

Anthony

[FVCTVP]

Hi everyone,
I know it's been a long time since this post was made, but after reading some pages, I still have a question about the timer_us variable calculation on the SW.
There is an explanation about it:

timer_us = timer_us + 50000 -

(((timer1CounterValue - timer1CounterValueOld) * 200 + TIC_Value - TIC_ValueOld)  >>>  those are in 200ns timer1C_ increments (OCXO/2) and you add TIC_V diff value (TIC is the voltage measured by the ADC from 4046+diode+3.9k+1nF) in nanoseconds  to it thus everything is in nanoseconds now

+50000500)/1000;  >> you add 50000500 because you do modulo 50000 and you want to round properly (xxx.500) and finally you divide all by thousands to get microseconds

You do modulo 50000 therefore (an example)

timer_us = timer_us + 50000 - (((1)*200 + 530 - 490) + 50000500)/1000 = timer_us + 50000 - ((200+40) + 50000500)/1000 = timer_us + 50000 - (50000740)/1000 = timer_us + 50000 - 50000 = timer_us +  0    >>> no change as the 1PPS came within 1usec.. (or better to say: the OCXO's freq at this moment is such thus it fits into 1PSS +/-0.5us).

But what does "modulo 50000" means? Sorry if it is a stupid question, I'm a HW guy with limited SW knowledge.
Thank you very much in advance!

[iMo]

OMG, it is 5 years old explanation, but I'll try - I think iMo wanted to say the values used in that math were always max 50000, even though a value off the timer registers is 16bit or max 65535, therefore the term "modulo 50000".

PS: for example a counter in "modulo 5" means it counts 0,1,2,3,4,0,1,2,3,4,0,1,2.. - the counter wraps around when it reaches the "modulus" 5.

[MIS42N]

But what does "modulo 50000" means? Sorry if it is a stupid question, I'm a HW guy with limited SW knowledge.
Thank you very much in advance!

modulo 50000 means the remainder when the number is divided by 50000.
e.g. 98765 divided by 50000 is 1 remainder 48765. So 98765 modulo 50000 is 48765
modulo is shorthand for 'remainder when divided by'. There's probably some much more esoteric meaning in mathematics, but this explanation works for me.

[FVCTVP]

OMG, it is 5 years old explanation, but I'll try - I think iMo wanted to say the values used in that math were always max 50000, even though a value off the timer registers is 16bit or max 65535, therefore the term "modulo 50000".

PS: for example a counter in "modulo 5" means it counts 0,1,2,3,4,0,1,2,3,4,0,1,2.. - the counter wraps around when it reaches the "modulus" 5.

Thank you very Much iMo, and you're right talking to you in third person as a 5-year-old answer is like another person's answer 

So, please correct me if I'm wrong, as I'm trying to understand Lars code, and it seems this line is one of the most important:

Code: [Select]

Timer_us = timer_us + 50000 - (((timer1CounterValue - timer1CounterValueOld) * 200 + TIC_Value - TIC_ValueOld)+50000500)/1000;

- The TIC_Value, if I understand correctly, measures time difference (in nanoseconds) between PPS rising edge and 1MHz rising edge. This is done by knowing the RC ramp behavior, measuring the voltage and hence estimating the time (time_diff_ns = ADC_read * 1ns/bit). So, if the ADC reads 500 and the old read was 450, that means 50ns off time difference

- The timer1CounterValue is what I do not understand. If timer1CounterValue - timer1CounterValueOld = 5, it means that there has been 100 overflows of 10ms and 5 additional counts? (which means the 5MHz signal counted 5million pulses 1us before the PPS).

With that said. Let's put an example:
Timer1CounterValueOld = 5
Timer1CounterValue=49995 (because the 5MHz signal goes slower than PPS). Without going to the formula, this means a difference of 10 pulses (10*200ns = 2us difference).

Supposing that TIC_Value-TIC_ValueOld = 0 (to simplify the example), let's go to the formula:

Timer_us = 50000 - (((49995 - 5) * 200) + 50000500)/1000;
Timer_us = 50000 - ((49990 * 200) + 50000500)/1000;
Timer_us = 50000 - ((49990 * 200) + 50000500)/1000;
Timer_us = 50000 - (9998000 + 50000500)/1000
Timer_us = 50000 - 59998500/1000
Timer_us = 50000 - 59998
Timer_us = -9998

Maybe I have done something wrong on this example, because I do not understand the actual/physical meaning of this timer_us variable.

Thank you again, I know this topic is very old 

[iMo]

As I can remember the key message here is the control loop works such it tries to keep the edges phase difference such it always points to the 500ns at the "RC ramp". The RC ramp starts at 0ns and ends at 1000ns (0V..5V aprox), the mid of the RC slope is at 500ns (or 2.5V aprox).

That is the ADC's input voltage, measured by the 10bit ADC, that is 1024 values from 0-1000ns (from 0 to 5V), that means 1ns TIC resolution aprox.

So when there is stable phase difference (I am not sure whether 0deg or not) between the edges the RC ramp voltage should point at 500ns or "into the middle of the ramp" and the ADC reads 511 (ideally). System loop adjusts the DAC voltage (the tuning voltage of the OCXO) such you are always close to the mid of the RC slope (around those 500ns).

When there are frequency fluctuations the phase shift between the edges jitters and that jitter means the voltage at the RC slope jitters around its middle - around the 500ns or 2.5V.

The result of all that math has to consider that principle - the max deviation from the middle (the middle being at those "500ns" at the RC slope) has to be less than +/-500ns - only then it fits into the regulation loop as the phase diff stays on the RC slope (the slope is from 0-1000ns aprox). When it is larger, it "jumps" into the adjacent usecond.

Mind you are always within the RC slope, even you are XXXusecs off, therefore the timer_us value must be 0 when all works as intended (the OCXO freqs is locked). Simply the total phase diff is "timer_us+/-(0..500ns from ADC)".

Otherwise it perhaps adjusts the DAC tuning slope such you get the phase diff much faster towards the 0 usecs. You have to doublecheck how it is used in the source..

Disclaimer: no warranties of any kind provided

[Dbldutch]

Old topic indeed, but it shows that we may not yet fully understand what Lars did with the code in his sketch.

BTW, Lars uses the 1.1V reference for the ADC so the mid-point of the ramp at 512 bits is at about 550mV, as the DSO screenshots in one of the above posts shows. (I can't verify that at the moment, but that's what I remember)

I don't mind instrumenting the sketch so we can better track what is going on, but that will have to wait until the second half of the month because I'm currently on vacation.

 

[FVCTVP]

Agree, specially for those who are not very skilled on SW (me), there are a lot of tricky parts on the code.
Thank you for the explanation iMo.
Yes, as Lars documented, he used 1.1V maximum voltage input to obtain a more linear response (the RC circuit values are calculated to charge until that voltage).
Dbldutch that would be an priceless effort if you finally decide do it. Keep us updated

I'm also considering an alternative design using a Time-to-Digital Converter (TDC7200) as I have seen many people here that have implemented it successfully.

Thank you both for the answers.

[thinkfat]

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

[Dbldutch]

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.

[Dbldutch]

Regarding a sawtooth example, no volunteers as yet so I started a little research project myself.

Here's an explanation I found while researching this topic. source:https://www.efos3.com/GPSDO/GPSDO.html

Sawtooth error.
The GPS receiver contains a CPU that is clocked from a crystal somewhere[1]. When time comes to output a pulse, the CPU must chose a clock edge of the incoming clock signal on which to go from low to high on the output pin — theres no [sic] magic gates that can toggle up and down independently of the clock signal, that is just a fact of digital processors.

More often than not, the PPS out will not occur precisely at the time the CPU thinks the second starts, it will start on the closest clock edge, which can be off by up to half the period of the clock frequency of the receiver, ballpark 20-50 nanoseconds. However, the CPU will know "how wrong it is", and many modules will output a message with that information. This is what's known as "sawtooth correction". So if the PPS out from the GPS differs in time from the PPS from the OCXO by 623 picoseconds, and the GPS reports an error of 211 picoseconds, we can correct the reading and use the resulting 412 ps in our disciplining loop. Another option is to simply ignore the error — we want the time constant of the disciplining loop to be as long as possible, and over time the sawtooth error will simply average out. This is a short term error that is relatively easy to deal with.

The correction -might- be "relatively easy", but there are caveats as shown here: http://www.leapsecond.com/pages/m12/sawtooth.htm
Some more information using a hardware solution is here, read pages 23-28 : https://ivscc.gsfc.nasa.gov/meetings/tow2013/Clark.Sem.pdf
Here is a link to an article that shows a solution from a scientific view: https://www.researchgate.net/publication/3262481_An_unbiased_FIR_filter_for_TIE_model_of_a_local_clock_in_applications_to_GPS-based_timekeeping/download

The following quote is from Nick Sayer, who implemented a look-alike Lars GPSDO and sells it commercially, at least he did a number of years ago.

My code sets the averaging window for the phase to the PI time constant divided by 4. This averages out the PPS jitter, but some GPS modules have a phenomenon called a "hanging bridge." See http://www.leapsecond.com/pages/m12/sawtooth.htm for an example. A hanging bridge can cause the averaging to be incorrect. Virtually all modules have PPS jitter because the microcontroller clock doesn't stay in phase with UTC, but it's only when the phase rate-of-change changes sign and the phase angle remains constant second-to-second for some period of time that there's trouble. Some GPS module select fractional controller clock frequencies to make *sure* that the phase rate of change never approaches zero for this reason. They don't have a problem because if you average the phase errors, they'll center around the actual value.

Timing modules will often provide you with a quantization error correction message. You take the observed PPS phase error and adjust it by the value of the quantization error. That gives you the actual phase error to the true UTC second. Hanging bridges and averaging are completely mooted by that.

Italics are mine.

The quantization error solution was already described a few pages up (#43) by UR8US. I'm going to try that myself soon.

It seems that with that qErr inclusion, there is no need for an additional sawtooth correction, or is there?