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.
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
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?
Yes cause I am from old shool
Can you send me *.clk and *.sp3 files for 2019/10/05 please?
For which date ?
2019/10/05
ftp://cddis.gsfc.nasa.gov/pub/gps/products/mgex/2073/COD0MGXFIN_20192780000_01D_05M_ORB.SP3.gz
ftp://cddis.gsfc.nasa.gov/pub/gps/products/mgex/2073/COD0MGXFIN_20192780000_01D_30S_CLK.CLK.gz
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!