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.