Lars DIY GPSDO with Arduino and 1ns resolution TIC

[W3AXL]

I'm thinking what might be going wrong with my setup is the AREF of 5.2V. I'm assuming once the voltage of the TIC gets low enough, there's too much noise in the ADC at those low levels and the PI loop can't reliably control things.

My diff_ns has plenty of jitter in it, with big outlier values popping up every 8 seconds or so. Thinking I may need to pull the MCU and cut that AREF trace to get things working again (assuming I didn't blow the internal 2.56V reference voltage by having it connected originally)

[W3AXL]

Okay, pulled AREF off and it's now using the internal 2.56V reference. Things are better, but I still have some issues.

I'm still seeing big jumps of several hundred ns in my TIC/diff_ns values every so often. These throw off the control loop pretty badly and prevent it from stabilizing at +/- 100ns and locking.

Code: [Select]

794 -124 41704 31.5 NoLock 7 3720 32 1 25040 326 1045 0 0 0
795 -114 41719 31.5 NoLock 11 3830 32 1 25040 334 1046 0 0 0
796 -108 41726 31.5 NoLock 6 3890 32 1 25040 338 1047 0 0 0
797 -98 41740 31.5 NoLock 10 3990 32 1 25040 345 1048 0 0 0
798 -90 41753 31.5 NoLock 9 4080 32 1 25040 351 1049 0 0 0
799 -85 41759 31.5 NoLock 5 4130 32 1 25040 354 1050 0 0 0
800 -75 41774 31.5 NoLock 10 4230 32 1 25040 363 1051 0 0 0
801 -71 41779 31.5 NoLock 4 4270 32 1 25040 365 1052 0 0 0
802 -448 41129 31.2 NoLock -377 160 32 1 25040 85 1053 0 0 0 <<<<<<<<<<<<<<<<<<<<<<<<<
803 -432 41151 31.5 NoLock 17 350 32 1 25041 95 1054 0 0 0
804 -415 41173 31.5 NoLock 17 540 32 1 25041 110 1055 0 0 0
805 -395 41202 31.5 NoLock 20 770 32 1 25041 121 1056 0 0 0
806 -377 41227 31.5 NoLock 18 970 32 1 25041 138 1057 0 0 0

Not sure where to go from here. I'm open to any ideas. Going to pack things up for the evening and head to bed. Sorry for spamming the thread so much, I'm just a bit flustered because I originally thought this would be an easy project to get working. That's what I get for making assumptions...

[thinkfat]

That jump looks like a TIC roll-over.

[AndrewBCN]

Lars' 1ns resolution TIC is designed around the 1.1V ADC voltage reference available in the 328P and a few other AVR MCUs, but unfortunately not in the 32u4. To use a 2.56V AREF you would have to change a number of values in the calculation() routine, and you would probably lose some resolution and linearity. Also you can change the resistor that charges the 1nF capacitor to get a voltage swing of approximately 2.5V instead of 1.1V in Lars' original schematic.

Another solution is to use an external 1.1V voltage reference, but that requires a PCB redesign to add the cicuitry for the external 1.1V voltage reference circuit.

In the worst case, abandon the 32u4 and switch back to the original 328P that Lars used.

I did mention the AREF pin when you asked for comments early on, but I didn't check the 32u4 datasheet for its internal voltage references. My bad.

Edit: Lars' GPSDO schematic is quite simple but the complexity lies in the source code and how everything is tied together. If you have an oscilloscope do check what happens at the 1nF capacitor in the TIC, triggered by the PPS. It's very interesting!

[bingo600]

I don't think Lars would want to see people making and distributing closed source ("black box") versions of his project.

But that is the whole issue ... It is not about what you think.

As per Lars post here to Nick.S
https://febo.com/pipermail/time-nuts_lists.febo.com.March2021/2018-September/094086.html

I have no problem you have ”stolen” the phase detector design from me. I have no intention at all to make it commercial as you have done. Of course due credits to relevant persons are always good.

He seems to have no problem with Nick.S had "stolen" his phase detector design , and use it in a commercial product. as long as due credits are given.
IMHO this points more to a MIT License as you described above, than a GPLV3
Maybe you should rethink your license choice.

Well enough of this ... Apparently you think you can apply whatever license that fits you, to Lars Code ....
I will use Lars original code , and based on his answer to Nick.S , i will assume it's ok to use it with a MIT or other non GPLV3 license.

Edit: Basically my guess is that Lars didn't care much about licensing , he just wanted his design & code to be used by the public.

/Bingo

[W3AXL]

Since (I believe) absolute accuracy of the ADC isn't that important, I might just bodge up a voltage divider to bring ~ 1.1V to the AREF pin for this board. We'll see if that makes things any better.

Like I said, I'm going to be making a second hardware revision and I'll absolutely include a true 1.1V reference in that.

[AndrewBCN]

...
IMHO this points more to a MIT License as you described above, than a GPLV3
...

That's because you have zero understanding of open source licenses.

And I don't want to discuss this matter with you anymore, in this thread or elsewhere.

[thinkfat]

Since (I believe) absolute accuracy of the ADC isn't that important, I might just bodge up a voltage divider to bring ~ 1.1V to the AREF pin for this board. We'll see if that makes things any better.

Like I said, I'm going to be making a second hardware revision and I'll absolutely include a true 1.1V reference in that.

Absolute accuracy is indeed irrelevant. Stability under environmental changes though, very much relevant. While you're hunting problems, go for it, just be advised that you want that ADC reference voltage be stable over temperature and independent of your supply voltage.

[AndrewBCN]

Since (I believe) absolute accuracy of the ADC isn't that important, ...

I agree. In Lars' GPSDO, I think stability of ADC operation is probably more important than absolute accuracy.

I might just bodge up a voltage divider to bring ~ 1.1V to the AREF pin for this board. We'll see if that makes things any better.

That should at least make the TIC  and LM35 readings work with Lars' code without modifications. Definitely worth a try.

Like I said, I'm going to be making a second hardware revision and I'll absolutely include a true 1.1V reference in that.

 

[W3AXL]

Well I bodged in a 100k resistor to +5V to create a very crude voltage divider with the internal resistance of AREF (supposed to be ~32k, but looks like it's closer to 37k). Getting 1.414V at the AREF pin right now. Good enough? I suppose we'll see.

I'm still seeing those occasional large negative jumps in diff_ns - thinkfat said it looks like a TIC rollover - what's that mean exactly? Is that something else that needs to be fixed with more hardware changes?

We'll see if I get any closer to a lock this time. This PCB is becoming more bodge wires than traces 

EDIT

Code: [Select]

849 32 42322 27.2 Locked 2 5296 32 16 25029 511 1101 0 0 0
850 26 42322 27.1 Locked -6 5295 32 16 25028 510 1102 0 0 0
851 27 42322 27.1 Locked 1 5293 32 16 25028 508 1103 0 0 0
852 28 42323 27.2 Locked 1 5293 32 16 25029 510 1104 0 0 0
853 32 42323 27.2 Locked 4 5295 32 16 25029 512 1105 0 0 0
854 24 42323 27.1 Locked -8 5292 32 16 25029 506 1106 0 0 0
855 26 42324 27.2 Locked 2 5291 32 16 25029 512 1107 0 0 0
856 23 42324 27.2 Locked -3 5288 32 16 25029 504 1108 0 0 0
857 23 42324 27.2 Locked 0 5285 32 16 25029 509 1109 0 0 0
858 20 42323 27.2 Locked -3 5280 32 16 25029 502 1110 0 0 0
859 21 42323 27.2 Locked 1 5276 32 16 25029 503 1111 0 0 0
860 22 42323 27.2 Locked 1 5273 32 16 25029 505 1112 0 0 0
861 17 42323 27.2 Locked -5 5267 32 16 25028 501 1113 0 0 0
862 19 42322 27.2 Locked 2 5263 32 16 25028 506 1114 0 0 0
863 21 42322 27.2 Locked 2 5260 32 16 25028 504 1115 0 0 0
864 15 42322 27.2 Locked -6 5254 32 16 25028 504 1116 0 0 0
865 18 42322 27.2 Locked 3 5250 32 16 25029 503 1117 0 0 0
866 13 42321 27.2 Locked -5 5243 32 16 25028 497 1118 0 0 0
867 12 42320 27.2 Locked -1 5236 32 16 25028 504 1119 0 0 0
Finally!

[AndrewBCN]

...
Finally!

 

Indeed, and well done! Also it's a tribute to how well designed/coded Lars' TIC + software PLL was, that despite having various parts of the circuit off specs, lock (stabilization of the OCXO frequency at a precise 10MHz +/- a fraction of a Hz) is still achieved.

[W3AXL]

Well I started plotting MDEV based on the DAC value in column 3 and here's where I'm at after 10 minutes



Something tells me that's not right...

[thinkfat]

Well, I'd say the form of the graph looks OK for DAC MDEV, the scale is whatever you made out 1 DAC digit to be. It is of course not representative of the actual output stability, at least for small "tau". You're supposed to get a "hump" in the graph at time intervals of "maximum disturbance", typically it corresponds with your integration time constant. To see the graph dive "down", you need much longer observation time (some thousands of seconds).

[AndrewBCN]

...
Something tells me that's not right...

There is very obviously a problem. For any GPSDO the slope of the curve is supposed to be negative (variance decreases with increasing tau) until the crossover point where the variance of the GPS time signal takes over. On page 3 of Lars' PDF documentation you have the correct plot for a few of his GPSDOs, which I am attaching.

Are you sure you plotted the correct column of data?

If you did indeed plot the correct column of data I would investigate if the OCXO is being properly "disciplined". Simply use a multimeter or DSO and measure the frequency control voltage at the OCXO. Is it what it's supposed to be?

Also you can check the two PWM outputs.

[W3AXL]

As far as I know I'm plotting the correct value. In Lars' screenshots for Timelab he used column 3 (the DAC output value) and that's what I'm using. Everything is set up the same per his screenshots.

The DAC is definitely working. The Bliley OCXO I'm using has an internal bias voltage which prevents a full 0-5V scale, but it still swings between ~1V and ~4V when commanded to its extremes. Should be more than enough I'd think.

I'm at work now but I've got an 8 hour plot running back home. We'll see what it looks like when I get back. I would've expected what you said - a slowly decreasing MDEV value. Could be the low amount of data (< 1 hr) causing it to look funny.

[W3AXL]

6 hours in and it's coming back down. Here's the new run compared to the previous run that I let go for 50 minutes.



Still interesting that it starts off in both cases close to 1E-12. Not sure why that would be - I'm not enough of a statistician to be able to explain it. I'm still buried deep in the wikipedia entry for Allan deviation.

[thinkfat]

The DAC MDEV graph is only a measure of how often the regulation corrects the DAC voltage and how much the difference is between observation intervals, on average. What parameters did you use when importing into Timelab? Is your scaling correct? Did you import it as a frequency series?

The 1.22e-12 @1s basically tells you that the second-to-second corrections applied to the OCXO are causing a change of 1.22e-12 * 10e6 Hz, and 3.03e-11 * 10e6 Hz when looking every 100s. Whether this has anything to do with reality depends on your actual frequency change per DAC LSB, and of course with a 1ns TIC your regulation is blind below 1e-9s of phase change. Also, for small Tau, the OCXO stability will dominate the output and those values are not worth much.

But from the shape of the curve I can see that the GPSDO is working and is keeping the OCXO in sync with the GPS clock. Well done!

[W3AXL]

Alright, I've done some more reading of the earlier pages of this thread. I probably wasn't using the correct scaling in Timelab for my gain (100). I'm running a new plot now.

On the topic of gain, I've noticed that with my OCXO the calculated gain I "should" be using is 26 (65535 / 2500ppb tuning range), but it seems like when the loop actually starts running it doesn't use nearly enough correction to tune in the TIC value. For example my TIC measurement could be +7000 and it would take forever to reach a DAC value that would actually be applying negative correction. Perhaps that's something that needs to be tuned in the PI loop, I'm not sure.

With a gain of 100 it obtains a lock just fine and seems to be pretty stable. But - would I use that value of 100 in my scaling calculations for Timelab, or should I use the calculated gain of 26?

[AndrewBCN]

You can save the DAC value and use the calculated gain, so that when you start the GPSDO, it reaches a lock very quickly.

[thinkfat]

Alright, I've done some more reading of the earlier pages of this thread. I probably wasn't using the correct scaling in Timelab for my gain (100). I'm running a new plot now.

On the topic of gain, I've noticed that with my OCXO the calculated gain I "should" be using is 26 (65535 / 2500ppb tuning range), but it seems like when the loop actually starts running it doesn't use nearly enough correction to tune in the TIC value. For example my TIC measurement could be +7000 and it would take forever to reach a DAC value that would actually be applying negative correction. Perhaps that's something that needs to be tuned in the PI loop, I'm not sure.

With a gain of 100 it obtains a lock just fine and seems to be pretty stable. But - would I use that value of 100 in my scaling calculations for Timelab, or should I use the calculated gain of 26?

Use the calculated gain.

[W3AXL]

8 hours and 3 minutes into my next Timelab run. I set the gain back to the calculated 26 and set up the plot to use (what I think is) the proper scaling factor for my setup. This is using the DAC column with a scaling factor of 3.84E-11 (1E-9 / 26)

Looks like the ideal TC for my setup would be ~ 4000s if I'm reading the chart right? That seems excessive. Addionally my overall scale seems to be pretty high. Looks like most other MDEV plots get down to the 1E-12 range, while I'm barely scraping below 1E-10.

[AndrewBCN]

8 hours and 3 minutes into my next Timelab run. I set the gain back to the calculated 26 and set up the plot to use (what I think is) the proper scaling factor for my setup. This is using the DAC column with a scaling factor of 3.84E-11 (1E-9 / 26)

Looks like the ideal TC for my setup would be ~ 4000s if I'm reading the chart right? That seems excessive. Addionally my overall scale seems to be pretty high. Looks like most other MDEV plots get down to the 1E-12 range, while I'm barely scraping below 1E-10.

1. Looks good to me.
2. I wouldn't worry too much about the MDEV absolute values. As thinkfat wrote, you are measuring variations in DAC voltages, not variations in frequency or phase.
3. You can easily experiment with different TC, IIRC. But (again IIRC) in principle, the longer the better.

[W3AXL]

So here's another design question. I've got a square wave OCXO and I'd love to make a nice pretty sine wave at my outputs. Currently I've got a pretty simple unity gain buffer followed by a lowpass which gets me the sine, but I'd like to get some more amplitude out of it.

The big challenge I've found with amplifying the resulting sine is the lack of a negative supply. Every single-supply amp I've designed has failed pretty miserably, even following the nice TI application note on single supply designs here: https://mil.ufl.edu/4924/docs/TI_SingleSupply_OpAmp.pdf

[AndrewBCN]

There are quite a few 10MHz distribution amplifier projects described on the Internet, here is one:

https://www.briandorey.com/post/10mhz-frequency-standard-distribution-project

And here is another:

https://github.com/kf4mot/10mhz_distributor

[Johnny B Good]

@axel

 Here's what I used to get a +14dB sine wave output (assuming the 3.2v pk-pk 'scope trace is accurate) in my own humble DIY GPSDO project (I'm currently working on an Efratom LPRO 101 based frequency standard that I plan on ultimately locking to the GPS timing signals). Although it's only a single channel output, it neatly avoids the need for any bi-polar HF opamps. I suppose you could duplicate the 3 inverter buffer (I used four simply to give mine a little more oomph) with an LPF each if you only need two channels.

 The 'scope traces show the resulting sine wave outputs from the GPSDO and the LPR 101 (yellow CH1 and magenta CH2 respectively). I'm using infinite persistence to monitor the GPS signal's short term (hour to hour) phase wobbles against the temperature stabilised Rb oscillator's steady 30 to 60ns drift per day.

 The filter is based on a 5th order butterworth using this calculator:

http://leleivre.com/rf_butterworth_LPF.html

 I think I used an Fco value of 12MHz and added a peaking inductor (L3) across C3 to maximise its output at 10MHz and neatly tie the output to ground. It's important (as I discovered when trying to re-purpose PC MoBo ferrite toroid cores to make up the inductors) that you use low loss at HF ferrite inductors in order to come anywhere near the theoretical frequency curve plots typically shown for these filters.