[time-nuts] PPP GPSDO v2 - ADEV ~3e-13, e-14 at ~2000 seconds
Ole Petter Ronningen
opronningen at gmail.com
Mon May 28 05:07:54 EDT 2018
Sorry, typo in the link to the data:
On Mon, May 28, 2018 at 10:46 AM Ole Petter Ronningen <opronningen at gmail.com>
> 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
> - 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 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  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
> Anyway, I thought it was a neat experiment. And theres *much* that still
> needs testing (which correction streams, 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.
> .tim-file (with all data) here: http://www.efos3
> : The TAIPPP pilot experiment (
> : Monitoring of UTC(k)’s using PPP and IGS real-time products (
> : Assessment of Multiple GNSS Real-Time SSR Products from Different
> Analysis Centers (http://www.mdpi.com/2220-9964/7/3/85/pdf)
More information about the time-nuts