Sorry, typo in the link to the data: http://www.efos3.com/downloads/GPSDO_brux_28.05.18.zip
On Mon, May 28, 2018 at 10:46 AM Ole Petter Ronningen <opronnin...@gmail.com> wrote: > 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) > > _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.