Lars DIY GPSDO with Arduino and 1ns resolution TIC

[thinkfat]

That is what I'd expect with a free running oscillator with no correlation to the 1PPS signal. It's just a tiny frequency offset, you cannot make any conclusion on the OCXO drift from that. If the frequency is off, you'll see the two signals drifting in- and out of phase just as is shown there. You should be able to calculate the frequency offset from that data, too. It's like watching two almost-aligned signals on an oscilloscope in XY mode

[thinkfat]

I do not know. You are going to write your own fw so it depends. You may use the INTs based on the 1PPS and 500kHz edges as well for something. I think Lars' version is using that somehow (I do not use Lars' system).

PS: Lars is using the 5MHz for feeding the Timer1 (200ns clock) for some internal purposes - (ie. he captures the Timer1 value at the beginning of the 1PPS ISR, he uses "timer_us" variable for "timer1 value in microseconds offset from 1pps").

For compatibility reasons I would feed 5MHz to the TimerX input as well. You will see whether it is useful or not.

Lars used the 5MHz clock to extend the TIC range beyond the 1000ns the ADC is able to provide. However, the TDC7200 in Mode 2 can measure time intervals of up to 8ms. That should be plenty. No need to have a 5 MHz clock walking about on the PCB. I'm beginning to worry anyway if I can pull this off on a 2 layer PCB.

[iMo]

In theory you do not need the 1PPS and 500kHz interrupts, when using the 7200's INTB. In practice the signals could be useful ie. for detecting whether the NEO or the OCXO actually work (or are connected in properly).
Also clocking the STM32 off the OCXO's 10MHz could be an interesting option.

[thinkfat]

In theory you do not need the 1PPS and 500kHz interrupts, when using the 7200's INTB. In practice the signals could be useful ie. for detecting whether the NEO or the OCXO actually work (or are connected in properly).
Also clocking the STM32 off the OCXO's 10MHz could be an interesting option.

Yes, indeed, I've played with that idea, having a counter running clocked by (a multiple) of the OCXO clock and using the 1PPS as a capture event. But I think you don't need to clock the whole chip from the OCXO in that case, because the STM32 timers can do event counting as well. Also, you'd need to be very sure that the OCXO is connected before you switch from the internal RC oscillator to the external clock...

[iMo]

The main reason for running the STM32 off the OCXO is its "synchronous operation" thus lowering interferences (beat frequencies), even not so critical with the 7200, but still, you want to chase picoseconds and uVolts
Afaik some HP high end counters used to use a dithering of their clocks to avoid that..

[Dbldutch]

I took the time today to make two of the modifications imo suggested:

1. 78xx are the poorest performers in terms of TC and noise, it could be the fluctuations come from there (I would replace the 7808 with something better)
2. pot trimmer - I would avoid it, large TC of resistance and of wiper contact
3. resistors around the EFC input - should be low TC ones
4. LM35 - with longer wires put a "68-82ohm ser 10u MLCC" between its output and gnd (close to its pins).

Instead of using the 78L08 as the basis for the 4V OCXO reference voltage divider, I'm now using an LM4040 4.096V shunt. (fed through a 3K9 resistor from the 8V to get a 1mA current)
The result is so remarkable it is beyond belief! Gone are the oscillations and the instability. If your OCXO does not have a reference voltage out, make sure you use a real reference. I'll show some results later.

I also did 4, but there is little change however. I think I'm going to be using a filter in software later on. I don't think the current variations are going to help if I invoke the temperature compensation.

I'll do 2 and 3 if/when I go to a pcb layout. Right now I'm still playing and experimenting. Yesterday I got my CTI OC5SC25 OCXO, still fitted on the original pcb that was cut from the original. After de-soldering, a quick test showed it to be working, so I'll have another one that I can play with.

More later

Thank you very much for your insights imo! 

PS: it turned out that I was using a different setting for my measurement. The result with the reference is not that spectacular, but definitely a significant improvement.

[iMo]

The basic problem of all PWM DACs is the stability and noise of the Vcc the drivers are powered from. That is usually the Vcc of the MCU.
I posted a solution in past afaik - the PWM's low pass driver could be created from those 5-6pin logic gates, while the gate is powered from a clean 5V.

An ideal component is for example the "Single-Bit Dual-Supply Bus Transceiver With Configurable Voltage Translation and 3-State Outputs" - https://www.ti.com/lit/ds/symlink/sn74lvc1t45.pdf
which is sot-23-6 package with 2 voltages - ie. you may drive it from an 1.8V MCU, and at the other side from 5V quality voltage regulator (the PWM filter side).

[Dbldutch]

Hi all,

After I got my third OCXO, the CTI OC5SC25, I made some more measurements.
Because my other OCXO, the Isotemp 143-141 had a defective Vref output, I suspected the results a bit.
I didn't need to worry, the results are very close.

To accommodate the CTI, I tried to keep the same VC adjustment as I used with the Isotemp.  It turned out that the sweet spot for the CTI is at 2.62V, not quite in the middle of the 4V range, but it allowed me to use the same resistor network as with the Isotemp. The adjustment range is more than enough.

I adopted a different calibration method this time.
Instead of using my counter or DMM to set the midpoint by frequency or voltage, I simply started the program, set the DAC to midrange with h32767 and adjusted the VC trimmer such that diff_ns was around zero. I then switched to H1 and ran that for a minute. I copied the trace results to Excel and used that to calculate the average of diff_ns, and wrote that down. I then switched to H65535 and did the same. The results were +75 and -69, nicely centered, and that resulted in a gain of 455. The trimmer can be substituted by fixed resistors when this has been done, to remove some possible jitter temperature drift as was suggested by imo.

While playing around with different settings, I noticed an unexpected behavior that I want to share here.
I've learned that to get a feel for the whole system, it is best to start with a TC of 4, and the damping at minimum (at 0.5). This allows you to see the almost unfiltered results of the OCXO drift and the response by the program to stay locked.
In the picture below, that is shown by the first 650 samples. The excursions show that every second, the OCXO is nudged rather aggressively into shape.

If you now switch to a TC of 32, the default setting, the combination of the TC setting with the minimal damping is causing oscillations. This is the period from about 730 until 1200. This could be a "trap for young players", I certainly fell for it and I'm no longer young.

If you now add more damping, by setting it to 3.0, the oscillations are almost gone.

At about 1,540, I switched to a TC of 100. At about 2,000 I set the damping to 5.0. You can see the effects.

Note that with higher TC settings, the DAC output is progressively more filtered and so the excursions of the DAC output are limited in time and value. If you have an OCXO that drifts easily, it can get outside of the DAC compensation rate quickly, resulting in the system loosing the lock. The effect of filtering with a higher TC is much more aggressive than the damping factor.

I have also found that before you switch to a higher TC setting, you should have already the corresponding amount of "locked" time sampled by the system that the new setting demands, otherwise you'll loose the lock right away. I found it best to progressively increase the TC setting.

With both the Isotemp and the CTI, I have difficulty getting TC's above 500. With my now dead Bliley, I could get up to 1,000 easily. The Bliley has a much thicker casing then both the CTI and the Isotemp, maybe this is a factor because I have not yet activated the temperature compensation.

Enjoy!

[Dbldutch]

I wanted to investigate the source and the amount of jitter that can be observed.
This measurement had been done before in an earlier post, but since I have more units, I could show additional information.

I have three different Ublox GPS modules.
I have a genuine NEO M8T, a fake NEO-6M and a fake NEO-M8N.
They are all on the same carrier. (I replaced one broken fake with the real M8T)

For the measurements, I used the NEO-M8T as the reference. Note that this unit is not completely set for the "timing" mode. Both GPS modules were connected to the same type powered antennas. The antenna cable going to the M8T is 4 feet longer. I usually have in excess of 10 satellites.

I triggered my scope from channel 1 connected to the NEO-M8T and monitored the other two separately.
The shot ending in 44 is the 6M and the other shot is the M8N.

The amount of jitter is about the same (about 50-60ns), and so is the position relative to the M8T.

From this it seems that it does not matter much which version you use, they all have the same 1PPS behavior.

While making these measurements, I noticed a missing or strange pulse every now and then on all three seperately.

Enjoy!




 

[iMo]

You may implement an "automatic adaptive setting" of the TC (time constant, should be higher than 4 secs, as 4 secs is the time constant of the pwm low pass filter) and the damping factor
Always start with safe values and slowly iterate to the optimal ones..

PS: is it possible to open the Bliley box (in fix the broken output)?

[thinkfat]

Well, yes, that's about the expected outcome. If you have an unstable OCXO, you have to discipline harder or more frequently than a good OCXO, or it will drift out of lock. If your regulation is too slow (TC too high, damping to high), it will not be able to kick the OCXO back into phase.

You'll see this in the ADEV chart: At low tau (< TC) the Allen deviation is limited by the OCXO, at long tau (> TC) the Allen deviation is limited by the quality of the time signal from the GPS system. That is why using a TCVCXO or completely uncompensated VCO is rubbish. You'll end up having to use small TC's and high gain and of course the short term ADEV can never be better than the free-running stability of the oscillator.

Practical example: I have a 10-digit counter that can give me up to 1E-9 resolution with a 20 second gate time. It cannot average over multiple gate times. That means, ADEV with tau=20s must be better than 1E-9 or it'll be useless as a reference clock for this counter. A GPSDO with an unstable oscillator will not do, even though at longer observation intervals it will appear "stable".

I have also found that before you switch to a higher TC setting, you should have already the corresponding amount of "locked" time sampled by the system that the new setting demands, otherwise you'll loose the lock right away. I found it best to progressively increase the TC setting.

This is due to the integrative part of the regulator. You have to null it before switching TC, but that will give the DAC a pretty hefty kick. You can, however, try to use the integrator content as a switching criterion for higher TC. If I is around 0 for a longer time period (a couple of TC), you can safely switch.

The trimmer can be substituted by fixed resistors when this has been done, to remove some possible jitter as was suggested by imo.

The trimmer will cause a higher temperature drift, not jitter.

[Dbldutch]

In order to find the optimum TC, I used method number 2 from the description in Lars's document (page12).
I used a TC of 4 and a damping of 0.5, and plotted the live DAC values of the CTI OCXO in Timelab.

I don't understand the results I'm getting as I don't see the "intersect" where "a reasonable TC can be found".
I know it has to be below 500, because that setting causes the lock to be lost.

This is the first time I'm using Timelab, it can very well be a pilot error.

Any suggestions as to what the meaning of the plot is?

[iMo]

Have you subtracted the linear drift? How the MADEV looks like?
Also you have it run for longer than 1 hour to get taus around 1000secs.
PS: you may log the data into the .csv file and then load into the Timelab.

When you convert the DAC values into "freq differences" by multiplying XXX x10^-12 (the figure 6) it is equivalent to measuring the OCXO frequency. So I do not understand why Lars suggested in the version 1 the "hold mode" (you do not make DAC corrections, free running OCXO, afaik) and the version 2 in "locked" one.

Maybe he forgot to mention you have to have the EFC wire disconnected?

With EFC wired you will see the picture as you have measured - as you are locked to GPS.

[thinkfat]

In order to find the optimum TC, I used method number 2 from the description in Lars's document (page12).
I used a TC of 4 and a damping of 0.5, and plotted the live DAC values of the CTI OCXO in Timelab.

I don't understand the results I'm getting as I don't see the "intersect" where "a reasonable TC can be found".
I know it has to be below 500, because that setting causes the lock to be lost.

This is the first time I'm using Timelab, it can very well be a pilot error.

Any suggestions as to what the meaning of the plot is?

Well the first maximum is obviously your TC. Apart from that - no idea. Does Method 2 really call for a damping factor of 0.5? I'd leave it at the default.

[sundance]

78xx are the poorest performers in terms of TC and noise

if voltage regulator noise is an issue here, maybe this is an interesting read/remedy:
http://www.wenzel.com/documents/finesse.html

[iMo]

As you wrote above with TC=4 and damping 0.5 you got "almost unfiltered OCXO drift". That is good as it is equivalent to the version 1 (hold mode). By measuring the ADEV/MADEV you will see the unfiltered OCXO drift and 1PPS jitter, but it is still "locked" so the ADEV curve will not go upwards with larger taus (like with a free running OCXO), imho.


Your maximum below 10secs is the filter loop constant, then with taus>10secs it drops down - downward slope - Lars wrote it is the 1PPS jitter.

In the picture you see the downward slope from the PPS jitter. At some point the slope changes and the oscillator drift and noise is seen. At this “intersect” a reasonable TC is found. If the oscillator has a lot of drift the slope start to go upwards to early (remember that the I-term compensates for linear drift). One recommendation is to use the “subtract linear drift” in time lab.

Let run it for longer time (ie 6-12hours) to see the "intersect with subsequent plateau" (if any ).
With 6 hours you will get up to 5000secs tau (at 1sec sampling period).

With your 1-2 hours long measurement the ADEV error in the 500-1000secs tau area is huge, it will decrease with much longer measurement (see below the "error bars" you may switch on), and the intersect becomes visible, hopefully.


PS: the red curve above is for an OCXO which "jumps" - like loosing the lock - therefore the curve goes upwards with larger taus (typical for all "free running OCXOs").

[Dbldutch]

I have started the test again, this time for 6hrs, and with a damping of 3.0. In earlier tests, I did use this damping factor, but it seemed to make no significant change.

As soon as the current test finishes, I’ll show the results, and I’ll field a few more questions,  but I already saw that my earlier tests were just a bit too short to register the change. They do now.

Thank you for the comments and suggestions so far.

[Dbldutch]

As has been reported earlier, the pwm stability is depending on the Vcc of the Arduino board. To address that, I want to use a better voltage regulator. Unfortunately, neither Mouser nor Digikey have the temperature stability in their selection criteria and my Google searches were fruitless.

Can any of you recommend a few types that fit the application, are easily and widely available and can be managed package wise by a hobbyist? SMD is not the problem, BGA’s and the likes are.

Thanks!

[Vgkid]

What sort  of power draw are you looking at?
What about a current boosted voltage reference.

[bogdanbrudiu]

Hello, is this mini GPSDO PCB available for order or as gerber?

Hello for a few days testing versions of mini gpsdo. Very fast stabilizes OCXO.
,

Thanks to Lars for a very good project.

I wish you all happy and prosperous New Year

best regards

73 Marek SP4ELF

[Dbldutch]

Vgkid, your suggestion to look for a "current boosted voltage reference" got me on the right track. Thank you.

One of the first finds was the LT6658, a dual voltage reference. That looks like a great part to use for the Arduino supply and also for the OCXO reference voltage, or, If I decide to go to a "real" DAC, the reference for that. With 10ppm/C, that should work.

[iMo]

Hmm, I would rather stabilize the output buffers as I indicated above in Reply #381. If not using those special voltage level buffers, you may use any 74HC logic in a non-inverting configuration and power the 74HC with your clean Vref. An example below.

[Dbldutch]

That is an interesting and simple approach as well imo.
I will certainly try that solution soon.

[Satbeginner]

Hmm, I would rather stabilize the output buffers as I indicated above in Reply #381. If not using those special voltage level buffers, you may use any 74HC logic in a non-inverting configuration and power the 74HC with your clean Vref. An example below.
(Attachment Link)

Hi all, I'm following this conversation with great interest!
Build the original Lars design about a year ago ( how time flies!) and consider upgrading my unit using the new suggestions being made here.

One question about powering the 74HCxx from Vref:

First we try to have the cleanest Vref possible, would using it for the 74HCxx not make it dirty again?

Just wondering,

Un saludo,

Leo

[Dbldutch]

As promised, I would show the results of my earlier test, to find the optimum TC setting.
Below is the chart that has the earlier test with a TC of 4 and a damping of 0.5 and also the newer test with TC of 4 and a damping of 3.0
With the first test, I used the default setting for the duration, which is an hour.

I plotted the DAC values, that were converted into a frequency with the factor 2.2E-12 (my gain is 455) and I used the Frequency Difference setting.

When I did the test again for 6 hrs, it showed that I needed to do the earlier test just a little bit longer. Bummer!

I have included both the ADEV and the MDEV charts.
Both were adjusted with the "drift line" setting.

If I understand it all, the optimum TC should be at the start of the "flat line", in my case 800 with the MDEV chart. With the ADEV chart, it could even be higher at 1,000.

Earlier, I was not able to get up to that value, I would loose the lock already at 500.

I'm now running another test by which I very gradually increase the TC in smaller steps (t4, 32, 64, 150, 250 etc.) with several hours in-between to let the loop system settle.
I'll show those results later.