Lars DIY GPSDO with Arduino and 1ns resolution TIC

[Leo Bodnar]

http://www.leobodnar.com/files/162Stable32.exe

Bill has same dl problems and said that Stable32 Version 1.62 is the property of the IEEE UFFC.  However, since it is freely available to all, he does not see any problem making available a downloadable copy. It should be also available on his website at http://www.wriley.com/162Stable32.exe

Link for download is active on IEEE site, but download process stops with error after approx 10% received (regardless of browser used)...

[Dbldutch]

Hi all,

I ran another test again, this time with a TC of 500, and I also added the temp correction.

Here is how I figured out the two factors, following the example Lars has given in an earlier post.
To calculate the tempRef factor, I used the average OCXO oven temp. My sensor is pressed to the CTI case by elastic bands. It reads an average temperature of 50.8 degrees C, so I entered a factor of 508.
To calculate the tempCoeff factor, I used the 10 ADC steps per degree C. With a temperature drop of 0.5 degree C, this means -5 ADC steps.
When the OCXO temperature drops 0.5 degrees C, my DAC changes 100 steps. The temp factor is then 100DAC/-5ADC = -20 The tempCoeff factor is then -20 * 100 and inverted becomes 2,000.

Below are the results from TimeLab. There is a long period of minimal DAC changes that are a mixture of the TC factor of 500 and the temperature corrections. My overall precision improved a bit compared to the graph with a TC of 200 just above in an earlier post.

From the Excel data you can clearly see the period of very good stability as well. It turns out that the instability comes from the heating system changes.
At 22:00 hours the heating system goes to night-time and the heater in my office turns on at 9:00 o'çlock.

I have a system by which I can set and monitor the individual radiators in rooms, and I also monitor the central heating system itself. The last graphs show the heating activity in my office, and below it you can see the heating system activity itself. I track the water temperature going out and back in. The instability during the daytime is caused by me entering the room and doing work within a feet of the GPSDO, and also the effects of the heater turning on and off. The heater activity is represented by the black lines in the heater graphs.

The net-net of all this is that the GPSDO at this level of precision is far more sensitive to ambient temperature changes than I anticipated, and using the sensor connected to the OCXO may not be the best method to correct this.

I will now add another sensor on the processor board and start to use that for the compensation factors.

[iMo]

Putting the stuff into a paper box is not enough, imho. Make a box from ~3-4cm thick polystyrene and put there the OCXO and all the electronics (including Neo and voltage regulators, the OCXO's heater will stabilize the temperature inside the box). I bet you get a stability as within 40k-80k secs in your graph above, or better.

[Dbldutch]

Haha imo, Chineese food in a paperbox is typical for the US, we get it in plastic boxes that are great to store food in for the freezer.

I do take your point though. Right now, my controller board and the OCXO board are in separate flimsy plastic containers. The controller board does not benefit from the OCXO temperature, which is what I track and is very stable. I designed a PCB that will arrive later this week. It will fit into a metal enclosure and I can add insulation on the inside. The board features all the modifications we talked about, but can also be removed and can take all of my current OCXO’s and the 8663 Oscilloquartz that will arrive soon as well. I found enough parts under the Christmas tree to build up several boards so I can start to compare. How to do that will be a new topic I will need some help with defining so others can hopefully benefit as well.

I’m gradually becoming a (novice) time nutter... 

[Dbldutch]

My pcb's came in and I build-up the GPSDO with the CTI OCXO.
I'm running several tests and I'm now trying to tweak the temperature compensation.
My special insulation sheets are not in yet, so I use bubble-wrap to insulate the inside of the box for now.

First results look pretty good, better than by using the two protoboards.
I'm using an old front-panel, but I designed a replacement pcb that is on order.

I had to make a few changes to the circuit and the layout already because I goofed up twice, and otherwise made some enhancements after going through the first build-up.

When I'm done with the layout changes, I will publish the Gerbers.
Here are some first pictures.
The colored wires go to my Raspberry Pi monitor.

Update: I inadvertently did not update the tracefield in the TL screenshot. It was made with a TC of 500 and a damping of 3.0, I have updated the chart.

[iMo]

How to interpret the above MADEV with TC=4?
Pretty different to Lars' picture.

[Dbldutch]

Hi imo,

I goofed by not updating the Trace field in the TL chart. I corrected and updated the chart.
It was made with a TC of 500 and a damping of 3.0.

[iMo]

Could you try with TC=4 too?

[Dbldutch]

Hi imo, I started with that to do a first check and to determine the optimum TC.

This is made with a TC of 4, damping 3.0, gain 285, TL factor 3.5087E-12, no temp corrections.
The enclosure was still without the cover and front/back panels but everything was in a bubble bag together with the Raspi monitor.

See anything interesting?

[iMo]

Based on the picture your OCXO has some drift and/or jumps.

[Dbldutch]

imo, that's not supported by the raw data but I agree that it looks a bit weird.

Granted, this run was the very first thing I did when I finished the pcb, so the temperature had not settled yet.
I'm running another test right now to figure out the temp compensation, but now that the GPSDO has settled in its new home, I will re-adjust the DAC setting, recalculate the gain, take out the temp correction entries and redo the TC4 measurement again.

After that I will switch to my second pcb with the IsoTemp OCXO and start that up.

[iMo]

I've removed first 6k and last 8k points from the measurement (unstable temp).
For record:
DACp-p = 2900 (1.02e-8)
DACstd = 343   (1.2e-9)

[Dbldutch]

Thanks imo,
It seems that every time I run a test, TL produces different curves I can't explain. I'm getting frustrated and annoyed. 
The updated chart shows that. Both IsoTemp plots were made under exactly the same conditions, one day apart. The green trace is the latest. Seems too big of a variance to me.

I'm afraid now that I'm hi-jacking this thread with my issues, but on the other hand, other newbies could potentially run into the same situation.
I considered starting a new thread, but this is so closely linked to the Lars GPSDO method of measuring the DAC results with TL that I decided against it. I hope I'm being excused.  I apologize up front though.

I ran a new TC4 test for the CTI, properly warmed-up for a few days in the enclosure and during the night (no disturbances).
At the same time, I also ran a TC4 test for the IsoTemp, properly warmed-up for several hours, in a bubble-wrap bag and also during the night. (don't have another enclosure yet)

The TC4 tests are described on page 11-12 from Lars' documents, and I used the second method to find the optimum TC.
Below are the combined results.
It seems that after warming-up, the CTI results are a little worse compared to the first plot. You would think that it would be better.
Although I'm easily running the CTI with a TC of 500, the MDEV plot seems to indicate an optimum TC of about 200 for both. Two hundred seems to be pretty poor.

The MDEV plot seems to indicate that the TempTech OCXO (bottoms at 1.37E-11) is not as good compared to the CTI which bottoms at 7.05E-11.

However, from Lars' comments on page 12, the sharp upward trend after bottoming out for the CTI indicates that it has a lot of drift.

The frequency plot shows no serious frequency jumps, but this plot also seems to indicate that the IsoTemp has a lot more noise/jitter compared to the CTI, which is much more stable. This to me seems to contradict with Lars' comment about drift on the MDEV plot.

What does the wriggle in the curve of the IsoTemp show after 4.000 seconds? What does that mean?

So can you infer the better OCXO by using the TC4 measurement results and if so, which is the better OCXO and what TL plot determines that?

[Dbldutch]

While running a test with the free running OCXO, I noticed a gotcha, but at the same time an interesting feature.

When you select h0 to hold (freeze) the DAC value to be able to see the drift of the now free running OCXO itself, the DAC still gets updated if you activated the temperature and the tempCoeff settings. This temp compensation creates peaks in the diff_ns values and wriggles in the ns values everytime the DAC is forced to change to a new value. Because the temp values are not very stable, there is a period of these wriggles until the DAC changes to a stable value.
So, make sure you set the tempCoeff to zero before you start the test.

Another hint is to first select a lock with a reasonably high TIC value (100-250+) before you invoke the h0 test. This makes the drift line a little less drastic because the DAC value is then pretty close to the GPS synchronization.

The side effect of the "incomplete" DAC hold is that you can clearly see the effect of temperature changes on the DAC based on the tempRef and tempCoeff settings, which is otherwise not so easy to verify and check.

[thinkfat]

Applying temperature corrections while in hold mode is actually a pretty important feature for "holdover". I'm very sure this is by design and not a forgotten corner case.

[Dbldutch]

@thinkfat, I called it a gotcha, and not an oversight or bug for the same reason.

[Dbldutch]

It's only fitting that after my last post from exactly 6 months ago it is followed-up by a new one today.

I'm still learning, experimenting, fiddling and adjusting with this project. I have three working units, and I'm trying 5 different OCXO's in them, with mixed results. Because the electronics and software are identical, I can really zoom in on the OCXO performance the two different UBLOX GPS modules I use.

While hunting for the cause of lost lock's, I noticed a strange phenomenon on two of my OCXO's, the Bliley and the IsoTemp ones. The third is my best, the Oscilloquartz 8663-XS.

I'm using the Bliley as an example here, but the IsoTemp reacts the same way.
The Bliley with model number NV47M1008 has a gain of 440 and I'm running it with a TC of 500. With that setting I'm loosing the lock every now and then, but that's not the point.

The first picture shows a typical run with the Bliley. I've only selected a smaller portion of the data to show the effect. It's pretty clear that I loose the lock because the ns value goes beyond +/- 100ns. The Lock shows this as a reference. Note the Ambient Temperature graph. There is a dip at exactly the time where the Lock is lost. I can't explain this drop in temperature. The ambient LM35 sensor is "lying" on top of the section with the diode and 1nF capacitor, because it is the most sensitive to temperature changes. My OCXO's are all isolated in a hard foam box, even from the PCB. The OCXO temperature is not really influenced by this.

The second graph zooms in on the data and shows the leading edge of loosing the Lock and it shows that the temperature starts to drop after the Lock is lost. The third graph shows the trailing edge and you can see here that the ambient temperature starts to rise after the Lock has been obtained again.

I know that my Trimble, Bliley and the IsoTemp are prone to sudden changes in frequency, which is why the loop cannot compensate fast enough. I've tried a lower damping factor (down to 1.5), to no avail. The reaction time of the loop is too slow at a TC of 500 for the Bliley, and at a TC of 200 for the IsoTemp, which I'm running with a gain of 617.

Can anybody shed some light on this dropping ambient temperature phenomenon?

[thinkfat]

Two things:
- If you can log the power consumed by the Arduino board, try correlating that graph to the temperature log. How much power does the "Lock" LED consume? It goes off when you loose lock.
- Try with a larger "filterDiv" parameter, to speed up the loop response. At large TC, the TIC prefilter is maybe too aggressive.

[Dbldutch]

Thank you thinkfat for the suggestions.

I thought about the LED, but it has a 220R resistor in series for a maximum of 22 mA. I doubt it has that much effect on the temperature inside the enclosure, but I can easily unplug the LED from the circuit and see if it makes a difference.

At first I thought about the 12V wall-warts producing a higher voltage at times, I use identical ones for both units. The Oscilloquartz version uses a 15V one.
That possible cause has been eliminated by switching to a 12V battery cell with a carefully set charge level.

By filterDiv, you mean the prefilter set by the p command I assume, because Lars uses two different names for the same thing I think.
Right now it is set at the default value of 1 second. Possible settings are 2, 3 or 4 seconds. Making the loop response faster by using a longer prefilter seems counter intuitive, but I'll give it a try.

Stay tuned...

[thinkfat]

Thank you thinkfat for the suggestions.

I thought about the LED, but it has a 220R resistor in series for a maximum of 22 mA. I doubt it has that much effect on the temperature inside the enclosure, but I can easily unplug the LED from the circuit and see if it makes a difference.

At first I thought about the 12V wall-warts producing a higher voltage at times, I use identical ones for both units. The Oscilloquartz version uses a 15V one.
That possible cause has been eliminated by switching to a 12V battery cell with a carefully set charge level.

By filterDiv, you mean the prefilter set by the p command I assume, because Lars uses two different names for the same thing I think.
Right now it is set at the default value of 1 second. Possible settings are 2, 3 or 4 seconds. Making the loop response faster by using a longer prefilter seems counter intuitive, but I'll give it a try.

Stay tuned...

The prefilter length is computed as "timeConstant / filterDiv". At TC=500, a filterDiv=1 gives a prefilter time constant of 500. Try 30.

What ublox modules are you using? The "ns" log shows quite a lot of deviation, more than +/- 50ns. Even without sawtooth correction, it's should not be that much. With my own design, using a NEO-M8T, after Survey-In completes, I never get more than +/- 10ns of deviation when running TC=500.

[Dbldutch]

Hi Thinkfat, thank you for the suggestions.

After going through Lars' notes, I realized that I misunderstood what the prefilter or filterDiv stood for.

A short sample of the normal rate for the "ns" log is posted below.
I don't think this is dramatic for a NEO-M8N. With an outdoor active puck antenna I always have in excess of 20 satellites of which 10-11 are above 20dBHz signal levels.



The more or less wild gyrations of "ns" start with a higher TIC value. The Bliley has an "ideal" value in excess of 1.000. I have been using 500, which is not too ambitious, but I loose lock too often. At 500 I wanted to see what I could do by tweaking the hardware, mostly looking at the supply decoupling. Maybe the incorrect FilterDiv setting is the problem.  For some reason, all my three units had a filterDiv setting of 1.    I don't recall ever having changed them. In any case, I'm now running new tests with the filterDiv at 2, and the lock LED disconnected.


BTW, here is a short sample of my Oscilloquartz 8663-XS which uses a NEO-8MT in the fixed position mode. It shows what my hardware is capable of.

[bingo600]

I really ought to get my Lars GPSDO's assembled 

Re Oscilloquartz
I'm just doing some  Oscilloquartz Star-4  GPSDO - Burn in logging w a FS2 counter 10s gatetime , and a Trimble Tbolt as ExtRef.

Turn on time 3 weeks , and the DOCXO is beginning to settle.

/Bingo

[Dbldutch]

I'm running another set of tests, after making some tweaks to the hardware, but also with the FilterDiv setting on 2 instead of 1.
Here are the results, just so you can see the difference between the two settings. This is from different runs, so the data is not the same but you can easily see that the DAC values much more closely follow the ns excursions, keeping the loop tighter.

This is the IsoTemp OCXO with a TC of 4, Damping 3.0 and FilterDiv 2.

[Dbldutch]

The LED for the Lock was disconnected, the dip is not as deep, but it's not the root cause for the temperature drop. I suspect that the Arduino activity during the lost lock is causing the on-board voltage regulator to drop temperature. That regulator is powering the LED too. This is not so easy to verify.

[Johnny B Good]

I'm running another set of tests, after making some tweaks to the hardware, but also with the FilterDiv setting on 2 instead of 1.
Here are the results, just so you can see the difference between the two settings. This is from different runs, so the data is not the same but you can easily see that the DAC values much more closely follow the ns excursions, keeping the loop tighter.

This is the IsoTemp OCXO with a TC of 4, Damping 3.0 and FilterDiv 2.

(Attachment Link)

 Just one question: Is the X axis seconds or minutes?

JBG