Post Processing Base + Rover to Reference Station

I’ve been looking at the Emlid tutorials and the RTK Lib documentation, but I’m still unclear on an important issue before I pull the trigger and purchase. Like many, I’m using the Emlid to place UAV GCPs.

My use case for the Emlid is surveying @ locations where I don’t have a fixed/known control point and don’t have cell service. I’d want to setup the base station and collect data for a few hours over an unknown position and then go out to setup GCPs with the rover using short observations. I’m assuming the radios on the Emlid may not be able to communicate to one another across 10s to hundreds of acres, so I’m assuming I’ll need to rely on PPK solutions for my rover.

It seems straight forward to correct my PPK rover observations to my Base Station observation to acquire a high-accuracy relative position relative to my base. My question is this.

Is it possible to achieve high-accuracy absolute coordinates for my PPK rover and base station coordinates using a reference station when I survey in this manner?

A couple of followup questions also.

  1. With this type of survey, how long should my rover observations be?

  2. What is the conceptual process for the post-processing workflow in this case? Is the rover data corrected to the base station to achieve an accurate ‘relative’ coordinate to the base, and then simply shifted in the XYZ based upon the delta between the field-estimated coordinate and the post-processed coordinate of the base? Or does the software post-process the rover based observations considering both the reference and base station observation datasets?

Please point me to some resources that I may have missed. Thanks.

1 Like

Ah, the age-old question of absolute accuracy!

Let us assume these things about your project:

  • no known points
  • no communication services
  • requires best absolute accuracy
  • data from a CORS will be downloadable afterward or a PPP service will be used afterward

You will be performing PPS for your GCPs and PPK for your UAV flight. So it should go like this:

  • Reach RS base set to save raw log, use “average single” for it’s coordinate, and output RTCM3 via LoRa.
  • Set up GCPs. Collect raw log for each GCP. Use LoRa to input RTCM3 if there is receptions.
    • Watch the status change to fix and then stay for some length of time (say 5 min).
    • If no LoRa reception, then stay for 20 minutes or at least a minimum of 5 minutes.
    • Turn off the raw log before moving to the next GCP and repeat for each GCP.
  • Perform the flight with Reach set up to save the raw log.
  • Remove the GCPs and collect another raw log for each one. If they are not going to be removed, then go collect another raw log for each GCP anyway.

Back at the office:

  • If you have CORS data, then do a coordinate transformation of their base coordinate from the CORS CRS to WGS84.
  • Post process your base log (as a rover) against your downloaded CORS base station data, otherwise submit your base log to a PPP service to get your new ‘accurate’ base coordinate.
  • If you used PPP, then do a coordinate transformation of your new base coordinate from the PPP CRS to WGS84.
  • Now with your ‘accurate’ WGS84 base coordinate, perform the PPS for your GCPs and PPK for your UAV flight.
  • Results will be WGS84, and those can be transformed to the CRS of your choice.

Thanks! That’s what I needed.

Hey bide,
This is exactly what I’m trying to do. You may have seen my post on the topic of “How to post process…”. Do you have any advice or info for folks who know how to collect the data but have no clue how to post process using the RTKLIB utilities. Your post is the absolute perfect course outline. Now if we can find someone to teach it :slight_smile:

Myself, I just learned what to do by reading lots and stumbling around with Reach and failing lots. One really doesn’t have to ask a lot of questions because the answers are all out there. You just need a few hints along the way. It seems like when you finally understand and recognize all the ways to fail, then the path to success presents itself clearly.

Here’s a few tidbits that are important for newbies rant of explanation for the uninitiated:

First off, the world is flat when it comes to drawings and plans and surveys and grid systems (like UTM). Now let's immediately throw that idea out the window:

The world is round when it comes to working with GPS. I mean that’s usually the case, and it is currently the case with our Reach devices, but instead of the world being round, it is actually oblate spheroid (a ball that is squished on the top and bottom and bulged out at the sides). They call this squished ball “the WGS84 ellipsoid”. The surface of this ellipsoid is defined to be at sea level all around the world. I mean, it is is a very, very simple model, so it is not at all perfect; it is just as “close” to sea level as they could get. In other words, it is a theoretical model of sea level and not “real” sea level.

Anyhow, there are two words there: sea and level. If you are on the surface of the sea and you project a line to some other spot on the sea, then your line is level. This is because every point on the surface of the ocean is of equal gravity (in a simplistic sense). Gravity levels the sea, and gravity determines plumb (straight up and down), and level is perpendicular to plumb.

Also, consider that when working over small distances, the earth seems flat, and the WGS84 ellipsoid also seems flat, but when you start looking at the bigger picture, then you realize you are on a ball and you see that a straight line across the ground is drawn as a curved line on a flat map, and parallel lines are maybe not so parallel, and so on and so on.

I should talk about datum, but I’ll skip it for now.

Then you get under the hood of the machine that drives our Reach devices and find out that our position is calculated in X,Y,Z coordinates which are relative to the center of the earth. In this coordinate system, there is no surface of the earth, there is only the center and you can go some distance from the center in any or all three directions. Not only is there no earth’s surface in this coordinate system, but there is no sea level, no plumb, and no level.

So, fundamental lesson #1 is that when you need to transform coordinates from one system to another, it is not just a simple case of multiplying or adding. You need to apply a complicated transformation matrix. Thankfully there is software out there that makes this quick and painless for us. We just have to recognize when we should be using it.

To make things even more complicated, the center of the earth is not a constant, and the earth’s crust is always shifting, along with movements from earthquakes and such. Everything is in flux.

In our minds, we think that acquiring survey-grade RTK hardware will instantly give us absolute accuracy in the world. What it really does is give precise measurement from one place to another. And remember, that measurement is only valid for that particular moment in time. Think, if you were measuring 10km across a fault line with 2cm precise equipment, and then you come back in 5 years and you find yourself 15cm off the mark; how do you allow for that in your work? It doesn’t have to be a fault line, there could be an earthquake that shifts things around, or you could be on soft sloping ground that flows ever so slowly.

And then there is the past. We know that people have been measuring the earth since long before we launched satellites. Their precision was not so good in the beginning, but when they declared one place to be 60N, 90W, and another place to be 61N 91W, then who are you to argue against it when your measurements don’t match theirs?

This is where accuracy comes up. Are you trying to gain confidence in your measurements in comparison to someone’s earlier work? Were their tools as precise as yours? Do you decide to disagree with the earlier work because they made a blunder, or do you calibrate your equipment/results to match the earlier work? Who is the authority?

So, fundamental lesson #2 when using your RTK equipment is that your measurements are relative measurements. The first, “previously known” point, is authoritative, and the second, “previously unknown” point, is based on that authority. If you have no previously known point to work from, then you have the opportunity of becoming the authority and declaring the point to be what you say it is. You can perform a whole survey from this new authoritative point; a place for which you have arbitrarily assigned some name or coordinate.

Now, in the future, should you wish to align your survey with a known point originating from some “other authority,” then you can do that by applying a transformation to make your points align with theirs. It could be a simple transformation if you are working in the same coordinate reference system, or it could be a complicated one if not.

This is done quite regularly. Say you mark a spot on the ground and then generate an inaccurate base coordinate by selecting “average single” for 30 seconds on your base station. Then sometime later you find a nearby survey monument with published coordinates. You can use that monument to survey new coordinates for your previously marked base station location. From that, you produce a new coordinate, one which is aligned to the local survey authority. From there you can calculate a transformation that can be applied to your whole survey to bring it into a new alignment; one which matches well with other surveys in the area.

@MDS, here is the point where I should be starting on your request, but I have squandered my energy on outlining some of the obstacles and gotchas. Perhaps I am not the best one for describing what you want as I have not been going through those motions lately. I would like to pass the torch on to someone else who is willing to get specific about the (or their particular) workflow with RTKLIB, and maybe even the pre and post coordinate transformation process.

@ everyone, I’m open to being corrected or commented on if you see something wrong or missing.


Wow! I sure hope you find the energy to just keep adding to this. Absolutely great info and easy to understand. You have at least one very attentive student eager to learn :+1:
Thank you for taking time to share some knowledge.


Well done describes it very well in general terms that make some sense!!!.

1 Like

Well, just posted this on facebook.


I could not have said that any better!! What a great and funny representation of the RTK process. To make it even more accurate you would put a line twice as high and that will be the PPK Line :wink:

1 Like


PPK does not need to be complicated! It just depends on the software you use to achieve it.
Some PPK software package are effortless: fully automated!

Stephanie, thanks for the reply. Could you elaborate on the different packages? Particularly the ones that are effortless and automated :slight_smile: I would love to learn the PPK process and be able to do it using the RTKLIB software. But right now I would certainly not be too proud to use some automation until I learn the ins & outs of processing.

I did find this site:
But the Emlid Reach is not in the list.

Any insight on more sites will be greatly appreciated.

I did find this site as well. . I am not sure on all the options. Can you or someone help with any tips for uploading to this site and any do/don’ts for getting accurate results?

EZSUrv post-processing software is very simple to use

it reads Emlid native file
search and download nearby base file
automatically smooth your Emlid observation (so you have basically no filtering, and no settings to do)
and then post-process your entry file
if you have photo file with time trigger, it will even interpolate the position for all your photos…

You can try the software with your Emlid data, just go to the link above and request a trial.

I sent you an email. I am curious on the cost.

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