TB_RTK
January 3, 2019, 5:03pm
5
You wanna try the RTKlib 2.4.2 version, I think i posted somewhere here in the forum that clock or something similar has a bug in later versions which makes the RTKlib rund with Q0 solutions.
Do you mean presice point positioning (PPP) ? which is somewhat different from PPK.
I never got that accurate result as stated (sub desimeter) with PPP. It always seems of by 1-1,5m from the origin with IGN and using RTKlib 2.4.2, which is the only version that process right and gives you Q6. Not sure if its because of the missing L2 or what.
So i would focus on PPK that do works.
Also check out this thread about points and processing
Time stamp and/or events is used for adding coordinates …
Oh, and Clock products only works with RTK or processed work, PPP is no good.
opened 08:10AM - 06 Sep 14 UTC
Dear Tomoji,
I suspect that precise clocks are not use with SP3 IGS predicted ul… tra rapid orbits and clock.
On RTKNAVI I choose for stream 3 FTP / "cddis.gsfc.nasa.gov/gps/products/%W/igu%W%D_%hb.sp3.Z" / anonymous / none@world.com / offset -6h
Stream 1 is a stream NTRIP / www.euref-ip.net / 2101 / DENT0
Option "precise ephemeris" is set.
No fix can be obtained.
If I look at the debug trace 3, the problem seems to come from the absence of precise clock.
For having a fix, I need to add a stream 2 with broadcast ephemeris (RTCM3EPH) , but after looking at the debug trace precise ephemeris are used but clock are used from the broadcast stream.
