Online calculation with extremely false positions

RTK position using REACH rtk modules as base and rover is terribly wrong. Online localistation results jump about 50 meters although rover’s status panel (in ReachViewApp) tells acceptable system states [single (70%), float (about 30%) and fix (0,5%)]. The base station was properly set up, diff_age is no issue.

The only flaws from my side I assume are:

  • ground plane too small at base station
  • missing ground plane at rover
  • no antenna parameters given with PPP so antenna high is not so exactly known


When I postprocess the files the rover has logged as they are:

  1. rover’s raw observations in ublox-format
  2. rtcm data from basestation

Then Offline windows based RTKNAVI is able to reproduce ecactly that track I was walking. RTKPLOT shows the track data jittered (in single mode) and smothed (in float mode) and there are NO JUMPS AT ALL in contrary to the results I see in the rovers *.llh file from the same epoches!


I looked in the settings of the rtk-parameters in ReachVewAApp but found no hint like wrong elipsoid or so. Also I could not reproduce such bad solutions in the offline rtklib processing data while iterating over many of that parameters I can influence.

Why I get such useless results from useful input-data?

I belive you need to eliminate obvious faults, such as no ground plane, use proper sized ground plane, set as close as you can coordinates and try again.

No that cannot fix that issue. As I said; measured data by the ublox receicer is fine because I can use them later in postproc without problems. Missing groundplane would influence that so this measurement data would deliver false output-values too…

… instead we found one of our two Reach-RTK modules as defective - just that module which shows that strange behaviour. We reflashed it completely and it 's still not willing to calculate reliable data … the companion works like anticipated …
Next question is how emlid will treat such RMA cases … our local dealer does not answer my mail …

I always think its is a good thing to eliminate obvious faults, but hey, thats me.
Anyways, with good PP results with RTKlib, it seems like Reach in fact works.
Sounds more like corrupt setting, or software. Would reflashet Reach with the latest version, provided grounding plate
and somewhat more accurate position on the base. And try again.
How to you record RTK? via bluetooth or RTKplot?

RTKpost and RTK is in my ears two sides of the same coin. I did google translate this, so i`m not sure this came out right :innocent:

Hi Jens,

Please share raw data and solution logs from Reach so that we can have a look at the issue. This is not something I have ever seen.