Emlid Post Processing Workflow Notes

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.

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.

Coordinate system translation: https://vdatum.noaa.gov/vdatumweb/vdatumweb?a=115701020190909

Get stationary GPS reciever station data: https://www.unavco.org/data/gps-gnss/data-access-methods/dai2/app/dai2.html#

18.d files is Hatanaka compressed GNSS observation file. Use this tool http://terras.gsi.go.jp/ja/crx2rnx.html When downloaded, drag and drop 18.d files over the crx2rnx.exe, it will create a 18.o files you can use in RTKpost

RNX2CRX [file] [-] [-f] [-e # of epochs] [-s] [-h]

the rinex header setting (rtkpost > options > positions: Base Station) was giving RTKPOST the CORS coordinates in NAD83, I thought it was referencing the xyz location. Changing this setting to Lat/Lon/Height and inputting the converted coordinates (using the same HTDP tool I linked above) for the base station did the trick! Now my coordinates are plotting within a cm of the marker, which is well within the uncertainty that comes from using a less-than-survey-grade tripod.

For others who might stumble upon this post looking for answers to a similar problem, here’s a brief outline:

-I collected observations for ~25 minutes over a known location with an emlid Reach RS system. -emlid outputs location data in reference to WGS83 datum. -The known location (PSU1b) is reported in NAD83. -The CORS data I got for post processing has, in the header, a lat/long/h which is in reference to NAD83. -In post processing if you allow RTKPOST to get the base’s location (the cors station in this case) from the rinex header, it references the NAD83 location. -This means you’re post processing data which references WGS84 against data which references NAD83. Resulting error will be on the order of meters.

Solution: Use Lat/Lon/Height setting instead of rinex headers if you need to perform an datum transform on the reference station location. Use a tool like https://www.ngs.noaa.gov/TOOLS/Htdp/Htdp.shtml 20 to perform the transformation. This will also adjust the reference station coordinates for plate velocities, which is important if you’re hoping for cm or better accuracy.

For the WGS84 ellipsoid to model Earth, the defining values are[7] a (equatorial radius): 6 378 137.0 m 1/f (inverse flattening): 298.257 223 563

https://www.ngs.noaa.gov/NCAT/ to convert from XYZ to LLH. Use 'other' for ellipsoid model and the parameters above.