# GPSDO in firmware?

There are numerous designs online for hardware GPSDO (GPS-disciplined Oscillators). I'm failing to find any firmware-only implementations. I wonder if my Google foo is weak or if these are impractical in firmware.

My scenario is a uC (an STM32) with a GPS. I need to output a 1Hz pulse that aligns with GPS PPS, even during loss of signal. Naturally, during LOS the output is only as good as my local oscillator, but I'd like to adjust relevant timer's timebase to average or recent GPS PPSs.

I'm sure someone has done something similar.

• Try: hanssummers.com/gpsref2.html STM32 is overkill if it has this one task. You have included no requirements for accuracy - this frequency-locked-loop method may be inadequate for critical needs. – glen_geek Nov 19 '18 at 16:05
• STM32 is about the cheapest you can buy, in small packages--cheaper than most 8-bit chips. It does a couple more things though in addition to the GSP loop. – iter Nov 21 '18 at 0:28

This is probably pretty simple to do. There are a couple of ways to approach this depending on the accuracy you need. The PPS output will be generated from a timer/counter module by dividing down the clock. In your serial receive ISR, capture the PPS counter value on receipt of the correct byte, I think it's usually the first byte of the message. Or use interrupt on change to capture the value when a PPS pulse from the GPS arrives. This becomes the error term. Now, the question is how to control the frequency. One way is to do some sort of fine control of the whatever oscillator is used to drive the timer module, which could be the main CPU clock. Use a PID loop to push the frequency higher or lower until the PPS counter is rolling over exactly when the message arrives from the GPS receiver. If you can't control the oscillator, then you're limited to adjusting the timer/counter upper limit setting until the rollover is aligned. Again, use a PID loop to adjust the value. You might want to make some small modifications if the input signal is lost, such as holding the error term constant and not updating the integral term until the signal is restored.

• I, too, think it should be simple to do. What surprises me is not seeing any code online. – iter Nov 21 '18 at 0:24

My scenario is a uC (an STM32) with a GPS. I need to output a 1Hz pulse that aligns with GPS PPS, even during loss of signal. Naturally, during LOS the output is only as good as my local oscillator, but I'd like to adjust relevant timer's timebase to average or recent GPS PPSs

When you buy a hardware GPSDO, e.g. from Jackson Labs, you'll find that it typically consists of a GPS receiver, a high-quality oscillator that gets disciplined and some microcontroller (in the case of Jackson Labs, they like LPC/espresso ARMs). You can actually see the NXP microcontroller on the bottom side product picture from Jackson labs (large black IC, right picture), next to the GPS receiver module (looks like a ublox AMY-6T or something). On the top of the device (left picture) you'll find the stable (and expensive) oscillator (large metal box).

The idea really is that in case of loss of signal, you need something stable to do your "holdover". That's why the better GPSDOs tend to use Oven-controlled oscillators.

So, first of all, check whether a ready-made GPSDO doesn't already fulfill your requirements of holdover stability. That'd be the easier way, and bonus, someone who's done this before has designed everything.

Notice that what Al alex.forencich describes is limited in accuracy: if let's say your counter runs at 10 MHz, then the best adjustment granularity achievable when only looking at a single second interval is 100 ppb – worse than many GSPDO's frequency accuracy! Of course, you'd remedy that with a narrower PID loop filter bandwidth, but that has other negative effects – what if your PID controller now can't keep up with the drift of your oscillator? What if the PPS edge timing has it's own error (hint: it has, typically in the order of 100 ns, at least)?

That's why the firmware on the GPSDOs probably is a bit smarter than just a PID; if you spend enough research and characterization on it, I'm sure you can model an oscillators f/V behaviour and it's drift better; extended Kalman comes to mind.

I've got zero experience modelling physical oscillators at this accuracy, nor modelling the variance behaviour of GPS receiver's frequency or timing output. That's why I'm not intending to build my own GPSDO anytime soon – but I wouldn't have to, because if I need the really high accuracy, I'd go to suppliers like Jackson Labs (not affiliated with these, btw), if I'm OK with decreased performance during holdover: ublox does sell their timing-specific GPS receiver ICs that you can just program to hold over. All they need is power, an antenna and an oscillator to control. They're pretty much what you describe in a single package.

• I don't have the money or the power budget for an OCXO. The device needs to run on a couple of AAs. If I could put an OCXO onboard, it would solve my problem. Timing-specific GPS module is an interesting idea. Their documentation says they need to stay stationary. Do you know if there's a way to configure them to say that the antenna may be moving? – iter Nov 21 '18 at 0:27
• no, but my guess is that they have a $v_{max}$ up to which they reliably work and you can ask them for that. As said, the ublox timing modules can work nicely with non-OCXO oscillators, so use whatever fulfills your cost/power/accuracy needs. – Marcus Müller Nov 21 '18 at 11:41