Tag Archives: gpsdo

GPSDO 10 MHz

u-blox GPSDO: a simple, low cost, yet – high performance approach

2 Comments

There are many circuits around in the web, related to GPSDOs, and a more sophisticated design with a self-steering u-blox receiver has been published earlier here. Now I felt tempted to try an easier approach, without the hassle of precision references, operational amplifiers, DAC, and other devices that are great but high cost when you need to avoid noise and other complications.
Essentially, this design is a clean-up PLL, with some monitoring of the receiver, and the PLL health. All monitored by a simple 8 bit microcontroller, an ATMega8-16PU in this case.

We have some elements here, (1) the OCXO and amplifier, distribution amplifier – to provide the outputs, 4 in this case, and a good TTL level 10 MHz signal for the PLL, (2) a u-blox receiver, configured to provide either 5 Hz flashing in non-locked condition (no GPS reception, or no good reception), and 125 kHz, 50% duty cycle as a phase reference in locked condition, (3) the MCU, ATMega8, that is configuring the GPS received, providing a 125 kHz signal derived from the 10 MHz OCXO (the OCXO is used as the microprocessor clock – don’t introduce a new clock in such circuits, which will only lead to spurious signals!), (4) a 74HC86 that is used as a phase detector, and to convert the GPS output (a 3.3 V signal) to 5 V level.

That’s the OCXO and distribution amplifier…

The phase detector…

The controller and PLL filter – a simple two pole filter. It replaces all the expensive references, DACs and opamps of the more sophisticated designs. There is another small, faster filter to convert the phase angle to a voltage – converted by the 10 bit ADC of the ATMega8, 1 bit is about 4 ns.

The circuit full view…

Some first tests turned out well. Monitoring the OCXO phase with a scope…

To do a more thorough tests, without all my various test gear that it back in good old Germany, I used the 10 MHz to run another GPS receiver (after upconverting to a 26 MHz clock), then the NAV-CLOCK message can be used to report phase and drift. The short term stability of the OCXO is better than the GPS, as can be seen, but there is no long term drift – because the OCXO is now steered by the 1st GPS receiver via the PLL (XOR phase detector and loop filter).

The phase detection is done at 125 kHz, a convenient frequency for precise measurement, and high enough for filtering.

About 20 ns of jitter are clearly visible in the u-blox output, because it is running on a 48 MHz internal clock.

The circuit is running well, because of the few parts the cost is low and should be easy to reproduce. Let me know in case you need the ATMega code (written in GCC).

The display shows the phase angle, essentially, the duty cycle of the phase comparator output, the stability of the OCXO voltage (by a low pass algorithm), and the lock condition of the GPS (detected by measuring the frequency with timer0 of the ATMega8, and the INT0 interrupt at rising flank to reset the timer).

Phase noise is very small, there are no visible spurs (the lines seen on the screen relate to recalibration events of the analyzer rather than spurious signals, except those at +-125 kHz – at -90 dBc – probably you can get rid of these by better shielding and compartmentalization).

Sure there could be more sophisticated phase noise measurement, by analyzing the control voltage with a low frequency analyzer. I may proceed with such analysis these days but don’t expect to find much, anyway, would be best to fit the circuit to a shielded box first.

All in all, I believe this is a very workable solution that will give you great performance at lowest cost, and with little effort. Sure it will work with various types of OCXOs, the Trimble unit used is generally very good in terms of drift and phase noise. Be aware that some newer Trimble units aren’t all that good. The OCXO draws about 2 Amps at 12 Volts upon startup, but it is OK to start it with a current limited supply, at about 1 Amp, if you don’t want to overdesign the power supply.

GPSDO 10 MHz

u-blox GPSDO: Joe’s and Gisela’s magic generator

Leave a comment

In reply to an earlier post, GPSDO Update, I received the following great implementation of a GPSDO using u-blox receivers. The pictures are rather self explanatory.
>>>>
Hello again Simon!
I trust you are well and are enjoying the year end break.

We ( My good Wife and I..) have put your GPSDO software to good use. We used your message processing code almost as is, and added the various functions to drive my specific hardware and DAC, etc.

I have built up the complete GPSDO, with the 1-50MHz Analogue Devices AD9854 Quadrature DDS as a signal generator, provided with a 200MHz clock from the SI5351 PLL.
I also have a ‘signal generator’ output from another Si5351 channel, 1 to 200MHz, and a third channel output. square wave, from the GPS time pulse output, and can set outputs from 1Hz to 10MHz in decade steps.
I used a 7inch NEXTION graphics display for the display and control inputs ( touch screen) – that works very nicely!

I have run the unit for a few days now, and logged a 48hour period of data, every 10seconds, regarding the clock bias, drift, DAC output voltage etc, and the result looks very good indeed.
I am very pleased with the instrument and grateful for your assistance in providing your code. Thank You!

I have attached a few photos for interest.

Kind regards, and have a very good Christmas!

Joe and Gisela.
>>>>

GPSDO 10 MHz

Si5351A + u-blox M7: Clock generator tests

5 Comments

With the Si5351A mastered, time for some tests with the actual application, the GPS receiver (and later GPSDO system).

Two tests were performed:

(1) Using the Si5351A clock generator with a standard, not specifically selected or particularly stable crystal. Presumably, an AT cut crystal, running at 25 MHz.

(2) With the Si5351A driven by a OCXO (HP 10811A, part of a 8662A unit – will be later replaced by a stand-alone unit using a HP 10811A with power supply and distribution amplifier, but essentially, to the same effect).

The first test, we need to set the registers of the Si5351A (check the Silicon Labs AN 618 Application Note – check it in a quiet hour, because it has a lot of heavy content…). 25 MHz clock input, 26 MHz OSC0 output – can be achieved by running the VCO at 650 MHz, and integer-only dividers.

For the calculation, I use a self-made Excel sheet, which allows me to play around with the numbers to figure out the best combination of dividers and VCO frequency.

Here, the over test setup:

That’s the Xtal used – it came with the board, and I couldn’t find any data on it. Appears to be an AT cut crystal. Starting from room temperature, frequency, will go down with increasing temperature, and up with colder temperatures.

Such temperature variation is easily introduced here in Japan. First, keeping the room at 22 degC by the aircon (A/C) unit, then switching it off overnight (cooling the room by a few degrees, maybe down to 17 degC), then, next morning, heating up again to 22 degC (and a bit more as we had a sunny day).

The detail below also shows the small thermal mass of the Si5351A, free-hanging in air. Better to enclose it or to add some thermal mass later, to avoid thermal-gradient introduced noise or instability. You can clearly see the on-off cycles of the A/C unit regulating the room temperature.

After all this study, we find out that we can use the GPS and Xtal as a quarz thermometer (such thermometers really exist!)!

Test 2, now running with a 10 MHz reference clock, and still 26 MHz output to the u-blox M7 (in all cases, the u-Blox has been modified by removing the TCXO, and feeding the clock signal directly to the GPS chip). Sure I known that I am running the Si5351A outside of the specified range – but after all the research, Si5351A Spec, Myth and Truth, I believe this is OK.

The test setup – note the dotted additions – this will be the later phase locked circuit.

The register settings – running the Si5351A VCO at 780 MHz allows the use of integer-only dividers.
Capacitance set to 4 pF (the lowest value possible for the Si5351A, but it has little effect on sensitivity, 10 pF default setting works as well, maybe 1 dB decreased sensitivity, but we are anyway feeding more then enough power to the Xtal A input of the Si5351A).

The GPS clock drift data – not very exiting – no drift at all, less than 1 ppb over a few hours. There is a slight frequency offset, because the electronic frequency control (EFC) of the 10811A OCXO set to 0 Volt, rather to the proper value for exactly 10 MHz, only for convenience and to avoid any artifacts from EFC DAC noise or drift.

The position accuracy also seems better with the stable oscillator, but may need to check this again after acquiring data for a full day or so.

All in all, more than a proof of concept. Next steps include setting up a stand-alone OCXO (I have a couple of spare 10811A OCXOs around), a distribution amplifier (nothing special, planning to use some 74HC14 with small signal transformers for isolation), and getting the PLL code into a microcontroller. For the DAC, I will use a fairly basic model, and provide a low pass filter at the output (much faster than the digitally-generated long time constant low pass of the PLL loop, but still slow compared to common standards) to reduce noise.

So far, the bill of material is very low, just a few dollars, including the GPS receiver. My goal is to stay below USD 10 total, excluding the OCXO, to achieve better than 10-9 stability, and an output with no jitter or other issues.

GPSDO 10 MHz

u-blox GPSDO: Update!

9 Comments

With the hardware already set up to provide a 10 MHz signal and electronic frequency correction, some optimization of the algorithm used for phase locking. It needs to be a really low frequency low pass filter (say, 0.001 Hz), and we need to deal with the discrete nature of the measurements and the quantization.
This is accomplished by three mathematical approaches
(1) The data is sent through a 32-parameter FIR low pass.
(2) The frequency drift is calculated for the last 32 seconds, and used as derivative signal, as long as the oscillator drift is less than 10e-9 (1 ns every second!).

The u-blox settings – these are no timing receivers, but I set the device for 2D stationary navigation, it gave the best results here. Also, better disable all messages you don’t need, it will be beneficial to avoid overloading of the slow serial interface (still running at 9600 baud).

Here some examples:

With the PLL open, the signal is drifting away, albeit, at a very small rate.

To check the stability and general behavior, I’m monitoring the 10 MHz signal on a scope, triggered by the time pulse (set to 100 kHz) of a 2nd u-blox receiver, sitting closeby. Horizontal deflection is 10 ns per div. Sure, the signal is broadened by the interpolation of the 2nd receiver, which has a free-running TCXO. Because of the synthesis of the 100 kHz signal from the internal 48 MHz, the trigger has about 20 ns jitter-no problem here, because the drift is much stronger and the phase of the 10 MHz signal relative to the 2nd receiver can easily be measured down to 1-2 ns.

GPSDO 10 MHz

u-blox GPS receiver: a self-regulating clock, and a GPSDO, and all of this, for the lowest cost

Leave a comment

The quest for precise timing, it is a mainstay topic for all serious electronic enthusiasts, and for a good reason – it offers so much insights into receivers, oscillators, phase detectors, regulation theory. After mastering such design, the hobbyist has himself earned a masters (or at least bachelor’s) degree.

With the advent of compact and really powderful GPS receivers, like the u-blox devices, receiving GPS signals is no problem any more, and in fact, it has never been over the last 20 years, with various Motorola receivers, etc.

The u-blox devices have a feature that makes a reference frequency (derived from its internal 48 MHz clock) directly available, rather than just the 1 pps signal that is not all that easy to use for locking a 10 MHz reference to it. The u-blox signal, which can provide a jittery 10 MHz, or, preferably, integer-divided 48 MHz (e.g., 8 or 4 or 2 MHz), has been widely used as a reference frequency in the amateur world, and u-blox company and other recommend to use an external PLL to clean up the signal according to below scheme. This implies that the GPS will be running on a drifting local osciallator, and with a good amount of knowledge and software u-blox is mastering the drift prediction and corrections, and after all such effort an external oscillator, typically, an OCXO is kept in sync with the GPS true clock, by even more phase detectors and control loops. It is doable, logical, practical, but not very clever.

Sure there a better and much more expensive GPS receivers, and even special timing-related u-blox devices (about 10x more expensive than the regular receivers), which can control an internal VTCXO (voltage-controlled temperature compensated local oscillator). With such approach, the drift of the local osciallator will be small, and all in sync with the GPS frequency, but still, it is not as precise as a really good metrology grade OCXO. I am still relying on some well aged HP 10811A oscillators.

That’s the magic neo-7m device, or a Chinese copy of it, you never know – but all that really counts is good reception, and this can be easily checked.

Which secrets hide inside the metal can? Well, let’s find out. Most important part, the G7020-KT GPS processor, it is a remarkable piece of engineering, and u-blox must have a crew of the most well educated, highly paid and hard working people to come up with such devices. Also, they know that they must protect their inventions, and even the datasheet of this device is strictly confidential, although you can find it at many places. What you can’t find are some secret control codes that would allow us to use a 10 MHz clock directly as the clock source for this chip – it is running on 26 MHz by default, for whatever reason! Internally, the other frequencies are synthesized from this 26 MHz anyway.

The typical TCXO performance, it is not bad, drifting along, and we can do some further stability analysis on it. For such a small thermal mass, the performance appears quite good. Accurate to 0.5 ppm over temperature, and 1 ppm per year.

That’s the GPS with the TCXO…

With no effort, the TCXO can be removed, just by holding a soldering iron to it to heat it up.

After removing it, we just solder a thin RF cable in position. In my temporary workshop here, I don’t have better tools, so this must work for now. Ideally, you add a decoupling cap, and solder a wire to a solder post or other propper connection or contact.

We have no good information what level of power is needed at this input, ideally, a 0.8 V p-p min. signal, DC coupled, but we don’t have such signal generator here, only a HP 8662A, which has sinewave output. Using the u-center software, and experimenting, the receiver works well from about -5 dBm of coupled power at the clock input. Operating at 0 dbm, that’s enough, we don’t want to fry this chip.

Even with a small antenna, good reception, within the (wooden) Japanese house.

Now, the feature we are going to use – not the reference frequency output of the u-blox, but the UBX NAV-CLOCK message, which is no less than a phase detector and drift measurement device, of the clock signal, relative to the GPS true-software-reconstructed clock. Marvelous.

As the new 26.0000000 MHz source, we use a 8662A generator with HP 10811A reference, and an EFC (analog frequency control input, about 0.1 Hz per Volt). On top, a 35601A interface, only using the DAC portion of it to generate a tuning voltage from the host computer (connected via GPIB). It is not the most handy DAC, but the only one I have around at the moment.

First, we try without any feedback – Allen deviation. First, the plot using the original TCXO, next, the same receiver (at the same location and setting), with the 8662A (freerunning).

The 8662a – not yet fully warmed up, but already one decade better – or even more, because of the resultion of the phase detector (1 ns!).

Next, we need to do some programming – this will later be put into a microcontroller, but for now, we use a regular PC, running a C program. This program reads the NAV-CLOCK message from the u-blox receiver, does a magic calculation, and then sets the EFC voltage of the OCXO, which in turn determines the 26.000 MHz clock for the same u-blox receiver. And after not too long time, all is frequency looked.

Here, some first results (using a rather small bandwidth regulation loop, just to proof the principle without waiting for too long time).

Introduced some artificial disturbaces, and the system is reacting well.

Next – using a Silicon Labs clock generator, and a stand-alone OCXO to do the same thing, and then, the software needs to be put in a small microcontroller (currently running a rather calculation intensive floating point algorithm). Stay tuned.