Processing of a GNSS survey in RTK or PPK mode made with Emlid Reach RS2 device

Introduction

Processing of GNSS data from a survey made with an Emlid Reach RS2 base and rover (applies also for RS+ device) in RTK mode but with a base installed on an unknown location. The base position must then be post-processed and 2 main workflows are possible. First implies to calculate the Delta (difference) between a priori and corrected position for the base station, and then applying this delta to the rover. Second one implies to post-process also raw data from the rover, as in a PPK survey.

The described workflow was set up for France dataset and referential. France official reference frame is RGF93, which corresponds to ETRF2000 (epoch 2009).

Surveying with Emlid Reach RS2

I’ll don’t enter into details of surveying, but just few points that will allow accurate post-processing of the survey.

First, save all the raw data from the base and the rover in UBX format rather than Rinex or RTCM3. This is the more complete format for Emlid devices.

Second, carefully write down and save the a priori position of the base station in ReachView app. It is this position that is used when transmitting the correction to the rover, and it is different from the position that will be found into Rinex header. Thus, when calculating the delta between a priori and estimated (corrected) position, we will need this information.

Third, the referential used by Emlid devices is WGS84. For a survey made today (2020), it corresponds to ITRF14 (epoch 2020). Thus, when setting information such as base station location into ReachView app during a survey, the location must be set into this referential.

Processing the base

The base beeing set up on an unknown location during the survey, its position must be corrected. The general workflow is described in Emlid reach tutorial, but the steps below give other information allowing an accurate positionning.

Transform the UBX files of the base and the rover (raw data from the Reach RS2) to Rinex with RTKConv. Better not to use the Rinex file that can be logged in the receiver as it does not contain as many informations as the UBX.

Correct the base position with one of the two correction methods below : (1) Precise Point Positionning (PPP) processing, or (2) static differential correction with permanent stations around.

Base Method 1 : PPP Processing

In case of dual frequency receiver, the PPP solution gives better results if the logging time is long enough (min. 4-5 hours, best 12-14h) and if you wait few days (minimum 4 days, optimal 14 days, see IGS site ) before processing as the ephemeris and clock are recalculted more accurately.

Use a web-service to do this processing. E.g. :

PPP workflow

The results of PPP is generally given in the same reference frame as orbits, which is WGS84 current realization, that corresponds today (2020) to ITRF2014 epoch 2020.

To transform ITRF2014 to RGF93, use this site and choose ETRF2000 (epoch 2009) as equivalent to RGF93 (see this post), for the velocities you must choose the one of the nearest IGS station (positions and velocities given at ITRF official site or Euref site). Then to transform cartesian to geographic coordinates, use Circé IGN software. And finally, use also Circé to convert to projected coordinate system.

Base Method 2 : Static GNSS differential correction with permanent station

In case of processing the base station relative to permanent stations, the corrected position is given in the same referential as the reference station. Thus for France using RGP stations, the results will be given in RGF93, no further conversion needed as it is the local official reference frame.

Use either RTKPost either a webservice such as RGP one for France. Choose 30s Rinex dataset instead of 1s. This avoids time dependant correlation.

Static differential GNSS correction

Calculation of Delta between a priori and corrected base position

This calculation is pretty simple, just make sure you have the same reference frame between a priori and corrected positions. Be sure also not to use geographic coordinates, but either geocentric coordinates or projected coordinates. The scheme below describes this process with geocentric coordinates.

The addition of 7cm come from the fact that Emlid Reach RS2 antenna is not calibrated and it is not of standard dimension. Then if you obtain the corrected base station from a web-service, the result will be under-estimated by approximately 7cm. If you don’t use a web-service but a software post-processing with for example RTKLib, no need to add these 7cm.

Delta base station

Processing the rover

Two possibilities appear to process the positions of the rover.

Rover Method 1 : Delta

Making sure we have the a priori position of the base station as recorded by ReachView app, we can calculate the correction rover positions by applying the same delta as the one between the a priori and the corrected base position. This is only possible if the distance between the rover and the base is short (let’s say <1km) as this does not take earth curvature into account.

Rover correction using Delta method

Rover Method 2 : Post-processing differiential GNSS

This is the same method as for a PPK survey, we process the rover positions relative to the base station with RTKPost. Be sure to set the base to the corrected position. The corrected positions of the rover will output in a POS file, and in the same referential as the base position.

The initial positions of the surveyed points were stored in a CSV file in ReachView app during survey, and contains for each point the name, the antenna height, and the start / stop time of logging.

The corrected positions in the POS files, and the time-span from the CSV file are merged using a utility such as emlid_survey_update.py

Rover correction with differential GNSS

Example of full process using base method 2 and rover method 2:

1- conversion of UBX files to Rinex with RTKConv
2- BASE correction: Correction with RTKLib in static mode compared to the nearest permanent GNSS base (30s Rinex). Use of GPS + Glonass(+Galileo). The result is obtained in the base station referential, therefore in RGF93 (epsg 4171).
3- ROVER correction: Correction with RTKLib in Kinematic mode compared to the corrected base position. Use of GPS + Glonass(+Galileo). The result is obtained in the base station referential, therefore in RGF93 (epsg 4171).
4- Association of the corrected POS format rover file with the CSV survey file from ReachView app. This is done with the Python program "emlid_survey_update.py". !!! The ellipsoidal height is contained in the "height" field and NOT in the "elevation" field
5- Transformation of geographic coordinates into projected coordinates with Circé IGN. For this we must reformat the CSV file obtained to have the format desired by Circé, namely ID Long Lat Height (list of possible formats in the help of Circé)
6- Reformatting the file output by Circé. Use of the AWK scripting language.
7- Re-assembly of the file from 6 with that of 4
8- Estimation of uncertainties by combining those of the base with those of the mobile, by sum in quadrature. 
9- Estimate of the deviations with the positions from some control points

Example of full process using base method 1 and rover method 1:

1- Note the a priori coordinates of the base. They are indicated in ReachView app at the time of the survey, and !!!!!! as they do NOT correspond to the coordinates of the RINEX header.
They are expressed in WGS84, i.e. in ITRF14 (epoch 2020.1 for our survey in March 2020), and they are expressed in LLH coordinates (Longitude Latitude Height).
Subtract the antenna height (Full height from the ground to the antenna phase center) from the H component. 
2- Convert these LLH coordinates to XYZ coordinates (Cartesian three-dimensional geocentric), for example with Circé IGN. Always be sure to re-format files from Circé that are badly screwed up.
3- Obtain corrected coordinates of the base.
We use the values ​​given by a web service such as the NRCAN-PPP which gives the coordinates in the GPS reference system (ITRF14 epoch 2020.1). In that case, !!!!! you will have to be careful because the height estimated by this web-service is underestimated by around 7cm (this must be a problem with the non-calibrated antenna of the Reach RS2). It will therefore be necessary to add this value to the ellipsoidal height later on, as the coordinates we use are now the one expressed in cartesian geocentric XYZ referential
4- Calculate Delta X, Delta Y, Delta Z on the base. Beware of the Delta sign to go from a priori coordinates to the corrected coordinates.
5- Retrieve the coordinates of the mobile. It is a CSV from ReachView. These coordinates are in LLH (ITR14 epoch 2020.1).
Convert these LLH coordinates to XYZ coordinates, for example with Circe IGN
6- This file contains Cartesian coordinates from the RTK but without correction of the base. This file is normally in id X Y Z format ..... it must be rewritten according to this form: id X Y Z Vx Vy Vz. The coordinates X Y Z will be modified by applying the Delta of the base. The Vx Vy Vz correspond to the  velocities (m/y) of the zone in the reference system used. For example in our case, we will use the velocities of the Marseille station in ITRF14, which can be obtained from the site http://www.epncb.oma.be/_productsservices/coordinates/index.php 
7- Transform the global referential to a local referential. In our case we will go from ITRF14 (2020.1) to ETRF2000 (2009). The latter corresponds to RGF93. This transformation is done with the online tool on EUREF http://www.epncb.oma.be/_productsservices/coord_trans/index.php 
Save the results in a text file. We will only keep id X Y Z 
8- Convert Local Cartesian coordinates to Local projected coordinates with Circé IGN. We will use RGF93 to RGF93-Lambert93. Make sure to properly re-format the file from Circé

More information