20190725 Ublox Z9P PPS and RTCMv3 corrections¶
For unrelated experiments, I have “borrowed a cup of RTCMv3” corrections from GPSnet.dk - one of the “real” RTK networks in Denmark.
On time-nuts the consensus is that RTK corrections should not matter for a position-locked receivers PPS output, and since I had the chance I decided to sanity check this consensus.
The setup is as follows:
RTCMv3 corrections from GPSnet.dk to:
UBlox Z9P receiver, (Note: ‘P’, not ‘T’) GPS+GLONASS L1+L2
PPS output feeds START input on:
HP5370C (ie: a B with JKS’ improved CPU board)
HP5065A feeds STOP input with 5MHz.
The raw data looks like this:

After unfolding the 5MHz period and removing the HP5065’s frequency offset (-5.3e-11) it looks like this:

The RTCMv3 corrections were on from 5000 to 10000 and again from 35000 seconds onward.
I have asked UBlox support if the 20 ns shift is intentional or a bug. Will update here if I get a reply.
The Modified Allan Deviation indicates a small but not uninteresting improvement:
