Evaluating relative repeatable precision of the Reach RS+

After some talks here on the forum, I decided to see how the relative precision of the Reach RS+ is.

I started by laying out and securing 40x30 cm GCP’s, and securing these with 2 spikes each to eliminate the risk of disturbing the point during repeated measurements.

Base setup on previously measured point on a tripod and tribrach. Rover on a pole, and stabilized with bipod. Measuring base and rover heights with a laser distance meter.

RTK-settings for Rover
SNR mask 35
Elev mask 15 deg
GPS Fix-and-Hold, Glonass AR on
5 hz

All set up, I set out to do 3 measurements at each GCP:

  • 3 sec obs time
  • 30 sec obs time
  • 120 sec obs time

For each observation, the rover is removed from the GCP and walked in in a ~3 m radius circle around the GCP. Then the Rover is re-positioned and re-levelled on the GCP.

This is how it looks from above (though the results presented are from RTK, not PPK):

So, results.
I will try presents these in 2 ways. Largest difference from shapefile in QGIS, and then the RMS Error from Photoscan processing

GCP 17: 3-4 mm difference
GCP 18: 1-5 mm difference
GCP 19: 0-2 mm difference
GCP 20: 2 mm difference
GCP 21: 3-4 mm difference

And then, Photoscan:
3s obs time, 3D RMS: 0.003949 m

30 s obs time, 3D RMS: 0.003787 m

120 s obs time, 3D RMS: 0.004064 m

Weather was

  • few scattered clouds
  • 4.5 deg C
  • 1.5-2 m/s wind

Conclusion, well, I will leave that to people more experienced than me, but I am certainly impressed, given that some the errors could also be mechanical.



Very nice experiment! I see, that your results are very close to my results. I will try also to PPK mine in order to see, whether they are the same, or not. Are you going to PPK yours?

I might, but it’s a bit of work using RTKlib, so if anyone got EZsurv and can load the raw-files and the surveyfile, then feel free!

Christian, I am a little late to the party :smile:

I PP the base but the CSV caused errors.

Cause of error in EZsurv was “-” in site name.


To my knowledge EZsurv should have direct support for the survey files made by the Emlid units for their stop-and-go flow ?
And thanks for trying !

How does Stop and Go differ from doing normal surveys in the ReachView app? In the app, after I create/name a Survey, I then manually add each point in the survey section (clicking SAVE and GO when done with each point.

They don’t. Stop-and-go is more the name for one long log-file, where you have time-marks for start and stop for each “stop”.

I emailed Stephanie at EZsurv to see if she could help. I survey each point in the ReachView app which works very nicely in EZsurv. I guess she will let us know if (and how) to handle Stop and Go.

I did the same, so should be just the same :smiley: Have you tried in the 2.16 firmware?

Yes. I did one this past Saturday. I don’t remember any significant changes, but I have slept since then :smile:

Stop & Go is mainly a term for kinematic file with sites (points) in it.
No matter how long your sites are.
A site could last a second, few seconds, or several minutes.

With ReachView, I believe you can record points with a certain duration.
The idea of recording few seconds is to average the centering error. For example if the antenna is on a rover rod, and if it is windy, it may be difficult to keep the rod centered on the point. In such case, averaging few readings will bring a better position for the point.

1 Like

Disregard my earlier message. Our files formats are identical :open_mouth: I did get an error but not sure why. Just a pure brain fart on the file format comparisons. Looked at a different file. Sorry for the confusion!!!

And I did a survey on Saturday with 2.16.1. All seemed to work smooth.

1 Like

Christian, what was the height of the Reach RS base station?

I’ll have to get back to my notes on that one. But around 1.8 meters, as far as I remember

Christian, I have attached the info from EZsurv. I used one CORS station (BUDP). The PPK was very close to your RTK and the difference will come down to what your RTK showed the base to be vs what PPK has the base to be. If I adjusted this to match your base coordinates then I would expect a near exact match.
The difference between the 3 second observation and the 120 second observation was 1-2 mm so almost non existent. I only checked for point 17 but I would expect the same for all of them.
I processed your base at 1.8 meters. I actually do a 1 point survey at the base so I have a record of the height which is the only way I seem to keep up with it :open_mouth:
You are providing some great info! Keep it up.Chrsitian Processed Survey.zip (210.1 KB)

Thank you for doing the processing! I’ll come back with the exact base height tonight.

I think I’ll do one more test, where I break the fix in between the measurements (and then only do 3s vs 120s). All when I get some more time :stuck_out_tongue:

For base height, try 1.6832 m, (tripod+tribrach+antenna)

I will rerun that now and have it to you shortly.

Thanks! I hope it is the right height, but I guess so :smiley:
Btw, the basecoordinates I use are:
55.311524072N 11.473211019E, elipsoid height 72.4053 m
Derived from a 5 hour log using BUDP 2 weeks earlier, using MGEX precise clocks.

This is what I came up with. See attached. When I used your fixed Lat/Lon coordinates, the difference was almost nothing. When I processed your base with the CORS, I had an elipsoid height of 70.141. I was using Geoid Model NLGEO2004. When I entered the EH of 72.405 the error was increased by about 2 meters on the height.

The 1.683 is the identical height of the rover so I don’t think that was it for the base. After losing mine a couple of times, that is why I now enter a single survey point on the base so I have it recorded :slight_smile:
Christian Survey 2.zip (115.9 KB)