PPK + GCP Workflow to Achieve Absolute Position

I thought I would share a workflow we’ve figured out that we think is a good measure to figure out absolute position. If we have an error, hopefully it can be corrected and it can be a useful guide for those in a similar position to us.

We are working in a situation where we have no known points, CORS is frequently not possible, and we cannot use an M+/M2 because we have a DJI drone.

We are using two RS2s (rover, base), a DJI drone (thus no M2), and ground control points (GCPs).

Here is our process:

  1. Place the base station on a high point. Turn on the base and let it average it’s position. Turn on logging.

  2. Place six GCPs around the property, roughly around the perimeter.

  3. Fly the drone survey.

  4. Turn on the rover. Turn on logging. Get FIX.

  5. Start a Reachview survey either via browser or Reachview3 connection. Drive to the first GCP, collect the point and let it collect data for 20 minutes. Drive to the second GCP, collect data for one minute. Drive to the 3rd, collect for one minute etc.

  6. Go back to camp. Download the logs from the base and the rover. Download the GCP survey as a .csv.

  7. Because our base position was not absolute, we need to have it corrected via a reference station. In our case, being in Canada, we used NRTCan PPP.

We uploaded our base station RINEX-3_03.zip file as in the picture and within half-an-hour received the corrected file back. In our case, we received a .pos file. We now have the absolute position of the base.


  1. Open RTKLib, specifically RTKConv.

We downloaded our rover log in RINEX 3.03 but it only produces files in the .21B, .21O and .21P format. So import the rover .ubx file into RTKConv, and click “convert”. If you download RTKLib from Emlid, it seems all the settings are already correct and don’t require adjustment.

  1. Open RTKPost. Again, as it was downloaded from Emlid all the settings appear correct without adjustment. Enter the Rinex rover .obs file and the Rinex base .obs.

In our case, we received a .pos (and .csv) from NRTCan for the base correction so I used the .pos file in place of the .obs. This may have been an error - but as far as I can tell RTKLib processed the data fine.

Click execute. We now have the corrected rover position in a .pos file.

  1. Open jurijs.jeshkins PPK Point Extractor Software. Import the new rover.pos file and the GCP survey .csv file.

Process each point (or batch process). Save as a corrected .csv

At this point, we should have our corrected GCP points which we can import back into our UAV software to correct the flight.


Always survey before you fly. This way, if you bump the GCP while measuring, there isn’t a difference between the measured GCP and the photographed GCP.
If you for some reason need to measure after the flight, then make sure that GCP’s are absolutely fixed to the ground with screws or nails, especially the center.

The best thing to do is to measure before flight (when setting them up) and then again after the flight, and then run a Network Adjustment on them (using a capable processor like EzSurv, or simply by averaging the 2 measurements) . Then you also account for changing satellite geometry etc, setup errors etc.

Why collect for 20 mins on the first and then 1 minute on the other?

Remember the height accuracy of an Ultra Rapid NRCAN PPP solution is around 20 cm. The Rapid is around 10 and Final is around 3-5, if my memory serves me correctly. So, if you need absolute accuracy, you have to wait the 16 or so days for the final product.
You dont have a nearby CORS station instead?

While this software is awesome, also try the Emlid Studio Beta, it provides a more integrated Work Flow.

As a final note, remember to transform the ITRF14 from NRCAN PPP to the appropriate system, otherwise your absolute coordinates will not be exact on the ground.


For someone in Canada, PPP can already export in the local best fit orthometric datum.

I guess you mean NAD83 here?
I wrote what I did as the ITRF14 was selected in the screenshot

1 Like

Oh, I see, hadn’t noticed the horizontal datum was set to ITRF. I thought you meant this as a general rule, not to correct OP.

1 Like

Great point about surveying before flying.

In another thread someone else had mentioned doing this. It’s not necessary?

This is our first time using NRCAN and it gave us no options for a rapid (or non-rapid) solution. Do you know if it automatically sends a second corrected file later on? Specifically in this case, we’re fine with 20cm height accuracy.

Re: CORS we frequently work in areas with no cell coverage. Given both this and that cm-accurate surveys are not something we always need, I’ve assumed the cost of CORS often won’t be worth it.

Ah, I made a mistake in selecting ITRF. And I’ll re-run this with Emlid studio and update.

It’s automatic. The system will always return the best available solution at the time of query. Same day will be ultra-rapid. Rapid is next day and Final is 14 days later.


Hi @intenna,

I generally agree with Christian. I just wanted to add a few comments.

Indeed, we’ve released a free beta version of Emlid Studio - our desktop application for PPK. The Beta means that this version is still in the development phase. The whole post-processing workflow is described in this guide from our docs. It’d be great if you could test it out and share your results with us.

You do not need to convert your RINEX files to .obs format. 21B, 21O, and 21P formats are standard and should be successfully processed in any post-processing software, including our RTKlib or Emlid Studio.

It’s not necessary to stand on the point for 20 minutes. If the receiver gets the fix, several minutes are usually enough.


I ran into an error where it won’t process. I’m trying to get my GCP locations so I’m doing the Stop and Go option. The one issue might be that I exported my CSV from the browser Reachview (not Reachview 3) but as far as I can tell the CSV is the same format.

Hi Brian,

Yes, you’re right. At the moment, the Stop and Go option in Emlid Studio works with the CSV project from Reach View 3 only. This is because the CSV file from Reach Panel (web-based app) does not contain all the fields you need for processing.

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