Lars DIY GPSDO with Arduino and 1ns resolution TIC

[metrologist]

I lost lock! Shortly after changing time constant from 180 to 240. Then there was an oscillation between lock and no lock. Every lock showed a steep downward trend until lock was lost. I guess this is just the OCXO out running the dac here. Something else might have changed too because I was having trouble getting lock again at time constant of 120. This is with the Condor GPS. I can't understand why the dac has gone so far to keep it in range.

green 100 = lock
red = tuning dac
blue = phase offset (ns)

Edit: It ran locked for 19 hours and then broke out into the same oscillation as shown here, so something seems to be happening. I set to hold mode to run for the day and I'll see what the oscillator does. I'm going to build a second one with slightly different layout and I'll use precision resistor divider on the efc rather than a trimpot.

[Miti]

My GPSDO was loosing lock every time I connected or disconnected the FTDI serial cable to the PC. I tried one time to figure out where is that coming from but I didn't find an obvious reason. So instead of wasting more time chasing a ground loop or something else on a thing that otherwise works really well , I added a Bluetooth module. Now I can connect from anywhere in the house without disturbing the loop.
So far stable for at least 12 hours with TC=500.
 

[cdev]

Is there a full list of different OCXOs people have tried and their findings with them?

If not, there should be along with their typical costs on the used market.

[metrologist]

I have 6-1/2 days of data with this CTI xtal - all daily plots on same scale and range except day 1 and 4.
Below are the latest 6 days with day 0.5 starting on the bottom and with higher TC (240). You can see it losing lock regularly. It was a little colder and the dac range was a little higher out of view.
Day 2 is better with TC 180, yet still struggling over long time periods.
Day 3 started in hold mode to observe xtal, then lower TC settings were used (~60-120). I could have picked a lower dac value.
Days 4-6 show a pattern that correlates. The plot center is mid-afternoon when it will be the warmest. It has been raining the last couple days and it's warmer with more stable temperature.
The top plot is all 6-1/2 days.
It looks like temperature effects and I suspect it may be more a result from the other components than the xtal. I do not yet have a thermistor installed so should check into that.

For contrast, I have added an almost 2-day plot of the same circuit, but with a lassen GPS. The plot range is opened up at least 2x. The PPS spec is 25ns for the condor and 100ns for the lassen.

BLUE is the ns value - typically ±50ns, over 100ns loses lock soon
RED is the dac value - typically range from 31100 to 30900 when locked

I will emphasize that when I was using the Trimble UCCM PPS signal, which I suspect my unit generates from its OCXO, the ns and dac was much more stable, with dac changes happening over periods of 10's of minutes rather that every few seconds with the more jittery GPS's.

[Miti]

What is blue, what is red?

[metrologist]

I edited my post, Miti.

And, here is the same circuit with about half a day run in UCCM PPS and TC=400. It looks marvelous to me. It ran two days and lost lock only once (recovered after 5xTC). So, the only thing changed from the silky smooth of below and the noisy mess of above is the quality of the PPS. (you have to look at the ns scale of ±40ns vs ±150ns and dac range of 10 vs 200!)

I think software can improve that with some knowledge of the PPS characteristics. I read here that Lars does not use sawtooth correction, for example. I think it would be beneficial to average more samples before feeding the value to the loop calculation. I'm not good enough with the coding though...

[Miti]

I've attached mine with TC=600, about 9 hours, Excel cannot take more than 32000 values I think.
Bottom blue is TIC, red is DAC, top is the temperature. What a perfect mirror, DAC with the OCXO temperature.

[metrologist]

I think xlsx files can handle 1,048,576 rows. It really starts to get slow at half a million records though... I'm undecided on what to do, so I put the UCCM PPS back on it with TC=200. Yesterday I let it run without PPS and it stayed within 100mHz the entire day (worst 9,999,999.904Hz). I need to add tempco as it may do more for me than it did for Lars.

[metrologist]

I went back to my breadboard and installed a picdiv 10M->1Hz to generate the PPS, so the OCXO generates the PPS as well. I expected this would show the noise of the circuit in ns. Here is a plot with TC=20, TC=4, hold mode, and TC=4. Red is dac and blue is ns. If that is noise, that is a lot more than I expected. Also, the jumps may be because I removed several missing PPS or 10M? lines...

[iMo]

Your noise is 50ns_pp/6.6=7.6ns_rms. That is not bad..

The Lars' design uses rather simple hw for the phase measurement. Its performance could be heavily influenced by the construction.

MCU is noisy, its internal ADC could be with +/-2 LSB noise with good wiring (+/-2ns), the integrator is not linear and the readout depends on capacitor quality (ie. DA).

Another ADC error source could be from a jitter coming from the none-uniform start of the ADC's conversion (S/H moment) after the integration stops.

Also there is none highZ ADC buffer thus the reading might be influenced by the ADC's input currents.

Also the schottky diode has rather high reverse current, in hundreds nA range (and Temp dependent).

And 4046 is also not an ideal phase comparator (dead time etc).

I've been using the TI's TDC7200 digital time interpolator in my design, which claims 55ps resolution with 35ps stddev (my start/stop pulses are coming from an FPGA) and I get 150ps_rms (that is 1ns_pp) when lucky with my wiring (breadboard style).

[metrologist]

Thanks for the explanation (ESR, DF and Q are all aspects of the performance of a capacitor...DA? oh, that DA https://www.eevblog.com/forum/beginners/fake-polypropylene-capacitors-from-china/?topicseen). I can measure the critical caps, but they are old electrolytics and a very poor choice here. I wonder also if the loop could be oscillating due to the way I have the feedback, and also due to I'm using pre-made (longish) breadboard wires. I'm thinking of using a second OCXO to generate the PPS and compare.

[iMo]

DA with the capacitor in the "integrator" could be a critical parameter. You do not use an electrolytic capacitor there, I bet.

[cdev]

If you take a couple of photos of it - maybe some issue might be non-obvious but amenable to multiple minds working on the problem, and a process of elimination?

Breadboard wires vary as far as making a reliable connection. I wouldn't think they would be so reliable in many timing applications. maybe you could use redundant double breadboard wires where the connection is critical to the timing, the chance of a glitch might be much reduced if it took a simultaneous glitch on two separate wires at exactly the same time to equal a glitch for the GPSDO?

Thanks for the explanation (ESR, DF and Q are all aspects of the performance of a capacitor...DA? oh, that DA https://www.eevblog.com/forum/beginners/fake-polypropylene-capacitors-from-china/?topicseen). I can measure the critical caps, but they are old electrolytics and a very poor choice here. I wonder also if the loop could be oscillating due to the way I have the feedback, and also due to I'm using pre-made (longish) breadboard wires. I'm thinking of using a second OCXO to generate the PPS and compare.

[iMo]

A simple "self test" would be to divide the 10kHz 10MHz (coming from the OCXO 100divider's output) to 1PPS (ie by PICDIV version doing /10000) and feed the gadget with those signals.
The ns readings should be all equal with no jitter (ideally).
You do not need an another OCXO for this experiment.

[metrologist]

imo, how is that different than what I did? Except my OCXO does not have a divider, so I just use the picdiv to divide the 10M output.

I'm not sure if I am really troubleshooting a problem with this self fed loop other than there seems to be much more noise than I was expecting (~5ns pp). There are many good explanations for what I'm seeing, but...

... when I clocked this with UCCM PPS there seemed to be much less noise. That is why I wondered if there is a loop oscillation being driven by the feedback and some instigator.

[iMo]

imo, how is that different than what I did? Except my OCXO does not have a divider, so I just use the picdiv to divide the 10M output.

Sure, it could be done that way too..
Try the self test and you will get a feel what comes from GPS and what from your board.

[metrologist]

Self test?

[iMo]

The "self test" means you feed the 1PPS and 10MHz inputs of Lars' board from the same Oscillator source (it must may not be the OCXO, a simple canned osc is ok).

That way the phase diff of the edges (in "ns") should be constant and with smallest jitter (may be with none jitter).
 
If not, there is a problem with something on the board.

Another test: you may try to invert/invert/invert... (different taps) the 10MHz clock before entering the 390' dividers. That way you move the phase diff (in "ns") towards the upper end of the ADC. You should see different "ns" numbers for the specific taps, but always constant.

OSC-------------------------->INPUT 10MHz
        |
        ------->PICDIV--------> INPUT 1PPS


OSC-------->74HC04------->INPUT 10MHz
        |
        ------->PICDIV--------> INPUT 1PPS

PS: sorry I will fix my above post for clarity, the 10kHz I referred to was a wrong number.

[metrologist]

I thought that is what I was basically doing, but I do not understand why the OCXO cannot be used?

[iMo]

What are your results with the test then?

[metrologist]

What are your results with the test then?

Reply #233? I tried another oscillator but it has an AC sine wave and that would not drive the picdiv directly. I put that aside for now and...

I added NTC to the circuit - except I have to do it funny because I had 100k NTC. I used two of them in parallel (5V -- NTCs - ADC2 - 1k1 -- GND). That seems to keep the voltage under 1.1V at high temperatures (100C). So I'll be operating in the lower/less linear area of the response curve. (I'm not seeing cheap 10k NTC - they are all dressed up for Arduino with flowers and butterflies and cost $10 a piece).
ADC2 bounces around 241 to 246 and did not move much at all overnight, but there was a clear rise in dac from turn-on.
I set a Tempcomp of -1. I was confused on the calculation and what's the purpose of the TempRef, and I do not know if it's compensating the correct direction.

I lined up the time scales in the plots as I had more temp data from turnon. I did not bother to plot efc dac and ns values during warmup and unlock. The glitches in the temp data result from me changing sensor types and display of dac, C or F values.

Now, if I compare my ns value driving with picdiv pps in reply 223 with my ns value driving with a (supposedly more jittery) GPS PPS, I get confused.

[Remco]

It has been quite quiet here last weeks . . .

Accidently I came across this forum in my search for a simple Arduino based
TIC GPSDO and read the full thread about three times to try to get 'sound and vision'
with the design/concept and experiences of others.

Today I built the circuit using a Bliley NV47A1282 (same as Miti) and with some fiddling
I got a lock earlier this afternoon. But it seems it's not a lOck but lUck ; -)

I suffer from (too much) 'Missing 10 MHz?' frames and seek some guidance.

From what I understood (from this thread and looking in the source code) this
'Missing 10 MHz?' coincides with a full ADC (1023), (meaning?) the pulse is too long (?)

I use R = 4.02k, C = 1 nF and decharge R = 6.6 MOhms (2 x 3.3 M in series)

To prevent myself burning precious time, should I lower the 4.02k value?

[Miti]

I suffer from (too much) 'Missing 10 MHz?' frames and seek some guidance.

From what I understood (from this thread and looking in the source code) this
'Missing 10 MHz?' coincides with a full ADC (1023), (meaning?) the pulse is too long (?)

I use R = 4.02k, C = 1 nF and decharge R = 6.6 MOhms (2 x 3.3 M in series)

To prevent myself burning precious time, should I lower the 4.02k value?

Use the recommended parts and check your ground. I had the same problem and I had to redo my ground and to move the RC close to Arduino. Very close.

[Remco]

Thanks for the prompt reply Miti!

Indeed, my 'analog wire' apparently was too long (and therefore noisy?).

To make connections as short as possible I selected A7 as sample port,
soldered the components on the Arduino board (see picture below, I use a BAT86 diode)
and routed an extra GND wire from Arduino GND to HC4046 GND (pin8).

The result is flabbergastingly different in a positive sense!
Until this moment of writing it never missed a beat.

Edit some hours later: it still hasn't

In run mode the DAC value converged and clamped to 0 (zero), so I had to
to lower the minimal voltage at the VFC pin and used 100k parallel too.

Edit: changed the resistor to 51k1 (so that DAC value appears ~31000 when in lock)

Now with h1 and h65535 the difference in diff_ns was around 600, so my gain is 65536/600 = 110.

Edit:with 51k1 resistor h1 = 996 mV, h65535 = 2200 mV --> Δ diff_ns = 490 --> gain = 134, I took 128.

Letting it run, the contraption locked within 10 minutes 

Edit: in warm condition (with 51k1 parallel to VFC) within 130 seconds.

[Theboel]

Hi All,

I understand Lars as the designer of this GPSDO has pass away some times ago but I think some one can help me to understand something about this design.

using 1MHz and 1PPS as input for TIC how to calculated the TIC resolution ?