Iphone is better than reach with RTK, or not?


my main goal is to map tracks in the forest. First try: iPhone 6, result is bad: around 10m error. So i searched and found reach RTK. It was clear that RTK in the forest is very hard and not the best choice. But my idea was: 600euros for an RTK solution must be better than something that is build into an IPhone.

So lets see what the result is!

Setup 1: iPhone, just go along the tracks in the forest, us the app maps 3d pro
Setup 2: reach base log to file, reach rover mounted on top of my car and log to file, post processing with RTKlib.

First observation is: very good performance in open field but bad in the forest:

This image shows a segment from my track. red: single, yellow is float, and green is fix. The doted grid is 20m wide!
One can see that huge jumping around. The yellow float point are also jumping a lot…

This image shows the iPhone track (red) and the reach RTK result (other circles). you can clearly see that the iPhone track is much better and the rtk point hop around for at least 10m.

I can not believe that the iPhone is so good in relation to the RTK solution!
My idea was that rtk is at least as good as the iPhone. The RTK solution gives me 5hz data.


  1. How can I do an averaging to get less point but with less hoping around. I think to switch from 5hz to 1hz is not the solution. I think this only does an sampling but not an averaging over some time/points.

  2. I know that RTK in the forest is hard. Are there setting that I can change to make it more robust. 1m or 2m accuracy would be great. 10 or 20m is too much error. Keep in mind I want to map a track, so to use static and wait for a minute at every point is not usable.

thank you and best regards

to prove that the rtk in general works i have an images with a larger part of the track.
On the top you can see a smooth perfekt track. this was outside the forest.
below right you can see the jumping of the point insight the forest.


Hello Franz,

In poor conditions gps in iphone could give better looking tracks. RTK relies on phase tracking, which requires better signal to noise ratio. In the forest iphone applies lots of smoothing on the data.

Did you enable dynamic filters when processing? Can you share your raw data log files?


Hi @igor.vereninov,

thank you for the option to process the data offline: I have send you a 7mbyte zip file and i have uploaded the file also here.

files for debuging.zip (6.7 MB)

ad dynamic filtering: this was not enables. I have tried with this option and the result is am little better. I estimate an error reduction von 15m to 10m. Also the points that have single status are much worse with this option. so i only can use the points with status float.

also when I look to the few points with the status fix then points jump around. Does this mean that there are multipath problems?

with best regards

Desr support team and @igor.vereninov

Any news to this?

Best regards

Franz, apart from being a code based solution which is more robust than a phase solution in the forest I suspect that the Iphone is using a combination of GPS and the internal IMU in a kalman filter to smooth the solution.

You should be able to configure the Reach to operate in DGPS mode (code only) and if you are still getting the jumps then you should look at the filter settings again.

1 Like

Here is what your files look like with smoothing applied to them. I tried to keep the same view as your pictures above:

the acceleration graph with smoothing:

the acceleration graph without smoothing:

the smoothed position file:
rov_201606181328_that_is_obs_of_rover_kinematic_nav_dynamics_smoothed_formatted.zip (323.4 KB)

I think heavier smoothing could be applied and also the point density could be reduced by quite a lot, say every 10 points merged into 1 would make this look much nicer.

Dear @bide,

thank you so much for the result!

Is the smoothing something you have implemented yourself or is it a setting in RTKlib (i do not find this) or is it an external program that I can also use?

the data looks much better, still there are positions where the track is wrong by 30m.

with best regards

No problem. On the errors, some of the positions are just bad, and those could probably be eliminated with a better algorithm that what I made. I just opened your .pos file in a spreadsheet and applied some math that made sense to me, and then substituted the results into your position file. This is what I did:

  • took a series of logarithmic numbers:
    0.3010299957 0.4771212547 0.6020599913 0.6989700043 0.7781512504 0.84509804 0.903089987 0.9542425094 1 0.9542425094 0.903089987 0.84509804 0.7781512504 0.6989700043 0.6020599913 0.4771212547 0.3010299957
    • in the above set, the number 1 represents a multiplication factor for the current position and the other numbers are also multiplication factors for the previous and next positions
  • in addition to that factor, the number of “Q” and the “Ratio” are mixed and multiplied as well:
    • a=1/Q makes a fix be 1 and float be 0.5 and single be 0.2
    • b= Ratio/30 (and if Ratio is greater than 30, then it is reduced to 30)
    • quality_ratio_mix = a0.5 + b0.5 (gives a maximum number of 1.0)
  • then the log_factor and the quality_ratio_factor are mixed and reduced in a way that the sum of all of the 17 factors = 1, and those individual factors applied to the group of positions that is centered on the current position.
  • the idea here is that the some previous and some future positions are mixed in to the current position such that the current position is given the most influence while the previous and next 8 fixes are given exponentially reduced amounts of influence, but if the quality of the particular position is poor, then the influence is reduced even further.

Sorry to anybody who knows about statistics, as you are probably facepalming at this, but hey, I gave it a shot. :wink: