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.