Electronics > Projects, Designs, and Technical Stuff

GPSDO: PLL or MCU controlled?

(1/11) > >>

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)/

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod