Lars DIY GPSDO with Arduino and 1ns resolution TIC

[Mike99]

Looking at the MDEV and the raw data graphs I'd say, it's working fine. I believe the diff_ns jumps are just quantization artifacts. The raw phase error data does not suggest any particular problem like phase jumps. Also, no excessive drift or similar.

Thank you, that's good to hear. I think the Vectron OCXO was a bargain (I bought two at that price and they arrived from China in a week).

I will persevere with temperature compensation but it may not be worth the effort!

Mike

[oz2cpu]

Q1 :
post 1 is always updated with the last goodies ?
so anyone who like to try make one, only need to look at post 1 ?

Q2 :
5V for arduino is normally not that clean, and this voltage is used to drive the VCO voltage via pwm,
is that a good idea ?
or are we missing a note about how to make a super clean and stable 5V for the arduino

PS: THANKS LARS.. for sharing, i am so much ready to make this project

[thinkfat]

Q1 :
post 1 is always updated with the last goodies ?
so anyone who like to try make one, only need to look at post 1 ?

Q2 :
5V for arduino is normally not that clean, and this voltage is used to drive the VCO voltage via pwm,
is that a good idea ?
or are we missing a note about how to make a super clean and stable 5V for the arduino

PS: THANKS LARS.. for sharing, i am so much ready to make this project

As Lars sadly is no longer with us, I'm afraid nobody is updating the 1st post. You'll have to dig.

[oz2cpu]

OMG.. i am sad to hear about that.. ok i do the digging, could have been nice to know where to dig.. 45 pages :-) to search.

[MIS42N]

I did some experiments with a U-blox NEO-6 GPS with active antenna, moving the antenna to different places. My GPSDO design is nothing like Lars, but this may be of interest since Lars' design is also for low cost components. I guess a point of comparison is I use averages up to 768 seconds (3 *2^8 if you want to know why) which is like a loop time constant. The results show there isn't much reason to improve the GPSDO without improving the GPS signal reception.

I was wondering if it was worth $20 to hold the control voltage within 4µV. Answer, not really. It may be with the best of the positions with the antenna on the roof and no obstructing buildings. Like most things, upgrade one part, then have to upgrade another. Get a higher antenna, use a timing GPS module (maybe the dual band costing three figures) then play with power supply stabilisation for a DOCXO (another three figures) etc. etc.

I am currently selling kits for my GPSDO for $55AU (only in AU, includes postage) which includes antenna, GPS module, USB/serial adapter, PCB, OSC5A2B02, support components, 10MHz BNC output into 50Ω - well, basically everything except the 12V power supply and an enclosure. Achieves 1ppb stability (0.2 ppb with the best GPS signals) and is locked long term so has that descending Adev that everybody likes. Any upgrade to one part, match it with other upgrades, cost goes up very quickly. The moral is, as always, you get what you pay for.

[oz2cpu]

MIS42N can you please share a working schematic, and a working arduino file ??

spend all night making one, after warm up, all i see is nolock,
when i scope all things, it apear to be correct

I am also using U-blox NEO-6 , and get super clean 1pps from my gps
I am using a 1ppm 10MHz TCXO
datasheet here
webx.dk/osc.pdf

[MIS42N]

MIS42N can you please share a working schematic, and a working arduino file ??

I think you skipped the bit where I said "My GPSDO design is nothing like Lars". If you are interested, the writeup is here https://www.eevblog.com/forum/projects/budget-gpsdo-a-work-in-progress/

You will find a schematic of the current design near the end of all the posts.

[oz2cpu]

thanks a lot mate, that looks a bit better all over..
but right now all i like to see, is my Lars thingy go into lock
i saw it takes 10 hrs for the VCO voltage to drop 500mV
that is a long time to wait..

[oz2cpu]

FINALLY MADE IT !!
it was not that easy to figure this out :-)
but now it is in lock and i am happy

[oz2cpu]

if you dont own a 74HC390
a good old 7490 can also be used, here is how you do that

See also the note in my schematic, you can ofcourse also use 4046
then it is pin 1 that is the 0-1uS output

[oz2cpu]

I have been playing a lot more with this circuit
added a driver buffer for the 1pps, so it can drive my cable correctly,
now i got fast and tight risetime,
this helped a lot on the nS error signal, see the attached picture

[oz2cpu]

this is not a thing ??

https://www.beis.de/Elektronik/4046vs9046/74HCT4046vs74HCT9046-en.html

[Johnny B Good]

 It seems to be for PC2 output but Lars was using PC3 (pin 15) which, afaiaa, does not have such a dead zone.

 BTW, when you mentioned that ten hours wait for the ocxo's EFC pin to rise a mere 500mV, my first thought had been, "Jeez! I thought hanging in for the two and a half hours it took for my own version of the G3RUH gpsdo to finally establish lock with a 5000s TC was bad enough!!

 I'd only stuck it out because unlike an earlier version with a 1000s TC PLL filter that had refused to get past a sticking point, this looked like it just might eventually reach its goal and I was curious enough to let it continue unmolested. I'd aborted the earlier run and added a 20M ohm 'helper resistor' between the output of the PLL filter and Vcc to brute force its way past its sticking point. This had done the trick, albeit at a slight reduction of the filter's time constant, and was retained as a permanent fix.

 I'm pretty sure I'd used the same 470uF cap, tested for sub nA leakage at 5 volts, so the puzzle of the stickiness of the earlier test build remains an unsolved puzzle - possibly a leakage issue in the cheap paxolin stripboard I'd built it on.

 Since I didn't want to be left hanging in the breeze for two and a half hours waiting for it to resume GPS lock every time I had to power it up (I was still tinkering with it), I came up with a two diode plus trimpot helper circuit to do the initial 'heavy lifting' of the EFC voltage to just shy of the 2.3570 on tune volts by about 150mV, relying on the forward bias current at sub 100mV dropping to less than a nA (12 and 15 volt zenners proving to the best choice over standard silicon diodes like the 1N4000 series for this job). This measure reduced the time to lock from a cold start to only half an hour. 

 The 5000s TC proved a bit too long for the oxco's short term stability so I reverted to a 1200s TC, keeping my speed up circuit in place where it now reduces the time to lock from cold to a mere 10 to 12 minutes, matching the time it takes for the ocxo's oven temperature to stabilise enough for the PLL to finally catch up with the resulting wild frequency swings (tens of mHz).

 Looking at the circuit diagram of the Lars gpsdo you posted, I noticed the use of two pwm pins to create a 16 bit DAC. Presumably the 10 bit ADC is being oversampled to gain an extra 5 to 6 bits to match the effective PWM resolution? I haven't examined the code in detail (or at all, tbh).

==============================================================================================
[EDIT] Whilst scanning Lars's code to get a clue on whether he'd used oversampling, I realised why he'd ganged two pwm pins to create a 16 bit pwm - to make full use of the ADC's 10 bit resolution of course! Mind you, I'm surprised he didn't oversample by 16 and decimate by two to add a couple of extra bits resolution. Perhaps a lack of code space? 
==============================================================================================

 At the time when I first download Lars' documentation, I'd not had any experience in using the Arduino IDE with any of these AVR based SoC boards. However, since spending the past 50 weeks (and counting), programming a Nano to control the base plate temperature of an LPRO-101 in my ongoing RFS project of the last two years, I now have a renewed interest in making a micro controller based alternative to my current gpsdo work horse lab reference and this looks a better bet than Andrew's pet project (for starters, at least).

 I've attached a couple of screen shots of the ruby versus the gpsdo covering a 25 hour and a half interval. The infinite persistence includes the 5 or 6 ns gpsdo disciplining wobble (mostly ionospheric effect) and the leisurely 33ns phase wander of the ruby which appears to be in part, a diurnal artifact.

[oz2cpu]

looks nice, we been performing quite a bit the last few days,
first using the same hardware,
but added a routine to count the 5Mhz, at 1Hz resolution, the AVR can do that just fine
then raw adjusting the DAC in a halve step methode, example :
from 32768 as the first try, then : if too high, then 16384, if still too high, then 8192
if too low now, then 12288 and so forth,
each measurement takes a 3 sec pause, just to be sure the dac filter is stable, after each dac change,
when error is under 1Hz, then call the normal software.
you be amazed how fast the system boots up and lock after this type of start up :-)

[Johnny B Good]

 I should think using a 'binary chop search' would make quite a difference to the lock up time. With a cold start, you still have to wait on the ocxo's oven temperature to stabilise for the frequency to fully settle down though - perhaps another ten to twenty minutes?

 That's the situation I'd had to face even with a hot start when the ocxo has only had a fraction of a second to cool down by a few mK after the briefest of power glitches. The oven temperature controller is obviously driven by a PID algorithm running on some sort of MCU which uses a "Shoot first, ask questions later" startup algorithm that doesn't check whether it actually needs to turn the heater on full blast to reach operating temperature in the shortest possible time.

 For a genuine stone cold start, that's an excellent strategy but the worst possible if it's the result of a few ms dropout of power that's caused the restart. This behaviour becomes very annoying when all you want to do is swap power sources or reroute the dc power feed - the gps module only takes 3 or 4 seconds to recover and start disciplining the ocxo back on frequency, assuming the ocxo didn't misbehave in such a fashion. Unfortunately, the resulting up and down temperature swings keep the PLL futilely trying to keep pace with the resulting frequency swings for the next 10 minutes or so before it can finally settle back down.

 In the end, I'd suffered enough of this ocxo's behaviour that I designed and built a backup power reserve into the gpsdo using a protected LiPo pouch cell. I'd had to add yet a second buck converter into the mix and switch the original buck and boost converter arrangement so I could float charge the LiPo to 65% SOC at 3.85v to power the 12v output boost converter used to power the ocxo and now also the 5v buck powering the logic circuitry (the 5v buck had originally powered the 12v boost).

 This added another 100mW onto the original 1500mW power budget but it was well worth the effort since not only did it remove the annoyance of having to suffer so much disruption for the briefest of interruptions during a power feed change over, it also extended the voltage range from a 6.5v minimum to 24v maximum by another two volts at the low end. In essence I can now use anything from a power bank or 2.1A rated usb wallwart right up to a 22v laptop charging brick and anything in between with a 5W or higher rating (hot swap case). I need a 10W minimum rated psu to handle the demand of a "Black Start" (stone cold ocxo with a discharged LiPo).

 Anyway, the upshot of this final modification being that the startup time is no longer an issue. 

[oz2cpu]

YES  'binary chop search' is the word i was looking for
that is exactly what we are doing, and it works amazingly

true the warm up drift is a thing,
but that should be handeled fine by the normal lock and filter software,
the way that it is today is it monitors the TIC variations over time, and when small enough
it changes the filter parameters, and then turn on the lock led

I suggest two lock leds, one for pre locked frequency mode, and the one we have today,
this means are the error far below 1Hz (1 mins after pow on)
or is it under 10e-10 or even smaller (5-10 mins after power on)

[Johnny B Good]

 What you're achieving with that start up strategy is making use of the GPS's short term stability which compared to a fully stabilised ocxo is poor but still much better than that of an ocxo which is in the process of getting up to temperature.

 Regarding a separate indicator lamp, there are ways to avoid adding another lamp but if you're already relying on only a single indicator lamp for power/gps lock/ocxo lock/or whatever else, a second one wouldn't come amiss since this provides a level of redundancy as to whether a lone completely extinguished lamp indicates power loss, an MCU lockup or simply a faulty LED or the circuitry that drives it. IOW, it helps reduce the guesswork when something goes wrong.

 Of course, if the front panel includes an oled or lcd display, the need for redundant indicator lamps reduces somewhat. I rely on only two indicator lamps (LEDs but let's stick with "lamps") to display the operating state of my gpsdo. The traditional red to show that it's powered up and a green one to show whether the gps receiver is locked/unlocked (steady half brightness or blinking at 4Hz respectively) or whether the user settings have reverted to their defaults (flashing at 1 Hz or extinguished) for any reason.

 This last set of signals are an inheritance from the days when I was using fake M8N modules with no functioning flash limiting the storage of user settings to the BBRAM alone with an 80mF supercap providing a mere 45 minutes of backup time if you don't add the usual fix of a CR2032 coin cell to extend the BBRAM endurance out to some 280 days in the absence of external power.

 Now that I'm using genuine M8T modules with functioning flash storage, I don't really need this status information but since there's still a remote chance of losing the user settings, I retained this functionality anyway. Initially, the red lamp only indicated its powered up status but now that I have a built in backup power source, it blinks at 2Hz to indicate the loss of external power and the switch to backup battery power.

 A reassuringly steady red glow is an unambiguous  indication that all is well, whereas a blinking red lamp is an obvious warning that "There's trouble in Paradise" so it's worth dedicating a lamp to this one task alone - the power status. I was quite pleased with myself in reducing the indicator lamp count to just two but in a discussion regarding the minimum number of indicator lamps to indicate the various operational states of something like a basic gpsdo, I was chided for not being minimalist enough

 When it came to building my RFS, I did elect to go "minimalist" on the indicator lamp count, However there really was no justification to have more than a single bi-colour 2 wire LED for power status. If it was glowing at all, regardless of colour, it was receiving power. Red indicating it was waiting for atomic lock or else green to show it had achieved atomic lock (typically some 3 minutes and ten seconds after being powered up from cold). Also, of course, I had a little SSD1306 oled display to provide a secondary indication that it was indeed in a powered up state.

 Some might argue that I'd not been minimalistic enough and question the use of a LED whilst there was (just enough) room in the display for an "Atomic Lock" symbol forgetting that most failures with these oled panels result in a totally unlit display (either a fault in the module itself or a problem with the wiring or the software running on the attached micro controller).

 I'm rather old skool in my attitude to the more extreme forms of minimalism in regard of front panel displays, meaning I'm all too mindful of the truth expounded by "Murphy's Law". There's no way I can guard against component failure other than to provide some sort of redundancy so I can at least minimise the chance of a single point of failure leaving me totally in the dark as to its most likely cause.

 In the end, the number of front panel indicators I choose to inflict on any of my project enclosures tends to the less extreme minimalist approach, largely on the basis of "The fewer holes I have to drill in this damned panel, the better it is for me!" 

[MIS42N]

Some might argue that I'd not been minimalistic enough and question the use of a LED whilst there was (just enough) room in the display for an "Atomic Lock" symbol forgetting that most failures with these oled panels result in a totally unlit display (either a fault in the module itself or a problem with the wiring or the software running on the attached micro controller).

My GPSDO is about as minimalist as it gets with a microprocessor. There are only two ICs, PIC16F1455 to do the work, 74HC04 to buffer the HCMOS OCXO 10MHz output to provide the 50Ω output. The processor had only one spare pin to drive a LED.

So I implemented a 24 bit shift register that is shifted every 50ms, a 1 bit in the register lights the LED. That encourages some inventive LED use.

At power up, 250ms on, 250ms off means there is no 10MHz from the OCXO (processor runs on its internal clock)
No NMEA data (faulty GPS module?) is 800ms on, 200ms off.
Satellites in view (waiting for GPS to indicate a fix) is indicated in binary over 4 seconds - 50ms on, 50ms off, 50ms on, 350ms off is a zero; 50ms off 50ms on 400ms off is a one. pad with off
NMEA data indicates a fix but no 1pps received - no LED data (another fault condition)
Adjusting control voltage - 400ms on 600 ms off
Locked but not stable - 50ms on, 50ms off, 50ms on, 850ms off
'all is well' - 50ms on 950ms off

The idea is the LED must be doing something if the circuitry is OK. Permanent on is a fault, permanent off is a fault (if it occurs at power up, different fault). It does go against your 'blinking red lamp is an obvious warning that "There's trouble in Paradise" ' (I use a white LED salvaged from Christmas Lights - good visual output with less than 50µA drive). But a one second blink is quite reassuring if it means normality, and it stands out against any background of other power on lights.

Regarding OCXO power on. The OSC5A2B02 I use takes about 3 minutes to be locked and 15 minutes before a guaranteed 10E-9 stability.

[Johnny B Good]

Some might argue that I'd not been minimalistic enough and question the use of a LED whilst there was (just enough) room in the display for an "Atomic Lock" symbol forgetting that most failures with these oled panels result in a totally unlit display (either a fault in the module itself or a problem with the wiring or the software running on the attached micro controller).

My GPSDO is about as minimalist as it gets with a microprocessor. There are only two ICs, PIC16F1455 to do the work, 74HC04 to buffer the HCMOS OCXO 10MHz output to provide the 50Ω output. The processor had only one spare pin to drive a LED.

So I implemented a 24 bit shift register that is shifted every 50ms, a 1 bit in the register lights the LED. That encourages some inventive LED use.

At power up, 250ms on, 250ms off means there is no 10MHz from the OCXO (processor runs on its internal clock)
No NMEA data (faulty GPS module?) is 800ms on, 200ms off.
Satellites in view (waiting for GPS to indicate a fix) is indicated in binary over 4 seconds - 50ms on, 50ms off, 50ms on, 350ms off is a zero; 50ms off 50ms on 400ms off is a one. pad with off
NMEA data indicates a fix but no 1pps received - no LED data (another fault condition)
Adjusting control voltage - 400ms on 600 ms off
Locked but not stable - 50ms on, 50ms off, 50ms on, 850ms off
'all is well' - 50ms on 950ms off

The idea is the LED must be doing something if the circuitry is OK. Permanent on is a fault, permanent off is a fault (if it occurs at power up, different fault). It does go against your 'blinking red lamp is an obvious warning that "There's trouble in Paradise" ' (I use a white LED salvaged from Christmas Lights - good visual output with less than 50µA drive). But a one second blink is quite reassuring if it means normality, and it stands out against any background of other power on lights.

Regarding OCXO power on. The OSC5A2B02 I use takes about 3 minutes to be locked and 15 minutes before a guaranteed 10E-9 stability.

 The nice thing about these DIY projects is the freedom to be as minimalist as you like. Presumably you made up a "Cheat sheet list" of the blink codes as an aide-mémoire for the more obscure ones.

As I mentioned, I'm a little "Old School" in my thinking in regard of the indicator lamp count, preferring to give the power status indicator a whole lamp of its own with one (or more) indicator lamps to indicate other vital information. I realise that modern LED lamps are just as, if not more reliable than, the rest of the component parts soldered onto the PCB(s) inside the box making the need for such redundancy a moot point.

 Even so, having a second indicator lamp provides a sanity check as to why an indicator unexpectedly remains unlit when it should be doing something. In the case of my G3RUH inspired GPSDO, the only microcontroller in the box was the one inside the Ublox M8N and M8T modules I was using which allowed me push out additional status information via the green LED.

 The use of a separate red LED to show power status had been a 'no brainer' choice as far as I was concerned, after all it was just a simple dropper resistor connection to the Vcc line, about as simple as it gets with no complications over interpreting its meaning (at least not until I'd added the battery back up feature ). Even I wasn't so lazy as to avoid having to drill a second hole in "That damned front panel".

 I appreciate the minimalist aesthetic but prefer to have some modicum of redundancy in the status indicator array, even if the "array" is just two lamps or one plus an oled or lcd panel. If you're using an oled display, you definitely need a separate power on indicator lamp. A backlit LCD panel, not so much, since the backlight makes for an effective power on indicator lamp in its own right.

 I could so easily go on about the subject but I think I've said more than enough and in danger of committing the cardinal sin of "Trying to teach granny how to suck eggs." I've probably already committed this 'cardinal sin' but, what the Hey! The deed is done. 

[iMo]

..That encourages some inventive LED use.
..At power up, 250ms on, 250ms off means there is no 10MHz from the OCXO (processor runs on its internal clock)..

Would not be better to learn Morse code? There are tons of source code for generating morse..
 
73

[iMo]

BTW, when you mentioned that ten hours wait for the ocxo's EFC pin to rise a mere 500mV, my first thought had been, "Jeez! I thought hanging in for the two and a half hours it took for my own version of the G3RUH gpsdo to finally establish lock with a 5000s TC was bad enough!!
..

To design the filter for Miller's design is not easy, indeed. I made a tool some time back to help with the design of the filter, and in my case the waiting time was not longer than 30 minutes.
Btw, it has been my understanding the Lars' design starts fine almost immediately as the mcu remembers the last EFC voltage (that is a great advantage over the Miller, sure).

https://www.eevblog.com/forum/projects/gpsdo-with-xor-phase-comparator-control-loop-filter-design/msg3458070/#msg3458070

[MIS42N]

..That encourages some inventive LED use.
..At power up, 250ms on, 250ms off means there is no 10MHz from the OCXO (processor runs on its internal clock)..

Would not be better to learn Morse code? There are tons of source code for generating morse..
 
73

With messages in Estonian.
In practice, only one indication is useful. Single flash once a second? Yes - all good. No - there's a problem. The rest are window dressing.

[W3AXL]

So I'm fighting some GPS issues and I'm curious to hear the group's thoughts.

I've got a marine GPS antenna up on the eaves with a pretty good look to the sky. I'm running it down into a 4-way splitter (1 DC pass + 3 DC block) to have multiple GPS drops for different GPSDO designs I'm testing.

I'm trying to survey-in a few M8Ts, and I can't seem to get the position StDev below about 3, whereas below 1 is desired for accurate timing. I've noticed my ADEV for the "baseline" GPSDO I've built is also rather bad with this new setup.  I know I take a 6 dB hit with the splitter, but there seem to still be plenty of birds in-view and in-use so I'm curious if it's just a signal level issue, and if adding an LNA inline would help things at all.

[MIS42N]

So I'm fighting some GPS issues and I'm curious to hear the group's thoughts.

I've got a marine GPS antenna up on the eaves with a pretty good look to the sky. I'm running it down into a 4-way splitter (1 DC pass + 3 DC block) to have multiple GPS drops for different GPSDO designs I'm testing.

I'm trying to survey-in a few M8Ts, and I can't seem to get the position StDev below about 3, whereas below 1 is desired for accurate timing. I've noticed my ADEV for the "baseline" GPSDO I've built is also rather bad with this new setup.  I know I take a 6 dB hit with the splitter, but there seem to still be plenty of birds in-view and in-use so I'm curious if it's just a signal level issue, and if adding an LNA inline would help things at all.

My opinion. If you have enough satellites (I think 6 is enough) 40dB and over you don't need an LNA. Others have said there are benefits to programming the GPS to limit the sky view and/or not use all the available constellations. I use crap GPS modules so I don't have experience there. Monitor the DOP (dilution of precision), it may indicate some sort of problem - reflection off nearby structures etc. One place I tried my antenna it showed a full sky view when mapped despite being squeezed between two buildings. That makes me think some signals were reflections; the GPSDO performed poorly. The DOP was over 2 for around 20% of the time, whereas with a good sky view it doesn't ever go over 2.

I use GPSview to monitor, with my good antenna place and an Neo-7 it shows a std deviation of around 1 meter. So 3 seems a bit high, worthy of investigation. If you think signal strength is an issue, why not run monitoring for a day without the splitter, then another day with it in. That should show if there's a difference.

[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.