Emlid Reach RS Guide #3 - Base Station Post Processing (PPK)

Author: Chad Hill

Revision date: July 2018

This guide is intended to help you establish a known position for your base station using only a single Reach RS and downloaded reference data from a nearby CORS (Continuously Operating Reference Station) location.

Overview of this guide:

1. Introduction

2. Before Fieldwork

3. Setup and data collection in the field

4. Download Logs

5. Download CORS data, precise clock data, and RTKLib

6. Process data in RTKlib

7. Check Solution

8. Troubleshooting

1. Introduction

When using a pair of Reach RS units in RTK mode, it is best to set up the base station over a known point. In most archaeological applications, though, there will not be a local point with known coordinates available. However, if there is a Continously Operating Reference Station (CORS) nearby, you can establish coordinates for your base station via post-processing. This guide will walk you through ONE way to establish coordinates for a local point to use for your base station setup. This process uses the open source software package RTKlib to do the post processing.

Unfortunately, RTKPost is not beginner friendly and can be frustrating for new users. The software does not provide feedback about why your processing might have failed, and there are many variables that can cause your processing to fail or have poor results. This walkthrough provides instructions for RTKLib settings for straightforward processing of a base station log, but you are likely to run into problems with real world data. There is a troubleshooting guide at the end with some suggestions for options you can experiment with to help improve your results.

N.B. Best practice for ensuring the accuracy of your base station position would be to set up, record, and post process your base station location for several hours over several different days and then compare the independent post processing results. For archaeological fieldwork, this might not be practical or possible.

2. Before Fieldwork

The hardware that will be required for establishing a base station position includes:

1. 1x Reach RS unit

2. 1x Survey Tripod

3. 1x Tribrach w/optical plummet

4. An Android or Windows Tablet for setting up/confirming the data logging

Before going to the field, ensure that your reach unit and tablet are charged. The reach is charged via a micro USB port on the front of the unit. There should also be a micro USB cable in the storage case. The Emlid should be charged completely after being plugged into any USB port for a few hours. The internal battery will power the Reach RS for many (up to 30) hours of continuous operation.

Front panel of the Reach RS: USB charge port at left, 3 status LEDs in the middle, power button on the right. Below is the brass survey tripod adaptor.

3. Setup and data collection

The goal here is to establish a point with known coordinates that can be used to set up your base station, in the future, for Real Time Kinematic (RTK) data collection. If you are going to be using the Reach units at this location repeatedly, you will want to choose or construct a monument to act as your base station point with the following in mind:

1. The point should be easy to set the base station up over

2. The point should have a clear/unobstructed view of the sky. Do not place it near trees, buildings, metal fences, etc.

3. The point should be rugged and hard to move/disturb

4. The point should be easy to re-locate in the future

For temporary points that do not need to remain in place for long term use, it may be sufficient to draw a mark on bedrock/asphalt or hammer a nail into the ground. For longer term use, it is preferable to use a more permanent object like a cemented rebar rod or survey disc.

Emlid Reach RS setup on a tripod over a piece of rebar cemented in place to act as a local base station point

Once you have established a point to survey, place the survey tripod, with tribrach, over the point that will become the base station location.

Mount the Reach RS base station to the tribrach using the brass adaptor, and ensure that the reach is level and directly over the survey mark using the leveling screws and optical plummet of the tribrach:

The bottom of the Reach RS, this is the location to measure to when recording HI.

Be sure to screw the external radio antenna into the bottom of the Reach RS before turning the device on!

Measure the distance (in meters) from the survey mark to the base of the receiver using a hand tape. Add 6.5mm to this measurement to get the height of the instrument (HI). Note this measurement, we will need to enter it below.

All setup of the Reach RS is accomplished via a Wi-Fi connection and through a browser window or the “ReachView” App for iOS and Android. The Reach RS can either connect to an external local Wi-Fi network or generate its own Wi-Fi hotspot. The “ReachView” app can be downloaded here for iOS:

https://itunes.apple.com/us/app/reachview/id1295196887?mt=8

Or here for Android:

https://play.google.com/store/apps/details?id=com.reachview&hl=en

N.B. You will only be able to access your Reach via the Android and iOS apps if you have already updated your Reach RS to firmware 2.8.0 or higher. Please see the “initial setup” guide for directions on how to connect the Reach to the internet to update firmware.

For the type of survey described here you do NOT need the base station to access the internet, so you can allow it to generate its own wifi hotspot. If you have previously configured your Reach to utilize the hotspot in your phone, you should turn your phone hotspot off so that the Reach does not log into it. When you turn on the Reach RS, it will first look for Wi-Fi networks it knows, and then create its own hotspot if it finds none. Turn on the Reach by pressing the power button for 3 seconds. The front LED lights should flash. After a few moments, the blue “Net” LED light should come on solidly to indicate the Reach RS has initiated the internal hotspot (if the blue “net” light is blinking, the Reach RS has instead logged on to an external Wi-Fi network). On your mobile device, search for available Wi-Fi networks and look for the one that is called either “reach:xx:xx” or, if you have renamed your Reach during the initial setup, it should have that name plus “:xx:xx”. In the example below, the Reach network is available as “DartmouthBase:f7:a5”. Log on to that network using the password “emlidreach” unless you previously selected a more secure password.

An iPhone Wi-Fi network selection window, showing “DartmouthBase:f7:a5” as an available network

Once connected to the Reach hotspot, open the “ReachView” app. You should be presented with a screen showing all available Reach units. Since you are connected to a Reach-generated hotspot, the list should only include the one Reach you are connected to:

Select this Reach and, after a loading screen, you will arrive at the main ReachView status page for this unit:

The main status page for the Reach RS

Alternatively, any time you are connected to the internal hotspot in your reach, you can always access the same status page (and all additional ReachView pages) via a web browser by entering 192.168.42.1 in the address bar.

To post process coordinates for your base station, you only need a log file. You do not need to do any other setup besides ensuring that the Reach is recording the appropriate log. In most cases, unless you have changed the default settings, the Reach should begin a new log any time it is turned on. However, it is good practice to check that the log is recording.

Select the “log” tab from the menu. If using the reachview app on a cell phone or tablet, the menu is accessed via the “” button.

Reachview Menu – Choose “logging”

On the logging page, you should see the following screen:

Main logging screen

Ensure that “Raw Data” is enabled and select “Rinex 3.03” as the format. The bar at the top shows how much local storage data is available. And the boxes below show that the device is currently recording 3 types of logs (position, base correction, and Raw Data). The timer at the right shows how long the active log has been recording.

Ideally, to ensure that you will have enough data to successfully post-process a base position, you should allow the Reach to record a log, while sitting over your point, for at least 2 hours. Once the reach has run for 2 hours, you can turn off the unit by pressing and holding the power button for a few seconds. The log will be finished and can be downloaded later. Ideally, you would wait a few days and then set the unit over the same point and collect another few hours of data so that you could compare independent processing results.

4. Downloading logs

When you are ready to download the log, turn the unit back on and log into it either via its wifi hotspot, or via a local router. You probably want to download the log to a computer for post processing, rather than your phone or tablet. The easiest way to do this is to allow the Reach to start its own internal hotspot by turning off any hotspots or routers that it knows. When the Reach boots up, if it does not see a local router, it will start its internal hotspot. Log into that hotspot from a laptop or desktop via wifi (default password is emlidreach). And then open a browser and enter http://192.168.42.1 in the browser bar. This should bring you back to the main status screen. Select “logging” again from the menu.

If you scroll down in the logging screen, you should see all of the previously recorded logs.

“Logging” screen, showing previously recorded logs

Find the log that corresponds to the point you collected (based on the date and length of recording) and press the “” button. The log should immediately begin downloading and be saved wherever your default downloads are stored (i.e. the “downloads” folder in a mac). The download should end up as a zipped folder (or it may be automatically unzipped by OSX) called “raw_YEARDATETIME_Rinex-3_03”. If necessary, unzip the folder using a program like “7-zip”. This folder should contain two files, one with .obs and one with .nav extension. These are the two files you will need for post processing.

5. Download CORS data

Besides the raw log data, you will also need reference data from a nearby CORS station. The National Geodetic Survey (NGS) maintains a network of Continuously Operating Reference Stations (CORS) across the United States (and a few outside it), data can be downloaded for post-processing via the User Friendly CORS interface here: https://www.ngs.noaa.gov/UFCORS/ . If you are working in a location outside of the US, you may be able to find similar local data sources, or you can check the International GNSS Service (IGS) network here: http://www.igs.org/network .

Surf to the UFCORS page (https://www.ngs.noaa.gov/UFCORS/ ). It will look like this:

The NGS User Friendly CORS page

Select the start date, start time, time zone, and duration of your survey log. Be sure to pick a start time that begins before the start of your log and a duration that will ensure you download a reference data set that covers your entire log.

N.B. MOST CORS stations update every hour. So if you record a log in the field and then immediately want to post process it, the CORS data should be available right away. However, some CORS stations don’t update until the next day. So you MAY need to wait up to 24 hours for reference data to be available.

Click on the CORS map link to open a new window/tab that will enable you to find your nearest CORS site. On the CORS map page, zoom into the general location of your survey point. Hover your mouse over the approximate location of your survey point, and the window in the upper left will show you the nearest 3 CORS stations. Note the 3-4 character code of the nearest site. In the example below, the CORS station nearest to Dartmouth College is “VTC1” in Randolph Center, VT. Helpfully, this window ALSO shows you an estimated distance to the nearest 3 CORS stations. N.B. The distance between the Reach RS and the CORS station (called the “baseline”) affects the likelihood that you will get a successful/good result with the base station processing. Best results are obtained from reference stations <~20km. Emlid suggests that the baseline length for static post processing like this should not exceed ~100km.

NGS CORS Map showing sites nearest to Dartmouth College

Site details for VTC1

Return to the UFCORS window/tab and select the CORS station you identified as the closest in the “Site ID” pulldown. Leave the “Sampling rate” as “As is”. Do check the “Coordinate File” and “IGS Orbits” check boxes.

N.B. You will get increased accuracy/better probability of a fixed solution if you utilize precise orbit files in the processing below. The best available precise ephemeris data will be included if you select the “IGS Orbits” box in the above step. However, as with the CORS data, this data may not be available immediately. Using this check box will return whatever orbit data is available when you request the file. “Ultra-rapid” orbit data is available after ~6 hours. “Rapid” orbit data is available after ~17 hours. “Final” orbit data is available after ~15 days. It is advisable to wait for “Rapid” orbit data, but may not be necessary to wait for “Final” orbit data.

Click the “Get CORS data file” button and after a brief pause, your reference data should begin downloading to your local download folder.

You should also download the GPS “Clock” data. Similar to the orbit data, this is available as “ultra rapid”, “rapid”, and “final” data with the same latency. Ideally you should wait at least 24 hours to get “rapid” clock data. This data is slightly more cumbersome to download, as it is not served by a “User-Friendly” user interface. First, you need to figure out what “GPS Week” and “GPS Day” you need (GPS data is organized by GPS Week and day as to organize time series data into unique numbers).

Surf to this page and find the date of your survey: http://navigationservices.agi.com/GNSSWeb/ When you find the date on the calendar that corresponds to your survey, note the second line in the box for that day. This is the GPS week and day number. For instance, in the screen shot below, a survey on June 5, 2018 would correspond with Week: 2004 day: 2.

Screen shot of the GPS Date Calendar website

Now you need to go to the IGS data download FTP server. IF you are using a mac, you may just be able to click the following link, and access the FTP site directly: ftp://cddis.gsfc.nasa.gov/gnss/products/ . On a mac, you should be presented with the box below, select “Guest” and hit “connect” and you should get a file browser window showing you all of the IGS data download folders. If you are using a PC or Linux, you likely need to use an FTP app to access this link. You can try a free app like FileZilla (https://filezilla-project.org) and then access the address above also using a “guest” login.

FTP login screen for OSX

Once in the FTP site for the IGS, navigate to the folder that corresponds to the GPS week you just looked up (for instance 2004 for June 5) and open that folder.

GPS week file folders at the IGS FPT site

Scroll down in this folder until you find the files that begin with “IGS”. Find the file that starts with IGS, then has the GPS week you noted, followed by the GPS day, followed by the suffix “.clk.Z”. In this example that would be: “IGS20042.clk.Z”. Download that file and copy it into the folder with your previously downloaded CORS data.

If using a mac, you should be able to uncompress the .z extension simply by double clicking it. On a PC, you likely need to download and use a free unzip tool like 7-zip (https://www.7-zip.org).

Finally, you need to download the free post processing package “RTKLib”. You should get the version of this software released by Emlid specifically for the Reach units. This can be downloaded for windows here: https://files.emlid.com/RTKLIB/RTKLIB-Win-x64.zip

N.B. : RTKLib will only work in windows or Linux (Linux version here: https://files.emlid.com/RTKLIB/RTKLIB-qt-Linux-x64.zip . If you are using a mac, you must be using parallels or bootcamp to run windows or linux.

6. Process data in RTKlib

When you download RTKlib, you end up with a folder with several applications in it. The primary two we will use are RTKPost and RTKPlot. Before you begin, ensure that you have the following files ready that you previously downloaded:

1. Emlid log observation file ending in “.obs”

2. Emlid log navigation file ending in “.nav”

3. CORS reference data file for the time range covered by your log, specifically you need the file in the CORS data folder that ends in something like “.18o”

4. Precise orbit data. This should also be in your CORS reference data download folder. It is the file with the extension “.sp3”

5. Precise clock data downloaded via the IGS ftp server. This file should have the extension “.clk”

Run RTKPost.exe. You will be presented with this main screen.

RTKPost main screen

There are primarily two things you must do to process data in RTKPost: load all of the files in the main screen, and adjust several settings in the “Options” menu.

Begin by going to the Options screen, as some options may limit your ability to select files in the main screen. Press the “options” button at the bottom of the window. You will be presented with a new window with several tabs at the top.

RTKPost “Options” window

You will need to check or change settings on the “Settings 1”, “Settings 2” and “Positions” tabs.

On the “Settings 1” tab, choose “Static” for positioning mode. This tells RTKPost that your rover was not moving, and all recorded positions SHOULD be the same.

Under “Frequencies/Filter Type” select “L1” for frequencies as the Emlid is only able to receive the L1 signals and select “Forward” for “Filter Type”.

For “Elevation Mask” select 15. This is telling RTKPost to ignore any satellite signals that are lower than 15 degrees above the horizon. Signals closer to the horizon suffer from more atmospheric error and are more likely to have multipath error. 15 degrees is a good starting point, but you may want to experiment with raising this number depending on your results (see troubleshooting below).

Turn “Rec Dynamics/Earth Tides Corrections” off. Receiver dynamics estimates the rovers speed and acceleration and attempts to account for that. Since your rover was static, this is not necessary.

For Ionosphere correction choose “Broadcast”. For long baselines, or to improve your result, you can also try “Estimate TEC”.

For troposphere correction choose “Saastamoinen”.

For satellite ephemeris/Clock choose “Precise”.

At the bottom, be sure that “GPS” and “Glo” are checked. This tells RTKPost to use the data received from both the GPS and GLONASS GNSS constellations.

Switch to the “Settings 2” Tab. It should look like this:

For Integer Ambiguity Res (GPS/GLO/BDS) select “Fix and hold” on the left most drop down and “on” from the middle box.

On the second to last line, ensure that for “Max Pos Var for AR/ AR Filter” the drop down menu on the right is set to “On”.

Switch to the “positions” tab which should look like this:

Enable the check box for “Antenna Type”. In the far right box under “Delta-E/N/U (m), enter the height of the instrument (HI) that you recorded in the field.

In the pull down menu below “Base Station” select “RINEX Header Position”.

Hit OK to close the options window and return to the main screen.

Load your files in the main screen. Under “RINEX OBS: Rover”, click the “” icon at the right and then select your Emlid log observation file ending in .obs.

The Rover data input area

Next, click the “” to the right of “RINEX OBS: Base Station”. Select the observation file you downloaded from the CORS station. This shoud be a file ending in .18o or similar.

Next, press the first “” below “RINEX NAV/CLK/, SP3, FCB, IONEX, SBS/EMS, or RTCM”. Select the .nav file from your Emlid log.

Press the second “” below “RINEX NAV/CLK/, SP3, FCB, IONEX, SBS/EMS, or RTCM”. Select the .sp3 file from you downloaded with your CORS data.

Press the third “” below “RINEX NAV/CLK/, SP3, FCB, IONEX, SBS/EMS, or RTCM”. Select the .clk file you downloaded from the IGS FTP server.

Select a location for your results to be saved under “solution”. RTKPost will default to storing your results in a file ending in “.pos” with the same name and in the same folder as the file selected under “RINEX OBS: Rover”. You can select a new folder by clicking the “” button, or you can edit the file name directly in the text box.

You SHOULD now be ready to process your baseline location. Press the “Execute” button and you should see a green progress bar along the bottom of the window. Depending on the options you selected and the length of your log file, it may take several minutes for processing to be completed.

7. Check Your Solution

Once the processing is finished (you should see the message “done” at the bottom of the main window) you can press the “plot” button to run RTKPlot and open the solution. It will open a window that looks like this:

RTKPlot window showing processing solution

When RTKPost processes the data, it assigns a quality value to each epoch of data. RTKPlot displays the horizontal position of each epoch of processed data and identifies it with a color corresponding to the quality value. In your RTKPlot window, then, you should see hundreds or thousands of dots of various colors. In this context each point in the window should be one of 3 colors: Red, Yellow, and Green. Red indicates that that epoch had a “single” solution meaning no correction was applied. Yellow is a “float” solution, meaning differential correction was applied, but the “integer ambiguity” problem was not solved. Green is a “fixed” position and means the integer ambiguity problem was solved. A “good” processing result is a majority of tightly clustered green dots.

You can see the proportion of fixed, float and single epochs in the bottom right of the window where it shows “Q=XXXXXXXXXXXX”. In the above result 92.9% of the epochs were fixed and 7.1% were float.

You can also see a summary of the average position and error calculations by turning on the statistics text. Select “options” from the “edit” menu at the top of the window. Ensure that “show statistics” is turned on. Hit OK to return to the main screen.

RTKPlot Options

In the pulldown at the top of the main window, change “All” to “Q=1”. Now you should be seeing JUST the “fixed” green data points. RTKPlot will place the origin of this plot at the average location of all of the fixed points and will show you the coordinates of this average in the statistics at the top right of the window:

The “ORI” (origin) line here shows you the latitude, longitude (WGS84) and height of the average fixed position. It also gives you a root mean square (RMS) error estimate for the latitude, longitude, and height of the average. In the above case the root mean square error is 1.7cm and 2.8cm horizontal and 6.5cm vertical.

You can also open the .pos file you generated in RTKPost directly, in a text editor. The beginning of that file should look like this:

.Pos file opened in a text editor

This text file will show you, line by line, each epoch of solution data. Columns 3, 4, and 5 show latitude, longitude and ellipsoid height. Column 6 shows the quality flag for the epoch, i.e. 1=fixed, 2=float, 5=single (uncorrected).

8. Troubleshooting:

Although powerful, free and open source, RTKLib is not a particularly beginner friendly software package. The user manual is dense and the Graphical User Interface is deceptively simple. RTKPost can fail or give poor results with no clear indication of what went wrong. This can be exceedingly frustrating. The final section in this walkthrough provides a FEW suggestions for how to correct common problems or improve poor results when trying to post-process Emlid log data.

1. When you hit execute, watch the progress bar along the bottom. The info bar will show the quality of each solution in real-time as it is processed. This will give you some indication of how the process is going. If you see that all of the quality flags are “0”, this means “no solution data”:

RTKPost status bar showing “Q=0”.

If the process completes and you hit the “plot” button, RTKPost will open and no data will be displayed along with the phrase “No solution data” at the bottom left. If you are getting “0”, you are missing some data somewhere. The most likely culprit is that the time span of your Rover data (the Emlid log) does NOT overlap with the CORS data you downloaded or you did not select the appropriate .obs, .nav, and .18o files. The easy way to check this is th hit the “” icon to the right of both the “RINEX OBS: Rover” and “RINEX OBS: Base” lines in the main RTKPost window. This will open two separate RTKPlot windows showing the raw observation data from the base station and the rover.

RTKPlot for the observation log from an Emlid Reach RS (Top) and a CORS station (bottom)

The information box in the bottom left corner of each window shows you the start and end time for the file. Ensure that the total time span of the CORS data contains the time span of the log data from the Emlid. In the case above, the rover data spans June 18, 2018 8:54am – 9:43am. Meanwhile, the CORS reference data file spans the entire 24 hour period of July 18, from 0:00-24:00. There is, therefore, complete overlap between the rover and the base station which will be sufficient for post-processing. N.B. the times in both windows will be reported as GPS time which is equivalent to Greenwich Mean Time (GMT) or Universal Coordinated Time (UTC).

2. More insidious is the case where the processing runs, but rather than a nice clustering of mostly green “Fixed” (q=1) flags, you get mostly or all Q=2, or float, solutions per epoch. Often, in such cases, you might find, when you open RTKPlot, that the small percentage of “fixed” points in the result are not close to each other. Float solutions can be off by as much or more than uncorrected “single” solutions, and should not be relied upon to provide an accurate location for your base station. Similarly, if only a small percentage of epochs are “fixed” and they have wildly diverging coordinates, even though the receiver did not move, you should not trust any particular fixed point OR an average of all of the “fixed” points.

RTKPlot of a solution file showing small percentage of fixed epochs (4.9%) with significantly differing positions.

In this case it is best to reprocess the data after adjusting a few options one at a time to see if the percentage of fixed epochs and the clustering of those epochs improves.

First, try adjusting the elevation mask and signal-to-noise ratio (SNR) masks found on the “Settings 1” tab of the “Options” menu. The default elevation mask is 15 degrees above the horizon. However, raising this number (and discarding satellite data from higher on the horizon) can improve the results until you reach a point at which too many signals are excluded and the result degrades. Try changing the elevation mask to 20 and processing again to see if the result improves. Additionally, try turning on SNR masks. Press the “”icon to the right of “Elevation Mask/SNR Mask” which opens this window:

SNR Mask window in RTKPost

Ensure that “Rover” and “Base Station” are checked. Leave all the values at their default of 35. Re-run your processing and see if the result improves.

If you used the default settings listed above, you may also try changing the Ionosphere correction to “Estimate TEC” which is likely to work better than
“broadcast” for longer baselines. You can also download actual Ionosphere data models to use in the processing which may help increase the quality of the result, though the latency for ionosphere data is similar to that for clock and ephemeris data. Data can be downloaded here and then added to the file selection window in RTKPost:https://cddis.nasa.gov/Data_and_Derived_Products/GNSS/atmospheric_products.html

If you download ionosphere data from this site, you would add it to the file selection window in RTKPost (.18i extension file), and then select “IONEX Tec” from the “ionosphere” pulldown menu in the Settings 1 tab of the options window.

Lastly, you might try running the process both forwards and backwards. Under “options”, on the “settings 1” tab, select “combine” from the pulldown menu for “filter type”. Running the processing with this setting gives you more chances to get a fixed solution for each epoch. This step can also help to filter out some bad data that was incorrectly flagged as “fixed” in forward only processing.