[time-nuts] PPP GPSDO v2 - ADEV ~3e-13, e-14 at ~2000 seconds

[Ole Petter Ronningen]

Hi, All

Another somewhat long winded post, my apologies. First off, thank you Bob
for encouragement and good advice!

A couple of weeks ago I posted some results from a GPSDO based on a
geodetic GPS dual frequency receiver and real time PPP, hitting e-14 at
around 6-7.000 seconds with an adev *ceiling* of 5e-13.

This scheme discplines the local oscillator to 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.

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.

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 a 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.

Given that TAI is (partially) calculated 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. I thought that would be rather neat.

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 I 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 in 3000 seconds or so, but I am too
impatient to wait for long enough. I then decided I should try to
discipline the BVA to a different maser - 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. This morning,
Timelab had some nice traces, attached.

The screenshot shows two traces: Purple, all data. Teal, 1 hour starting at
approx 00:00 UTC deleted.

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. I need to run a zero baseline common clock
comparison. In particular there is an unsightly bump starting at precisely
00:00 UTC - I have not chased down the cause of this, but I suspect it can
be managed/compensated for.

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 data, that I dont
think will make it into RTKLib (at least I am not competent to put it
there..)

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, PI-tuning, optimal sampleinterval, etc
etc), and of course much more data to collect.

Ole

.tim-file (with all data) here: http://www.efos3
,com/downloads/GPSDO_brux_28.05.18.zip

[1]: The TAIPPP pilot experiment (
https://www.researchgate.net/publication/224564551_The_TAIPPP_pilot_experiment
)
[2]: Monitoring of UTC(k)’s using PPP and IGS real-time products (
http://sci-hub.tw/10.1007/s10291-014-0377-5)
[3]: Assessment of Multiple GNSS Real-Time SSR Products from Different
Analysis Centers (http://www.mdpi.com/2220-9964/7/3/85/pdf)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dd brux.PNG
Type: image/png
Size: 20804 bytes
Desc: not available
URL: <http://www.febo.com/pipermail/time-nuts/attachments/20180528/c0a29a36/attachment.png>