GPS assisted Frequency Transfer: ADEV e-14 in 2000 seconds
A couple of weeks ago I posted about a Sub 5e-13 ADEV GPSDO, hitting e-14 at around 6-7.000 seconds with an ADEV ceiling of 5e-13.. This is pretty good as GPSDO's go — in fact I am not aware of any GPSDO anywhere near as stable, but it is very possible that a better GPSDO exists. Drop me a line if you know of one!
That GPSDO steers the local oscillator towards what amounts to "IGST as realized by GPS observations and real time corrections, filtered through the PPP process", for lack of a shorter description. I also posted some results from measuring, in a somewhat haphazard way, the stability of this "IGST virtual clock" — and it was not awesome, at least compared to IGST as realized with IGS Rapid products.
As far as I can work out, with a not insignificant amount of hand-waving, this is because the corrections are worked out based on results from many different analysis centres, but the results are not normalized to a single time-scale. Or some such...
The logical next step is to treat this "IGST-like timescale" as a transfer clock: (clock A - clock C) - (clock B - clock C) = clock A - clock B, as I am led to believe. Given that TAI is realized using pretty much this method[1] (apart from the whole real time and disciplining aspect), I had pretty high hopes.
The instabilities of the "quasi IGST" should simply fall away in the differencing, and with some caveats and if's and but's we should have access to "maser-like" stability to discipline towards, ofcourse with some added noise and some delay, simply through a single TCP port from halfway across the world. That would be neat.
The scheme is as follows:
At the "master" site there is a dual frequency GPS receiver clocked by a maser, which makes available a stream of observations to the slave site over tcp/ip.
At the "slave" site there is another dual frequency GPS receiver clocked by the oscillator we want to discipline, feeding observations to RTKLib which does real time PPP using some real time product stream.
Also at the slave site is another instance of RTKLib, processing the real time stream of observations from the master site, using the same corrections. The resulting two phase records are then differenced, and the result used to feed the PLL which disciplines the local oscillator at the slave site.
I've found a paper[2] thats pretty close to what I try to do (except the whole "disciplining" thing), and from a cursory reading it seems the basic idea is sane.
I ran a zero-baseline experiment doing precisely what is outlined above: Two separate GPS receivers in my lab, with separate local oscillators (the maser being one of them), each feeding an instance of RTKLib using the same settings and the same stream of corrections. The resulting clock solutions was matched by timestamps, and the differenced output — simply "phase A - phase B", was used as input to a PI-controller that disciplines the local oscillator of one receiver.
The results was encouraging — e-14 between 2 and 3000 seconds, but I am too impatient to wait for long enough. Zero baseline is good for getting some bounds on the performance, but to be useful the method needs to work over longer distances. In essence, what was needed was a GPS receiver at a remote (to me) location, clocked by a hydrogen maser, publishing a real time stream of observations that I could get access to...
And as luck would have it, the IGS Network has dozens of sites clocked by masers and the observations can be had real time. Ideal for what I am trying to achieve. I selected a receiver/maser in Bruxelles and left it alone over night. The next morning, Timelab had some nice traces, shown right.
Two things are evident in the plot: the basic approach works — but it does not work "perfectly". Even when differencing the phase records, there is plently of crud left. In particular there is an unsightly bump in the phase and frequency plots starting at precisely 00:00 UTC that I edited out of this plot — I have not chased down the cause of this, but I suspect it can be managed/compensated for. Looking closely at the plots, it does look like the PPP filter gets reset at midnight. But that is speculation.
It was precisely this kind of crud I was hoping the differencing would get rid of. As it stands, the approach works pretty well, but I am not confident it works very much better than simply disciplining to IGST directly. In [2] they do some pretty hefty cleanup of the observations, that I dont think will make it into RTKLib (at least I am not competent to put it there..)
There is also the very real chance that the traces will get worse as more data is collected.
The PPP process works by filtering observations, corrections and various modelled effects through a Kalman filter. The output of the filter ofcourse depends on the various inputs, and not all inputs are the same: even if we difference the phase records, there will be noise. The question is, how much.
The best way to test this, I think, is a zero baseline common clock experiment: Run two separate GPS receivers, on the same antenna, clocked by the same oscillator, through two separate instances of RTKLib using the same corrections. Difference the phase records, and look at what's left. Since the clock is the same, any instability is process (and receiver) noise.
Unfortunately, doing this would mean breaking the disciplining loop I was measuring, which I was not inclined to do. Thinking a little about it, I think I came up with an elegant solution that would give me the information I was after; some indication of the noise in the method. The best part of it was that it was already set up. I already had a separate instance of RTKLib solving the observations from the NetRS clocked by my maser. And I was running RTKLib on observations from a distant maser for the disciplining loop. Basically, those two sets of PPP solutions could be differenced, and the output of that would give a pretty good indication of the noise. Plots below.
In this plot, the local maser is a bit off frequency, which agrees with the monitoring I have using IGS Rapid products and post processing. The ion-pumps have been acting up these past couple of days, and the weather has been exceptionally hot — I fully expect the frequency to vary a few parts in e-14. It should also be noted that I was a bit impatient when collecting this data, the PPP processes should ideally be allowed to churn away for at least a few hours before using the output. I gave them half an hour or so, so some of the drift could be due to the filters still converging.
The ADEV of the difference between the two goes e-14 at 1500-2000 seconds — presumably, the tuning of PI-loop can be "firmed up" a bit. In particular, I though the phase plot was interesting around 5000 seconds or so, where it is very visible how the noise is cancelled out by the differencing. Just to be clear, neither of these plots is the disciplined oscillator — but it does put an upper bound on the performance.
It is not a perfect test. It is not common clock, so some noise is due to the masers. But given that these are masers, the noise they contribute to the measurement should be negligible, far below the levels present in a disciplined oscillator. It is also not zero baseline, so some noise could come from that — but that would be part of the "use case", and it would be relevant to include that in the "baseline" measurement.
There is one other factor that may be an advantage or a disadvantage, depending your point of view: in this setup the local oscillator is disciplined towards one specific frequency source. If that source is off frequency with respect to some timescale, tough luck. This can of course also be an advantage, if this is what is needed. IGST is an average of several sources, and presumably would be more accurate in terms of absolute frequency. On the other hand, disciplining to a remote maser seems to be more stable. So, its a tradeoff between absolute frequency or better ADEV. Pick your poison.
Keep in mind that the frequency offset can easily be quantified, postprocessing with PPP and IGS Rapid corrections, and the offset is likely in the neighbourhood of few parts in e-14, depending on which maser/receiver is picked.
There is one more potential issue that needs to be characterized in some way: as mentioned, PPP at its core is a Kalman filter, and by steering the input frequency to the GPS receiver, we are changing one input to the Kalman filter. How these two filters, the Kalman filter and the PI-controller, interacts is not obvious to me. I suspect a long(er) poll interval might be in order..
Anyway, I thought it was a neat experiment. And theres *much* that still needs testing (which correction streams[3], should GLONASS be included, L2C or not, various PPP knobs and dials, tropospheric modelling or estimation, PI-tuning, optimal sampleinterval, etc etc), and of course much more data to collect.
This research was written up and presented at 2019 Joint Meeting of the IEEE International Frequency Control Symposium (IFCS) and the SFMC European Frequency and Time Forum (EFTF): "A Novel PPP Disciplined Oscillator"
[1]: The TAIPPP pilot experiment
[2]: Monitoring of UTC(k)’s using PPP and IGS real-time products
[3]: Assessment of Multiple GNSS Real-Time SSR Products from Different Analysis Centers