Strange position shift while maintaining fix status

Hi there!

I’m testing my new REACH RS updated to ReachView version v2.10.0 in the field. I’m getting corrections from a public NTRIP network over RTCM 3.1. Everything connects well and i obtain FIX status rather easily. It’s even seemingly very robust, maintaining itself in a small town squares etc.

I’m aware of the limitations of Reach in comparison to professional grade equipment but i’m worried about one particular behavior and would like to understand it’s reasons and implications.

I have compared my REACH RS measurments with a highly precise ortophoto made by professional surveyors and aligned to permanent state geodesic points. Starting of from a high place with an open horrizon things get going pretty well.

there is only a small shift which i attribute to my hand shaking as i was fiddling with settings.

But going down into town i start to see a strange shift to the measurments going from 1,10 m southwestward to ~1,20 m southeastward, depending on the location even though fix status is maintained. See this picture:

Green dots are FIX orange dots are FLOAT. The objects measured are a small manhole and a permanent geodesic point marked in blue. Satelite count and S/N ratio were fine all the time and pretty low RMS is maintained for all the points:

I have repeated these observations on several locations: open horizon - everything ok <> some obstacles position shift, even while maintaining FIX.

Working with professional equipment i have learned to trust FIX status and the estimated accuracies. With REACH i have following questions:

  1. Is there a straightforward explanation for this? Bounced signals maybe?
  2. How to estimate situations when i can or cannot trust the FIX status and RMS estimated accuracy?
  3. Any good practices or settings with regards to this scenario with obstacles? Should i fiddle with elevation masks? Experiment with turning constellations on and off?

Many thanks,


Sound like a multipath issue. Just a hunch. You are working close to a builing, yes?
Could you please share system report or setting used during this survey?


Thank you for the report. This is definitely not a normal outcome, given your setup and a Fixed solution. Would you please share the system report and your logs with us? This might help shed some light on the issue.


Don’t forget about scale factor when your working on a geodetic coordinate system.

Scale Factor=Grid Distance/Measured Distance (at MSL)

If your working from an ortho image it will have a grid coordinate system.

To answer each point:

TB_RTK: I also suspect multipath - measurments were made in a small medieval town square and there are plenty of buildings. It’s just that from the systems i have used previously i never got 1.2 m of deviation while claiming fix solution and 0.03 RMS. With that, how can i be sure if i’m getting valid data in the field?

Peter: transformation into Croatian national grid is done in qgis with official parameters, scale included, so it’s definitely not that.

Egor: All logs from that day and a current system report are included. For the record, GLONASS was also turned on at the time - i have turned it off since.

Many thanks,

Logs, system (7.3 MB)

system report.log (2.3 KB)


Both same mask angle of 15 degree.

And last picture i have added a continuous mode at 30 degree mask angle.
Green=continuous mode with 30degree mask

From what i could see of the system log, base support gps/glonass, but only gps was used on your rover.
Also fix&hold with 15 degree mask angle was used.

I would guess contiuous mode with higher mask angle and possibly glonass activated would get you closer to true position.
If you PPK this in RTKpost, what do you get then?
or if you share true coordinates of surveyed object, we could throubleshot from here

BTW. All solutions are shown as one and the same color (fix/float/single)


I am a bit confused by your graphs. Shouldn’t the 30 degree mask have improved the results?

With higher mask comes worse satellite geomtri= less accuracy
But for all we now, 30 degree mask is the most accurate one of those tracks. I havent studied the log

By worse satellite geometry I guess you mean you are using fewer satellites, don’t you? I don’t know why you say that it is the most accurate one. It looks more jumpy to me, at least.

Usually it gets fewer satellites, but by bad geometry i mean satellites used are the ones chunked in a smaler area above you. To get higher accuracy its important to have them spread over the skyview and with lower angle.
@bide did have some awesome illustration somewhere in this forum.

By most accurate, i mean most likely to be the most accurate of the them 3 logs i posted above. And if fix&hold is used in juction with low mask angle, it might have you running around with bad fix much longer then with continuous. Its my theory anyways

1 Like

Found it.

1 Like

That is a great post. It made a couple of thing much clearer for me.

which RTCM messages did you use in correction input? Can you share this logs too?

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.