Update3 on 2014-02-20: by popular demand, screenshots of options (at least roughly correct...) used in RTKPOST to get the results shown:
Update2: gLAB data now at 30s intervals, and an error-plot that compares CSRS to gLAB clock offset.
Update: using the latest RTKLib from github on Ubuntu, I now got this, with the lat/lon/height results between CSRS-PPP and RTKLib in better agreement. There is still a 4ns offset between the clock results - which curiously is about 0.5*ZTD, but this may be just a coincidence.
GPS based Precise Point Positioning is used worldwide to compare clocks against each other and maintain UTC.
The idea is to connect your clock to a dual-frequency GPS receiver that collects data (in RINEX format). The RINEX data is then post-processed by using satellite orbit and clock information available (with delay) from the IGS. While normal GPS has a precision of maybe 1-10 meters (~10 ns clock offset/noise), PPP can achieve <1 cm precision (<1 ns clock offset).
I tested a few of the PPP algorithms I found by running them on the same datafile (KAJA2900.13O) and got the results shown below.
If anyone wants to try this at home you will need from the IGS (I used RTKGet, a tool that comes with RTKLib to download these): clock data CLK file igs17624.clk, orbit data SP3 file igs17624.sp3, NAV file brdc2900.13n, antenna correction ANTEX file igs08.atx, earth rotation parameters ERP file igs17627.erp, and possibly also an ocean tide loading BLQ file available from Onsala Space Observatory.
The CSRS-PPP and ESA-gLAB clock offset solutions agree reasonably well, but the clock offset of the RTKLib/JPL-APPS solutions differ by 3-4 nanoseconds - which is a lot if we are using this for monitoring/steering an atomic clock. I'm not sure why this happens - if anyone knows how to reproduce the CSRS-PPP results with RTKLib please let me know!
- CSRS-PPP is an online web-based tool that returns results by e-mail. AFAIK the same code is used by the BIPM to maintain UTC.
- JPL-APPS is a similar web-service by NASA.
- ESA gLAB and RTKLib are open-source software packages for GPS/GNSS processing.
See also: A Comparison of Free GPS Online Post-Processing Services
CAN you please tell me hoe can I use RTKLIB post processing using IGS corrections.Please help me
Hello,
Do you have the reference coordinates from the site?
Thank you
Hi, the antenna location for the KAJA RINEX file is roughly this:
https://goo.gl/maps/CgkNJBPKwF42
I don't have any more accurate coordinates for the site.
There is much more RINEX data for that receiver on our archiving site at: ftp://monitor.mikes.fi/GNSS/MI03/RINEX/
Hi,I want to do some research about the receiver clock offset with rtklib. But in rtkplot, it doesn't provide the figure about clock offset. Can you tell me how can you get the results about clock offset with rtklib? Thx!
Hi Tachien,
I have looked at my old results from 2013 when I made this blog post. It looks like I was using the program "rnx2rtkp" like this:
rnx2rtkp -x 3 -y 2 -k $OPT $INPUT $NAV $SP3 $CLK $ERP $DCB
this should produce as output a ".pos" file that for me has the first line:
% program : RTKPOST ver.2.4.2 b11
if you look at the data-columns of this file, the first column is a GPST time-stamp which tells you the receiver clock offset relative to GPST (or perhaps IGST for PPP-processing). For me it looks like:
2013/10/16 23:59:59.999999755514
from this you can calculate that the receiver clock offset is about -250 ns. It might not be possible to plot with rtkplot, you would need to read the text-file yourself e.g. with a python program and plot e.g. with matplotlib.
This is a bit different from ESA gLAB or CSRS-PPP where the time-stamps are rounded to exact seconds, and there is a separate column in the output file for the receiver clock offset
I have started on some utilities for PPP time-transfer calcuations over here:
https://github.com/aewallin/ppp-tools
you are very welcome to contribute to these tools if you find them useful.
hope this helps!
Anders
Thx!
Hi！ Ander!
I checked the manual of RTKLIB 2.4.2.It says that the time column in .pos is the epoch time of the solution indicating the true receiver signal reception time,not the time by receiver clock offset(page 101 in manual).Maybe it can explain the 4ns offset you mentioned.And the receiver clock-bias is located in the file of solution status file,which is called xxxx.pos.stat. Glad to communicate with you for academic!
Hi,Anders! It's me again.I want to do some research about time transfer with rtklib. But I find that the accuracy of clock offset by rtklib is worse than gLAB and other softwares. I find that the clock offset by rtklib is in the time scales of GPS,not in IGST. Maybe this is the reason about the 4ns offset.Do you agree with it?
Hi Anders,
In RTKPOST you need to set Ionosphere Correction to “Iono‐Free LC” for dual frequency data as those you used. This will offset the ionospheric delay across L1 and L2 data. However since in your settings you have instead used “OFF”, your data are biased by ionospheric delays.
Regards,
Al