Lars DIY GPSDO with Arduino and 1ns resolution TIC

[Dbldutch]

Seconds, tracking the output of the "Lars" program.

I'm feeding the Arduino with a regulated 8V input, and I've isolated all other circuits from the 5V output of the Arduino. There is only a 100uF cap on that pin now. The Arduino drives the lock LED of course. My assumption is that the Arduino spends less time filtering when the lock is lost, and loss of activity together with the switched off LED causes the temperature drop. I have three units, all with different OCXO's, and all three show the same behavior. You can only witness this when the OCXO is thoroughly isolated from the rest of the circuit, otherwise that temperature dwarfs the ambient temperature excursions. I'm measuring the ambient temperature with an LM35 on top of the R1/C1/D1 components.

Go figure...

[thinkfat]

have you already set up your temperature compensation?

[Dbldutch]

Hi Thinkfat,

No, I did not setup the temp corrections yet, as a matter of fact, I took them all out to help track down the much bigger issue that I have. I'll describe that in a separate post.
Besides, if you look at the data in my post #466 (top right hand graph), you see that there is not a great deal of DAC deviation caused by temperatures that is worth compensating.

Thank you for helping me out though.

 

[Dbldutch]

I promised to show one issue that I had with my setup. This is a typical "trap for young players".

For several months I suspected bad behavior from my OCXO's, but because I have 5, with only one behaving as expected, I just couldn't believe 4 out of 5 were bad. I suspected temperature issues and the PWM/DAC circuit, but could not prove anything with the equipment that I had.

I've just found the problem, but only after modifying my DIY micro-Volt meter by adding logging capabilities.

The symptom was that I saw strange out-of-lock events that I could not explain. If you look many posts back, you can see that I used a suggestion from imo to isolate the "DAC" output pins from the Arduino 5V rail. The Arduino does some strange things to the ambient temperatures as I've found out, so isolating that circuit from the very sensitive rest as much as possible is a good thing. I used 74HC14 gates between the Arduino "DAC" outputs and the PWM filter. The 74HC14 got it's own 5V supply, generated by a REF02 voltage reference. Following another suggestion from imo, (post # 415) I added a current booster circuit that used one transistor and a bias resistor. There are several versions of that circuit that I've found. Here is another one:



I fed that circuit with the output of an LM7808. This regulator feeds all the other separate 5V supply rails. In hind-sight, that was a mistake, I should have used a higher voltage. According to the REF02 specification, 8V is the minimum. When you measure the output voltage, it is fine and stable, so I didn't suspect it. It did see some oscillation on the output with a scope, and I removed a 2.2uF tantalum cap directly on the output of the REF02 to get rid of it. Although this was according to the datasheet. I also changed the transistor to a 2N3906 because that gave me better regulation.

When I was finally able to use my modified micro-Volt meter on the VFC output, I noticed glitches that shouldn't be there.
Below is a plot to show what I mean. These glitches are not coming from the DAC.

When I tracked the output of the REF02, I noticed the glitches on the last picture below. (both pics have a horizontal scale of 1 second per data point)

My assumption is that the regulation of the REF02 is compromised when the voltage of the LM7808 drops below a critical level. (if you use a micro-Volt meter on the output, you'll be surprised how wobbly these 78XX regulators are) The 220 Ohm bias resistor is also in-line with the REF02 input, and that drops the voltage below a critical point, causing the REF02 to sometimes get out of regulation, and causing the glitches on the output.

The REF02 only powers 4 gates of the 74HC14 plus the PWM filter and bias setting resistors for the OCXO. I measured the load to be less than 4mA, while the RF02 can sink 10mA. The booster is not needed, so I took it out, eliminating these mysterious glitches that haunted me for months.

Having fixed that, I can now continue to see if I can further improve the results some more, because I'm still a long way from where I think I can get to.

Stay tuned...

[Dbldutch]

thinkfat,

In your forum post about your own development (DIY GPSDO project w/ STM32), you mention in post #192 that you should not use SBAS and should not use multiple constellations.

There is very little written about setting-up NEO's specifically with the Lars' system.
When I switch to only using GPS, I loose track (No PPS) for short periods of the sats several times a day as an example. Unfortunately, I only have access to an East facing windowsill on my 3rd floor apartment, so I need better coverage.

Can you give us the rational about using only one constellation? Is there a switch-over issue from one to the other in addition to what is in the u-blox M8 Receiver Description manual at paragraph 4.2.1?

Many thanks in advance

[thinkfat]

thinkfat,

In your forum post about your own development (DIY GPSDO project w/ STM32), you mention in post #192 that you should not use SBAS and should not use multiple constellations.

There is very little written about setting-up NEO's specifically with the Lars' system.
When I switch to only using GPS, I loose track (No PPS) for short periods of the sats several times a day as an example. Unfortunately, I only have access to an East facing windowsill on my 3rd floor apartment, so I need better coverage.

Can you give us the rational about using only one constellation? Is there a switch-over issue from one to the other in addition to what is in the u-blox M8 Receiver Description manual at paragraph 4.2.1?

Many thanks in advance

The documentation of the ublox m8t receiver recommends to not enable SBAS, because it will degrade the stability of the time pulse (see chapter 19.2) I have found that, too. SBAS is also primarily interesting for navigation, it has no benefit for timing.

The recommendation to only enable one major GNSS is from own experience - however, if you don't have sufficient sky view, this is a moot point. It is then more important to have satellite coverage, as obstructed sky view will degrade the timing precision anyway.

What I'm experimenting with right now is to enable SBAS only during survey-in under the assumption that the position average will converge quicker with the increased fix precision.

My current setup has GPS and Galileo enabled as major GNSS' permanently, with SBAS being switched in only during survey-in. My software handles that automatically.

[Dbldutch]

I have finally found the root cause of the poor performance of my GPSDO's. It turns out that I have been looking in the wrong places.
To recall, I have 5 different OCXO's that all showed strange events that were difficult to explain, so I blamed it on the OCXO's. For several months they have been nursed back to an easy life after the most likely rough handling and transport. To no avail. The strange phenomena didn't go away, even though I was able to fix several smaller issues.

It turns out that my GPS modules, in combination with my geo position, the sky view and the place of the antenna, is the root cause. As I mentioned earlier, my puck antennas are located on a metal windowsill on the outside of my apartment. The window in the apartment building is East-facing, and there is another floor above me. This results in a very restricted eastern sky view.

I have three different GPS modules, a NEO-6M, a NEO-M8N and a NEO-M8T. The 6M and the M8N are confirmed Chinese fakes. As far as I can tell, the M8T is a genuine u-blox one. (also purchased from a french guy, probably the same one thinkfat got his from) The 6M has poor reception and is limited for my particular situation. The M8N seems to work fine, although it does not restart with the saved configuration. After a power-cycle, I have to put in the setup again.

Strangely enough, the M8T refuses to accept the activation of the Galileo sats. (I use the right NMEA version of 4.1) When I program the setting, it flips the activation check mark back to inactive. It does not show any min/max channels for Galileo either. Hmmm. Other than that, it seems to work fine. (it does not have the right firmware, see update below)

Here is a typical example of the best performance I could wring out of the GPSDO with the M8N and the Bliley NV47M1008 OCXO. These charts were made with a gain setting of 442, damping at 3.0, prefilter at 2, and a tc of 500.



Note the swings in the "ns" chart between about +/- 50, compared to the rather good diff_ns chart. The sudden glitches that happened several times per day in the ns chart forced the GPSDO to loose lock. All of the OCXO's that I have and tried showed the same problem, so I have been hunting for these strange events.

For the last couple of days I have been switching the hunt to the GPS modules themselves because I was more and more convinced that the hardware performed as it should. While changing the NEO configurations with u-center, I noticed that the 6M would only see GPS sats. It looked like there were enough, always more than 3, so I set the minimum to 3, and the inclination to 20 degrees. Since then I lost lock with the sats every now and then. That put me on the right track.

I continued to change the settings on the M8N and the M8T and was eventually able to raise the tc to 1,000 while keeping a GPSDO lock.

I knew my M8T was better, so I took the 6M out of the GPSDO socket and mounted a BNC on the front panel with a connection to the now empty NEO socket. I fed the 1PPS output of the GPSDO with the M8T into the new BNC, in effect feeding that GPSDO with the reliable M8T 1PPS signal. Below is that result (Bliley tc 1000):

As you can imagine, I was elated with this result. I was finally convinced that my hardware is capable and working really well. Although I'm running with a gain of 442, I'm going to see if I can double that to get a better resolution for the DAC.

With this result it now turns out that my "reference" GPSDO with the M8T and the Oscilloquartz 8663-XS OCXO at a tc of 1,000 has some issues that I now need to hunt down. (Oscilloquartz tc 1000) It turns out not to be very stable. On my scope, the back-and-force drift between the Bliley and the Oscilloquartz 10MHz out wave-forms is very noticeable. I also still have issues with the M8N as well, so my conclusion for now is that in my particular case with my geo position and the limited sky view, the Chinese fakes have issues and are not good enough. Buyers beware!

[above edited for clarity & update:]
I have found that there is a huge difference with the Fixed Mode setting in TMODE2. Without the fixed mode, the readings are all over the place, and it shows on the TIC results as well. I ran a 24hr survey and used those results in the Fixed mode setting, and that improved the stability of the TIC dramatically.
 
My M8T does not have the required firmware and although I found it and tried, I can't load it due to communication errors with the device. Upgrading the fw for the M8T apparently is not without risks. In any case, that's why I don't have access to Galileo.

[Dbldutch]

I managed to get the firmware of my M8T upgraded to 3.01

It was not easy.
The firmware file is hard to find,  I found it here: https://www.eevblog.com/forum/metrology/u-blox-m8t-firmware-fw-3-01-tim-1-10/
The procedure to do the actual upgrade is not clear either.
I found a good howto description here: https://www.junipersys.com/data/support/Mesa-2-Ublox-GNSS-Firmware-Update.pdf

Even then, there is one thing missing.

In the field for the FIS file, you need to set the link to the flash file that came with your u-center installation. The flash.xml file is located in this directory.

Lastly, it does not take 30 seconds as is mentioned in the document, it took about 5 excruciatingly long minutes.

Don't forget to set the NMEA Version to 4.10 in the NMEA Protocol setup. (Version 4.11 did not stick, it reverted back to the old version)

I'm now acquiring the Galileo sats.

Enjoy!

[Dbldutch]

The effect of a GPS glitch on the GPSDO.

I've noticed the following event while tracking my M8N GPS module.
Here is what happened in the u-center dashboard.


My M8N reception uses a minimum SV elevation of 15, a threshold of 4 SVs and a minimum of 20dBHz. Notice the fact that I have many satellites with more than adequate reception quality. This is with the stationary configuration setting, so I'm a little surprised to actually see this result, even though I only have an eastern sky view.

The M8N is in my Oscilloquartz GPSDO, and that shows an immediate loss of lock. The settings are gain of 987, tc at 500.

It shows that the GPSDO is very sensitive to the GPS module performance, even though there are many satellites in view.

My other GPSDO's with the Bliley and the CTI both driven by the 8MT in the stationary setting and with the timing mode in the fixed configuration do not show anything of a glitch at all.

[thinkfat]

Using the "TIME" mode is one major contributor to GPSDO stability. The other one is "sawtooth" correction. The first one can be achieved easily under the command of u-center. The latter will require major changes to the GPSDO control software.

[Dbldutch]

My Oscilloquartz based GPSDO is now slaved connected to the master NEO-M8T, and the results are pretty remarkable. The switchover happened at about 45.000 on the horizontal (seconds) scale.

This is with a TC of 500 and a gain of 987.
 
I think I have found my root cause...

[Dbldutch]

My GPSDO with the Bliley NV47M1008 linked to the NEO-M8T has the best performance of the three GPSDO's I'm currently testing with my hardware. The results are almost too good to be true, I think...

This is with a tc of 1000, the rest default and no temperature compensation. My OCXO is in a foam box and has virtually no temperature influence I can determine. The drift of the OCXO is only in one direction, and even with a gain setting of 902, the DAC only needs minimum size steps to keep it in check.

Below are the MDEV and Frequency graphs from TimeLab.
I'm certainly no expert, but this is very impressive performance of the Bliley I think.
Maybe I got lucky...

It also shows what the hardware is capable off, and it's probably worth considering adding the imo modifications that I described in detail many posts earlier. To quickly sum them up; use different regulators for all building blocks to isolate influences. Properly decouple all parts. Replace the 10M discharge resistor for C1 and do that by software control. Isolate the PWM/DAC outputs with gates that are powered with a reference supply to minimize the Arduino effects on the OCXO tuning. Put the OCXO itself in a foam box that also includes the bottom part. Extend the leads from the OCXO to go through the foam bottom which will further isolate the OCXO from the PCB.

[Dbldutch]

So is my Bliley perfect?

No, well maybe. It has a weird behavior when warming-up.

After about a picture perfect 10 hours after turn on, I noticed this weird glitch. It briefly lost lock, but quickly got it back, but now with a DAC setting that is considerably lower than before. Since then, for a period of 38 hours and counting it has been extremely stable again as you can see in the previous post.

Interesting... it shows that nobody is perfect!

[thinkfat]

How did you generate the ADEV graph, what input and reference? The results are suspiciously good, worth looking into the methodology of your measurement setup.

[Dbldutch]

Hi thinkfat,

I was expecting comments like yours... This Bliley OCXO seems to be too good to be true.

OK peer review:
I collect the data from the Lars' report through a Raspberry Pi that puts it into daily logs, which I then import and concatenate together in Excel.
From that data I then make the graphs that I show on this blog. I also use the DAC data and feed that into TimeLab.

My gain for the Bliley is 902 so the import multiplier becomes 1.10865E-12. After I import the data, I use all three of the Substract options.
When I added another 24 hours of data to that from yesterday, I got the attached graph out of TimeLab. This shows why I personally still have have difficulty interpreting the ADEV and MDEV TimeLab results. The Frequency Difference in TL jives with what I graph out of my Excel data, so that is consistent.


Unfortunately, I can't post the Excel file because even zipped it is already 34MB and too large to post here.
I have extracted the DAC data and put that into a zipped file. This can be imported into TL.
I also put the Excel file without graphs and some deleted columns to save space on my github site here: (removed link)

Looking forward to hear if you can spot something...

[Dbldutch]

Here is a picture of wonderboy and also an MDEV and Freq compare with the other two OCXO's I'm currently testing.

The other two mere mortals are an Oscilloquartz 8663-XS with a gain of 987  and a CTI OC5SVC25 with a gain of 554.

[thinkfat]

I was assuming already that you only had the DAC output log to feed into Timelab, so unfortunately, the graphs that you get tell you nothing (well, a little) about the actual output of the GPSDO, unless you can be dead sure that a specific DAC output always corresponds to a specific frequency. Of course this is not the case.

The MDEV and frequency graphs give some insight into the overall system behaviour, though.

First of all, the tau=1s MDEV is effectively defined by the smallest step the DAC does with the GPSDO in lock. It depends mostly on the "gain" and the DAC width (16 bit, in your case) and the time constant. If you run with a smaller time constant, the DAC output will change more frequently and the small-tau MDEV will be larger.

The MDEV graph, if you only have the DAC values, tells you mostly how much the GPSDO control loop "disturbs" the ouput of the OCXO, and if you knew the MDEV for the same OCXO running against a stable reference (very stable Rb or Cs standard), you could infer something about the actual performance. In fact, you could mark the datasheet values of your OCXO, if you have them, in the MDEV graph and connect them with lines to have a baseline for the expected performance, and wherever the DAC MDEV is above that line, it "degrades" the performance of the OCXO.

The datasheet I found for the NV47A OCXO series says it has a 1s stability of around 1e-10, which is OK but not exceptional, your DAC MDEV is around 1e-13, that means the GPSDO doesn't impact the OCXO and it will exhibit its natural performance. But of course it cannot do better, so the output of the GPSDO is not stable to 1e-13

Now on the use of the "subtract" options in Timelab - I'm not very familiar with the software but I suspect that they will only hide information that is in the data. For example, if you remove all trends in the data, it will make the GPSDO "look very good" for large tau, but it will also hide the OCXO's long-term drift behavior, which is an interesting property to know.

Another remark on MDEV - I'm not sure but I think the DAC output is a frequency-time series and not a phase-time series, because changes denote a change in frequency and not a change in phase. That is something to keep in mind.

[Dbldutch]

Hi thinkfat,

Thank you for the clarifications. I agree with you, wholeheartedly, but keep in mind that just about every TimeLab graph presented on this particular forum is a presentation of the DAC values, all by themselves. So that's what I did as well. Even Lars only shows the DAC values in his document, and never once in relation to his rubidium standard, which would give us a reference. To compare results between various posted graphs, we all need to use the same data, and since Lars recommended (figure 7) to subtract the driftline in TL, so did I and many others.

It has been my understanding all along that because the 1PPS pulse coming from the GPS satellites drives the control loop, adjusting the OCXO to this standard. Therefore, all ns and DAC excursions are in relation to the stability of the atomic clocks in the satellites, which is why looking at the DAC values can be construed as showing the difference to an "absolute standard". I may not express this well, but that is my understanding. Please correct me if I'm wrong.

I already mentioned that I have difficulty interpreting what the TL graphs present, and prefer to look at the stability of the OCXO using Excel and looking at the TIC ns difference, stability/drift and the DAC stability and drift. If you collect temperature data as well, you can see those effects as well. Having said that, in absence of a ppb counter or an "absolute reference", all you can do is a relative compare between devices, which is why I collected data from a couple of OCXO's.

As a minimum, my data shows that the Bliley is a lot more stable than the Oscilloquartz, and that one is a lot better than the CTI.

Or is there another way?

[thinkfat]

As a minimum, my data shows that the Bliley is a lot more stable than the Oscilloquartz, and that one is a lot better than the CTI.

I'm not so sure about that. You'd have to run them all with the M8T GPS, with the exact same TC and filter settings (except gain of course), in the same stable environment, to make the graphs comparable.

BTW the only references to Timelab in this particular thread that I found are for finding the optimum TC. This is point where the GPS becomes "better" than the OCXO, i.e. where you start to see the drift behavior of the OCXO. If you think about it, to achieve the best performance you need to "slow down" the control loop to the point where it is just fast enough to compensate the long-term drift of the OCXO. This is the best possible case, have the GPSDO output be the free-running OCXO up to the point where the GPS is more stable.

[Dbldutch]

They are all connected to the same M8T in the same hardware design and running with a TC of 1.000 except the CTI which used a TC of 500. I just switched it to 1.000, but I'm not too happy with it so I'm in the process of switching the CTI to my Trimble 65256 again. The reason is that OCXO's with a solid and thick case have virtually no hindrance from ambient temperature changes, if you put them into an isolation box all by themselves.
Both the CTI and the IsoTemp I tried have flimsy housings and suffer greatly from ambient temperature changes.

If you look in the original pdf from Lars, it shows the TL graphs that I referred to.

[thinkfat]

Well, the graphs on page 3 are against various Rb standards (PRS, LPRO), the graphs in the last PDF are all against "Rb3", which was probably Lars'  house standard.

[thinkfat]

They are all connected to the same M8T in the same hardware design and running with a TC of 1.000 except the CTI which used a TC of 500. I just switched it to 1.000, but I'm not too happy with it so I'm in the process of switching the CTI to my Trimble 65256 again. The reason is that OCXO's with a solid and thick case have virtually no hindrance from ambient temperature changes, if you put them into an isolation box all by themselves.
Both the CTI and the IsoTemp I tried have flimsy housings and suffer greatly from ambient temperature changes.

If you look in the original pdf from Lars, it shows the TL graphs that I referred to.

I think what you can safely conclude from the graphs is that the whole system with the Bliley OCXO is the most stable of them, since the MDEV graph basically shows that the control loop has to do much less "work" to keep the OCXO locked. This might be due to the OCXO alone. If you isolated the other two OCXOs better from temperature changes, they will likely improve as well. But as it stands, under the conditions you tested, the Bliley is the "best". The final proof can only come from doing a measurement e.g. against a good Rb standard. This will bring you into serious "time-nut" territory

[Dbldutch]

Just to see how far I could go with my now stable and reliable hardware and GPS setup, I selected a TC of 2,000 and ran that for about 20 hours. I also switched the CTI out for my Trimble 65256. This Trimble has a sine wave output, just like the Oscilloquartz.

During this run, there was absolutely no risk of getting out of lock and I think I can increase the TC even higher. The deviations get a little larger, so from a precision point of view for the output, it makes no sense to me. It looks like a TC of 1,000 seems to be optimal for all three of these OCXO's. Due to the thermal isolation I provided by boxing in these OCXO's, there is no temperature effect that I can determine, unlike with the CTI and IsoTemp ones.

[cdev]

Just curious if all the 10 MHz sine waves from all these oscillators remain in phase with one another, year in and year out?

Ive recently acquired a perfectly sized thermal box (used for shipping frozen goods, etc.) and I am wondering if I should first fireproof it, and then try putting my (Bliley OCXO containing) GPSDO in that and putting it in my basement and building a separate controller to put upstairs in the living area. I could maybe use it for training GPSDOs. Have a little "rack" for disciplining them.

Just for fun.

[thinkfat]

Just to see how far I could go with my now stable and reliable hardware and GPS setup, I selected a TC of 2,000 and ran that for about 20 hours. I also switched the CTI out for my Trimble 65256. This Trimble has a sine wave output, just like the Oscilloquartz.

During this run, there was absolutely no risk of getting out of lock and I think I can increase the TC even higher. The deviations get a little larger, so from a precision point of view for the output, it makes no sense to me. It looks like a TC of 1,000 seems to be optimal for all three of these OCXO's. Due to the thermal isolation I provided by boxing in these OCXO's, there is no temperature effect that I can determine, unlike with the CTI and IsoTemp ones.

Yes, that's to be expected. There's a decision to be made where you want the best performance. If you want stability at small observation intervals, you choose a long time constant to slow the regulation down. If you favor long intervals, make the time constant shorter. Have a look at this image, it shows my DiY GPSDO against a commercial Trimble UCCM module. My own GPSDO is running with a time constant of 700 seconds, the Trimble is using whatever, but you can clearly see that it uses a different strategy: It sacrifices small-tau stability for a faster dive-down into stable regions around 100s.


However, increasing the time constant looses its benefit at a point, as you cannot get better than the short-term stability of your OCXO.