TABLE OF CONTENTS

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 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 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:


RegionHost Name
Bands
 Constellations
North Americana.skylark.swiftnav.com:2101
L1+L2
GPS+GAL+BDS
North Americana2.skylark.swiftnav.com:2101
L1+L5
GPS+GAL+BDS
Europeeu.skylark.swiftnav.com:2101
L1+L2
GPS+GAL
Europeeu2.skylark.swiftnav.com:2101
L1+L5
GPS+GAL
Asia/Pacificap.skylark.swiftnav.com:2101
L1+L2
GPS+GAL+BDS
Asia/Pacificap2.skylark.swiftnav.com:2101
L1+L5
GPS+GAL+BDS



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 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 observations to a file named skylark.obs
  • -n skylark.nav: Write Skylark 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 CRS mountpoint


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

  • Base: Orion_CRS_L5_prod_obs.rtcm (from Skylark 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 observations to a file named skylark.obs
  • -n skylark.nav: Write Skylark 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) observations
  4. RINEX NAV file containing base station (Skylark) 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
  • Use -sys G,E when only GPS and GAL corrections are available (i.e. European Skylark endpoints)
  • 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:


SettingValue
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
ant-postypeSet to rinexdynamic to use base stations from the RINEX header and RINEX site occupation events


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) observations
  4. RINEX NAV file containing base station (Skylark) navigation messages


Procedure

  1. Start rtkpost.exe
  2. Click on Options button
  3. Change the following settings in the Setting1 tab:
    1. Positioning ModeKinematic
    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 FormatNMEA0183
    2. Output Single if Sol OutageON
  6. Change the following settings in the Positions tab:
    1. Base StationRINEX 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


Procedure

  1. Copy example configuration file from rtk_skylark_l1l5.conf
  2. Modify the settings as appropriate:
    SettingValue
    pos1-frequencySet to l1+2 for L1/L2 receivers, or  l1+2+3 for L1/L5 or L1/L2/L5 receivers
    pos1-navsysSet to 9 for GPS + GAL receivers, or 41 for GPS + GAL + BDS receivers
    pos2-armodeSet to wide-lane
    pos2-wlarmodeSet to off for dynamic rover or on for static rover
    pos2-bdsarmodeSet to off
    inpstr1-typeSet to source of rover obs, e.g. tcpcli
    inpstr1-pathSet to source of rover obs, e.g. localhost:52302
    inpstr1-formatSet 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:password@eu.skylark.swiftnav.com/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


Procedure

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

FieldValue
nf

Set to 2 for L1/L2 receivers, or  3 for L1/L5 or L1/L2/L5 receivers

navsysSet to SYS_GPS|SYS_GAL for GPS+GAL receivers, or SYS_GPS|SYS_GAL|SYS_CMP for GPS+GAL+BDS receivers

modear


Set to ARMODE_WL

wlmodear

Set to 0 for dynamic rover or 1 for static rover


bdsmodearSet to 0


Option 3: Automatic Runtime Configuration

Requirements


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 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).