home about telemetry projects publications gallery log

A sub 5e-13 ADEV GPSDO

---

Some chatter on the time-nuts mailinglist lately prompted me to finally do an experiment I've been thinking about for a while. It is yet another GPSDO, but one which uses a geodetic L1/L2 GPS receiver and real time PPP.

A "traditional" GPSDO consists basically of a good (or not so good) OCXO, a cheap GPS receiver, and some circuitry and a CPU to measure the time difference between a Pulse-Per-Second (PPS) from the GPS module and a PPS derived from the OCXO, and using the result to steer the OCXO with a DAC. The goal being to keep this time interval close to constant, which would mean the OCXO is on frequency. The idea is that the GPS derived PPS has a very, very stable and precise frequency — much better than the OCXO itself, at least when viewed over sufficiently long timescales.

The trouble with this, as with so many other things, is in the details. There are many large and small sources of error in the PPS out from the GPS receiver. The challenge for the designer is to make a controlling loop that ignores the errors and applies corrections to the OCXO such that the frequency output is as close to "perfect" as possible. A couple of the larger errors are:

Sawtooth error. The GPS receiver contains a CPU that is clocked from a crystal somewhere^[1]. When time comes to output a pulse, the CPU must chose a clock edge of the incoming clock signal on which to go from low to high on the output pin — theres no magic gates that can toggle up and down independently of the clock signal, that is just a fact of digital processors.

More often than not, the PPS out will not occur precisely at the time the CPU thinks the second starts, it will start on the closest clock edge, which can be off by up to half the period of the clock frequency of the receiver, ballpark 20-50 nanoseconds. However, the CPU will know "how wrong it is", and many modules will output a message with that information. This is what's known as "sawtooth correction". So if the PPS out from the GPS differs in time from the PPS from the OCXO by 623 picoseconds, and the GPS reports an error of 211 picoseconds, we can correct the reading and use the resulting 412 ps in our disciplining loop. Another option is to simply ignore the error — we want the time constant of the disciplining loop to be as long as possible, and over time the sawtooth error will simply average out. This is a short term error that is relatively easy to deal with. The next one is not.

Ionospheric disturbances. A frustrating fact of the ionosphere, for those who spend any time considering the ionosphere, is that it delays radio wave propagation. What's worse, it is not even static — over time, a few hours, the Total Electron Content of the ionosphere varies appreciably, and the delay of the radio waves emitted by the GPS satellites change with it. The delay will depend on the angle and direction from the satellite to the antenna. GPS depends on knowing the time-of-flight of the signals from the satellites to the receivers, so this unknown delay impedes the accuracy with which we can know our position — and the precise time.

The GPS signals themselves contain a rough estimate of the state of the ionosphere at any given time, but the path between each satellite and each receiver on earth can ofcourse not be modelled and transmitted. SBAS adds better modelling, but it is still not great from a timing perspective. On my L1 setup, I will typically observe a 10 ns "undulation" in phase in the course of 24 hours. The goal of this project is to get rid of this effect.

The challenge when we talk about GPSDOs is that the change in the ionosphere is slow compared to the disiplining loop for an OCXO, so there is no way to avoid this phase shift. The only way, using an affordable L1-only GPS receiver, is to use an oscillator that is so stable that it needs corrections only once per day or so, typically a rubidium. Rubidiums have their own issues, so we'll leave that out of the rest of the discussion.

Fortunately, the delay through the ionosphere is frequency dependent. This is the reason why GPS signals are transmitted on more than one frequency^[2]. If we have a GPS receiver that can make observations on two separate frequencies, the delay can be calculated and taken out of the equation. This is the primary source of accuracy in "geodetic" class GPS receivers^[3]. For the rest of this post, "observations" refers to dual frequency observations. Single frequency observations can be postprocessed in the same way, but the improvements will be modest; the ionosphere is the largest source of error.

Orbital errors. As mentioned, the time-of-flight of the signals from the satellites to the receiver is used to determine the distance between them, and thereby the receivers position. That hinges on knowing precisely where the satellites are in space. As with the ionosphere, the satellites transmit an estimate of where it is. And again, it is based on an imperfect model. The orbits transmitted from the satellites can be off by tens of centimeters — and this translates directly into errors in the position and time estimates in the receivers. SBAS carries corrections for the orbits as well, but the corrections distributed on the real time product streams from IGS et al are better. Presumably satellite bandwidth is limited, whereas internet bandwith less so.

In the same breath we might as well mention the clocks on the satellites. Since we are measuring time-of-flight of signals, knowing where the satellite is and what delay the signal has been subjected to is clearly not enough — we also need to know when the signal was sent. And that knowledge is in the satellite. The local oscillator on board the satellite, a cesium or a rubidium, is pretty darn accurate. The precise frequency of that oscillator is the definition of what time it is, as far as that satellite is concerned — and that time is encoded and transmitted to the receivers back on earth^[5]. While accurate, the satellite clocks are not perfect, and again there are corrections that needs to be factored in.

The final piece is when the signal was received — and this is where the receivers local oscillator comes in to play. It is the precise frequency of the local oscillator we want to correct and stabilize. PPP puts all this together and calculates two pieces of information with great precision: where the receiver is, and the phase of the local oscillator. It is this last part that is of interest.

It might sound tempting to use the PPS out from a geodetic GPS receiver as the source for the disciplining loop, but so far I have not found one where this would work — the PPS out is not engineered to be really precise in time, and commonly the PPS is derived from single frequency observations — which would give no benefit. Another point is that there are many other issues we would not correct for with this approach, Solid Earth Tide being one of them, so if we are going to the trouble of using a geodetic GPS receiver, we might as well go all in..

Putting it all together. The way to get the absolutely best position and time estimates from a GPS receiver is to "post process" dual frequency observations with PPP. The observations of satellite signals are combined with precise measurements of the satellite clocks and orbits from e.g. IGS, as well as a number of modelled corrections^[6]. Black magic, aka math, is performed and a very accurate result pops out. The fly in this particular ointment is that the corrections are not available until the next day (or 2 weeks later, depending on the level of precision required). This, obviously, is not a viable approach for a disciplining loop, at least for an OCXO. For a cesium or a maser, sure.

The good news is that IGS and others are experimenting with Real Time corrections — here is a somewhat dated article from GPSWorld. These corrections are nowhere near as precise as the "proper" corrections, but they surely must be better than nothing. This is what I wanted to test in this experiment. The PPP process itself also corrects a few effects that does not depend on precise corrections.

IGS Real Time Service distributes corrections that can be used in the PPP processing of observations, and RTKLib is capable of processing them. So it is simply a matter of putting the pieces together, and see what pops out!

The setup. I chose my very best OCXO for this experiment, an Oscilloquartz 8601 option 3 BVA. This OCXO has an ADEV below 1e-12 out to about 10.000 seconds, and a floor around 2e-13 from 10 to 100 seconds. This, in my book, is spectacular. Better OCXO's exist, but "factory fresh" we're looking at a pricetag in the neighborhood of 18K USD.

To discipline the OCXO, a source of stable, high resolution voltage that can be applied to the electronic tuning of the oscillator is required, and for this I use a Keysight 33510B function generator. While not really intended for this type of use, I still got good results — very little noise is visible in the short term. The generator will output a fixed voltage with 10 microvolt resolution. Coupled with the very limited tuning sensitivity of the BVA, this seems to work well enough for a proof of concept. I expect the tempco is not exactly stellar, but I have not really seen any obvious bumps — and 5e-13... Well. 'Nuff said.

A Novatel OEMV-3 is clocked from the BVA, and the observations from the receiver coupled with the PPP processing is our very sensitive phase-detector. It is a bit convoluted, but the reference for our phase detector is actually a "virtual clock" — the collected satellite clocks combined with the corrections obtained, filtered through the PPP process. This clock is stable enough for our purpose, we will come back to that.

If patience is at a premium, and in my case it is, some way to measure the GPSDO real time is also highly desirable. Since I have access to a maser and a Timepod, the second output of the BVA was used. Note that the maser and the Timepod do not form part of the loop, but facilitates a direct view of what the BVA is doing — which saves more than a little time when tinkering with the PLL tuning!

A maser and a timepod is not necessary, but can be replaced by patience. If the GPS observations are logged to disk when the GPSDO is running, these observations can be postprocessed using precise corrections the next day, and a very accurate phase record of the OCXO/PLL pops out. This "self-documenting" property is extremely attractive in my view!

Corrections. The IGS and other entities distribute various real time streams of corrections. A simple, free, registration process is required to gain access. It is worth noting that CDDIS distributes its streams over SSL only, I have not found a way to use this in RTKLib. I registered with rtcm-ntrip.org and get the corrections from products.igs-ip.net. There are many variations — a summary is at igs.bkg.bund.de. In the end I more or less randomly chose CLK93. I have also done some preliminary testing on IGS01, but it seems the clock corrections are less frequent, every 5 minutes by the looks of it, which leads to spikes on the phase plot. CLK93 transmit clock corrections every 5 seconds.

An interesting question is how good are the corrections? And while there are some statistics, see for instance igs.org and igs.bkg.bund.de, I think the best way is to simply test the whole shebang, PPP and all, on a Trimble NetRS which is clocked by the maser. In this case we know that the local oscillator, i.e. the maser, is "perfect" in this context — the noise is far below what we are observing, at least at timescales less than a day or two — so any noise and instability shown in the PPP results comes from the corrections and the processing^[4]. This is best case, whatever we do we can not get better than this in the long term. We should tune our PLL such that whichever is better, the OCXO or the PPP results, "win" at that timescale. This is visible in the first plot in this post: the blue line is the BVA doing its thing, until it intersects the pink ADEV curve from the PPP, at which time the disciplining steers the BVA to follow the PPP results.

For both CLK93 (in blue) and IGS01 (in green) the clock solutions from the NetRS/maser combo is a bit bumpier than one might whish for, as can be seen below: