Outline Requirements for a DIY GPSDO

[Gandalf_Sr]

I have an old Trimble-based GPSDO and have recently been experimenting with a Ublox MAX8 GPS module. I'm an EE designer and have not got much work at the moment so I thought I'd pursue the idea of a PCB that would be a GPSDO so the fundamental blocks would be:

1. GPS/GNSS receiver
2. Oscillator, VCXO or VCTCXO
3. PLL with microcontroller providing UI perhaps via LH or terminal
4. Buffer/distribution amplifier

I have the idea that the PCB could be designed to accommodate a high end or medium end specification e.g. there could be 2 overlapping footprints for VCTCXOs.  I don't want to reinvent the wheel so if there are obvious building-block components that y'all could recommend, I'm listening.

I'll leave this first post clear so that I can come back and place the design decisions here.

So please chip in with ideas and suggestions with simple justification.

[Gandalf_Sr]

VCTCXO

OK, the heart of this is the oscillator.  Lars Walenius design seems a good reference point to work from, he says that the Connor-Winfield DOT050V-010.0M available from Digikey for about $28 is pretty good and would fit my idea of a mid-range device.  Any comments?

[edpalmer42]

Do you see this as being a turnkey system or a platform for experimentation?  Turnkey would be simpler, but a platform would be more fun. 

A platform suggests things like optional external oscillators, frequency dividers, lots of user options, etc.

Ed

[Gandalf_Sr]

I see it as being a platform for experimentation, a bare PCB that caters for at least 2 options so it could have a couple of options for VCTCXO although I guess you could wire it up to one that didn't fit on the PCB.  It could have options for a display too.  As I said in my first post, I'm looking for design requirement ideas and advice.

Given that it needs an ADC and DAC, how many bits do I need for each?  The Lars implementation seems to take 2 DACs and stack them end on end which I'm not familiar with.  There'as also the question about the PLL, Lars has it running from the 1PPS signal but the Iblox MAX8 that I've been messing with can be set up to output various frequencies, including 10 MHz so I'm interested in hearing which would be better.

My preferred technology is SMT but, if I keep it at 0603 and SOIC level, it's all doable by hand.  I'd also prefer to stick with PCB edge-mount SMA connectors.

[thinkfat]

Lars DIY GPSDO design is centered around a minimum viable solution. It's a great example of how to make do with the least possible components be put on a perfboard and have a working device. It's not necessarily a blueprint for an optimal design.

[Gandalf_Sr]

Lars DIY GPSDO design is centered around a minimum viable solution. It's a great example of how to make do with the least possible components be put on a perfboard and have a working device. It's not necessarily a blueprint for an optimal design.

Thanks; I kinda figured that out after I created this thread.  If I was aiming at the <$60 / <$120 for the mid / high versions, what approachs would you suggest?   I'm thinking I would come up with the PCB design and maybe write the code for the microcontroller.

[Kleinstein]

For keeping the costs down the 2 DAC version is a good idea. One does not actually needs a full high resolution DAC, but one should have fine resolution and monotony for the PLL to work well and enough range not to hit the edges because of drift and aging. So the corse part is more for static parts not so much the actual PLL.

The ADC should not have need for too much resolution. It is mainly to get good time to digital values, so as good as the analog time interpolation works. So I would expect the µC internal one to be sufficient.

The really tricky part is more like the software side: how to handle satellites coming and going or getting weaker or stronger.  Changing the satellite set can give some jumps.

[iMo]

The simplest form which works well is a design with XOR phase comparator and low pass filter.
The output of the low pass (ie. buffered by an opamp) drives the EFC of the OCXO.
XOR is fed with 20kHz from NEO module, and from a divider ( /500 for the 10MHz OCXO).
You do not need any ADC/DAC, nor any sw loop. Works fine.

[Gandalf_Sr]

NOW we're generating the discussion that I hoped we would!

[Gandalf_Sr]

The simplest form which works well is a design with XOR phase comparator and low pass filter.
The output of the low pass (ie. buffered by an opamp) drives the EFC of the OCXO.
XOR is fed with 20kHz from NEO module, and from a divider ( /500 for the 10MHz OCXO).
You do not need any ADC/DAC, nor any sw loop. Works fine.

Do you have an example schematic that shows the approach you're advocating for?

[iMo]

The simplest form which works well is a design with XOR phase comparator and low pass filter.
The output of the low pass (ie. buffered by an opamp) drives the EFC of the OCXO.
XOR is fed with 20kHz from NEO module, and from a divider ( /500 for the 10MHz OCXO).
You do not need any ADC/DAC, nor any sw loop. Works fine.

Do you have an example schematic that shows the approach you're advocating for?

See below almost complete wiring. The loop shall settle in about half an hour. R and C values have to be calculated based on OCXO's gain (Hz/Volt) and other required parameters of the loop.
I've been using NEO's 40kHz divided by 2, such it is exactly 50/50 duty. The /500 divider is expected to have 50/50 duty too. All digital logic could be put into a small CPLD or you may use discrete chips.
PS: if somebody showed me why complex MCU based PLL/FLL should work better, I would appreciate

[thinkfat]

While this approach certainly works I'd rather use a microcontroller and a software PLL or FLL. Of course it adds a lot of complexity and parts, but it's a much more interesting platform to play with.

[edigi]

VCTCXO

OK, the heart of this is the oscillator.  Lars Walenius design seems a good reference point to work from, he says that the Connor-Winfield DOT050V-010.0M available from Digikey for about $28 is pretty good and would fit my idea of a mid-range device.  Any comments?

I don't know how many digits precision are you aiming for, but this VCTCXO by the detailed data sheet has +-10ppm tuning frequency (or pull range; typical for VCTCXOs). That translates to +-100 Hz@10MHz. Considering the 2.7V control range it translates roughly to 74Hz/V sensitivity. That's far too high for good precision and also probably drift due to temperature change makes it less stable than desirable.
A decent OCXO has roughly 1Hz/V tuning sensitivity.
If your aim is 10 digits, that's 1mHz error@10MHz that translates to 1mV for OCXO. If your aim is 12 digits, well let's forget it for now.
Thus even with an OCXO you need for 10 digits at least a 12 bit DAC. Not many cheap micros have that. Not only that, the PCB arrangement must be such that the control signal can exceed the noise level.
The alternative is PWM and heavy filtering. Yet another alternative is using multiple DACs, e.g. one for coarse tuning and 1 for fine tuning.
For the frequency measurement part I've described my solution here:
https://www.eevblog.com/forum/projects/gpsdo-pll-or-mcu-controlled/msg2588532/#msg2588532
Basic idea is that OCXO output is continuously counted and GPS 1pps signal is used for time stamping. The fraction from last OCXO signal edge is also measured with TDC chip (up to ~100nS that's bigger than jitter of the 1pps output). If the output of the OCXO is exactly 10MHz, the long term average between 2 1pps timestamps will be exactly 10 million cycles (considering also the fraction), if not the error can be used to drive the compensation voltage of the OCXO to reduce the error.
(Note: 1pps output can use also more pulses per second but I didn't want to complicate my description here.)
The rest is just SW. Sorry I don't have any ready made solution but the above description should provide plenty of ideas in my view.

[iMo]

I do not want to advocate any particular solution, there are many approaches possible. My lesson learned is following:

I wanted to build a reciprocal counter. I integrated OCXO disciplining (NEO-7) into the counter. My OCXO is double ovenized Trimble 10MHz with sine output and 1.5Hz/Volt gain. My reciprocal counter is using TDC7200. The logic is put into an FPGA and the presentation layer is made of a BluePill.

I spent months messing with PLL and FLL loops for disciplining the OCXO. I was also using TDC7200 measurements within the loop, and 16bit external MAX541 DAC fed by OCXO's Vref.

The simple XOR worked best. The design (the math around) of the "RC loop filter" needs some effort, however. But it is the part of the "fun". The only "specialty" I added is the monitoring of the EFC by an ADS1110, not included into the control loop. When the EFC voltage is within a certain range the OCXO is considered "locked" (sure, the "locked" EFC voltage range may change in a few years) and a green LED lits. It takes about half an hour after cold start.

So you have to answer yourself a basic question: Do I want to play with MCU/ADC/DAC/TIC and write mega code which shoots out kilobytes of data per second (the data which are basically not needed..), or, do I want to lock my OCXO to GPS easy way?

Both solutions may work fine when properly done (and there is always a lot of space for improvements), the difference between the "complex MCU based" solution and the "simple analog" one is like the difference between MP3 and vinyl, imho

[edpalmer42]

FYI, the source for info on the XOR circuit is http://www.jrmiller.demon.co.uk/projects/ministd/frqstd.htm .  This circuit performs well even when compared to the HP Z3801A and Trimble Thunderbolt.  Data is here:  http://www.leapsecond.com/pages/gpsdo/ .

[Gandalf_Sr]

Thanks for all the ideas guys.  One thing that I may bring to this is that I have been working recently with the Cypress PSoC6 dual core processor and have just done an implementation where I made the M4 core run at 150 MHz doing fast ADC and dumping the results in a shared RAM area that I set up, then the M0+ core looks into the shared RAM and takes actions depending on what it sees there. The M0+ core is running at 100 MHz and manages the whole device i.e. it tells the M4 to run when the M0+ is ready; the M0+ also 'owns' all the communications, UART, BLE, etc.  There's also an application note for PSoC to get better DAC resolution by using 2 or more DACs that could be ported to the PSoC6.

I was also looking around at oscillators and came across this $15 SIT5155AI-FK-33VT-10.000000XMEMS one on Digikey take a look at the datasheet that's linked and you'll see that there's a variant that  takes the frequency adjustment via I2C.  Is this one any good? is the jitter OK or not?

[EDIT] I also found this out about the PSoC6...
PSoC 6 has one dedicated 12bit voltage DAC and in addition two 7bit current DACs that are shared with the CapSense component. For the last two the availability depends if CapSense is used and how it is configured.

[FriedLogic]

It's probably worth looking at some of the many GPSDO projects and teardowns around, since almost everything has been discussed/done/refined/refined more... Here and the time-nuts archive are good places to start.

For driving the electronic frequency control of an oscillator, you would probably be looking at more like 16+ bits, although it all depends. If your oscillator has a control range of 1PPM, you would effectively need a 20 bit DAC to get close to 1E-12 resolution. Then just 1PPM of noise on the control line would ruin the performance if you had a very good oscillator.

An interesting read if you've not seen it is the 1998 QST article 'A GPS-Based Frequency Standard' by Brooks Shera, although you wouldn't normally want to copy that design two decades on.

[Gandalf_Sr]

FriedLogic Thanks for the input.  My last post was around the idea that if might be possible to combine the PSoC6's 1 x 12 bit voltage DAC with the 2 x 7 bit current DACs to achieve an effective resolution of > 16 bits. If 1 ppm of noise on the control line would ruin the performance, that would suggest that 3 uV would be unacceptable and, if this is true then an analog solution seems easier than digital but then you lose a lot of the control that an MCU brings.  How do the high end professional GPSDOs work then, are they analog or digital?

I've been trying to read up on this quite a bit but there's clearly many different ways to approach it. There are many people asking similar questions here and this thread has a good discussion about PLL vs MCU.  It seems to me that what's needed is a very slow, clean, noise-filtered, ultra-fine resolution, DAC to feed the VFC on the VCXO and some way of measuring the frequency precisely.  I like the concept of using the 1PPS as a timing gate and then having a MCU count the 10 MHz waveform pulses from the oscillator.

[edigi]

If you need good precision, you need OCXO. If you have access to a good resolution frequency meter (it does not need to be precise and 10 digits resolution is already OK) and have a TCXO around, it's very easy to check. A mere touching of the TCXO or breathing to it will result in shifting its frequency within seconds.
So while temperature compensation helps, it still does not solves the issue entirely for good precision.
This means that TCXOs have to have always a wider pull range and they will have some temperature dependent drift as well (most likely it's cut is also not optimal for this kind of purpose etc. but let's forget it for now).

This is an issue because the GPS 1pps output is loaded with jitter (with a magnitude of 10ns, depending a lot of factors). It can be amortized over longer time but during that time it's better that the oscillator that you discipline with GPS is stable. Actually it's better to be stable within the magnitude of minutes. And that's a problem for TCXO. If you don't aim for very high precision (let's say 9 digits) and you need a quick cold start or power consumption matters a lot TCXO can be still OK but for higher precision the stability of the oscillator must be better and this is where the ovenized crystal comes into the picture.
(Without OCXO it's like a turtle trying to chase a mouse.)

Some people even prefer double oven (I have also 2 of those double oven OCXOs). While I don't know their exact operation probably they have separate loop for the outer and the inner oven and that means that the inner oven can be more sensitive (to the error signal that is the base for compensation) and that means better temperature stability.

Not only this, but powering the OCXO can be an issue as well. When checking one of those double oven OCXOs initially I was quite unhappy that it did not seem to produce low enough noise checked with a good resolution meter (since I've bought it used my first idea was that I had been cheated; actually not). For whatever reason, I still decided to check it with spectrum analyzer (generally it does not reveal too much since the SAs own noise masks interesting things) and to my surprise I was seeing sidebands at 50Hz (the mains frequency in my country) like in case of AM. Not very strong, something like 80dB below the real signal level but still enough to completely destroy precision. It has stuck me very soon that it's probably power supply feeding through the mains and reaching the frequency control of the OCXO (confirmed later on with a better linear PSU that has less than 0.5mV residual ripple).
Moral of the story: One has to pay a lot of attention to very many details when it comes to good precision...

Note: While I don't think that MCU based GPSDO is very complex, I'm ready to accept that probably the analogue version is simpler, especially if you can get it right at the first or from few attempts. (When I mentioned in the other thread FPGA or second CPLD it was for the frequency meter part). The MCU based version however has a lot of flexibility that you can play with. None of these should matter if you buy a ready made solution.
 

[iMo]

The XOR analog solution has got one minor issue - when you disturb the loop it takes time to lock again. It does not posses a "memory". The construction of the "well made" XOR loop should be similar to that constructions the volnuts do like - you are chasing microvolts. When you switch on a lamp close to the XOR loop wiring you have to spend another XX minutes to lock again. On the other hand, theoretically, based on current laws of physics, the MCU based solution cannot be better than the analog XOR one. Simply because the MCU solution introduces much more sources of errors and uncertainties due to quantization and finite precision than the simple XOR analog one (there are none "discrete levels" of information involved). 

[FriedLogic]

My last post was around the idea that if might be possible to combine the PSoC6's 1 x 12 bit voltage DAC with the 2 x 7 bit current DACs to achieve an effective resolution of > 16 bits.

A common way to reduce how good a DAC you need is to use a voltage divider on the frequency control input of the oscillator. If that is set so that the frequency is almost correct, the DAC can be configured for a much smaller control range. That's shown in the QST article. A&A Engineering who did the boards have a copy on their site:
http://www.a-aengineering.com/QST_GPS.pdf

A related page that I just noticed:
http://k6jca.blogspot.com/2019/02/an-arduino-version-of-brooks-sheras.html

[edigi]

It does not posses a "memory".

Possessing memory and possibility for glitch filtering are probably the most important advantages of MCU solution. Surely the MCU based solution won't be more precise, like you wrote this is simple physics, but it can be made harder to disturb and quicker to converge after a cold start.
As most people here seem to have magnitude of orders more time (and ambitions) than me for this kind of things probably my glitch filtering is not very well worked out (or primitive if you like) but nevertheless the idea is here:
There is an x (currently 4) item FIFO queue and then its average is compared to the last measurement. If it's within tolerance it's used for compensation calculation, if not then it is not used. It gets to the queue though no matter what.
One can play with tolerance and queue length (kind of an adaptive FIR filter).

Due to saved compensation value cold start is typically within 8 digits precision with TCXO just after start (although depends on aging retrace and assumes relatively stable temperature) and within 9 digits in around a minute (that is roughly the max).
With OCXO the fast start gain is not so much as OCXO warm-up is slow (my relatively quick double oven OCXO starts with roughly 330 Hz error, stability getting within 1Hz takes around 5 mins, within 1mHz yet another 5 mins) and aging retrace is also higher. So in short, after cold start mostly only aging retrace has to be compensated thus it can be made faster.
If someone does not know what is aging retrace (and many other interesting XO related stuff) I copy a link from FA2 topic here: https://apps.dtic.mil/dtic/tr/fulltext/u2/a248503.pdf

I don't know what can be the root cause for lamp disturbance (can guess from micro-volts) but what I've experienced is vibration. Even accidentally knocking something close enough can cause a short jump in the order of mHz. Analogue loop will chase it with a damped oscillation, digital can just ignore the glitch (sounds easier than done). This is where I've actually lost most of my ambitions for precision. If something is so easy to disturb, it's really not practical to use. It's fun to play with it but that's it.

[edigi]

A common way to reduce how good a DAC you need is to use a voltage divider on the frequency control input of the oscillator. If that is set so that the frequency is almost correct, the DAC can be configured for a much smaller control range.

That works, but due to aging it will get out of locking range eventually and therefore will require manual adjustment occasionally.

[Gandalf_Sr]

On the idea of adding a preset resistor and then making the range that the VFC runs through way smaller by going through a potential divider, how about introducing digital pots that did the presetting? Or are they going to be noisy and drift?

As I look more at the various ways to get better resolution for the DAC, there are a number of things that can be brought to play; e.g. the PSoC6 can use the built in 1 x 12 bit voltage DAC, 2 x 7 bit current DACs, and a PWM signal set up to provide a steering tweak.  These ideas need proving out, time for some testing on my PSoC 6 evaluation boards.

[Gandalf_Sr]

So, for a reasonable OCXO to experiment with, is the Isotemp 10 MHz OXCO 134-10 12 VDC Sine Wave Output any good?

The short term stability of  1 x 10^-10/second seems a lot.