Lars DIY GPSDO with Arduino and 1ns resolution TIC

[KA8BRK]

I have tried three different Nano's, similar problems with all.
Are all of my Nano's and the Uno I tried bad?

Actually all three Nano's are bad!  They probably have fake atmega328P chips as discussed in this thread:
"https://www.eevblog.com/forum/manufacture/atmega328p-woes-from-jlcpcb-smt-order/"
and elsewhere.
I replaced the Nano with another (removed from a different working project) and my GPSDO now seems
to work as it should.  Has run for about 40 hours without losing lock.  Thank you Lars.
The same chip is used on the pro mini and there are reports of similar problems with some of them as well.

Ding, KA8BRK
 

[salomonsk8r2003]

Actually all three Nano's are bad! 

Oh dang, that sucks! Sorry to hear you got some duds. Where did you order them from?

If it helps, here is the link to where I got my Pro Mini's and my FTDI as well:
https://smile.amazon.com/gp/product/B004G53J5I/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
https://smile.amazon.com/gp/product/B00IJXZQ7C/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

I got two of those Pro Mini's and they work great. They seem to be authentic as far as I can tell. I didn't investigate them TOO much though because they looked legit and worked fine so I didn't dig deep. I think they are authentic though. They came with SparkFun's little warranty card too and their "thank you" note which I know comes in their authentic products. If you (or anyone else) is wanted to order from that link and you know of a more in-depth authenticity check for the Pro Mini with 328P, let me know, I would be happy to run the test on mine and make sure they are authentic before you buy some.

[KA8BRK]

Oh dang, that sucks! Sorry to hear you got some duds. Where did you order them from?

Really, really sucks.  This has cost me countless hours of hair pulling over about five or six weeks of calendar time.
These were purchased on Ebay from seller 'allamandi'.  Purchased in early January, so beyond warranty time.
I suspect the seller got scammed by his vendor.  Perhaps same vendor referenced in the link about the problems.
I see that other sellers on Ebay are also selling similar looking units.  Buyer beware.
I should have remembered, "If the price seems to good to be true, it probably is."
Did order two more Nano's that appear to be genuine and in sealed, real Arduino boxes.  Bet they will work.
Would be very suspicious of anything using the atmega328 that was manufactured since at least the start of 2022.
Neither Mouser or Digikey have them in stock, and they have many on order.

Ding, KA8BRK
 

[salomonsk8r2003]

Yeah eBay is always quite a hit or miss. I think I lucked out on my last coupled purchases there but I have been bit before. My 10Mhz oscillator I got on there works pretty good! And I got my HC390 and HC4046 chips on there too just for this project. One was a 3-pack and had a single chip with badly bent pins, so I messaged them and they sent me a whole new 3-pack! And the chip was still useable, I was just messaging them to tell them they should put more foam on the pins, but they sent them anyways, so I guess not all are bad sellers.

Did order two more Nano's

May I ask, is there a reason why you are using the Nano's for this project instead of the Pro Mini?

[KA8BRK]

May I ask, is there a reason why you are using the Nano's for this project instead of the Pro Mini?

I just like having the USB / serial connection on the board.  Easier to use to me, especially when testing.

I have had pretty good experiences on Ebay.  Have only had a few bad experiences and the sellers
or Ebay made things right.  Can't really fault the seller of the flaky Nano's too much except he does not
seem to want to admit that the chips are probably fake and that he got scammed.  Plausible deniability??

Ding, KA8BRK

[KA8BRK]

Has anyone else looked at the code behind the status words that are serial printed after the three hour averages?
I am using the 'lars_gpsdo_30_170801.ino' sketch.
The serial print code is located at lines 1017-1037.  The status word for the first (0th) three hour average is based
on the values in EEPROM locations 576 and 720 (see line 1006) and on the value of variable
'temperature_Sensor_Type' (see line 1009).  The values stored in EEPROM locations 576 and 720 is based on the
variable 'sumTemp2' (see lines 398 and 399).
I do not understand what temperature has to do with the 'locked', 'restarted', etc. status.
I think this is a mistake.  I have not seen this discussed elsewhere.   
Am I missing something?
Are there other versions of Lars' code out there that may have revisions?

Ding, KA8BRK

[AndrewBCN]

...
I do not understand what temperature has to do with the 'locked', 'restarted', etc. status.
I think this is a mistake.  I have not seen this discussed elsewhere.   
Am I missing something?

I'll take a look at that when I have some spare time... but that could take a while. 
But in principle, the temperature readings from one of the thermistors are only used to adjust very slightly the DAC values, they should not have any further use than that (to the best of my knowledge).
This is the line of code that applies this adjustment:

Code: [Select]

dacValueWithTempComp = dacValue2 + ((tempRef * 100 - tempADC2_Filtered) * tempCoeff / 10000 * timeConst);
Note that you can build a Lars' DIY GPSDO without thermistors and it will still work fine.

Are there other versions of Lars' code out there that may have revisions?
...

No, Lars has only ever published a single revision of his code (as far as I know) and there have been no significant changes to his code base (again, as far as I know). From Lars before he unfortunately passed away:

...
One question is if I have an updated software and the answer is no. Actually I have not found or heard of any bug so severe that I have had a reason to do any changes. I have a long list of improvements but as testing is so important I would like to have a very good reason to do changes.
...
Lars

[AndrewBCN]

Hello,

I finally finished wiring my build of Lars' DIY GPSDO on a breadboard using an Arduino Uno clone. I turned it on a couple of hours ago, set the gain to 100 and am waiting now for the "Lock" status LED to come on. The TIC has not yet stabilized at 550mV or so.

Attached is a picture of the breadboard + Uno setup, and my humble 2ch DSO showing the 1PPS rising edge in yellow and the TIC capacitor (goes to ADC0 on the AVR MCU) charging.



There are two obvious problems with my build that are immediately visible on the DSO screenshot:

• Noise and ringing, which is more or less expected on this kind of circuit on a breadboard.
• The TIC is offset by approximately 200mV and there is a ton of noise at the AVR ADC input, meaning the input sometimes exceeds the 1.1V range of the ADC; Lars' software interprets this as a "missing 10MHz", but the 10MHz is very much there.

[AndrewBCN]

Well, since I wasn't getting a lock after more than 6 hours, I decided to try two things:

• I doubled the ground connection between the Uno and the breadboard.
• I replaced the 1N5711 Schottky diode in the TIC with a 1N4148 small signal fast switching diode. The assumption here is that this would prevent the voltage to the AVR ADC from exceeding 1.1V, since the 1N4148 has a larger forward voltage drop (around 0.7V) compared to the Schottky diode (around 0.25V). In his PDF Lars explained that he tried a 1N4148.

I powered Lars' DIY GPSDO back on and got a "lock" within 10 minutes! And the DSO shows the TIC voltage rather stable at ~550mV (meaning the PLL is working fine). I am very impressed!

[thinkfat]

A better ground connection certainly helps, but instead of the 1N4148, you could try choosing a larger resistor. Ideally, you want a low voltage drop and a small leakage current.

[AndrewBCN]

A better ground connection certainly helps, but instead of the 1N4148, you could try choosing a larger resistor. Ideally, you want a low voltage drop and a small leakage current.

Thank for the tip!
I thought about replacing the 39k resistor with a 47k resistor and I think that would work too (to prevent the voltage across the capacitor from exceeding 1.1V), but I noticed that Lars has experimented with the 1N4148, so I decided to try replacing the diode first, and it worked.

But I might try the 47k resistor + 1N5711 Schottky diode combination. Actually I have a list of things I want to try:

1. Set my DSO probes to 1x (they are set to 10x right now) and see if this cleans up some of the noise.

2. Replace the 74HC4046 with a 74HC74 following the brilliant idea by Erik Kaashoek (erika in this forum).

3. Configure the thermistor and check if that makes any difference at all.

4. Adding a few extra status diodes and even perhaps a display of some kind. That would of course mean I would have to work on Lars' code, something I have avoided until now.

[KA8BRK]

I finally finished wiring my build of Lars' DIY GPSDO on a breadboard using an Arduino Uno clone.

I would be first suspicious of the Uno clone.  I have tested multiple different Nano's and one of my Uno clones.
Two of my Nano's are 'genuine", four others are clones.
They have different levels of DC offset at A0 varying from near zero to about 250 millivolts according to my old scope.
The two 'genuine' ones show 150 and 200+ millivolts offset.  Two of the clones show near zero, the other two over 150.
So much for 'genuine'.  I wonder if there is really a spec for this??
The Nano clone that seems to work best has almost 200 millivolts offset.  Maybe the offset is not causing the no lock..
Suggest you try checking the offset with PPS disconnected.  Perhaps with just a large resistor to ground and 'Blink'.
Probably should look at my earlier post about fake chips, as it looks like your Uno could be using the same style 328P
as my clone Nano's.  I read somewhere that one of biggest problems with the bootleg chips has to so with the analog inputs.

All of this makes me wonder if there is not at least a little bit of luck involved in getting a Lars GPSDO to work.

Ding, KA8BRK

[AndrewBCN]

[I would be first suspicious of the Uno clone.  I have tested multiple different Nano's and one of my Uno clones.
Two of my Nano's are 'genuine", four others are clones.
They have different levels of DC offset at A0 varying from near zero to about 250 millivolts according to my old scope.
The two 'genuine' ones show 150 and 200+ millivolts offset.  Two of the clones show near zero, the other two over 150.
So much for 'genuine'.  I wonder if there is really a spec for this??
The Nano clone that seems to work best has almost 200 millivolts offset.  Maybe the offset is not causing the no lock..
Suggest you try checking the offset with PPS disconnected.  Perhaps with just a large resistor to ground and 'Blink'.
Probably should look at my earlier post about fake chips, as it looks like your Uno could be using the same style 328P
as my clone Nano's.  I read somewhere that one of biggest problems with the bootleg chips has to so with the analog inputs.

Thank you KA8BRK, for the information about the possibly fake or reject AVR chips in these clones. Definitely the approx. 250mV DC offset at the ADC input looks suspicious, and it does cause problems, as my personal experience shows. Perhaps that was the source of your problems too?

If you check Lars' code, you'll notice that he inserts a "dummy read" in between ADC readings:

Code: [Select]

// read ADC1 and 2 - temperature
  int dummyreadADC = analogRead(A1); //without this ADC1 is influenced by ADC0
  tempADC1 = analogRead(A1);
  dummyreadADC = analogRead(A2); //without this ADC2 is influenced by ADC1
  tempADC2 = analogRead(A2);
  dummyreadADC = analogRead(A0); //without this TIC_Value (ADC0) is influenced by ADC2

which is really a waste of CPU cycles. What is this "influence" ? Unfortunately Lars is not among us anymore to answer this kind of questions.

EDIT: I found a thread on the Arduino forum that deals with this issue: https://forum.arduino.cc/t/is-reading-and-discarding-first-read-value-still-required-for-analogread/548741/2

It seems this is a problem inherent to the AVR chip ADC. 

All of this makes me wonder if there is not at least a little bit of luck involved in getting a Lars GPSDO to work.

Indeed there is certainly some degree of tinkering required in some cases, and also possibly some room for improvements to the code and documentation. That is one of the reasons I created a repository for Lars' DIY GPSDO on GitHub, here: https://github.com/AndrewBCN/Lars-DIY-GPSDO

[AndrewBCN]

I have replaced the 74HC4046 part of the TIC with a 74HC74 configuration designed by Erik Kaashoek (see: https://github.com/erikkaashoek/Arduino_SI5351_GPSDO ) and Lars' DIY GPSDO is still working fine. So the BOM for my build of Lars's DIY GPSDO is slightly simplified from the original:

• 1N5711 replaced with 1N4148.
• 74HC4046 replaced with 74HC74.

I have also set my DSO probes from 10x to 1x and that changes everything in terms of noise. Also the DC offset of the ADC input is now around 180mV, down from 250mV previously.

[KA8BRK]

I do not understand what temperature has to do with the 'locked', 'restarted', etc. status.
I think this is a mistake.  I have not seen this discussed elsewhere.   
Am I missing something?

Yes, I was missing something.  Lars used a subtle method of reusing a variable that was
not obvious to me when I first started looking at his program.  I get it now.

Ding, KA8BRK

[UR8US]

Hello,

Some time ago I built my own copy of Lars' GPSDO. It was operating just fine, but I decided to add an ability to read the qErr parameter out of UBLOX receivers. As a result, the phase jitter from the GPS module was attenuated about 10 times. In my version, this was done via I2C. Tested with NEO 6N, 8N, 8T modules.

I am attaching a modified source code to this message, for those who are interested (please rename .TXT to .INO). Changes are marked with "// DN" comment lines.

[UR8US]

[UR8US]

[thinkfat]

That looks really very nice. Note also - this effectively eliminates the need for the TIC pre-filter in Lars' software. It was needed for anti-aliasing the time pulse, but the quantization correction achieves the same much better and without slowing down the regulation.

[UR8US]

Yes, sure! But also the qErr is not a random value. It may show wierd patterns depending on GPS module type (8N or 8T), and also on the exact frequency of the module's oscillator. When I head the module, the pattern changes.

Unfortunately, there may be DC jumps, and I am afraid they may only be filtered by using a very long time constant. The blue track is an output of the TIC. Horizontal: seconds, vertical: nanoseconds.

[AndrewBCN]

Yes, sure! But also the qErr is not a random value. It may show wierd patterns depending on GPS module type (8N or 8T), and also on the exact frequency of the module's oscillator. When I head the module, the pattern changes.

Unfortunately, there may be DC jumps, and I am afraid they may only be filtered by using a very long time constant. The blue track is an output of the TIC. Horizontal: seconds, vertical: nanoseconds.

(Attachment Link)

Very interesting and an outstanding addition to Lars' original firmware. With essentially zero cost in hardware or complexity, you have improved the performance of Lars' TIC by approximately an order of magnitude for tau < 1000s. 

I think finding the optimal time constant is more of a function of matching the intersection of the OCXO and PPS ADEV curves rather than trying to find ways to deal with the jitter in the TIC readings.

For the cheap OCXOs we use in DIY GPSDOs, this intersection is usually around tau=500s to 1000s so we would gain very little or nothing by using a shorter time constant.

[thinkfat]

"Andersrum wird ein Schuh draus".

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. That's a big advantage especially with OCXOs with unknown history. You can also design a control loop that is more responsive to external influence like temperature, air pressure, OCXO misbehavior etc, without actually modeling these external sources (which can be tricky).

Using a PI regulator like in Lars software, think of Kp as its ability to respond to transients and Ki as the maximum aging speed of the OCXO it can follow. A small Ki means you need an OCXO that ages slowly. A noisy phase measurement requires a small Kp, a looser coupling to the reference.

A zero-cost addition that improves the input uncertainty by a magnitude is nothing I'd just write off as irrelevant.

[UR8US]

Thank you, guys.

I believe, both of two points of view make sense. I should only notice that the qErr is not a white noise (but sometimes is having both periodic and DC components), and also the PI-filter does not eliminate the noise generated by DAC and power supply.

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.

As for the built-in TIC, I think we are missing the ability to measure ADEV at 0.01, - or - at least, at 0.1 seconds, since we can only get 1pps as a reliable, lowest-noise output of a GPS receiver. In addition, it is obvious that ADEV plotted from the built-in TIC, does not fully characterize the output signal of the GPSDO.

For the experiments, I built a stand-alone TIC, based on TDC7200 and Arduino M0. This is a home-brew analog of famous PIC TIC and TAPR TICC devices.  I will publish all the details in the next message of this topic.

Of course, noise from ADC and power supply should also be studied. It is a good idea to use QO-100 or other sat's beacons to see the quality of the GPSDO's signal just on your screen, simply because thing invisible at 10 MHz become visible at 10 GHz. :-) It looks like the sats are ideal low-cost sources of high-quality 10 GHz signal. As many people successfully use RTL-SDRs and $3-$5 LNBs to receive signals from QO-100, the only task was to synchronize _all_ PLLs to the same 10 MHz output of the GPSDO. I experimented with several types of RTL-SDRs, Pluto and Lime SDR, and also with LNBs taking 24 or 25 MHz as an external clock (it looked like RTL-SDR is sufficient for many experiments).

To convert 10 MHz to a number of other frequencies, such as 28.8, 40, 31.25, 24 and 25 MHz, I developed a simple SI5338-based, Arduino-controlled device with 4 independent outputs. This setup (frequency converter + LNB + RTL-SDR) was very sensitive and was very good to compare several different GPSDOs.  Also, it is much more pleasant to look at a live trace on the waterfall of the SDR, than to stare to the still ADEV graph. :-) I will also describe the details in next messages here.


   

[UR8US]

Here is my version of the stand-alone, TDC7200 and Arduino M0 based TIC. This devices compares two inputs of 10 MHz, sending data to TimeLab.

TDC Click comes from mikroe.com , and the Arduino M0 comes from AliExpress.

PIC12F629 is carrying a PICDIV PD16 firmware, to generate 1 or 10 or 100 Hz our of 10 MHz. The output of the PICDIV is connected to the START input of the TDC Click.

74HC390 divides 10 MHz by 10 and again by 10 to get 1 MHz and 100 kHz, one of these signals is fed into the STOP input of the TDC click.

I am attaching a ZIP file with source code and other useful info. We will need the more powerful SAMD21 MCU instead of the ATMEGA328 just for the larger data throughput to be able to produce 10 or 100 outputs per second (ADEV at 0.1 or 0.01 sec).

8 MHz (own TCXO), connected to both inputs, was used to test the resolution. Unfortunately, I could only get about 125 ps instead of 50-55 ps (as they promise in the datasheet) - most likely, because of a poor PCB construction. Or, is it some dumb error in the software?

Interesting: thanks to Mode 2 and Multi-stops feature of the TDC7200,  we do not need extra hardware to deal with a case when the phase difference of the two input signals is zero.

[UR8US]

The images for the above message:



The input frequency for testing was 8 MHz, in fact.

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

Some more tests are needed.


Correction: it looks like I need to count 55 picoseconds (resolution of the TDC7200) twice, since the ring oscillator is used twice in Measurement Mode 2.