Lars DIY GPSDO with Arduino and 1ns resolution TIC

[Solder_Junkie]

There is another issue with the circuit by Murray, the use of parallel connections to the outputs of the hex inverters is plain wrong, as is using a 100 Ohm series resistor on the output of two in parallel. If you take the scenario of a short on the output, the hex inverters will be trying to draw excessive current and may fail. The correct method of using inverters as buffer stages for a 50 Ohm output is to use four inverters with a 200 Ohm series resistor on each, this article shows the method:
http://www.jrmiller.online/projects/ministd/manual.pdf

I will try to model the TIC circuit by Lars, but by all accounts it works fine.

SJ

[bingo600]

using a 100 Ohm series resistor on the output of two in parallel.

If it was for adapting the impedance to 50ohm i agree.

However i also have seen 100ohm used in output chains, just to dampen ringing.

/Bingo

[iMo]

Mind a naked CMOS output has got some output impedance already.
Look at the output's voltage/current characteristic and you'll get it.
Thus adding 200ohm into each of 4 paralleled outputs (or 100ohm with 2) will not create 50ohm, imho..

[MIS42N]

In my design I used 5 parallel outputs with 270 ohm resistor in each. The 270 ohm is enough to limit current with a continuous short. And it provides a very nice square wave into a 50 ohm load.

That said, the unloaded output is near 5V P-P which can overload some devices. If I do a redesign, I was thinking two gates in parallel each with 330 ohm, in series with a 68 ohm across the output. A much smaller P-P unloaded and should suppress most ringing into 50 ohm. Also frees 3 gates for other uses - a generated 1PPS maybe.

All vaporware ATM.

[AndrewBCN]

There is another issue with the circuit by Murray, the use of parallel connections to the outputs of the hex inverters is plain wrong, as is using a 100 Ohm series resistor on the output of two in parallel. If you take the scenario of a short on the output, the hex inverters will be trying to draw excessive current and may fail. The correct method of using inverters as buffer stages for a 50 Ohm output is to use four inverters with a 200 Ohm series resistor on each, this article shows the method:
http://www.jrmiller.online/projects/ministd/manual.pdf

I will try to model the TIC circuit by Lars, but by all accounts it works fine.

SJ

Hi SJ,
You may want to check a few pages back in this thread, where you'll find some fine DSO captures of the actual workings of Lars' TIC. It's certainly very interesting to model Lars' TIC, but I suggest you possibly may find it quite fun tp assemble Lars' DSO to examine its workings. Also a few pages back you'll find some pictures of Lars' GPSDO which I have assembled on a breadboard, it can in fact be put together in a couple of hours if you already have the parts. 

[W3AXL]

Seeing a strange issue with my current GPSDO, looking for some opinions

Last week I replaced the Bliley OCXO in my GPSDO with one of those smaller CTI 10MHz OCXOs since I got a big bunch of them for a good price. I was letting it retrace all week, watching the DAC value slowly go down, until today when I noticed I'd lost lock. Here's a nice plot of several log values over the last week:

Everything seems like it was okay until about day 5, where the first big DAC spike occurs. The loop slowly brings things back down again, but the latest data shows the loop seems to be failing to keep the oscillator stable.

The oscillator starts drifting like crazy, the loop brings it back in, and then the oscillator drifts again. It's happening on a period of approximately 12 minutes or so. GPS is fine, this is on a surveyed-in M8T, so the PPS shouldn't be going wacky. I'm guessing the CTI OCXO has just failed in some way?

[Solder_Junkie]

Patrick, my guess is that it’s the oven. My Lars GPSDO has a high grade NEC oven and M8T, with a roof mounted “mushroom” antenna. During the past week it hasn’t missed a beat, although I don’t have it connected to USB, only monitoring via a ZL1BPU LCD display on the Arduino. My timing loop is set for 120 seconds, but that obviously depends on the stability of the oven.

Attached is a plot of my GPSDO with 30, 60 and 120 seconds loop time setting. Damping is 6. The reference is a rubidium and a TinyPFA (phase frequency analyser).

73 SJ

[MIS42N]

Seeing a strange issue with my current GPSDO, looking for some opinions
...
Everything seems like it was okay until about day 5, where the first big DAC spike occurs. The loop slowly brings things back down again, but the latest data shows the loop seems to be failing to keep the oscillator stable.
...
The oscillator starts drifting like crazy, the loop brings it back in, and then the oscillator drifts again. It's happening on a period of approximately 12 minutes or so. GPS is fine, this is on a surveyed-in M8T, so the PPS shouldn't be going wacky. I'm guessing the CTI OCXO has just failed in some way?

I've powered up quite a few of the OSC5A2B02. One was DOA, one went weird, the rest have been OK. The weird one control input resistance dropped and eventually was too low to maintain lock. I guess at the price you get what you pay for. I replaced it with another, was OK. I've had one powered now for months, its control volts was around 1.6V a week after I powered it up and it still is around 1.6V. Might last years.

I would be inclined to replace the OCXO first, start debugging if it doesn't fix the problem. If that's not your style, do you have a meter good enough to see the change of DAC voltage at the OCXO pin? Then you can see if the change is real, or something like a dry joint.

[W3AXL]

Thanks guys. Thankfully I've got 30 of the things so I just did a quick swap and it's running again now. We'll see if it works any better.

[W3AXL]

Welp, sadly the new oscillator has the same issue



Obviously, that implies a hardware fault somewhere on the mainboard. But since everything else is working fine, it's got to be something directly related to the OCXO itself.

I wonder if maybe it's drawing too much current for the oven from the 5V rail through my ferrite bead - the voltage could be sagging just enough to cause the internal circuitry to freak out periodically like we see in the plot.

[Solder_Junkie]

Patrick, if you shorten the loop time, does it remain in lock, or is the problem still there?

SJ

[W3AXL]

that definitely seems to be part of the problem. I was originally running with a TC of 128. I halved it to 64 and it seems to be running fairly stable now.

Are these CTI OCXOs just a little more drifty than, say, the Bliley OCXO I was using previously? I was able to stretch my TC up to 128 and above easily with that one.

[MIS42N]

Are these CTI OCXOs just a little more drifty than, say, the Bliley OCXO I was using previously? I was able to stretch my TC up to 128 and above easily with that one.

First time powered up they are very drifty for at least a day, and get much better over a week. They are fine if (1) you keep it powered (2) don't move it. I suggest just monitor daily, look for tiny improvements.

[Dbldutch]

W3AXL,

OCXO's like the OSC5A2B02 you're using have a very flimsy package. They are therefore very sensitive to ambient temperature changes.
Compare that to a Bliley or an Oscilloquartz and the likes, which have a much more thick casing, and most likely, also a better oven regulation.
The other reason that you are seeing these fluctuations can be due to the instability/drift of the voltage at the adjustment pin (CV). I don't mean the DAC changes, but really the stability of the voltage that you can measure when the DAC output is fixed (like with h32767). Variations in micro Volts can already have an effect on the OCXO output frequency and will effect the controlling loop.

When you can keep these two factors under control, a TC of say 500 should pose no problem.

I went through a lot of work to reduce both effects in my GPSDO.
Have a look here for possible inspiration: https://www.paulvdiyblogs.net/2023/06/gpsdo-version-4.html


A little heads-up is probably in place. It's easy to get sucked in to the deep and dark rabbit hole of time-nutters.
Enjoy!

[Solder_Junkie]

OCXO's like the OSC5A2B02 you're using have a very flimsy package. They are therefore very sensitive to ambient temperature changes.
<SNIP>

When you can keep these two factors under control, a TC of say 500 should pose no problem.
<SNIP>
A little heads-up is probably in place. It's easy to get sucked in to the deep and dark rabbit hole of time-nutters.

It is also easy to become fixated on running long time constants, unless you can reasonably accurately measure the stability I don't think there is any point in increasing the time constant beyond the point where the short term stability improves. With my NEC Toyocom oven, going from a TC of 60 seconds to 120 seconds only improves the short term wandering by 1E-11. From a warm or cold start, 120 seconds is about the longest TC that my unit will lock in a reasonable time, which takes around 20 to 30 minutes after the 7 mins oven warm up delay.

I have some foam insulation over the TIC parts, as suggested by Lars, but I have no temperature measurement, compensation or cabinet heater.

I have no experience with the CTI ovens, as I am fortunate in having a couple of NEC TCO-6703N ones that are probably an order of magnitude better... although the spec is a bit vague: Temperature Stability  +/-2.5x10^-9, Ageing:  +/-2x10^-10 (per day), +/-3x10^-8 (per year), Frequency trim:  +/-0.3ppm (0-5V). They are larger than a CTI oven and draw 1A (cold) and 300mA (warm) from 12 Volts.

I am happy that my home made Lars/Muray Greenman GPSDO has around 10 times better short term stability/jitter than a Leo Bodnar GPSDO and 4 times better than a G3RUH Simple GPSDO, as measured using a TinyPFA (phase frequency analyser) and TimeLab. The limitation I have is that my reference is a rubidium with a spec of 1 second Allan Var 1E-10, 10 second Allan Var 3.16E-11 and 100 sec of 1E-11. I am really only interested in the short term stability for use with test equipment and to keep my ham radio gear on frequency.

SJ

[MIS42N]

OCXO's like the OSC5A2B02 you're using have a very flimsy package. They are therefore very sensitive to ambient temperature changes.
Compare that to a Bliley or an Oscilloquartz and the likes, which have a much more thick casing, and most likely, also a better oven regulation.
The other reason that you are seeing these fluctuations can be due to the instability/drift of the voltage at the adjustment pin (CV). I don't mean the DAC changes, but really the stability of the voltage that you can measure when the DAC output is fixed (like with h32767). Variations in micro Volts can already have an effect on the OCXO output frequency and will effect the controlling loop.

I agree with the second reason. The OSC5A2B02 is more sensitive to changes of control voltage than many other OCXO. Its sensitivity is about 1 part per million/V. i.e. a change of 1V changes the frequency by 10Hz. A Morion MV89 is 0.1 ppm/V - 10 times better. The MV89 also has an internal precision voltage source from which CV can be derived.

The quoted sensitivity to temperature change of the OSC5A2B02 is ±10ppb over its full operating temperature 0-75°C so less than 1ppb/°C. If the OCXO was in the weather this might have some effect, but in an indoor situation the temperature normally changes quite slowly, and most OCXOs would be in some sort of enclosure which gives even more isolation. So I don't think the OCXO is directly affected by temperature as much as indirectly by other components. A typical voltage regulator (7805) changes output measured in parts per million/°C. If the same regulator is supplying an IC that is the output, plugging a lead into the output can also cause a voltage change.

My design is different to Lars, the CV is not adjusted each second, but once every 1024 seconds. The largest adjustment in the last 5 hours (which is how much history is stored in the uP) was 4.2*10^-11 Hz. These adjustments are mainly dictated by the crappy GPS signal from a NEO-7, not temperature. The OCXO runs off a different regulator to the rest of the circuit and the CV is derived through a precision regulator and is varied in steps of less than 1µV. A test a while back with an M8T reduced this to around 2*10^-11 Hz with a crappy antenna. I have yet to put up a decent antenna, doing some renovations instead.

[thinkfat]

The better the stability of your timing reference signal, the shorter time constants you can afford without impacting the output stability.

However, the longer the time constant, the less the control loop will be able to compensate for other influence than OCXO aging, especially temperature, the more effort you need to spend on compensating or eliminating those external factors.

[RikV]

Is there  -on GitHub or elsewhere- a complete project available for DIY of this GPSDO project? I've read most of this thread but I got lost in the woods...

[Gyro]

Not unless somebody else has put it up. Lars sadly died a few years ago.

[enut11]

Is there  -on GitHub or elsewhere- a complete project available for DIY of this GPSDO project? I've read most of this thread but I got lost in the woods...

@RikV, have you looked at the Budget GPSDO project by @MIS42N. There is a partial kit for the hard-to-get parts available for this project at Silicon Chip (Australia). I built one and it works well.

https://www.eevblog.com/forum/projects/budget-gpsdo-a-work-in-progress/

[Solder_Junkie]

Is there  -on GitHub or elsewhere- a complete project available for DIY of this GPSDO project? I've read most of this thread but I got lost in the woods...

See : https://www.qsl.net/g4aon/gpsdo/

There is a complete circuit diagram and a link to the Murray Greenman LCD display version of the Lars GPSDO. Sadly Murray has also died, but his web page is still available inc the Arduino code

SJ

[Dbldutch]

@RikV,
There is a lot of information available for a DIY build on my Blog. Somewhere earlier on this forum there are references to my Blog.
A first version, and later a version 3 and a "final" version 4 is described in a lot of detail. Everything (Schematics, Gerbers, details, script etc.) is available for a DIY build.
Several people have already successfully build these versions.

https://www.paulvdiyblogs.net/2020/07/a-high-precision-10mhz-gps-disciplined.html
https://www.paulvdiyblogs.net/2023/05/a-new-gpsdo-design-v3.html
https://www.paulvdiyblogs.net/2023/06/gpsdo-version-4.html

Have fun!

Paul

[Johnny B Good]

@RikV,
There is a lot of information available for a DIY build on my Blog. Somewhere earlier on this forum there are references to my Blog.
A first version, and later a version 3 and a "final" version 4 is described in a lot of detail. Everything (Schematics, Gerbers, details, script etc.) is available for a DIY build.
Several people have already successfully build these versions.

https://www.paulvdiyblogs.net/2020/07/a-high-precision-10mhz-gps-disciplined.html
https://www.paulvdiyblogs.net/2023/05/a-new-gpsdo-design-v3.html
https://www.paulvdiyblogs.net/2023/06/gpsdo-version-4.html

Have fun!

Paul

 First off, I have to take my hat off at your tenacity in overcoming the effect of temperature on a micro-controller based gpsdo design.

 I read through all those blogs, aghast at all the extra complication being introduced to match the stability of a G3RUH design where this issue of temperature effect is effectively subsumed into the PLL feedback correction. By the time I got to looking at the latest blog, I have to admit my eyes were starting to glaze over.

 I've been tempted to trial a micro-controller based gpsdo design over the past three years but this issue of temperature stability has been the main reason why I've been sticking with the modern day variation of the James Miller design as offered by Gyro's post which had inspired my very first attempt at lashing together the most basic of gpsdo circuits onto a solderless breadboard.

https://www.eevblog.com/forum/projects/my-u-blox-lea-6t-based-gpsdo-(very-scruffy-initial-breadboard-stage)/msg1493431/#msg1493431

Rather pragmatically, I'd omitted the cmos rro opamp (I didn't have one to hand at the time) and fed the filtered output from the pll directly to the efc pin on my 13MHz ocxo (divided down to 10MHz with a rather cunning but noisy ttl circuit). It worked surprisingly well and I only recently discovered the reason why I'd been able to get away with is additional 'simplification' being the G ohm input impedance of the ocxo I'd been using.

 Like you, I'd been motivated by the 'infamous' FY6600-60M arbitrary wave generator which amongst several other improvements, now sports a 10MHz ocxo which can be frequency injection locked to an external reference I can plug in or out without the need to power cycle it each time as Tony Albus has to do with his FY6600. The ocxo has its own independent 12v 6W smpsu to keep it powered all the time it is plugged into a mains outlet (a 1.3W vampire load) to eliminate the warm up time whenever I wish to use the generator and, more importantly, eliminate the issue of 'retrace'.

 The first boxed up gpsdo (the MK I) had been based upon that breadboard lashup (with an RRO opamp included) built onto stripboard (not a quiet combination with all the extra ttl circuitry to generate 10MHz from a 13MHz ocxo - I could barely pick out the 1.2MHz switching frequency of the tiny Mini 360 24v to 5v buck converter from all the ttl noise on the Vcc rail when looking at the noise spectrum. I had to add a 10MHz xtal in series with the LPF output filter to filter out the close in frequency harmonics generated by the ttl circuitry but, apart from that, it was otherwise operating perfectly fine.

 The MK II version didn't require the extra xtal since I'd acquired a bunch of 10MHz ocxos by then, allowing me to ditch all that ttl circuitry (reducing the power demand from 1.8W to a mere 1.4W and eliminate all those troublesome current ripple noise components in the Vcc rail with the change from stripboard to a copper clad groundplane construction further reducing this issue of noise on the Vcc rail to a vanishingly small level no doubt helping somewhat.

 This MK II gpsdo has been (and still is) my only gpsdo frequency reference over the past three years or so. Initially, I'd used (fake) M8N receiver modules until I chanced upon a seller on Amazon selling genuine M8T modules for a mere 42 quid. Since the description quite clearly described the timing feature, I took a chance and bought one.

 This proved to be the genuine article so, when i spotted a few weeks later that the seller had dropped his price to just 24 quid each, I snapped up another two despite a slight misgiving on account of not being able to reprogram the minimum elevation angle without locking the module and having to reset to defaults and do the settings all over again (that turned out to be the effect of a faulty FTDI 232 usb to serial converter so am rather glad I took the chance to purchase the additional 'spares' when I did - he'd raised the price just a week or two later to 61 quid each.

 At the moment, I'm in the middle of constructing a MK III based on the same design but using a Sparkfun ZED9T gps receiver module to reduce the effect of 'space weather' on the phase stability (slow +/- 5ns movements against my temperature stabilised rubidium reference). I say 'in the middle of constructing' but the reality is that it has been set aside over the past 4 or 5 months whilst I continue to wrestle with refining the baseplate temperature control algorithm of my rubidium reference, a project not unlike yours since I've spent the past three and a half years on this particular project.

 The motivation for building a ZED9T based gpsdo being the need to reduce this phase wander to allow me to more accurately syntonise the ruby to a more stable reference and eliminate mood swings which range between elation and that of despair as I seemingly achieve rock solid stability followed by a 'sudden' phase drift of 'failure' due to a combination of just by chance adjusting it just as the gps drift cancels the daily 2 or 3 mico Hertz ageing drift and thus seeing less than 20 ns in 24 hours phase drift, followed by a seemingly rapid increased phase drift rate (the ZED9T should reduce this effect by an order of magnitude).

 I really should stop trying to 'tweak' the temperature control algorithms and switch my attention back to completing the MK III project but it's hard to leave it alone. However, since I do need a much more stable gpsdo reference in order to more accurately assess the frequency stability of my rubidium reference, I've very little excuse for putting it off any longer.

 One thing I did finally come up with to extend the lower ambient temperature limit to below the 16 degree point at which the fan had to be brought to a standstill to limit undershoot and the addition of a special 'kickstart' pulse to bring it back up to speed to reduce the ensuing overshoot, was to add a couple of return galleries (40mm plastic waste pipes to return the exhaust air back to the intake plenum) and add a couple of servo controlled flap diverter valves between the angled ends of these tubes and the exhaust ports along with an intake damper flap (all linked to the same servo) controlled by the temperature reported by a BMP280 formerly used to sense the ambient temperature but now relocated by the fan intake inside the plenum chamber to control the fan intake air temperature.

 I tried various temperature settings and rates of control, landing up with a plenum midpoint setting of 31.0 deg C with a +/- 0.5 degree control range   over which it would gradually transition between full flow exhaust and total internal recirculation. This plenum temperature range corresponds to an ambient temperature ranging from a low of  around 19 to a high of 30 degrees. Below 19 degrees, the hatches were battened down and the plenum temperature would continue falling at a tenth half of the rate of the drop in ambient temperature.

 This measure saved the fan control algorithm from having to get anywhere close to the cut off point, allowing for a more responsive control at very low ambient temperatures even down to a very chilly 4 deg during an overnight test run in my garage/workshop a few weeks back.

 You might well find this technique of (effectively) enclosing your gpsdo inside a larger "air conditioned box'  an effective way to stabilise the temperature of the whole gpsdo enclosure's contents.

 For a bit of added interest, I've attached a 26 hour sequence of screenshots showing the drift between the gpsdo (yellow trace) and the rubidium starting just before 8pm last night (image 17 is where I cleared the infinite persistence), along with a screenshot of the arduino plot of base plate temperature (498 points at an 80Hz control cycle rate plus an adjacent pair of  rescale defeating spikes (0 and 120). The vertical scale is milli-Kelvins above the 36.00 degree base line.

[MIS42N]

I have generally avoided saying much about my own project since this thread is about Lars project. However, lately there is a bit of commentary about temperature stability, a problem addressed by my design. So I commend my design to you: https://www.eevblog.com/forum/projects/budget-gpsdo-a-work-in-progress/

Unfortunately, the link still says 'work in progress' despite changing the title to 'complete'. Although are these projects ever complete?

In the design, control voltage is generated by dithering a 10-bit PWM to synthesize a 24-bit DAC. That output can be used directly as the control voltage, and was in the first PCB design. It was done that way to avoid the complication of using multiple fixed PWM to come up with a pseudo 16-bit DAC, or using a proper DAC. The control voltage is varied in increments less than 1uV, which is as good or better than any other uP based design. But does suffer the problem that the generated voltage is dependent on the supply voltage of the processor.

The second PCB design overcame that by buffering the PWM in the digital domain, using a pair of small signal FETs. Now the control voltage is dependent on the supply to the FETs. And since the current is negligible, this can be from a precision voltage source such as a MAX6350, or in a high end OCXO the regulated voltage supplied by the OCXO. In the simplest implementation where a 5V OCXO is used, the OCXO supply can also be used as supply to the FETs. The supply to the OCXO is separate to the supply to the rest of the circuitry so provides a fairly constant load. Which the uP and 10MHz buffer doesn't.

Maybe the design doesn't get traction because it looks too simple. But I have not had any negative feedback from the few who have built it. Even though @enut11 built a cut down version using a different OCXO than the design, he says "it just works".

So what am I missing? I am not a marketing person, no idea how to promote my design and I don't have any investment in having it used. However, I see people struggle with other designs and think "I addressed that". More documentation? Another new blog with a better title? {end of self promotion}

[Solder_Junkie]

Johnny, I will be interested in hearing how much improvement a Sparkfun ZED9T makes over an M8T. My own Lars build (Murray Greenman, ZL1BPU, display variant), is at the limits of what I can measure in terms of short term stability.

I haven't experimented with increasing the smoothing caps on the oscillator Voltage control line, I note that Murray used 22uF caps against Lars using 4.7uF. I use 10uF. If you refer back to the James Miller "Simple" GPSDO, James uses a 160K resistor and 100uF cap to smooth the control Voltage line and achieves around +/-5 parts in 10^11 over a 10 second period. Maybe a larger capacitor would work just as well as going to a more expensive GPS module?
http://www.jrmiller.online/projects/ministd/manual.pdf

My reference oscillator is a surplus Efratom FRS-C, which has a specification of 3.16 parts in 10^11 over 10 seconds, and 1 part in 10^10 over 1 second, which puts my short term comparisons at the limit of that rubidium. I use a TinyPFA (phase frequency analyser) with TimeLab softwre. Details of the rubidium at:
https://bama.edebris.com/manuals/efratom/rfs

Back to GPS modules, my measurements using a Lars/Murray GPSDO give an reduction in short term jitter by about half, when using a genuine UBlox Neo-M8T compared to a doubtful origin Neo-6M (I have boards with both types and can swap over in a few minutes). The differences are pretty small and may be more related to using a timing vs navigation module, as opposed to genuine vs fake.

My thoughts are that the stability of the OCXO has more effect on the overall short term stability than the GPS module, although using high grade versions of both is the ideal solution... it can come at significant cost.

In addition to a Lars/Murray GPSDO, I also have a James Miller Simple GPSDO, in both these I use NEC ovens and M8T modules. I also have a Leo Bodnar GPSDO that uses a TCXO and (I guess) a navigation grade GPS module. In terms of short term stability, the Lars unit is around 2 to 4 times better than the James Miller  and 10 times better than the Leo Bodnar. The latter is realistically good enough for all I need and has the advantage of being ready to use within a minute or two of being switched on, and can output any frequency from 400 Hz to 810 MHz.

SJ