TABLE OF CONTENTS

• Background
  • What is RTKLIB?
  • What are wide lane corrections?
• Applicable Mountpoints
• Post Processing
  • Conversion to RINEX
    • Converting SBP data to RINEX
      • Requirements
      • Convert base observations
      • Convert rover observations
    • Converting RTCM3 data RINEX
      • Requirements
      • Convert base observations
      • Convert rover observations
  • Post-processing RINEX data
    • Post-processing with rnx2rtkp
      • Requirements
      • Procedure
    • Post-processing with rtkpost
      • Requirements
      • Procedure
• Real Time Operation
  • Option 1: Static Configuration via rtkrcv.conf
    • Requirements
    • Procedure
  • Option 2: Static Runtime Configuration
    • Requirements
    • Procedure
  • Option 3: Automatic Runtime Configuration
    • Requirements
    • Procedure

Background

This document describes methods for using Skylark corrections to compute precise positions using RTKLIB.  

What is RTKLIB?

RTKLIB is an Open Source suite of tools used for capturing, converting and processing GNSS data. It includes a number of GUI (Graphic User Interface) applications (e.g. rtknavi, rtkpost) and CLI (Command Line) utilities (e.g. rtkrcv, rnx2rtkp, str2str). The rtkrcv utility is used as the RTK Engine in a number of GNSS receivers, and the remaining tools are extremely popular for a variety of off-line processing tasks.

Swift Navigation maintains a fork of the upstream RTKLIB repository which can be found here. This fork includes sbp2rinex, a modified version of the convbin utility which allows logs in Swift's SBP format to be converted to RINEX format. It also includes changes which allow RTKLIB to achieve integer fixes using wide lane corrections such as those provided by the Swift’s Skylark Cx correction service.

What are wide lane corrections?

A wide lane combination is a linear combination of measurements from the same satellite at the same time on two different frequencies (see here and here for more technical details). The result is a signal which has a longer wavelength than the two original signals.  Instead of attempting to resolve integer ambiguities using the original code/carrier observations, a GNSS receiver may instead attempt to perform wide lane ambiguity resolution by creating wide lane combinations of local and remote observations, which generally increases the probability of resolving ambiguities in comparison with attempting the resolve the ambiguities of the (shorter wavelength) original signals.

The correction data output from the Skylark Cx correction service requires that the Positioning Engine uses wide lane ambiguity resolution. This means that a linear transformation (namely, subtracting L2/L5 ambiguities from L1 ambiguities) is required on the float ambiguities before performing the search of the closest integer vector. Once resolved to integer, wide lane ambiguities can be used to constrain the position to get an RTK integer fixed position.

Applicable Mountpoints

The instructions described in the document have been tested using corrections from the Skylark CRS mountpoint.  Using corrections from any other Skylark mountpoint (e.g. OSR or SSR) will require additional conversion steps.

The CRS mountpoint is available on the following Skylark endpoints:

All endpoints provide corrections for the GPS, Galileo and BeiDou constellations.

Post Processing

Post processing typically consists of two steps:

1. Convert log files to RINEX format
2. Use rnx2rtkp or rtkpost to postprocess the RINEX files

Conversion to RINEX

Converting SBP data to RINEX

Requirements

1. sbp2rinex v2.3 or later.  Pre-built binaries for Windows, macOS and Linux can be downloaded from here. 
2. SBP log containing local observations and remote observations from Skylark Cx CRS mountpoint.  The minimum required message set is:
   1. MSG_OBS (message type 74, sender ID not 0) for local observations
   2. MSG_OBS (message ID type, sender ID 0) for remote observations
   3. MSG_BASE_POS_ECEF (message type 72, sender ID 0) for remote observations
   4. Ephemeris messages for relevant constellations:
      1. MSG_EPHEMERIS_GPS (message type 138)
      2. MSG_EPHEMERIS_GAL (message type 141)
      3. MSG_EPHEMERIS_BDS (message type 137)

For the example below, the log file PM_Starling_CRS_prod_10Hz_Ant1.sbp (from a Piksi Multi GNSS receiver, captured during dynamic driving conditions) will be used.

Convert Base Observations

$ sbp2rinex PM_Starling_CRS_prod_10Hz_Ant1.sbp -ro CONVBASE,BASEPOS -o skylark.obs -n skylark.nav

Explanation of command line options:

• -ro CONVBASE: Convert data from base station, i.e. sender ID == 0.  Note: if the SBP file contains remote observations from a sender ID other than 0, then the CONVBASE option should not be specified.
• -ro BASEPOS: Use MSG_BASE_POS_ECEF messages to populate base station position in RINEX header and RINEX site occupation events
• -o skylark.obs: Write Skylark Cx observations to a file named skylark.obs
• -n skylark.nav: Write Skylark Cx navigation data to a file named skylark.nav

Convert Rover Observations

$ sbp2rinex PM_Starling_CRS_prod_10Hz_Ant1.sbp -o rover.obs

Explanation of command line options:

• -o rover.obs: Write rover observations to a file named rover.obs

Converting RTCM3 data RINEX

Requirements

1. rtcm3tosbp v1.1.0 or later.  Pre-built binaries for Windows, MacOS and Linux can be downloaded from here. 
2. sbp2rinex v2.3 or later.  Pre-built binaries for Windows, MacOS and Linux can be downloaded from here. 
3. RTCM3 log containing local observations from rover
4. RTCM3 log containing remote observations from the Skylark Cx CRS mountpoint

For the example below, the following logs will be used:

• Base: Orion_CRS_L5_prod_obs.rtcm (from Skylark Cx CRS mountpoint)
• Rover: STEP_DPFB_L5_VSS_TCP_OSR_prod_10Hz_Dr_AmotechL5.rtcm (from a TeseoV with L1/L5 configuration, captured during dynamic driving conditions)

Note: the convbin utility from the RTKLIB website can also be used to convert RTCM3 data to RINEX.  However, as of time of writing, the latest official version of convbin (2.4.3 b34) does not support BeiDou B2a signals. It also includes a bug with the conversion of the Half Cycle Ambiguity flag (fixed in the Swift Navigation fork of RTKLIB) which degrades performance during post-processing.

Convert Base Observations

$ rtcm3tosbp -d 2022:01:05:18 < Orion_CRS_L5_prod_obs.rtcm > skylark.sbp
$ sbp2rinex skylark.sbp -ro BASEPOS -o skylark.obs -n skylark.nav

Explanation of command line options:

• -d 2022:01:05:18: Approximate start time of base station log
• -ro BASEPOS: Use MSG_BASE_POS_ECEF messages to populate base station position in RINEX header and RINEX site occupation events
• -o skylark.obs: Write Skylark Cx observations to a file named skylark.obs
• -n skylark.nav: Write Skylark Cx navigation data to a file named skylark.nav

Convert Rover Observations

$ rtcm3tosbp -d 2022:01:05:18 < STEP_DPFB_L5_VSS_TCP_OSR_prod_10Hz_Dr_AmotechL5.rtcm > rover.sbp
$ sbp2rinex rover.sbp -o rover.obs

Explanation of command line options:

• -d 2022:01:05:18: Approximate start time of rover log
• -o rover.obs: Write rover observations to a file named rover.obs

Post-processing RINEX data

Post-processing with rnx2rtkp

Requirements

1. rnx2rtkp built with changes from this Pull Request or the Swift Navigation fork of RTKLIB
2. RINEX OBS file containing rover observations
3. RINEX OBS file containing base station (Skylark Cx) observations
4. RINEX NAV file containing base station (Skylark Cx) navigation messages

Procedure

$ rnx2rtkp rover.obs skylark.obs skylark.nav -w -n -o output.txt -sys G,E,C -z

Explanation of command line options:

• -w: Enable wide lane ambiguity resolution
• -n: Enable output in NMEA0183 format
• -o output.txt: Write output to a file named output.txt
• -sys G,E,C: Enable processing of GPS, Galileo and BeiDou constellations
• -z: Output single-point positions when unable to compute RTK positions

Depending upon the specific scenario, the following additional command line options may also be required:

• Add -rb 6 to use base positions from the RINEX header and RINEX site occupation events (note that RINEX files created by sbp2rinex with the -ro BASEPOS option will insert these events based upon the contents of MSG_BASE_POS_ECEF messages, see above).  If MSG_BASE_POS_ECEF messages are not present in the SBP log (or the RINEX files were not created by sbp2rinex) then a static ECEF position for the base station can be specified using the -r <x> <y> <z> argument.  ⚠ Note however this will ignore the possibility that the base station position may have changed mid-stream due to NTRIP reconnection events. ⚠
• Add -f 3 for logs which contain L1/L5 or L1/L2/L5 data
• Add -h to enable fix and hold ambiguity resolution for logs captured in static scenarios (i.e. stationary rover)

More advanced parameters may be specified using a configuration file. An example configuration file can be found attached to the bottom of this article. Depending upon the specific scenario, it may be necessary to modify one or more of the following settings:

An example invocation of rnx2rtkp with a configuration file is as follows:

$ rnx2rtkp rover.obs skylark.obs skylark.nav -k rnx2rtkp.conf -o output.txt 

Post-processing with rtkpost

Requirements

1. rtkpost.exe built with changes from this Pull Request or the Swift Navigation fork of RTKLIB. A pre-built version can be found attached at the bottom of this document.
2. RINEX OBS file containing rover observations
3. RINEX OBS file containing base station (Skylark Cx) observations
4. RINEX NAV file containing base station (Skylark Cx) navigation messages

Procedure

1. Start rtkpost.exe
2. Click on Options button
3. Change the following settings in the Setting1 tab:
   1. Positioning Mode → Kinematic
   2. Frequencies → Select L1+2 for L1/L2 receivers, or L1+2+3 for L1/L5 or L1/L2/L5 receivers
   3. Enable GPS and GAL (and BeiDou, if applicable)
   4. Enable RAIM Fault Detection and Exclusion (if desired)
      
4. Change the following settings in the Setting2 tab:
   1. Integer Ambiguity Res →Wide Lane (or Wide Lane with fix and hold for static rover)
   2. If using BeiDou, disable BDS Integer Ambiguity Resolution
5. Configure desired settings in the Output tab, e.g.:
   1. Solution Format→NMEA0183
   2. Output Single if Sol Outage→ON
6. Change the following settings in the Positions tab:
   1. Base Station→RINEX Header Position and Site Occupation Events
7. Click OK
8. Load observations and navigation message files
9. Specify output file
   
10. Click on Execute button

Real Time Operation

Option 1: Static Configuration via rtkrcv.conf

Requirements

• rtkrcv built with changes from this Pull Request or the Swift Navigation fork of RTKLIB

Procedure

1. Copy example configuration file from rtk_skylark_l1l5.conf
2. Modify the settings as appropriate:

   Setting	Value
   pos1-frequency	Set to l1+2 for L1/L2 receivers, or  l1+2+3 for L1/L5 or L1/L2/L5 receivers
   pos1-navsys	Set to 9 for GPS + GAL receivers, or 41 for GPS + GAL + BDS receivers
   pos2-armode	Set to wide-lane
   pos2-wlarmode	Set to off for dynamic rover or on for static rover
   pos2-bdsarmode	Set to off
   inpstr1-type	Set to source of rover obs, e.g. tcpcli
   inpstr1-path	Set to source of rover obs, e.g. localhost:52302
   inpstr1-format	Set to format of rover obs, e.g. rtcm3
   inpstr2-type	Set to ntripcli
   inpstr2-path	Host name depends upon geographic region and frequencies supported (see "Applicable Mountpoints" section above), e.g. username:[email protected]/CRS
   inpstr2-format	Set to rtcm3
   inpstr2-nmeareq	Set to single. ⚠Note: the single option requires that the rover is able to compute a standalone position to populate the GGA message to send to the NTRIP caster.  This is only possible if both observations and ephemeris are available from the rover.  If ephemeris information is not available from the rover, then set inpstr2-nmeareq to latlon and provide valid values for inpstr2-nmealat and inpstr2-nmealon.⚠

3. Start rtkrcv, e.g. rtkrcv -p 2222 -m 3333 -o rtk_skylark_l1l5.conf
4. Connect to telnet port: telnet localhost 2222
5. Login with password admin
6. Start server: rtkrcv> start
7. Monitor status: rtkrcv> status 1

Option 2: Static Runtime Configuration

Requirements

• rtkrcv built with changes from this Pull Request or the Swift Navigation fork of RTKLIB

Procedure

Modify rtkrcv to set the following fields in the prcopt_t structure:

Option 3: Automatic Runtime Configuration

Requirements

• rtkrcv built with changes from this Pull Request or the Swift Navigation fork of RTKLIB

Procedure

When rtkrcv is used as the embedded Positioning Engine in a GNSS receiver it may be desirable to only enable the settings listed above when connecting to the Skylark Cx service since wide lane ambiguity fixing may degrade performance with other services.  The following code snippet shows one method for how this can be achieved:

diff --git a/src/rtksvr.c b/src/rtksvr.c
index e031596..a82b151 100644
--- a/src/rtksvr.c
+++ b/src/rtksvr.c
@@ -845,6 +845,17 @@ extern int rtksvrstart(rtksvr_t *svr, int cycle, int buffsize, int *strs,
         sprintf(errmsg,"server already started");
         return 0;
     }
+
+    if(strs[1]==STR_NTRIPCLI&&paths[1]&&strstr(paths[1],"swiftnav.com")) {
+        /* apply desired settings for Skylark */
+        prcopt->modear=ARMODE_WL;
+        prcopt->bdsmodear=0;
+    } else {
+        /* apply desired settings for non-Skylark services */
+        prcopt->modear=ARMODE_INST;
+        prcopt->bdsmodear=1;
+    }
+
     strinitcom();
     svr->cycle=cycle>1?cycle:1;
     svr->nmeacycle=nmeacycle>1000?nmeacycle:1000;

Note that the appropriate configuration values may differ from those shown in this example (see "Static Runtime Configuration" section above).