agreement between PPP algorithms? about rtklib HOT 5 OPEN

Such constant bias for receiver clocks is often derived from satellite-side DCBs. Please check results after applying P1-C1 DCB correction.

from rtklib.

Thanks, I have tried inputting DCB files to RTKPost, both the ones in the /data folder and ones I downloaded with RTKGet, but this does not remove the 4 ns offset between the RTKPost solution and the gLAB/CSRS solutions.

I would be interested in a test-case where one can show that the three programs (RTKLib/gLAB/CSRS) produce similar output. Is there a PPP-Static software test included in the RTKLib distribution?

from rtklib.

Hi Aewallin,
I wonder you fix the issue or not, or find the reasons for the difference. I think besides correcting the satellite DCB for P1-C1, actually the receiver DCB P1-C1 also exist, which will be absorbed in the receiver clock parameter. To keep the consistence, I suggest using P1 instead. C1 has the priority in RTKLIB.
Regards,

from rtklib.

Hi, I have not done further comparisons of PPP algorithms since my original post (above).
Since that test I have also learned that PPP is possible with the free GPS toolkit (http://www.gpstk.org), so there are now three open-source/free PPP implementations that I know about: rtklib, ESA gLAB, and GPStk.
I am still interested in PPP for time-transfer, in particular there is new work on integer-PPP (iPPP), but I don't know if an open-source/free iPPP algorithm exists.

from rtklib.

Hello Aewallin,
I am not working on the timing. I have little knowledge on timing. As far as I know, RTKLIB have a PPP-AR mode. Probably, you can try it.
regards,

from rtklib.