GPSDO: PLL or MCU controlled?

[Illusionist]

As my first 'proper' project after a long break as a hobbyist, I'm making a GPSDO. I have a NEO-M8T on a board I had made, a new 10MHz OCXO and boxes full of assorted ICs.

I originally planned to use a PIC to control the OCXO, using the GPS's PPS output averaged over time as many do. But then I changed my mind and made a PLL, just because I came across some fast XOR logic while digging in a box. The NEO outputs a 10kHz signal for the PLL, which is basically the same as the JRMiller design but with faster, SMD logic. It might end up in a CPLD (excluding the xor) and I even programmed a PIC to do the division instead of the 390s and that worked as well.

But... before I finalize my design, which method (PLL/MCU) do people think is better, and why?

My only method of testing the frequency is to use it to clock a dsPIC, multiplied up to 50 MIPS, and count clock cycles vs. the jittery PPS from the GPS. I do this with a free running counter (the counter is never stopped so no clock cycle is ever missed) and sample and log at 1,10,100,1000 and 10,000 PPS totals (so I have a count for every PPS second, and can add up any count interval I want from that).

Is counting the cycles as above a reasonable method to determine accuracy and stability alone?

I've been doing that for two weeks with the circuit on a breadboard and the counts are rarely more than +/-1 LSD (all the way up to 10,000 PPS). Once a day or so I might see a +/-2 in the log. For a breadboard layout, surrounded by all sorts of noisy kit, it seems to do remarkably well.

My thinking so far goes like this:

An MCU solution would allow the GPSDO to be used in the absence of a GPS signal, once it has a control voltage for the OCXO stored. The point is to have a GPSDO, not just an OCXO, so that's rather moot. I tend to think that the PLL method can respond more quickly/linearly to environmental changes whereas the MCU might take longer (due to needing long sample times) to determine that and account for it. The MCU is limited to one clock count resolution; The PLL has analogue resolution. But...

...perhaps the PLL method has some oscillation that I can't detect with my equipment. Certainly the MCU can maintain a stable DAC output (at least as far as what the MCU tells it) whereas I have no idea what the PLL is really doing.

Here's the big catch:

I don't have much kit to test this with. Just the counting method above, plus a 210,000 count multimeter, 200MHz Siglent oscilloscope and Siglent AWG with counter.

Once the OCXO/PLL have stabilized (about 5 minutes), measuring the OCXO control voltage:

...the meter stays still on the last digit (100uV) and just occasionally will move a few 100uV and stabilize again, perhaps due to temperature or supply fluctuations. It reads <1.5mV rms on AC.
...the oscilloscope shows noise of ~60mV peak up to a few 100kHz from all the switching things in the vicinity. Nothing discernible out of that at 10kHz which I thought might show if the PLL was oscillating on the 10kHz inputs.
...the counter on my AWG shows 10.000,030MHz constantly, well within its specs if the input is truly 10.000000MHz (3ppm out of +/-25ppm spec).

[iMo]

There is a thread somewhere with the XOR PLL I did with my GPSDO. Used NEO7 and 10kHz and then tried with 20 and 40KHz.

You have to design the low-pass filter after the XOR (not an easy stuff, btw.), and I've been using an opamp for driving the OCXO and the second one for buffering the ADC (inside my stm32).

The only "issue" I see with the XOR is when it comes to a disturbance (ie you mess with wiring) the XOR needs its time to settle (around 15minutes here), while with the MCU+DAC it could be done faster, imho.

PS: I plan to buffer the XOR output with a 5pin cmos driver powered by a clean and stable voltage (my XOR is inside an FPGA).

The XOR PLL and a good OCXO with NEO8 should show you something like 10.000.000,0xy without any finetuning and in rather "noisy" environment.

[MosherIV]

It depends on how the 10KHz from the neo-m8t is generated.
My understanding is that it is using the same timing source as the 1pps, so will therefore have the same jitter problem. Ublox have an onboard TCXO whuch is used to generate the 1pps or any freq via the programable interface, the jitter is created by the divide down method from the TCXO. I think the TCXO is 12MHz so only multiples of 12MHz will not have much jitter. The remainging jitter will purely be down to the jitter of the crystal part of the TCXO.
The PLL method only works if the signal is derived from the GPS signal itself. The older GPS modules did this but not models from Ublox.

The more stable method for 1pps signal is to use the averaging method.

I think you will get better results by usung the 1pps and averaging even though  you have a T model (timing - better for timing application as opposed to location applications).

[iMo]

The NEO6/7/(?8 ) modules produce a "clean" frequency when 1pps_out=48MHz/N, where N is an integer. The clean frequency is not "gps cesium" stable but drifts around, for several reasons.

XOR PLL is chasing the 1pps_out continuously, where the loop parameters are given by the low-pass filter (usually a higher order one) and the OCXO's "gain".

Therefore, "ideally", the XOR PLL modulates the OCXO slowly around the "zero phase difference", where the EFC amplitude of the "modulation" is in the range of uVolts, and frequency in milliHertz. The quality OCXOs have the "gain" in range of couple of Hz/Volt thus the peak-peak changes are somewhere in the ppt range.

In practice, with the NEO's "1pps_out" jitter, OCXO's walk, the XOR PLL wired on a noisy solder-less breadboard, you may get best the "10.000.000,000 +/-0,0xy" readings, imho.

[Gyro]

Here's a pll based one that I did (still at the same scruffy breadboard stage  )...

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

[jpb]

This, surprisingly, is a huge subject - I have a long term project to design and build one but so far am only as far as the trying to set up accurate measurement stage.
My understanding is that a digital PLL is the way to go, or a standard PLL to a 10kHz output (James Miller design).
Frequency locking, though simpler, seems to be very slightly inaccurate (a small frequency offset).
Historically some designs are:
Brooks Shera:
https://www.qsl.net/n9zia/wireless/QST_GPS.pdf
a recent version of it:
https://k6jca.blogspot.com/2019/02/an-arduino-version-of-brooks-sheras.html

James Miller:
http://www.jrmiller.demon.co.uk/projects/ministd/frqstd.htm
http://www.jrmiller.demon.co.uk/projects/ministd/frqstd0.htm

And on this forum there is Lars design which is well thought out and popular:
(Sadly Lars is no longer with us, but there is a lot of information and answered questions on this forum.)
https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/

Note: frequency locking to 10kHz or so is easier than to 1PPS (1Hz) but from things said on the Time Nuts forum I understand that you don't gain anything accuracy wise, that is the 10kHz signal itself is only updated by the GPS module roughly once a second though this may be less true of later Ublox units where they do some internal phase locking I think.

EDIT: I almost forgot this design from Wenzel which is fun and different, and nice and simple:
http://www.techlib.com/electronics/GPSstandard.htm

here is a frequency locked version:
http://ve2zaz.net/GPS_Std/Downloads/VE2ZAZ_GPS_Derived_Std_QEX_09_10_2006.pdf

And here are some comparative measurements:
http://www.g4jnt.com/10MHz_Reference_Source_Stability.pdf
which come from this page:
http://www.g4jnt.com/freqlock.htm

There is lots more stuff out there and lots of discussions/links spread around on this forum which is probably why I never seem to get around to actually starting my project properly - I spend all my time on the design/data gathering stage!

[Illusionist]

Thank you all for the replies... plenty of food for thought.

My OCXO is a Micro Crystal scoxovt-cv5 with about a 10Hz/V response over 0..5V. Not exactly a great one, but new, cheap, quick warm up and low power, and good enough for anything I'll ever need. I do hanker after a better one though, just because.

Gyro, I read your post a while ago but forgot about it; I've just gone and read it again. I might have to build yours and see how my OCXO responds - I had already pulled out a tube of 74HC4046 while mulling over ideas at the start.

Interesting comment about the PLL cycling about around the uV level. That's sort of my concern with the DAC; even with 16 bits (I have some MAX542) I can't get anywhere near that resolution. Then again, it works out at about 0.76mHz per DAC step... I think I would be lucky if that became the limiting factor!

I'll have to try it I guess, and see if I can code a decent control loop.

jpb, that list of links looks a lot like my 'examples' folder of saved websites from when I first thought of making this. I'll take a look and see if there's anything I missed.

-------------------

My biggest problem is that I want to get on and build the thing, but I don't yet know enough to make the most of what I have available. I've done too many things and then found I should have done it differently. And I do want to mostly design it myself, not that I think I'll come up with anything that hasn't been done countless times already, but I want the challenge and learning experience as much as I want a functioning GPSDO (which is required for my next project...)

More testing required! (in between which I'm designing the output filters and buffers in Multisim, and deciding what I actually need out of it).

-------------------

Oh, and then there's the final piece of the puzzle... synchronizing a 'derived' PPS, with much lower jitter (easy to do) than the GPS PPS but locked to the time (not so easy). My current test circuit on the breadboard is doing that too.

So far I can get the derived PPS to sync within 20ns of GPS time, but I have some ideas on how to improve on that, including the use of a nice 0.25ns per step delay line from Maxim. (Well, it's not a production design so no worries if Maxim decides to discontinue the part.)

[Gyro]

On your last point, I'm not sure if a synchronized picDIV divider would do you any good?  They have very low jitter. Just a thought.

http://www.leapsecond.com/pic/picdiv.htm

(about half way down)

[Miti]

Lars GPSDO is PLL and MCU controlled.

https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/

I made it and it is very well designed.

[Illusionist]

Gyro, funny you should mention that... I saw them and rolled my own into a 16F18313. I've been using little MCUs for tricks like since they became cheaper than a couple of logic chips. I even used one in place of the '390 dividers (just to see) and the PLL still worked nicely.

However, it can't synchronize closely enough without outside help (best effort alone with some tweaking to the sync timing is about +/-200ns iirc).

What I do is use the main PIC to stretch or shrink a single clock cycle to the divider PIC by 10ns, thus I can move the phase of the PPS in 10ns steps.

The next trick is measuring that... against the jittery GPS PPS. My measurement method so far only gets down to about 20ns resolution, and that's after some averaging, hence my limit.

I might try to make an interpolater with some logic, a small capacitor and the PIC's ADC. I don't know if I really need this accuracy though so it's a bit on the back-burner compared to the 10MHz output. I can't think of any practical purpose (for me) for such an accurate PPS, I just can't resist 'improving' things if I can.

--------------

Miti, your post came in while I was typing this, so I'll go and take a look now, thank you. I was wondering about combining the two...

[Illusionist]

Ha - that Lars design is using the method I was thinking of for sync'ing my PPS... but for the main OCXO control. I think... need to read it but it looks like that.

[David Hess]

The NEO outputs a 10kHz signal for the PLL, which is basically the same as the JRMiller design but with faster, SMD logic.

That will of course work however beware that the time pulse outputs are only updated at the GPS navigation update rate:

The time pulses are generated on edges of an asynchronous clock; for pulse rates below 2 Hz, the exact phase of the TIMEPULSE output is reported before each pulse in the TIM-TP message.

So frequencies higher than the navigation update rate do not provide any extra information and the phase comparator output still needs to be filtered to a very low frequency.  Otherwise the DO is going to phase lock to the oscillator producing the time pulse outputs with GPS guided discontinuities.  At least that is how I read the documentation for the NEO-M8T and if this was not the case, then there would be no need to report the phase of the time pulse outputs.

Based on the 20 nanosecond specification, I assume the clock is 25 MHz.

[Illusionist]

Yes, I understand about the 10kHz not being 'better' - just simpler on the PLL. I was just reading the manuals regarding the TIM-TP message, in case I can utilize it.

20ns - from my post about sync'ing the derived PPS? The main dsPIC clock is the 10MHz OCXO, with the dsPIC multiplying it up to 100MHz and an instruction cycle of 50 MIPS.

The dsPIC generates a 10MHz output of its own (PWM) which serves as the clock for the divide-by-1,000,000 PIC, which gives the derived PPS.

By having the dsPIC tweak the PWM phase by a clock cycle (100MHz=10ns) just once for a single period, I can move the derived PPS phase in 10ns steps.

The problem I have is measuring the difference in the first place. I'm trying to use the CTMU in the dsPIC but it simply isn't behaving at all and I can't figure out why. I've just posted another thread in the microcontroller forum about that. That's where the limit of 20ns is coming from, simply from measurement on the oscilloscope. That's as close as I can get the CTMU to measure, so as close as I can adjust the phase.

If I can get the CTMU to work as advertised, I can then use the Maxim delay line to bring the derived PPS as close as my measurement resolution allows.

[David Hess]

The problem I have is measuring the difference in the first place. I'm trying to use the CTMU in the dsPIC but it simply isn't behaving at all and I can't figure out why. I've just posted another thread in the microcontroller forum about that. That's where the limit of 20ns is coming from, simply from measurement on the oscilloscope. That's as close as I can get the CTMU to measure, so as close as I can adjust the phase.

If I can get the CTMU to work as advertised, I can then use the Maxim delay line to bring the derived PPS as close as my measurement resolution allows.

I responded in your other thread about the CTMU.

[fourfathom]

Sorry if this is obvious, but given the low frequency of the VCXO loop filter, you aren't stuck with the DAC LSB resolution, or the 10ns timing of the 100MHz clock.  Just use numeric pseudo-noise or other high-frequency dithering to provide fractional average resolution.  The high-frequency noise component will be filtered out by the loop filter.  The Bresenham line-drawing technique is another way to provide a very filterable fractional output and can be used in both time-domain and amplitude-domain (DAC) applications.

[Johnny B Good]

Here's a pll based one that I did (still at the same scruffy breadboard stage  )...

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

 Hi, Gyro,

 I've been messing about with a homebrewed GPSDO assembled onto a plug in prototyping breadboard for the past month or so, based on your scruffy GPSDO (well, the LPF parts following a 74HC86 xor phase detector that replaced the ancient 4046 micropower pll chip I'd been using with a (very cheap) ublox neo 6M module[1] which could only be programmed to a maximum PPS frequency of 1KHz requiring a couple of '390s to divide the OCXO's output down to a glacial 1KHz to drive the 4046 (PD2 output option).

 When a replacement M8N module[2] I'd had on order finally turned up, I retained the same glacial 10,000 divisor for my initial tests just to confirm that the cheap 6M had definitely been the sole cause of all my woes of the week before, before doing the 'sensible thing' by programming the M8N to give out a 100KHz on its PPS line, allowing me to shed one of the '390s and ditch the 'glacier watching' experience associated with a 1KHz phase locking frequency from a 10MHz ocxo.

 That meant that, at long last, I could finally ditch the 4046 and use a 74HC86 xor gate phase detector to feed the LPF which initially drove the OCXO's Vfc pin directly. To start with, I used 100k with 22μF and 470μF in series with a 39k in my filter (not exactly the same component values you'd chosen, just near enough for the job - they were just what I happened to have to hand to put me in the same ball park).

 It was only later on that I changed them to 10M with 1μF and a 10μF with a 390k series resistor once I had inserted a 5v cmos RRO buffer amp in between the LPF output and the OCXO's Vfc line. This seems the best compromise so far with my current batch of CQE branded OCXOs between minimising the effects of the phase variations inherent in the GPS system and holding the startup time to a reasonably acceptable 15 minutes[3].

 I experimented with much larger time constants (500 seconds!) to see whether I could smooth out the random timing error excursions in the GPS system but gave up on this method of filtering when it became obvious that during the more protracted map deviation events the phase excursions were being amplified.

 It had looked promising enough for the shorter half minute or so shifts in positional error once the hour or so startup time had elapsed but I could see that using very long time constant filtering here wasn't going to cut it so it was a case of going back to the "Devil You Know" with less ambitious time constant values (10/100 seconds versus your original choice of 3.3/33 seconds).

 With such a basic PLL solution as this, the output is always going to be polluted by these 20 to 30ns phase shifts when using non-timing GPS receiver modules such as the NEO-M8N and the NEO-6M. Timing modules may reduce this effect but they cost far more than the additional cost of an Arduino nano running a Kalman filtering algorithm to filter out such effects to ever greater and greater effect with each passing hour of operation.

 Long term (weeks to decades) the PPS or its derived 100 to 10,000KHz is never going to be out from the exact GPS time by much more than 50ns anyway whether you use a costly timing module or a cheap 'n' cheerful navigation only module. If you can live with these nanosecond sized phase shifts, typically at less than one ns per second either way every few minutes or so, on a 10MHz reference, a simple PLL design will do the job.

 If you're building your first GPSDO, you can always leave a bit of room spare to add an Arduino nano with another IC or two to allow for a future upgrade. After all, even a basic GPSDO is better than no GPSDO at all.

 I'm now actually in the process of reassembling my breadboarded GPSDO into a proper enclosure. I've finally had enough of the unpredictability of plug in breadboard construction - stable enough if you don't physically disturb it but a pain if you have to wrangle it around the bench.

 I've now actually committed myself to building it onto a vero board I'd previously trimmed to slide into the slots of a small extruded case by drilling the extra hole between tracks to accommodate the Vref pin of my OCXO which unconscionably doesn't line up with the 0.1 inch hole spacing of veroboard. Who knows? I might actually have it ready for initial testing before the end of next week! 

 I'm going to use up my very first CQE OCXO acquisition on this model, a 13MHz 5v example rather than any of the 12v 10MHz units in my collection. I've already had this OCXO setup on a breadboard lashup to generate a 10MHz signal using a 74193 as a divide by 13 of the doubled up to 26MHz so as to feed a 3N502 ultra low jitter clock multiplier with its minimum specified input clock frequency of 2MHz. On that occasion, I'd used another 3N502 for the initial doubler but I'm going to use an XOR gate this time round (I've got three going spare) to save using up any more of my precious 3N502s. I'd already tested the XOR doubler idea with the breadboarded GPSDO lashup so I'm quietly confident this will work.

[Notes]

[1] This had been driving me round the twist with its 1ms pps 1/2ms pulse that kept getting narrower and narrower about halfway through a 10 to 15 minute cycle (a sawtooth correction bug I guess) before finally disappearing up its own fundament to then instantly reincarnate itself as the 50% duty cycle 1ms pulse I'd programmed before starting another cycle of this nonsense. 

 I'd set up two '390s to divide the 10MHz ocxo to feed the phase detector with 1KHz (the fastest I could program that 6M to output on its PPS line) and spent many days trying to get the damned thing to lock, even resorting to that 4046's frequency/phase detector output which did eventually start to show signs of working for longer than the 15 minutes it would take to lock phase at such a glacial 10,000:1 division ratio from the OCXO to the PLL's phase/frequency detector.

 At that stage I was waiting on delivery of a cheapish M8N (which has since proved to be a Chinese fake but not fatally so - it's what I'm currently using). I decided at that point to probe the phase detector inputs (after nearly a week of slowly going round the bend) and finally discovered that weird behaviour of the 6M's narrowing pulse - no wonder I couldn't get it to work! - in fact, I'm surprised I'd experienced those brief moments of  short lived "triumph" even using the PD2 output from the 4046!

 I suppose it's just possible that this effect might not appear if it's left on its default 1PPS setting but I haven't tested this possibility since I've no immediate plans to try it out using Lars' GPSDO design where it might just be able to redeem itself. It had only cost me £3.99, delivered anyway so such testing can stay on the back burner for now, (or even forever - it only receives GPS svs anyway).

[2] I'd managed to burn out the PPS line on my first (genuine!) M8N module with a 12 volt jolt just over three months ago now , hence this replacement module from China which, unsurprisingly, is a fake (no flash and no SAW filter, judging by the anomalous results between externally mounted and internally mounted active GPS patch antennas). A CR2032 1KR and Schottky blocking diode solves the short 50 minute BBRAM retention time issue, giving me an estimated 250 days or better powered off retention time to protect my settings and maintain the RTC.

[3] The point at which it's no worse than the GPS positional error induced phase shifts can become (when the final excursions around the phase lock in point become lost in the GPS system noise).

JBG

[Johnny B Good]

It depends on how the 10KHz from the neo-m8t is generated.
My understanding is that it is using the same timing source as the 1pps, so will therefore have the same jitter problem. Ublox have an onboard TCXO whuch is used to generate the 1pps or any freq via the programable interface, the jitter is created by the divide down method from the TCXO. I think the TCXO is 12MHz so only multiples of 12MHz will not have much jitter. The remainging jitter will purely be down to the jitter of the crystal part of the TCXO.
The PLL method only works if the signal is derived from the GPS signal itself. The older GPS modules did this but not models from Ublox.

The more stable method for 1pps signal is to use the averaging method.

I think you will get better results by usung the 1pps and averaging even though  you have a T model (timing - better for timing application as opposed to location applications).

 The NEO M8N  (and, I think this also applies to the timing variants, BICBW) use a 48MHz tcxo. The M8N modules at least, issue a new PPS on the closest rising edge of this 48MHz clock which generates a skipped pulse of up to +/- half a cycle corresponding to a jitter of 20.833333ns every so often. If you program the M8N to give out a 10MHz on its PPS line, it seems to apply this sawtooth correction at anywhere from 5 a second or so to once every half minute or even longer, depending on how close to the exact 48MHz this tcxo happens to have settled on.

 Also, because 10MHz isn't an exact even integer divider ratio, the 10MHz will have a clock divider jitter component as well as this sawtooth correction. You can eliminate this divider jitter (but not the sawtooth jitter) by selecting an even numbered divisor indirectly by selecting, for example, a 12 or 8 or 6 or 4 or 3 or 2 or 1.5 MHz frequency and so on. As long as the chosen frequency is based on an even numbered integer, it'll remain free of this non integer divider induced jitter (but not free of the ubiquitous sawtooth corrections).

 These issues are seemingly a serious problem to the novice GPSDO builder with hopes of using a NEO M8N's ability to generate a 10MHz reference directly from its PPS line and avoid the expense of a 10MHz OCXO. Whilst the raw 10MHz output can be used as a calibration reference to trim the reference XO or TCXO inside other test gear and communications equipment, it certainly can't be used as an external 10MHz reference directly in most cases (there may be exceptions where the reference is phase locking a much higher internal reference which is filtered from any such jitter components but I don't know of any specific examples).

 Once you've bitten the bullet on the cost of a reasonable to excellent quality OCXO for your GPS receiver to discipline, you can stop worrying about divider jitter and even the sawtooth jitter since the necessary LPF after the phase detector will rather effectively remove their effect on the OCXO, leaving you to concentrate on the one remaining 'insurmountable' (as far as a simple PLL based GPSDO setup goes) issue of phase errors in the GPS system itself which are mainly due to the effects of varying electron density in the ionosphere on the propagation speed of the signals emanating from the SV's themselves.

 There are other, lesser sources of error in the SV's and the receivers themselves but they pale into insignificance when compared to the vagaries of the ionosphere. You can see the effect reflected in the u-centre deviation map plots and the altitude display, typically deviations of 10 metres or more for both being not unusual. At a speed of just under a foot per nanosecond for the SV's signals, such deviations could represent timing errors of as much as 30ns, almost a third of a cycle at 10MHz.

 For amateur radio use, this is still generally good enough as an external reference for radio equipment operating in the low GHz bands but if you're trying to calibrate a 10MHz OCXO in a signal generator to within 50ppt, the operation becomes somewhat tricky with this level of phase deviation.

 Calibrating OXCOs in test equipment (notably frequency counters) to within 0.1ppb can be achieved without too much difficulty at this level of phase error typical of a basic PLL GPSDO design so all is not lost for the lack of Kalman filtering. You can follow the Time Nuts down that particular rabbit hole at your leisure any time you feel the urge once you've had a chance to become dissatisfied with your current GPSDO project.

JBG

[Gyro]

Here's a pll based one that I did (still at the same scruffy breadboard stage  )...

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

 Hi, Gyro,

 I've been messing about with a homebrewed GPSDO assembled onto a plug in prototyping breadboard for the past month or so, based on your scruffy GPSDO (well, the LPF parts following a 74HC86 xor phase detector that replaced the ancient 4046 micropower pll chip I'd been using with a (very cheap) ublox neo 6M module[1] which could only be programmed to a maximum PPS frequency of 1KHz requiring a couple of '390s to divide the OCXO's output down to a glacial 1KHz to drive the 4046 (PD2 output option).

 When a replacement M8N module[2] I'd had on order finally turned up, I retained the same glacial 10,000 divisor for my initial tests just to confirm that the cheap 6M had definitely been the sole cause of all my woes of the week before, before doing the 'sensible thing' by programming the M8N to give out a 100KHz on its PPS line, allowing me to shed one of the '390s and ditch the 'glacier watching' experience associated with a 1KHz phase locking frequency from a 10MHz ocxo.

 That meant that, at long last, I could finally ditch the 4046 and use a 74HC86 xor gate phase detector to feed the LPF which initially drove the OCXO's Vfc pin directly. To start with, I used 100k with 22μF and 470μF in series with a 39k in my filter (not exactly the same component values you'd chosen, just near enough for the job - they were just what I happened to have to hand to put me in the same ball park).

 It was only later on that I changed them to 10M with 1μF and a 10μF with a 390k series resistor once I had inserted a 5v cmos RRO buffer amp in between the LPF output and the OCXO's Vfc line. This seems the best compromise so far with my current batch of CQE branded OCXOs between minimising the effects of the phase variations inherent in the GPS system and holding the startup time to a reasonably acceptable 15 minutes[3].

 I experimented with much larger time constants (500 seconds!) to see whether I could smooth out the random timing error excursions in the GPS system but gave up on this method of filtering when it became obvious that during the more protracted map deviation events the phase excursions were being amplified.

 It had looked promising enough for the shorter half minute or so shifts in positional error once the hour or so startup time had elapsed but I could see that using very long time constant filtering here wasn't going to cut it so it was a case of going back to the "Devil You Know" with less ambitious time constant values (10/100 seconds versus your original choice of 3.3/33 seconds).

 With such a basic PLL solution as this, the output is always going to be polluted by these 20 to 30ns phase shifts when using non-timing GPS receiver modules such as the NEO-M8N and the NEO-6M. Timing modules may reduce this effect but they cost far more than the additional cost of an Arduino nano running a Kalman filtering algorithm to filter out such effects to ever greater and greater effect with each passing hour of operation.

 Long term (weeks to decades) the PPS or its derived 100 to 10,000KHz is never going to be out from the exact GPS time by much more than 50ns anyway whether you use a costly timing module or a cheap 'n' cheerful navigation only module. If you can live with these nanosecond sized phase shifts, typically at less than one ns per second either way every few minutes or so, on a 10MHz reference, a simple PLL design will do the job.

 If you're building your first GPSDO, you can always leave a bit of room spare to add an Arduino nano with another IC or two to allow for a future upgrade. After all, even a basic GPSDO is better than no GPSDO at all.

 I'm now actually in the process of reassembling my breadboarded GPSDO into a proper enclosure. I've finally had enough of the unpredictability of plug in breadboard construction - stable enough if you don't physically disturb it but a pain if you have to wrangle it around the bench.

 I've now actually committed myself to building it onto a vero board I'd previously trimmed to slide into the slots of a small extruded case by drilling the extra hole between tracks to accommodate the Vref pin of my OCXO which unconscionably doesn't line up with the 0.1 inch hole spacing of veroboard. Who knows? I might actually have it ready for initial testing before the end of next week! 

 I'm going to use up my very first CQE OCXO acquisition on this model, a 13MHz 5v example rather than any of the 12v 10MHz units in my collection. I've already had this OCXO setup on a breadboard lashup to generate a 10MHz signal using a 74193 as a divide by 13 of the doubled up to 26MHz so as to feed a 3N502 ultra low jitter clock multiplier with its minimum specified input clock frequency of 2MHz. On that occasion, I'd used another 3N502 for the initial doubler but I'm going to use an XOR gate this time round (I've got three going spare) to save using up any more of my precious 3N502s. I'd already tested the XOR doubler idea with the breadboarded GPSDO lashup so I'm quietly confident this will work.

[Notes]

[1] This had been driving me round the twist with its 1ms pps 1/2ms pulse that kept getting narrower and narrower about halfway through a 10 to 15 minute cycle (a sawtooth correction bug I guess) before finally disappearing up its own fundament to then instantly reincarnate itself as the 50% duty cycle 1ms pulse I'd programmed before starting another cycle of this nonsense. 

 I'd set up two '390s to divide the 10MHz ocxo to feed the phase detector with 1KHz (the fastest I could program that 6M to output on its PPS line) and spent many days trying to get the damned thing to lock, even resorting to that 4046's frequency/phase detector output which did eventually start to show signs of working for longer than the 15 minutes it would take to lock phase at such a glacial 10,000:1 division ratio from the OCXO to the PLL's phase/frequency detector.

 At that stage I was waiting on delivery of a cheapish M8N (which has since proved to be a Chinese fake but not fatally so - it's what I'm currently using). I decided at that point to probe the phase detector inputs (after nearly a week of slowly going round the bend) and finally discovered that weird behaviour of the 6M's narrowing pulse - no wonder I couldn't get it to work! - in fact, I'm surprised I'd experienced those brief moments of  short lived "triumph" even using the PD2 output from the 4046!

 I suppose it's just possible that this effect might not appear if it's left on its default 1PPS setting but I haven't tested this possibility since I've no immediate plans to try it out using Lars' GPSDO design where it might just be able to redeem itself. It had only cost me £3.99, delivered anyway so such testing can stay on the back burner for now, (or even forever - it only receives GPS svs anyway).

[2] I'd managed to burn out the PPS line on my first (genuine!) M8N module with a 12 volt jolt just over three months ago now , hence this replacement module from China which, unsurprisingly, is a fake (no flash and no SAW filter, judging by the anomalous results between externally mounted and internally mounted active GPS patch antennas). A CR2032 1KR and Schottky blocking diode solves the short 50 minute BBRAM retention time issue, giving me an estimated 250 days or better powered off retention time to protect my settings and maintain the RTC.

[3] The point at which it's no worse than the GPS positional error induced phase shifts can become (when the final excursions around the phase lock in point become lost in the GPS system noise).

JBG

Good to hear that you've been having some fun. It sounds as if you've duplicated quite a lot of my findings. I found that 100kHz locking was better that 1MHz (with some advice from Lars), I haven't really tried 10kHz but suspect that 1kHz is too low for sensible PLL filtering.

I would be tempted to build the filter section dead-bug style on a piece of copperclad rather than veroboard. It's not RF, but a solid ground is beneficial for keeping noise to a minimum (as is the buffer opamp as you found).

As you are aware, you are still compromised by the use of a non-timing GPS module. I'm not sure how much you've invested so far, but I see that there are still a few LEA-6T based modules being listed on ebay from China and Hong Kong for just over the £20 mark. You ought to get some performance improvement over an 8M (real or fake!). You may well get away with longer time-constants then.

[Illusionist]

It's interesting to read what others are doing, and adjusting things to try them out here.

I've gone over to 100kHz, along with a different OCXO. It's a Chinese made, new (old stock, couple of years) OCXO with a marginally better specs and a lower adjustable range than the Swiss one I was using. 3Hz/V versus 10Hz/v. I'm thinking that can't hurt. It also runs a lot hotter.

I'm playing with the loop filter too. Later today I might try an active filter, since there's a dual op amp sitting there just as a buffer anyway. Being able to watch the startup up on the 'scope is useful (and fun!) as the PLL hunts, locks and stabilizes. I'm still getting used to having a good 'scope.

I even got the main PIC to generate the 10kHz, then 100kHz, signal for the PLL instead of the '390 divider. It's running from the OCXO so why not. That seemed to work OK, just took a little longer to settle but not much. It was a problem when I reprogrammed the PIC and restarted it though, which I'm doing quite often, having to then wait for PLL stabilization again before I could test the code. So I went back to the '390 divider.

I'm thinking of making the thing reasonably modular, once the design is stable enough to have some PCBs made. I already have the board I made for the neo-m8t which I designed to work both as a development board and final part of the GPSDO. I was thinking of putting the OCXO and PLL (or DAC if I go back to that route) on one PCB and the control/user interface/main PSU on a third board, and the output drivers on a fourth fitted on the back panel of the enclosure. That way I can swap a module out when I want to 'upgrade'. We'll see how it pans out.

Oh, and I was lucky enough to catch a couple of new neo-m8t's from a seller in France, for about £20 each. I gave up on the Chinese ones - every one I got was fake, including the m8n which didn't even have the flash inside the module.

I have some nice 18-bit calibration DACs on the way, should arrive today, so I might have another go at the MCU/DAC control method again later.

One thing I have noticed is that with that method, and my code, my derived (lower jitter) PPS very slowly goes out of sync with the GPS PPS. Clearly I'm not hitting the spot, although I can't measure any frequency error even over 10,000 seconds. With the PLL method the DPPS and PPS stay in sync within 20ns even after two full days running. I need to investigate that and look at my code. I want to roll my own code, but I'm not exactly familiar with writing filtering algorithms. I should probably learn though, otherwise I'm sort of wasting that 50MIPS dsPIC I'm using...

[edigi]

My solution (not completed, but concept is tested and it works) is MCU based and I prefer that because of the great flexibility.

The 10 MHz xCXO frequency is directly measured with 60-100ps resolution (counters continuously run in both CPLD and MCU).
The concept is described here http://n1.taur.dk/permanent/frequencymeasurement.pdf but instead of the analogue interpolation I've used TI TDC7200 chip to measure the fraction (the TDC chip's clock input uses also the same 10MHz).
The end of the previous measurement/the beginning of the next measurement (basically the time stamping) is determined by the GPS output (actually another viewpoint is that the time period of the GPS output is measured with the 10 MHz reference). It can be from 1 Hz to couple of hundred Hz (but as others already wrote the GPS output must be integer fraction of its clock, in case of NEO 48 MHz) depending on SW configuration.

The upper limit is determined by the MCU's capability to handle the measurement and low pass filtering (since the time stamping signal from the GPS has big jitter even if the xCXO is very stable due to the jitter of the time stamping the measured frequency will be loaded with jitter as well). Aiming for too many measurements per second is pretty pointless in this case as nothing is gained with that but it can create many challenges.
The low pass filtering of the measurement results is done in the MCU thus very flexible; new filter means new algorithm is uploaded to the MCU.

The error from the low pass filtered measured frequency is used to drive a DAC (external or if the MCU has precise enough DAC even internal) that drives the voltage control of the xCXO.
If GPS output fails (no output at all or too jittery; or there are glitches that the MCU can reject/filter, which makes the MCU based solution better than the PLL based one) last xCXO control voltage can be held or if this is after switch on taken from MCU's flash.
Precision depends mostly on the phase noise and walk/drift of the xCXO (also the clock source of the GPS but let's assume that we use it as it is). In my view 12 digits is not impossible to reach with high quality xCXO (10 digit is easy with any decent quality), however that is beyond my needs and I also don't have any frequency counter to check that (the one that I've built is based on the same concept and it would be a bad idea to make cross check with it because of that).

Due to summer vacation I'm actually too busy with other things to go into details/progress this project...

[Illusionist]

edigi, that's all very interesting. My next project after the GPSDO is to make a frequency counter, reciprocal with interpolation and time stamping, and probably in an FPGA. I've been sketching ideas for that for years. That TI chip looks very useful indeed; I might have to get one to play with. Basically, I'm aiming for something with the facilities of a Pendulum counter, at a small fraction of the cost.

Your reasons for the MCU method are exactly what I was thinking. I'll have to work on my filtering in the dsPIC and see if I can get working properly.

My 18-bit DACs just arrived... time to play! ... Even better, they are 20-bit! (The 18-bit was another I looked at, and I forgot which I ordered.)

[edigi]

One quick note: For the interpolating part highly deterministic delay is needed that is for that part CPLD is a must and FPGA won't cut (not only that, CPLDs with FPGA like internal architecture won't cut either).
The TI TDC7200 has good resolution but it's very easy to destroy it if the surrounding logic does not have very deterministic delay.

I'm actually still on the edge if it actually worth using FPGA for the fast processing or use instead a CPLD+CPLD architecture. For the slower counters even an 1 EUR CPLD is good enough but it can help avoiding all kind of synchronization issues between the fast CPLD (fast counters in CPLD) and MCU. Modern MCUs have HW SPI and transferring even 10k measurements/s via it is not an issue as it does not create extra load to the MCU (10k measurements due to noise square rooting means 12 digit/s basically for very low cost).  In addition modern MCUs have huge number crunching power including FPU so both FPGA and MCU would be very heavily underutilized.
For more than 10k measurements/s FPGA is a must to consolidate time-stamping result and maybe even do some basic preprocessing on them.  That would however imply > 12 digit/s where I'm very skeptic that for that a decent front end side could be done on hobbyist level (that I am).

[Illusionist]

It had not occurred to me that an FPGA would be inferior to a CPLD in that way. I'm more familiar with CPLDs, having only played around with FPGAs occasionally and never actually designed anything with them. My original idea, a few years ago, was being prototyped in some -4 speed grade Altera MAX CPLDs. Old, but they still work.

I'm considering using a Raspberry Pi Zero for the user interface and overall controller. That would make developing that side of it much easier and give some nice functionality for graphs, logging etc.

I've been slowly gathering potentially useful bits for the front end too, some fast ECL counters/dividers, MiniCircuits amplifiers etc.

That project is some time away though, with a lot more research needed. I need to finish this one first.

[Johnny B Good]

====previous quotage snipped for the sake of brevity ====

Good to hear that you've been having some fun. It sounds as if you've duplicated quite a lot of my findings. I found that 100kHz locking was better that 1MHz (with some advice from Lars), I haven't really tried 10kHz but suspect that 1kHz is too low for sensible PLL filtering.

 No need to guess, I can assure you with some confidence that this choice would tax even the patience of a Saint.

I would be tempted to build the filter section dead-bug style on a piece of copperclad rather than veroboard. It's not RF, but a solid ground is beneficial for keeping noise to a minimum (as is the buffer opamp as you found).

 I must admit, I was half tempted to go that route but decided, in view of how well it had worked on a plug in prototyping breadboard, that even the use of veroboard would be a vast improvement (I could always double up on ground traces or add some single sided copper clad board in selected critical areas where I might, in hindsight, consider such measures to be of some tangible benefit).

 In any case, I can always rebuild another version on copper clad board at a later date if I thought it might solve any issues arising out of the use of veroboard. At least that way, with a second version to compare against the original, I'd be able to verify, or not, the benefit of dead bug style on ground plane construction over the use of veroboard when the highest frequency is likely to be the doubled up 13MHz to drive a /13 counter to feed the x5 clock multiplier chip with its minimum 2MHz clock input requirement.

 However, since I'm now going to use an XOR doubler instead of a 3N502 driven from my 13MHz OCXO, that now gives me the option to put it after the /13 counter rather than in front, saving the need to double up from 13MHz by doubling up from the 1MHz output of the /13 counter to meet the final 3N502's minimum frequency requirement. I'd had problems with the classic RC delay XOR doubler when testing with a 10MHz clock so had resorted to using three gate delays from the 74HC14 package. Hopefully, I might have more success with the RC delay at a mere 1MHz input frequency, leaving those three 74HC14 gates available for better use as an output buffer.

As you are aware, you are still compromised by the use of a non-timing GPS module. I'm not sure how much you've invested so far, but I see that there are still a few LEA-6T based modules being listed on ebay from China and Hong Kong for just over the £20 mark. You ought to get some performance improvement over an 8M (real or fake!). You may well get away with longer time-constants then.

 Do you mean items like this?

https://www.ebay.co.uk/itm/HP-LEA-6T-GPS-Module-w-Compass-for-APM2-6-APM2-8-Pixhawk-PX4-Flight-Controller/254283159923?epid=1239162641&hash=item3b34751973:g:UR8AAOSwK6RZJEJo

 There was another slightly cheaper version from a supposedly separate trader. It didn't offer as much detail in the pictures yet both had identical product ratings -  is that all about???

TBH, I've rather gone off the idea of buying from traders located in Shenzen or Hong Kong just lately. I'm waiting on a delivery of 10x 74HC14 chips for 99p which, according to its tracking number, is still languishing in HK customs ever since it fell into that black hole over two calendar months ago, just two days after it had been shipped from Shenzen.

 I've just placed an order for 50x SOP8OP8 TSSOP8 SMD To DIP8 Adapter 0.65/1.27mm PCB Board F6T4 as a result of checking out ebay for those LEA-6Ts. At just £1.06 delivered, it was a bargain I just couldn't resist, notwithstanding the fact that I still have seven of these little beauties left over from my first pack of ten bought over six months ago at the, now seemingly obscene, price of £3.47!

 What's worse is that I'm now dithering between ordering a pack of 20 74HC14s from another Chinese supplier for a whopping £2.17 or go with one shipping a pack of ten from within the UK by the 9th Aug for around the same price - decisions, decisions.

 As for my bargain second FY6600-60 that I'd ordered the 11th June, that's been lost in the postal system for over three four weeks now, I'm still waiting on delivery . Weirdly, the seller didn't opt for a tracked shipping option on this 40 quid item (unlike the seller of that 99p pack of 'HC14s currently stuck in HK customs) but has promised to send another unit claiming a 10 to 15 days delivery time. The earliest date has already expired and the 15th day equates to the... today! Needless to say, I'm still waiting.

 With all that said, you can see why I'm a little leery of ordering modules wrapped up in drone antenna packages like this, especially from China/Hong Kong, especially now with all the riots and protests going on in our ex-colony which might have some bearing on the "Black Hole of HK customs" effect.

 Although use of a timing receiver module might reduce the timing errors and improve the performance of a basic PLL GPSDO, I do wonder whether it would be worth the extra expense when the use of a 3 quid Arduino nano and an extra IC or two would ultimately provide a superior solution (holdover feature and ever improving accuracy/stability with each passing day of Kalman filtering).

 At just 22 quid or so, those LEA-6T modules are a bargain, if you can trust the supplier to deliver a genuine module all the way from China (I know how to tap into the PPS signal ). I might consider one if I can find a Chinaman shipping his product from a UK based warehouse in a timely fashion (typically a week or less). Incidentally, my first M8N cost me 21 quid from a Chinaman shipping from Manchester in less than a week. Now, the only other example of that exact same module is being sold by a Chinaman in China/HK for a rather cheeky 27 quid and some pence!  The one I did go for (that fake) was just under 16 quid. Talk about "False Economy"! I guess I got what I deserved notwithstanding that I wasn't altogether surprised.

 I'm more than pissed off right now with deliveries delayed by months. For the time being, I'll manage with my fake M8N and get a GPSDO built and working to a reasonable standard of accuracy and stability and keep my eyes open for any timing module bargains I won't have to wait more than a couple of weeks at most for delivery - I'm not getting any younger and time really is of the essence these days.

 With regard to that GPSDO project of mine, I'd already figured that the 100KHz phase detection frequency option would be a good compromise between the extremes of 1Hz and 10Mz in terms of lock up time and filtering effect on the clock jitter and sawtooth components so was going to set it up that way to begin with. However, before I eliminated the "surplus '390", I did reconfigure it to test the 10KHz, 1MHz and 10MHz options (I saw no point in going below 1KHz), the results of which did confirm my initial thoughts on the 100KHz option as being the best choice.

 The 10KHz showed the faster lock up performance (compared to my original 1KHz setup with the 6M) as expected with no evidence of jitter effects. The 1MHz showed an even faster response, now dominated by the LPF response but I could see signs of jitter starting to creep in. I tried phase locking directly to the squared up 10MHz sine wave output from the OCXO just for the 'Hell of It" where, unsurprisingly, jitter from the non-integer division ratio was starting to become more evident, whilst, even less surprisingly, the random sawtooth correction jumps could now be seen 'plain as day'.

 Once I'd satisfied my curiosity on this aspect of the design, any nagging doubts that may otherwise have festered over my "no brainer choice" of 100KHz had been well and truly quashed. As for the 10KHz option, that's not so bad a second choice when it's the highest PPS frequency option available.

 Phase locking one generator to another reference generator is a bit like towing one vehicle with another blessed with cruise control using a bungee cord to iron out speed variations of the towed vehicle. The larger the divider ratio, the longer and/or stretchier the bungee cord. In the case of the 10KHz choice, that means we can afford to use a less aggressive LPF to mitigate the more sluggish settling down time and of course, it helps in this case to use an OCXO with a high Hz/V tuning rate.

 The whole system, OCXO's tuning rate, the amount of division applied in the PLL and the LPF on the phase detector's output, all combine into a single equivalent LPF in the control feedback loop anyway. It's just a question of optimising the balance between these three elements to obtain a best trade off between settling time and filtering out the unwanted sources of phase noise in the GPS reference.

 Also, if using a u-blox GPS receiver (or any other brands likewise blessed) with the facility of being able to produce alternative frequencies on their PPS line, selectable in 1Hz steps, you're not stuck with the obvious decade steps of divider ratio. You could, for example, program the GPS Rx to output 312.5KHz and use a 5 stage binary counter to divide the 10MHz OCXO's frequency to match.

 This might well prove a more optimal choice at which to run the phase detector in a basic PLL based GPSDO. You could also try 156.250KHz and even 78.125KHz before you run out of integer frequency options that can match any further binary division. A single '393 will let you experiment to your heart's content (and beyond!) with these binary division options.

  Indeed, now I think about it, you could try a larger range of ratios by using a '390 and a '393 or even just one '390 by itself (I'd overlooked the 200 and 500KHz options I could also have chosen with my single '390, let alone all the other possibilities I'd have had with a pair of '390s - a total of four /2 and /5 options in all ).

 Never mind, I'm more or less committed to reassembling my GPSDO into a cased final prototype on veroboard - reconfiguring it for 200KHz or 500KHz are still available options though (with 200KHz being the most likely best alternative to my current 100KHz choice). At this stage, I've no intention of backtracking to the breadboard setup to check out any more options since I think I'm as close to the best possible compromise as I can be already. Besides which, it's high time I finally took this project to the next level, shiny extruded aluminium enclosure and all (with sockets 'n' things so it can at least pretend to be a fully functioning lab grade frequency reference). 

JBG

[Illusionist]

I've just placed an order for 50x SOP8OP8 TSSOP8 SMD To DIP8 Adapter 0.65/1.27mm PCB Board F6T4 as a result of checking out ebay for those LEA-6Ts. At just £1.06 delivered, it was a bargain I just couldn't resist,

Same here, same price! Couldn't resist that.

More importantly, the seller in France that I got my NEO-M8T from has more:

https://www.ebay.co.uk/itm/Ublox-NEO-M8T-0-IC-GNSS-Receiver-GPS-GLONASS-BeiDou-Galileo/193014081445?hash=item2cf08927a5:g:3YoAAOSwt91cxbn8

As far as I can tell, these are the genuine article. Mine are working well and I flashed them with the latest firmware.

The main differences between the NEO and LEA are the NEO does not have an internal bias-t for antenna power, but instead has a second internal LNA and a filtered power output for feeding into an external bias-t. That's what I did. I designed a simple development circuit and had the PCBs made at JLC - I still have a couple spare...