Lars DIY GPSDO with Arduino and 1ns resolution TIC

[Mike99]

Mike,

You can't tell that from the MDEV chart.
You'll need to store the report from Lars' program over a 24hr period and use Excel to chart the ns, DAC and OCXO temperature values to try to make sense out of what's going on. Can you publish those graphs, or post the excel file with the report?

Thanks Paul, here's a 24 hour extract.

Mike

[nealix]

Does anyone here know where can I find  a datasheet for the CTi OCXO model OSC5A2B04 ?

Thanks,

Neal

[thinkfat]

Does anyone here know where can I find  a datasheet for the CTi OCXO model OSC5A2B04 ?

Thanks,

Neal

I think they share the pin-out of all the other OCXOs with the same size and footprint. Or what else did you haven in mind looking for in the datasheet?

[nealix]

Does anyone here know where can I find  a datasheet for the CTi OCXO model OSC5A2B04 ?

Thanks,

Neal

I think they share the pin-out of all the other OCXOs with the same size and footprint. Or what else did you haven in mind looking for in the datasheet?

I am trying to decide which OCXO to use for my first build here.   
For square wave, I have the CTi and the ISOTEMP.
For Sine, I have an 8663, a pair of Morion MV85, a CMAC, and a couple of Bliley 1282's.

Any opinions or favorites re which one I should build my first unit with?

Cheers

[Dbldutch]

@Mike

Attached are the charts based on your 24hrs Lars' report on your Vectron.

From the ns chart, it seems your GPS signal is too noisy. It really should be within +/- 20ns.
I would investigate why this is so by analyzing the NEO performance with u-center. If you didn't already put it in stationary mode, I recommend you do that. Also, do you limit the reception to better than 20dB? How many sats do you then have, and which constellations do you receive. Is your view of the sky OK? All these questions can be answered by u-center. I should point out that many of my own earlier strange GPSDO behavior were caused by the poor results coming from the NEO. By using an M8T timing version due to my poor reception, all my troubles melted away like snow in spring.

What is strange is that nowhere are your ns values going beyond +/- 100ns, so this is not the reason for loosing the lock.
If you look at the filt output, it follows the lock status. I cannot find a reason for loosing the lock based on the control loop of the system.

If you look at the DAC data, it seems that it is still settling. The curve is slowly moving down.
I also included the 3 hr averages from the status report. You can clearly see the settling of the OCXO in the curve. Your 3 hr OCXO temperature has a lot of movement.

Your temperature reports seem a bit off. If you use temp for the OCXO, that seems a bit low, and it varies quite a bit. I also looked at the temp1 data, and it is around 29 degrees but varies the same way. Is that sensor measuring the inside of the enclosure? Is the enclosure really closed, or do you have the lid open? I suggest you close it.

This was with a TC of 200. I think you are now running with a TC of 4? This will really show the components because there is no filtering taking place.

If you can, post that TC 4 run as well.

Can you also post the f2 and f4 reports together with the status reports?

I'm puzzled by the frequent lock losses though.
One suggestion I have is to clear the EEPROM with e22, restart the program and input only the required values like gain, TC and temp sensor type (11), then save them with s1.

Good hunting!

[thinkfat]

For Sine, I have an 8663, a pair of Morion MV85, a CMAC, and a couple of Bliley 1282's.

The MV85 is definitely my favorite of the day. Beware of fakes, though.

[Mike99]

Attached are the charts based on your 24hrs Lars' report on your Vectron.

Paul, many thanks for looking at this for me. I have trouble producing those graphs because I use LibreOffice Calc and it is very slow and crashes frequently on large files. I also have Excel 2003 but that has a limit of 65k rows and 32k points for a chart.

You could be right about the satellites. I can't receive any at all with a puck antenna even on the window sill. My active outdoor antenna is mounted on the house wall facing east and usually sees 10-12 satellites. My U-Blox is a NEO-7N.

It will take me a while to respond to all your suggestions. I'd like to leave the tc=4 run for a bit longer before trying anything else.

Mike

[Dbldutch]

Mike, when you have about a day's worth of data for the TC 4 run, upload that file, but also post the f2 and f4 reports.

[thinkfat]

Paul, many thanks for looking at this for me. I have trouble producing those graphs because I use LibreOffice Calc and it is very slow and crashes frequently on large files. I also have Excel 2003 but that has a limit of 65k rows and 32k points for a chart.

Mike, take a look at Matlab or Octave (free Matlab clone). It's definitely worth it and gets things done much faster than messing with apreadsheet. Takes some getting used to, but handles big data sets much easier than Excel/Calc.

[cdev]

You could be right about the satellites. I can't receive any at all with a puck antenna even on the window sill. My active outdoor antenna is mounted on the house wall facing east and usually sees 10-12 satellites.

A GPS patch antenna should always be facing up, or close to up or be pointing at the clear patch of sky -with an elevation mask set! the elevation mask will then reject odd order reflections, which are polarity reversed.

An elevation mask is always a good idea with a patch antenna.

Also, it sounds like you may be using it without a ground plane. A patch antenna doesnt work properly without a flat piece of metal beneath it. Ideally it should be aligned with the horizon, really.
Thats an integral art of the antenna. It doesnt responate properly without it. At the minimum you should use something like a junk CDRom or ideally a piece of steel the magnet can adhere to. A piece of PCB will do fine too. The bigger it is the better it will work!  I also put a small ferrite on the coax coming from them to decouple the feedline. That usually makes a small but meaningful improvement in the pattern.

I recently got a NanoVNA and its obvious when sweeping the passinve GPS antennas I have why the groundplane is essential and why it should be larger. They clearly come from the factory tuned to a large GP, like the roof of a car. There is a very noticeable dip at the resonant frequency and if you use a passive GPS antenna with the factory's minimal ground plane you can see how radically it shifts with a small versus large ground plane.

They come just as the ceramic element with a peg, to connect it, the equivaent of having an antenna supplied just as a whip, and a PCB pattern, the device, not the antenna - manufacturer ususally provides their own PCB and it is the groundplane.

Basically, the groundplane makes the antenna.  So you cant just put a puck antenna on your windowsill and expect it to work. What I would do is take a junk CG and using any available means, attach that to your puck's bottomside.  They are cupposed to magnetically affix to an automobile roof.  Thats how they are supposed to be used.

But just a CD/DVD will give you just enough GP to get it to work. A bit larger would be better. 20 cm or more, several wavelengths, would be ideal if its practical. It will improve your performance a lot.  Anything flat and conductive will do it.  Put some copper tape on your windowsill.

A lot of people make this mistake.  The same appllies in any rover, UAV, etc. situation.

[Mike99]

If you can, post that TC 4 run as well.

Can you also post the f2 and f4 reports together with the status reports?

Here are the requested reports.

I believe the temperature readings to be accurate. The Vectron OCXO runs much cooler than my Trimble. The ambient sensor is positioned next to D1. The board is in an enclosure (same as yours) with the lid on.

Mike

[Mike99]

Also, it sounds like you may be using it without a ground plane.

Not so sir. I placed the puck on a sheet of copper clad PCB but it would still only receive satellites when outside the house. When you consider that the GPS module and puck together cost 7 UK pounds I'm happy to consign that antenna to the bin.

That's why I gave up with the puck and mounted an active antenna on the house wall.

Mike

[Mike99]

I would investigate why this is so by analyzing the NEO performance with u-center. If you didn't already put it in stationary mode, I recommend you do that. Also, do you limit the reception to better than 20dB? How many sats do you then have, and which constellations do you receive. Is your view of the sky OK? All these questions can be answered by u-center. I should point out that many of my own earlier strange GPSDO behavior were caused by the poor results coming from the NEO. By using an M8T timing version due to my poor reception, all my troubles melted away like snow in spring.

My NEO-7 was in Portable mode. I changed it to Stationary mode and captured the attached images. However as my module is an M suffix it appears that I am unable to save configuration changes? I couldn't find where to limit the reception to >20dB.

Mike

[thinkfat]

Disable SBAS. It doesn't typically help the stability of the timing signal.

[bingo600]

Paul, many thanks for looking at this for me. I have trouble producing those graphs because I use LibreOffice Calc and it is very slow and crashes frequently on large files. I also have Excel 2003 but that has a limit of 65k rows and 32k points for a chart.

Have a look at gnuplot

/Bingo

[cdev]

Also, it sounds like you may be using it without a ground plane.

Not so sir. I placed the puck on a sheet of copper clad PCB but it would still only receive satellites when outside the house. When you consider that the GPS module and puck together cost 7 UK pounds I'm happy to consign that antenna to the bin.

That's why I gave up with the puck and mounted an active antenna on the house wall.

Mike

Is the GPS antenna's normal up pointing sideways?  Thats what I am getting at.  It may work fine, but I would put it on a 90 degree bracket and groundplane.

and if there is still enough sky view that it still works, set an elevation mask perhaps. Ive lived in lots of flats at various times where the only sky view is  up an air shaft.  I'd be surprised if that worked well but as long as the GPS can see a few sats at once it should woirk enough to get a lock. Newer GPS receivers are pretty sensitive.

[Dbldutch]

@Mike

I looked at your TC4 results.
The graphs I made from your data in Excel look pretty good. The 1PPS has the expected noise level, so your GPS is not the culprit. The ns band is significantly below +/- 20ns, with only a wobble in the middle of the data, which is acceptable.
The DAC follows the 1PPS jitter lead, but the excursions are a little high.
The temperatures look very stable too.
So this looks very good, and offers no explanation for loosing the lock at higher TC's.

However, when you look at the DAC values in TimeLab, it shows a very different story.
Look at the MDEV chart. The curve looks great, but look at the left axis. This is rubbish.

Note that to import the DAC data into TimeLab, you have the convert the DAC values back to frequency. You do that by dividing 1E-9 by the gain. In your case, with a gain of 590, that results in a value of 1,69492E-12 and that is used to convert the DAV values inside TimeLab.

I suspect that there is something not quite right with the way you calculated your gain, or the method that you used to obtain it. Otherwise your hardware that drives the OCXO adjustment has issues. This would explain the weird loss of locks at higher TC's, and also the weird TimeLab results.

The way I adjusted my OCXO's was by setting the DAC at mid-range (h32767) and while looking at the Lars' report, adjust the OCXO DAC by a trimmer so the diff_ns reads an average of 0ns over a page of data or so.
Now set the DAC to the minimum with h1 and again look at the diff_ns report for a page of data. Take the average of that data and write it down.
Now set the DAC to the maximum with h65535 and again look at the diff_ns report for another page of data. Take that average too and write it down. One of them will be below 0, and one above. Add the two averages together without using the sign.
Divide 65535 by that result and that is your gain.
 
If the gain is significantly below 500, adjust the trimming resistors for the DAC adjustment to make it larger. If it's significantly above 1.000, make it a bit smaller. I suggest a range between 600 - 900, but in the end, it all depends on the drift and aging of your OCXO.

If your OCXO has aged enough and the DAC results are no longer drifting up or down over a longer period, replace the trimmer with fixed resistors to remove temperature effects.

I hope this helps...

[Mike99]

Paul, thanks for looking at that for me but I think something went wrong with your MDEV chart. Here is what I get from the same data, and the parameters I used to import it.

I replaced the trimmer pot with fixed resistors before starting my aging run. My resistor values are:

R104 = 20k, R105 = 5k1, R110 = 2k7, R111 = 12k, R109 = 100k.

The diff_ns values averaged over a page of data were 51.6 for h1 and -59.5 for h65535, so a total of 111ppb. 65535/111 = 590 and 1E-9/590 = 1.6949E-12 so I think I got that right.

Mike

[Dbldutch]

Well I'll be d...
I tried to import your data several times with the same results, even after closing and restarting TL.

I just tried it three more times, same results.
I de-installed TimeLab en re-installed it.
Same result. 

Tried earlier data from one of my own GPSDO's, same bad results. 
  is going on?

De-installed TL again and removed all remnants I could find.
Installed it again.
Tried my own data, works!
Tried your data, works!



The net-net is that it seems your GPSDO is (now?) working as expected. Why don't you try to increase the TC and see if it stays locked after getting a lock?
Be on the watch-out for the swings in the ns values. If you see it starting to drift slowly and regularly, it means that your TC is getting too high.

[Mike99]

The net-net is that it seems your GPSDO is (now?) working as expected. Why don't you try to increase the TC and see if it stays locked after getting a lock?
Be on the watch-out for the swings in the ns values. If you see it starting to drift slowly and regularly, it means that your TC is getting too high.

Thanks I will do that.

Glad you got TL sorted!

Mike

[Yannick99]

Have a look: https://www.instructables.com/id/GPSDO-YT-Disciplined-Oscillator-10Mhz-Reference-Fr/
Any comments?

These GPSDO work with a FLL not with a PLL. The lock is very fast and stable. Are there any further experiences with this type? Unfortunately there is no source code from the project.

Hi 0xFFF0,

I just released my code on github https://github.com/YannickTurcotte/GPSDO-YT

 If the pps is accurate, yes it's fast and very stable.

Regards

Yannick

[Dbldutch]

Yannick was so kind to develop a special counter version of his own GPSDO project for me, to tailor it to GPSDO's in general.
I have extensively tested it over the past couple of weeks, and it works really well.

The latest version has a programmable gate time that can be set to 1.000s with 3 decimal digits of resolution, or 10,000s for a 4 decimal digit resolution and it sends the results to a serial port. It does not need an LCD display and needs only a few components.

Just displaying the result on a display has little benefit with high precision and stable OCXO's, but logging the results to track them over time does. As a minimum, it's a poor mans high resolution counter that gives you another look at the GPSDO precision and stability.

I will post my development for the Lars project on my own blog to not pollute this one too much.

[Yannick99]

Yannick was so kind to develop a special counter version of his own GPSDO project for me, to tailor it to GPSDO's in general.
I have extensively tested it over the past couple of weeks, and it works really well.

The latest version has a programmable gate time that can be set to 1.000s with 3 decimal digits of resolution, or 10,000s for a 4 decimal digit resolution and it sends the results to a serial port. It does not need an LCD display and needs only a few components.

Just displaying the result on a display has little benefit with high precision and stable OCXO's, but logging the results to track them over time does. As a minimum, it's a poor mans high resolution counter that gives you another look at the GPSDO precision and stability.

I will post my development for the Lars project on my own blog to not pollute this one too much.

It was a pleasure Paul.

Source code for this counter available here: https://github.com/YannickTurcotte/GPSDO-Counter

Like Paul said, more info on his blog.

Yannick

[Mike99]

I need some more help please guys.

I've been running my GPSDO with tc=100s and it has lost lock three times in under 24 hours. The out of lock periods are remarkably consistent: 525s, 523s and 514s.

I've posted some pictures and the log. Any ideas what's going on please?

Mike

[thinkfat]

Did you do the TIC linearization?