Lars DIY GPSDO with Arduino and 1ns resolution TIC

[W3AXL]

The signal strength looks sufficient, doesn't look like you need to worry about that.

Limiting the elevation doesn't help during survey-in, on the contrary. For accurate positioning you need low'ish elevation SVs, the more the better. What you can also do is enable SBAS (WAAS/EGNOS), but only during the survey-in. That will help getting a better positioning accuracy.

Final hint: Switch off all constellations but GPS and Galileo.

You win a cookie! Disabling all the constellations except GPS/Galileo resulting in an immediate order of magnitude improvement. I'm currently looking at a StdDev of 0.4 after only 8 hours.

Interesting that GLONASS was causing that much of an issue.

[thinkfat]

The signal strength looks sufficient, doesn't look like you need to worry about that.

Limiting the elevation doesn't help during survey-in, on the contrary. For accurate positioning you need low'ish elevation SVs, the more the better. What you can also do is enable SBAS (WAAS/EGNOS), but only during the survey-in. That will help getting a better positioning accuracy.

Final hint: Switch off all constellations but GPS and Galileo.

You win a cookie! Disabling all the constellations except GPS/Galileo resulting in an immediate order of magnitude improvement. I'm currently looking at a StdDev of 0.4 after only 8 hours.

Interesting that GLONASS was causing that much of an issue.

I generally keep GLONASS disabled. It also messes up timing. No idea if it's a firmware or a GNSS issue, though.

Another thing you can do to speed up position convergence: higher measurement frequency. I do 4 measurements per second during survey-in.

[cncjerry]

I haven't been on this topic in a while, and was wondering if sawtooth correction was added to this GPSDO? 

I built one from a friend that was based on Lars', had dual EFC DACs, sawtooth etc. and it did a good job with HP 10811s, symmetricom sprinter series, and an X72 Rb I have.   I brought it out the other day and promptly blew up the arduino by attaching the received signal from the GPS directly to it without using a voltage divider.  Now I can't recognize the arduino or reprogram it, and Amazon let me down on overnight shipping.  But then I started wondering if this DO had ever been updated with sawtooth and maybe start here if there was more support.

Using the other GPSDO, I had planned to take the DACs out and send the tuning word to the X72 over serial, but I ran out of serial ports so I would have to rewrite some of it and setup another software serial port.  I planned also to convert it to an STM32 board so I didn't need a PC to monitor it.  I want to shut down my two lucent GPSDOs and just run the X72 until I repair my Cesium (I have another tube to put in it). The two lucent boxes take over 100w of power to run and at .40 per KW hour, that's not cheap.

Thanks

Jerry

[W3AXL]

Anyone have any suggestions for improvement? This is my GPSDO, with a Bliley OCXO and an M8T surveyed-in to 0.1m stdev. For some reason, even with a TC of 96, the DAC value never totally settles.



Any time constant higher than 96 and the loop doesn't seem to lock.

[MIS42N]

Anyone have any suggestions for improvement? This is my GPSDO, with a Bliley OCXO and an M8T surveyed-in to 0.1m stdev. For some reason, even with a TC of 96, the DAC value never totally settles.

How long have you run it? Some OCXO need a few days to settle down. Is the DAC just jittering around a value, or going in a particular direction (up or down). If it is going up or down it is worth waiting. If it is jittering, then it may be other causes - power supply maybe?

[W3AXL]

Anyone have any suggestions for improvement? This is my GPSDO, with a Bliley OCXO and an M8T surveyed-in to 0.1m stdev. For some reason, even with a TC of 96, the DAC value never totally settles.

How long have you run it? Some OCXO need a few days to settle down. Is the DAC just jittering around a value, or going in a particular direction (up or down). If it is going up or down it is worth waiting. If it is jittering, then it may be other causes - power supply maybe?

That was a 14-day run. Before I took that data it had also been running for about three months continuously. With G=27 and TC=96 it never unlocked, but I suspect my actual performance was rather poor as demonstrated by the plot I posted above.

[MIS42N]

Anyone have any suggestions for improvement? This is my GPSDO, with a Bliley OCXO and an M8T surveyed-in to 0.1m stdev. For some reason, even with a TC of 96, the DAC value never totally settles.

How long have you run it? Some OCXO need a few days to settle down. Is the DAC just jittering around a value, or going in a particular direction (up or down). If it is going up or down it is worth waiting. If it is jittering, then it may be other causes - power supply maybe?

That was a 14-day run. Before I took that data it had also been running for about three months continuously. With G=27 and TC=96 it never unlocked, but I suspect my actual performance was rather poor as demonstrated by the plot I posted above.

Yes sorry, I didn't look closely at the graph, just the question. You didn't say if the DAC was jittering or going in a direction. A 16-bit DAC will always be moving by 1 because it can rarely generate the exact EFC needed, it will be alternating between two adjacent values. But you imply it is doing more than that?

[W3AXL]

Anyone have any suggestions for improvement? This is my GPSDO, with a Bliley OCXO and an M8T surveyed-in to 0.1m stdev. For some reason, even with a TC of 96, the DAC value never totally settles.

How long have you run it? Some OCXO need a few days to settle down. Is the DAC just jittering around a value, or going in a particular direction (up or down). If it is going up or down it is worth waiting. If it is jittering, then it may be other causes - power supply maybe?

That was a 14-day run. Before I took that data it had also been running for about three months continuously. With G=27 and TC=96 it never unlocked, but I suspect my actual performance was rather poor as demonstrated by the plot I posted above.

Yes sorry, I didn't look closely at the graph, just the question. You didn't say if the DAC was jittering or going in a direction. A 16-bit DAC will always be moving by 1 because it can rarely generate the exact EFC needed, it will be alternating between two adjacent values. But you imply it is doing more than that?

Yeah, it seems to be alternating quite a bit more. Here's a log excerpt from the last of the 14 days (I have some extra columns in my FW). You can see the DAC value moves from 42013 all the way down to 42009.

Code: [Select]

1050906 -2 42013 31.3 Locked -1 5058 96 48 25092 629 11 0.764 4994 42018 30.1
1050907 -4 42013 31.3 Locked -2 5056 96 48 25092 625 11 0.765 4995 42018 30.1
1050908 -6 42013 31.3 Locked -2 5054 96 48 25092 622 11 0.766 5015 42019 30.1
1050909 -7 42013 31.3 Locked -1 5052 96 48 25092 622 11 0.767 5009 42019 30.1
1050910 -9 42013 31.3 Locked -2 5049 96 48 25092 621 10 0.768 4989 42019 30.1
1050911 -12 42013 31.3 Locked -3 5046 96 48 25092 620 10 0.769 4990 42019 30.1
1050912 -14 42012 31.3 Locked -2 5042 96 48 25092 618 10 0.7610 4995 42019 30.1
1050913 0 42012 31.3 Locked 14 5041 96 48 25092 631 10 0.7611 4983 42019 30.2
1050914 -1 42012 31.3 Locked -1 5041 96 48 25092 625 10 0.7612 4967 42017 30.2
1050915 -3 42012 31.3 Locked -2 5039 96 48 25092 624 11 0.7613 4971 42017 30.2
1050916 -5 42012 31.3 Locked -2 5038 96 48 25092 622 11 0.7614 4940 42015 30.4
1050917 -8 42012 31.3 Locked -3 5035 96 48 25092 621 11 0.7615 5021 42016 30.4
1050918 -11 42012 31.3 Locked -3 5032 96 48 25092 619 11 0.7616 5024 42018 30.5
1050919 -14 42012 31.3 Locked -3 5029 96 48 25092 618 11 0.7617 4970 42017 30.5
1050920 -16 42012 31.3 Locked -2 5025 96 48 25092 617 11 0.7618 4989 42016 30.5
1050921 -2 42012 31.3 Locked 14 5025 96 48 25092 625 11 0.7619 4976 42015 30.5
1050922 -4 42012 31.3 Locked -2 5023 96 48 25092 624 11 0.7620 4995 42016 30.7
1050923 -4 42012 31.3 Locked 0 5022 96 48 25092 622 11 0.7621 4971 42015 30.7
1050924 -5 42012 31.3 Locked -1 5021 96 48 25092 623 11 0.7622 5014 42016 30.7
1050925 -7 42012 31.3 Locked -2 5019 96 48 25092 627 11 0.7623 4990 42016 30.7
1050926 -9 42012 31.3 Locked -2 5017 96 48 25092 621 11 0.7624 4949 42014 30.7
1050927 -11 42012 31.3 Locked -2 5015 96 48 25092 619 11 0.7625 5020 42015 30.8
1050928 -13 42012 31.3 Locked -2 5012 96 48 25092 619 11 0.7626 4995 42015 30.8
1050929 -14 42012 31.2 Locked -1 5009 96 48 25092 617 11 0.7627 4948 42013 30.8
1050930 -15 42011 31.3 Locked -1 5006 96 48 25092 616 11 0.7628 5020 42014 30.8
1050931 -16 42011 31.3 Locked -1 5002 96 48 25092 615 11 0.7629 4968 42014 30.9
1050932 -18 42011 31.3 Locked -2 4999 96 48 25092 619 11 0.7630 5035 42015 30.9
1050933 -4 42011 31.3 Locked 14 4998 96 48 25092 624 11 0.7631 4910 42011 30.9
1050934 -7 42011 31.3 Locked -3 4997 96 48 25092 622 11 0.7632 5037 42012 30.9
1050935 -9 42011 31.3 Locked -2 4995 96 48 25092 622 11 0.7633 5013 42014 30.9
1050936 -11 42011 31.2 Locked -2 4993 96 48 25092 620 11 0.7634 4981 42014 30.9
1050937 -12 42011 31.2 Locked -1 4991 96 48 25092 618 11 0.7635 4981 42013 31.1
1050938 -15 42011 31.2 Locked -3 4988 96 48 25092 618 11 0.7636 4979 42012 31.1
1050939 -14 42011 31.3 Locked 1 4986 96 48 25092 622 11 0.7637 4976 42012 31.1
1050940 -3 42011 31.3 Locked 11 4986 96 48 25092 626 11 0.7638 4972 42011 31.1
1050941 -5 42011 31.3 Locked -2 4985 96 48 25092 625 11 0.7639 5003 42011 31.1
1050942 -6 42011 31.3 Locked -1 4984 96 48 25092 623 11 0.7640 4987 42012 31.1
1050943 -9 42011 31.3 Locked -3 4983 96 48 25092 621 11 0.7641 4989 42012 31.2
1050944 -11 42011 31.3 Locked -2 4981 96 48 25092 623 11 0.7642 4905 42009 31.2
1050945 -12 42011 31.3 Locked -1 4980 96 48 25092 618 10 0.8143 5091 42012 31.2
1050946 -14 42011 31.3 Locked -2 4977 96 48 25092 617 10 0.8144 4967 42010 31.2
1050947 -16 42011 31.3 Locked -2 4975 96 48 25092 615 11 0.8145 5019 42011 31.2
1050948 -4 42011 31.3 Locked 12 4974 96 48 25092 624 11 0.8146 4979 42010 31.2
1050949 -6 42011 31.3 Locked -2 4974 96 48 25092 623 11 0.8147 5065 42019 30.5
1050950 -9 42011 31.3 Locked -3 4973 96 48 25092 621 11 0.8148 4987 42016 30.4
1050951 -12 42010 31.3 Locked -3 4971 96 48 25092 623 12 0.8149 4988 42017 30.4
1050952 -13 42010 31.3 Locked -1 4969 96 48 25092 618 12 0.8150 4995 42017 30.4
1050953 -14 42010 31.3 Locked -1 4967 96 48 25092 616 12 0.8151 4976 42016 30.4
1050954 -14 42010 31.3 Locked 0 4965 96 48 25092 617 12 0.8152 5036 42018 30.4
1050955 -17 42010 31.3 Locked -3 4962 96 48 25092 616 12 0.8153 4964 42016 30.4
1050956 -3 42010 31.3 Locked 14 4963 96 48 25092 624 11 0.8354 5017 42017 30.2
1050957 -5 42010 31.3 Locked -2 4963 96 48 25092 624 11 0.8355 4991 42017 30.2
1050958 -6 42010 31.3 Locked -1 4962 96 48 25092 627 11 0.8356 4995 42018 30.2
1050959 -9 42010 31.3 Locked -3 4962 96 48 25092 620 11 0.8357 5010 42018 30.2
1050960 -11 42010 31.3 Locked -2 4960 96 48 25092 619 11 0.8358 5006 42018 30.2
1050961 -12 42010 31.3 Locked -1 4959 96 48 25092 619 11 1.0759 4984 42018 30.2
1050962 -14 42010 31.3 Locked -2 4957 96 48 25092 617 11 1.0760 5010 42019 30.2
1050963 -15 42010 31.3 Locked -1 4955 96 48 25092 617 12 1.0561 4992 42018 30.2
1050964 -17 42010 31.3 Locked -2 4952 96 48 25092 614 12 1.0562 4949 42017 30.4
1050965 -4 42010 31.3 Locked 13 4953 96 48 25092 625 12 1.0563 5033 42017 30.4
1050966 -7 42010 31.3 Locked -3 4952 96 48 25092 623 12 1.0564 4945 42016 30.4
1050967 -9 42010 31.3 Locked -2 4952 96 48 25092 622 11 1.0765 5001 42017 30.4
1050968 -10 42010 31.2 Locked -1 4951 96 48 25092 620 11 1.0766 4992 42017 30.4
1050969 -12 42010 31.3 Locked -2 4950 96 48 25092 619 10 1.0767 5025 42018 30.2
1050970 -13 42010 31.3 Locked -1 4948 96 48 25092 620 10 0.8368 5010 42018 30.2
1050971 -15 42010 31.3 Locked -2 4946 96 48 25092 616 10 0.8369 4978 42018 30.2
1050972 -17 42010 31.3 Locked -2 4944 96 48 25092 616 11 0.8370 4984 42017 30.2
1050973 -5 42010 31.3 Locked 12 4944 96 48 25092 624 10 0.8371 5034 42018 30.2
1050974 -7 42010 31.3 Locked -2 4944 96 48 25092 623 10 0.8372 4990 42018 30.2
1050975 -9 42010 31.3 Locked -2 4944 96 48 25092 620 10 0.8373 5003 42019 30.2
1050976 -11 42010 31.3 Locked -2 4943 96 48 25092 619 10 0.8374 5012 42019 30.2
1050977 -14 42010 31.3 Locked -3 4942 96 48 25092 623 10 0.8375 4960 42018 30.1
1050978 -2 42010 31.3 Locked 12 4942 96 48 25092 626 10 0.8376 5023 42018 30.1
1050979 -4 42010 31.5 Locked -2 4943 96 48 25092 625 10 0.8377 4993 42019 30.1
1050980 -6 42010 31.3 Locked -2 4943 96 48 25092 623 10 0.8378 4980 42019 30.1
1050981 -8 42010 31.3 Locked -2 4943 96 48 25092 622 10 0.8379 5012 42019 30.2
1050982 -10 42010 31.3 Locked -2 4942 96 48 25092 620 10 0.8380 4975 42018 30.2
1050983 -11 42009 31.3 Locked -1 4941 96 48 25092 620 11 0.8381 4969 42017 30.2
1050984 -12 42009 31.3 Locked -1 4940 96 48 25092 619 10 1.0782 4983 42018 30.2
1050985 -13 42009 31.3 Locked -1 4939 96 48 25092 617 10 1.0783 5034 42018 30.2
1050986 -15 42009 31.3 Locked -2 4937 96 48 25092 616 10 1.0784 4992 42018 30.2
1050987 0 42009 31.3 Locked 15 4938 96 48 25092 628 10 1.0785 5004 42019 30.1
1050988 -3 42009 31.3 Locked -3 4939 96 48 25092 626 10 1.0786 5003 42019 30.1
1050989 -4 42009 31.3 Locked -1 4940 96 48 25092 629 10 1.0787 4971 42018 30.1
1050990 -6 42009 31.3 Locked -2 4940 96 48 25092 622 11 1.0688 5039 42018 30.1
1050991 -7 42009 31.3 Locked -1 4940 96 48 25092 621 10 1.0789 5010 42021 30.1
1050992 -8 42009 31.2 Locked -1 4939 96 48 25092 621 10 1.0790 5002 42019 30.1
1050993 -10 42009 31.3 Locked -2 4939 96 48 25092 621 10 1.0791 4976 42020 30.1
1050994 -12 42009 31.3 Locked -2 4938 96 48 25092 619 10 0.8392 5017 42020 30.1
1050995 -14 42009 31.3 Locked -2 4936 96 48 25092 618 12 1.0593 4981 42020 30.0
1050996 -1 42009 31.3 Locked 13 4937 96 48 25092 631 12 1.0694 5002 42020 30.1
1050997 -3 42009 31.3 Locked -2 4938 96 48 25092 626 12 1.0695 4953 42019 30.1
1050998 -4 42009 31.3 Locked -1 4938 96 48 25092 626 12 1.0696 4975 42018 30.2
1050999 -6 42009 31.3 Locked -2 4938 96 48 25092 622 12 1.0697 4985 42018 30.2

Looking at that log, I also noticed my LM35 temp (last column) spikes when this happens. Which is strange considering the GPSDO is inside of an enclosure and insulated. Wonder if maybe the OXCO temperature regulation circuitry is going out?

[thinkfat]

At T=96 you have not yet eliminated GPS uncertainty. You need a longer time constant for that, especially when you're not using sawtooth correction.
Also, make sure you have calibrated the gain correctly. This is pretty important to obtain good stability of the regulation.

[W3AXL]

At T=96 you have not yet eliminated GPS uncertainty. You need a longer time constant for that, especially when you're not using sawtooth correction.
Also, make sure you have calibrated the gain correctly. This is pretty important to obtain good stability of the regulation.

Yep, I have calibrated my gain and it's 27, which seems high for an OCXO. Unfortunately, I can't go past T=100 with this revision for whatever reason. It just never locks. I'm guessing the tuning resolution probably just isn't fine enough.

I do have a newer revision PCB that I've built and am testing for my friend, and that one is miles better. Gain of 16 and actually has a good MDEV plot. I guess if nothing else I can just build another one of those...

[thinkfat]

Locking is not a question of tuning resolution. If the GPSDO doesn't lock at higher T, the OCXO is drifting too fast for the regulation to keep up. Try setting a smaller "damping" parameter. I think the default is "2", but you can easily set it to 1 without risking instability.

[W3AXL]

Well initially I thought setting damping to 1.0 had fixed things, but this morning the GPSDO is unlocked again. I guess my OXCO must be going out. Not sure what else it could be.

[MIS42N]

Well initially I thought setting damping to 1.0 had fixed things, but this morning the GPSDO is unlocked again. I guess my OXCO must be going out. Not sure what else it could be.

I've had only one OCXO fail, the input impedance of the control pin went from a couple of hundred kΩ to about 5kΩ  - no idea why. One thing to look at.

I had trouble figuring your log with no heading, two columns with figures in the 420xx range - which one is the control voltage? One is going down slowly which was the initial symptom of my OCXO, then it just dropped away and failed. I looked at everything except the OCXO as I've used quite a few and none failed before (whereas with experimentation lots of other things went wrong).

[W3AXL]

Well initially I thought setting damping to 1.0 had fixed things, but this morning the GPSDO is unlocked again. I guess my OXCO must be going out. Not sure what else it could be.

I've had only one OCXO fail, the input impedance of the control pin went from a couple of hundred kΩ to about 5kΩ  - no idea why. One thing to look at.

I had trouble figuring your log with no heading, two columns with figures in the 420xx range - which one is the control voltage? One is going down slowly which was the initial symptom of my OCXO, then it just dropped away and failed. I looked at everything except the OCXO as I've used quite a few and none failed before (whereas with experimentation lots of other things went wrong).

The first 42xxx column is the one you're looking for. I've added in some extra NMEA columns for # of sats and HDOP, but I'm not sure what the last few columns in my log are.

It does appear to be decreasing, but extremely slowly. A few days and restarts later and it's now around 419xx. I've got my rev E PCB running alongside the rev D model now, we're doing a direct head-to-head run. I'll let these cook for a few days to see just how much better my later revision design is. Appreciate the help everyone.

As a sidenote, I'm using my rev E PCB as the reference for the ARRL Frequency Measurement Test this evening. Wish me luck!

[thinkfat]

Hi,

for all of you wanting to find out the actual performance of your GPSDOs: Forum user @erikka has made a pretty ingenious firmware implementation for the nanoVNA-H4. It turns the device into a very precise phase-frequency analyzer that is ideal to measure the stability of the 10MHz output of your GPSDO.

Website here: https://www.tinydevices.org/wiki/pmwiki.php?n=TinyPFA.Homepage

BR,
Matthias

[0xFFF0]

I think this box is more convenient. But the solution with the NanoVNA is interesting.

[W3AXL]

Curious what you guys think could be the issue here.

I built up another one of my GPSDO boards, and after calibrating the gain and linearizing the TIC it's having all kinds of problems keeping lock. It's running an M8T module surveyed in to around 0.6m STDEV and has a consistent 8-10 satellites and a good skyview.
Here's a plot from my plotting tool showing a couple things. Top graph is the TIC value and diff_ns value. Middle is the DAC output value, and bottom is # of satellites in view. I normally also plot HDOP but since it's a surveyed-in module that always stays at 99.



OCXO is a Bliley NV47x, which I've had good luck with. Gain is 25 which isn't unreasonable for an oven as far as I can tell. I've been running it at a TC anywhere from 96 to 128 with the same results. Thinking this one might have a drift issue of some kind. Notice as soon as the loop closes and the DAC value is held constant, the OCXO quickly drifts low.

I'm going to scrounge up another OCXO to test with, but I'd love to hear the thoughts of the group.

[thinkfat]

Yes, the OCXO drifts faster than the regulation can cope with once it's switching into "locked" mode. If you're sure about the gain, check the filter coefficient for the TIC input prefilter. It might be too slow. Also, check the "damping" parameter. It might be too high. Try setting it to 1.

All in all one can see that the GPSDO is in principle working because it gets the phase locked, but then the bandwidth is too narrow to follow the OCXO.

[MIS42N]

Curious what you guys think could be the issue here.

Is it possible a bad earth and hum is getting in causing a beat with the mains.

[nealix]

Curious what you guys think could be the issue here.

Is it possible a bad earth and hum is getting in causing a beat with the mains.

:-)   Look at his graph.   It is a cycle with an approx ~10 minute period.   That can't be 50 or 60 Hz mains, can it?
(It is possible I missed something)

Cheers,

Neal

[W3AXL]

Well, I swapped with another Bliley OCXO and it seems to be behaving better so far. I made sure to re-run the linearization and gain calibration as well.

I guess you can't expect too much with these secondhand salvaged ovens. They aren't exactly gentle when they remove them from the looks of it. At least they're cheap!

[MIS42N]

Curious what you guys think could be the issue here.

Is it possible a bad earth and hum is getting in causing a beat with the mains.

:-)   Look at his graph.   It is a cycle with an approx ~10 minute period.   That can't be 50 or 60 Hz mains, can it?
(It is possible I missed something)

Cheers,

Neal

The power company try to keep the mains frequency exact at 50 or 60 Hz so that clocks that use the mains as a reference are accurate. However there are deviations due to load changes. If hum gets into the detector, it will bias the result. If the mains were exactly right that bias would be the same point in the cycle when the 1pps arrives, would not affect the timing. But if the phase changes slightly each second you get something like what OP saw. It was a long shot, but the regularity of the error makes me think of external influences rather than internally generated. Probably wrong, but I would check it out to make sure.

[W3AXL]

Things are looking much better now, except there seems to be a very slow downward drift in my DAC values. Wondering if this oven is also having issues, or if it's still not totally stabilized. This is after about 5 hours of runtime.

[MIS42N]

Things are looking much better now, except there seems to be a very slow downward drift in my DAC values. Wondering if this oven is also having issues, or if it's still not totally stabilized. This is after about 5 hours of runtime.

I have powered up quite a few second hand OCXO. Many take a day to settle in, and may show an improvement for a few days after that.

I had a further thought about the previous OCXO - was its thermostat working properly? If it was cycling every 10 minutes that could produce the problem you saw. Could confirm it with an infrared thermometer if you have one.

[thinkfat]

Just graph the DAC curve over a few days. You'll see it flattening out as time goes on. OCXO "retrace" is a thing. When you power up an OCXO that has been off for a longer time period, it goes through a cycle of accelerated aging that can last days or even weeks. At least it behaves much better than the one you've tried before.