Difficulty with PPK using RTKpost; very poor precision

Greetings. I am a new user of the RS2. I’ve downloaded the version of RTK post listed on the emilid site:

I’ve tried to do something very very simple. I set up one RS2 on a tripod to use as a base station. I then took a second RS2 and used it as a rover to log a total of two locations and I’ve logged each location twice, a few minutes apart. I occupied one location for 2 minutes each time and the other for 3 minutes. I then did PPK both using my RS2 base station and also using a CORS station that is just a few kilometers away.

After doing the PPK using RTKpost, I then calculate the mean position for each location using the CSV file from the RS2 (that indicates the starting and stopping time involved in logging each location) along with the *.pos file from the RS2 (that logs EVERY location from when project was started to when it ends). Obviously, the *.pos file is a very big file and, as many on the forum have noted, you need to snip out the points for each location and calculate a mean position for each location. I’ve done this using the Point Extractor program that has been discussed on the forum: : PPK point extractor software

I wanted to check the precision of the RS2 coordinates by comparing the 2 sets of coordinates for my two locations. The short answer is that the agreement is not at all good. When looking at the uncorrected data (no PPK) the coordinates are off by 0.2-0.3 m (lat/long coordinates differ in the 6th decimal place). This is not too bad for uncorrected data. Pretty good actually. But after PPK using the other RS2 as a base, the coordinates are off by 20-30 meters (lat/long coordinates differ in the 4th decimal place).

I get similar results when I use data from a nearby CORS station as the base.

This is just awful.

Any suggestion on what I might be doing wrong?

I add the 18 seconds for the start time and end time? if you are going to do ppk take a reading of at least 10 minutes and then you can measure the points you want to observe. The rms in single is high unlike rtk. it must be taken into account that the coordinates of the base are the same for the postprocess for both situations

Hi David,

Could you please clarify how you specified the base position in RTKPost Options before PPK? Did you enter the base coordinates in WGS84?

1 Like

I was not aware that I need to specify the location of the base station when doing ppk. Can you explain how/where I would do this? There is no mention of a need to do this in the PPK workflow described in the tutorials provided on the Emlid site for the RS2.


I did use the correction for GPS time vs UTM time.

And, as I indicated above, I’ve occupied each location for either 2 minutes (resulting in about 600 logged positions) or 3 minutes (resulting in about 900 logged positions). The PPK point extractor routine, then calculates a mean position from this large number of data points.

A bit down on this page

So just to give you an example since you are using CORS.
If you use the downloaded file from CORS and use this as base, i would set base to RINEX HEADER (be sure the coordinates in the header correspond with the actual location of the base) and use logged file from YOUR base in the rover section and PPK. Really simplified would this give you coordinates for YOUR BASE. With your new base coordinates and base log, use resulting LAT/LONG from the previous PPK in the base location setting.

Edit: You could fill in LAT/LONG manually for CORS station, but these files usually comes with the position described in the RINEX HEADER-


I’ve already been using this setting. And I’ve checked the coordinates in the RINEX HEADER and they are correct. I had to convert the header coordinates from Earth-centered-earth-fixed to lat/long but they are correct so this isn’t the problem.

Would you mind sharing the raw base, rover and cors file?

Sure! Thanks for taking a look. All of the files are available here:


At this site, the rover folder contains zipped versions of the raw rinex file as well as the CSV file for the RS2 that I used as the rover. The base folder contains the same zip files for the RS2 I used as the base as well as a beli_cors folder that contains a zip file with all the files for the nearby CORS station.

I’d be grateful for any suggestions that you might have.


Thank you.

Do you have coordinates of these points?

No unfortunately, I don’t have “true” coordinates for these points.

OK, i am not sure how you were benchmarking this. I have reread the first post but its still not clear how you QC this. (QC= quality control). Could you elaborate?

Edit: Hang on, i think i see what you are trying to do…

From what i can see, if you average a position based on time on point two, you would average a position when you are on the move from point 1 to 2. And i guess this is what throws of your compareable position. (Its not the difference between utc and gpst time)
Either use PPK straight as it is, then you`ll see how those points line up or find out why the timeframe doesnt line up with the PPK track. I dont think this is an reciver issue.

Hope this helps.

I think that I did follow the PPK procedure. As I understand the RS2, it starts logging data as soon as you launch a project and continues to log data (every 0.2 seconds) until you close the project. This gives you a continuous set of positions for your entire time in the field, including locations as you walk between points as well as a large number of locations while occupying a point of interest. The CSV file that you get provides you with the start and stop time for each point.

Running RTKpost, along with data from a base station, then provides a .pos file with corrected positions for the entire project, including locations logged while walking around as well as locations logged while occupying a point of interest. Armed with this, it is then possible to refer to the CSV file for the start/stop time for each point, then go into the *.pos file and manually snip out the sequence of locations for each point, paste this into an excel file and calculate the mean XYZ coordinate for each point. This is very tedious and hopefully Emlid will automate this process VERY SOON in a new version of ReachView. As an alternative, the PPK Point Extractor software will do this for you. I’ve done it both ways (the tedious manual way and using the PPK Point extractor software) and I get pretty much the same result. Not exactly the same but pretty close. But not clear exactly how PPK does the calculation (not sure if any of the quality data is used to screen the locations and maybe just use a subset).

As I tried to describe in my original post, after doing this, I compared the coordinates that I logged for two points. Each point logged twice and compared. This should give me a sense of the precision (repeatability) of the location data but not of the absolute accuracy. Each pair of coordinates should match but they don’t. They differ by ~20 m.

Have you tried doing this with my data and did you get the same poor agreement?

Thanks very much for your time.


I must be doing something wrong. I’d be

Oh and just to be clear, I did not use any of the locations as I was moving between points when I did the averaging.


Hi, did some screenshot to show that points measured line up.
The first screenshot shows you the time fram point nr 2 in the .CSV file has the logged time, and if you average a position within this time frame, you see the track starts at point 1 and moving towards point to.
These other pictures show you the distance between the two recorded points on the first area and second area.
And as you can see, they differ no more then few cm. That could be the pole, it seems to wobble a bit
The issue here is, why the recorded .CSV file has a differnt time frame? It seems out of sync.

Here is a better picture, describing it. Its an example of CSV point 2

1 Like

Just as a procedural question, couldn’t all the hassle of isolating each point have been completely avoided by simply enabling logging when positioned over the points, then disabling it after the required time? There would then have been a file for each observation that could have been averaged separately.

Am I missing something that would prevent this from working?

This will work, however, you need to log a little bit longer than normal to ensure you can get a fix in Post-Processing. Not really an issue if you log more 1-2 minutes with the RS2, but on the RS+/RS L1-only, this shouldn’t be below 15 min, which makes it cumbersome to work with.