Cannot use Precise clocks with RTKpost

Let me know how it goes! Would be both weird and nice if it works for you!

Ok I remember that it worked for me and I still gained a few millimeters of accuracy.

Please have another stab at it and let me know. Would be a huge help.

No problem! I will reply ASAP.

1 Like

Let’s keep on topic here. You are most welcome to create a new thread. RTKget is very nice, and not that hard to make work (but it can be frustrating).


I decided to use the same example of post processing seen in link above
I used GNSS Solutions to download precise ephemeris and precise clock files from IGS.
I got almost the same result as seen in a screenshot.

can you try with the MGEX products ?

I think to avoid Q = 0 you have to use both files together, you can not use the file precise clock alone!

Also seen in the RTKLIB manual :slight_smile:

That’s my flow. Always using both.

inspired by your success, I also tried the IGS solution. That works, but takes away 5-7 sats (basically all suitable GAL & GLO sats), which is why I like using the MGEX product, then I can have all the sats used.
Missing out on those sats get more floats in the precise solution than the non-precise solution.

Good but I find a difficulty to download a files for 05/10/2019?!

You must have some older data-sets? :smiley:

Yes cause I am from old shool :smile:
Can you send me *.clk and *.sp3 files for 2019/10/05 please?

For which date ?


So this seems to a problem when using MGEX products only. When IGS product, it’s not a problem, however, it gives a significantly number of sats, as GAL and BEI now can’t be used.

Solved! Wrote the author of RTKlibDemo.
Turns out RTKlib has a bug where it doesn’t accept .SP3, but has no problem with .sp3.
Renamed my MGEX file, and now the world is awesome.


Rename .SP3 to sp3 ?

Yep… simple as that!

1 Like