RTK Corrections
General requirements
The coverage (geographic operation area) of the service must match the operation area of the sensor
For example, SAPOS Bavaria works only in Bavaria, and not in the rest of Germany (or the world)
The transport must be Networked Transport of RTCM via Internet Protocol (NTRIP, version 1 only)
That means, the sensor must have access to the internet and the chosen service (server)
The data format must be RTCM3 (implied by NTRIP), see RTCM3 input messages
The data content must be OSR style messages (“MSM”, multi-signal messages)
The data must include data for all GNSS (i.e., GPS, GLONASS, Galileo and BeiDou)
Missing systems will degrade performance significantly.
VRS correction service vs. basestation
A virtual reference station (VRS) type service is the preferred means to obtain correction data for the sensor. Alternatively a single basestation receiver can provide correction data.
VRS
Operated by a third-party specialized in providing such a service
The data is from a network of continuously operating reference stations (CORS)
Can be costly (subscription needed)
Coordinate reference system is defined by the service operator
The operation are is typically nation or state wide (for example, Swipos for Switzerland, SAPOS Bavaria for Bavaria)
The performance and reliability should be very good (if it provides data for all four constellations)
Not all services have data for all constellations (some only have GPS+GLONASS, which is not good enough for VRTK)
Basestation
Operated by customer, who may or may not have all the necessary expertise
A single receiver (CORS or not CORS) provides the correction data
A internet server running a NTRIP caster is required to connect the basestation to the sensor (Fixpostion can provide this)
Choice of the basestation receiver. High-end options (recommended for any serious business) from Leica, Novatel, Javad, etc. or low-end options (such as the Emlid Reach RS2) are available.
The installation of the basestation receiver is not trivial. For example, it has to be mounted in a suitable place (such as on the roof of the highest building), it needs internet connectivity (can be cellular or Ethernet, depending on the receiver), power supply, lightning protection etc. Such installations may need approval from local authorities.
Configuration and operation of the basestation receiver is not trivial.
Establishing precise reference coordinates for the base station (antenna phase centre) is not trivial. Typically, specialized surveying companies have to be paid to do this work.
The operation area is typically a few kilometers around the basestation.
The initial installation can be costly (geodetic quality receivers are quite expensive). Maintenance and operation isn’t free either.
Combining multiple such basestations into a network is beyond what Fixposition or its customers can do (see VRS above…)
RTK GNSS
NTRIP VRS caster behaviour
NTRIP caster services for a virtual reference station (VRS) require the client (rover) to send its position using a NMEA-GN-GGA message. Before the rover sends its position they are not able to calculate the correction data and therefore will not send any correction (RTMC3 messages) before the rover has sent the GGA message.
Different services have slightly different requirements on the GGA message sent. For example, the Swipos service checks the message quite thoroughly. Besides the position (latitutde, longitude) it also checks the timestamp, the number of satellites reported and the fix status. Most services (for example, QXWZ) are much less picky and only look at the latitude and longitude values and ignore all other fields (including the fix status).
If the VRTK2 does not yet have a GNSS position fix when connecting to the NTRIP caster, the caster will simply remain silent until the sensor does send a usable position.
Once the service has a valid position and started sending RTCM3 corrections, it will not stop sending those even if the VRTK2 looses GNSS position (for example, in a tunnel) and the GGA message becomes invalid. That is, the service uses the first usable GGA, and only the first usable GGA. (This is true for the services we have tried so far. Perhaps other services behave differently.)
Receiver behaviour
The u-blox ZED-F9P uses RTK OSR corrections with an age of up to one minute (60 seconds). The performance probably suffers a bit, but it means that the VRTK should be able to handle internet resp. correction data stream outages of up to one minute without any significant impact.
RTK correction data (web interface)
Configuration
The RTK correction data source can be configured in two ways:
Configure the built-in NTRIP client to connect to a NTRIP caster of your choice.
This requires that the sensor has network (internet) access to the caster server.
In this mode the sensor automatically sends its location to the caster
Automatic position from GNSS
Manually configured reference position
When using NTRIP, all fields in the form have to be filled in. If the NTRIP caster does not use a login, put
dummyornonefor both of the User and Password fields. A Mountpoint is always required.
Configure to use RTCM3 data received on the serial port or TCP port 21000
This requires the user to send appropriate RTCM3 messages at appropriate rates on the serial port (UART1).
In this mode the sensor DOES NOT send its location.
Manual RTK reference position
Here are a few screenshots showing the difference with automatically sent position (to Swipos VRS service) and manually configuring a position close by.
RTK corrections via serial port
Note: the same procedure works for inputting the RTCM3 data via TCP port 21000.
The requirements on the correction data for input of RTK corrections via serial port are the same as for obtaining them via NTRIP.
In this configuration the built-in NTRIP client in the VRTK2 sensor is disabled and the sensor does not need an Internet connection for the correction data. It is entirely up to the user to provide the correct correction data on the serial port in the correct way.
The System Info page shows the following information when sending RTCM3 messages on the serial port to the VRTK2:
“rx” shows the number of bytes received on the serial port
“rtcm3” shows the number of RTCM3 messages received on the serial port
RTCM3 input messages
Besides meeting the General requirements above the sensor needs at least the following RTCM3 messages for proper operation:
Reference station position (rate: every 10 seconds, or more often), one of
RTCM type 1005 (Stationary RTK reference station ARP)
RTCM type 1006 (Stationary RTK reference station ARP with antenna height)
GPS observables (rate: 1 Hz), one of:
RTCM type 1074 (GPS MSM4)
RTCM type 1075 (GPS MSM5)
RTCM type 1077 (GPS MSM7)
Galileo observables (rate: 1 Hz), one of:
RTCM type 1094 (Galileo MSM4)
RTCM type 1095 (Galileo MSM5)
RTCM type 1097 (Galileo MSM7)
BeiDou observables (rate: 1 Hz), one of:
RTCM type 1124 (BeiDou MSM4)
RTCM type 1125 (BeiDou MSM5)
RTCM type 1127 (BeiDou MSM7)
GLONASS observables (rate: 1 Hz), one of:
RTCM type 1084 (GLONASS MSM4)
RTCM type 1085 (GLONASS MSM5)
RTCM type 1087 (GLONASS MSM7)
GLONASS code-phase biases (rate: every 5 seconds, or more often):
RTCM type 1230 (GLONASS code-phase biases)
The latency (age) of the data should be kept as low as possible, ideally better than 1 second. See NTRIP stability on how to measure (observe) the latency on the sensor.
Local NTRIP caster
Alternatively to using the built-in NTRIP client to connect to the internet, it can also connect to a local IP address. One can setup a local NTRIP caster, which can then be used by the VRTK2 sensor (or multiple sensors!).
Here is an example setup to demonstrate the concept of a local NTRIP caster. The example uses with data received from a serial port (for example, a reference station receiver). This serial port input can be replaced with other data sources (e.g. a raw TCP/IP socket)
For this we run the str2str program (download links below) on a host system that is network connected with the VRTK2 (any network connection will work).
On the host system run the following command:
str2str -in serial://ttyUSB1:115200 -out ntripc_s://:12345/BASEThis gets the data from the serial port ttyUSB1 at baudrate 115200 (the exact string to use depends on the host system, refer to str2str documentation for other options) and offers a NTRIP caster server on port 12345 with the mountpoint name BASE (a different name can be chosen if desired).
On the VRTK2 we can now configure this local caster as the source for the correction data (the IP address depends on the host system and local setup choices):
The VRTK2 can now get the data from this caster, which in turn has the data from a serial port.
(Note that the screenshot is from a bad location and the second GNSS receiver has no antenna connected. Therefore, GNSS 1 is only “RTK float” and GNSS2 has no signals or fix at all.)
The output of the str2str shows something like this:
stream server start
2022/01/25 16:14:15 [CW---] 0 B 0 bps (0) /dev/ttyUSB1 (1) waiting...
2022/01/25 16:14:20 [CW---] 21693 B 33888 bps (0) /dev/ttyUSB1 (1) waiting...
2022/01/25 16:14:25 [CW---] 42725 B 33584 bps (0) /dev/ttyUSB1 (1) waiting...
2022/01/25 16:14:30 [CW---] 63984 B 33987 bps (0) /dev/ttyUSB1 (1) waiting...
2022/01/25 16:14:35 [CW---] 85334 B 34172 bps (0) /dev/ttyUSB1 (1) waiting...
2022/01/25 16:14:40 [CW---] 106672 B 33948 bps (0) /dev/ttyUSB1 (1) waiting...
2022/01/25 16:14:45 [CC---] 128133 B 34363 bps (0) /dev/ttyUSB1 (1) 10.0.1.1
2022/01/25 16:14:50 [CC---] 149344 B 34068 bps (0) /dev/ttyUSB1 (1) 10.0.1.1
2022/01/25 16:14:55 [CC---] 170778 B 34283 bps (0) /dev/ttyUSB1 (1) 10.0.1.1
2022/01/25 16:15:00 [CC---] 192298 B 34446 bps (0) /dev/ttyUSB1 (1) 10.0.1.1
2022/01/25 16:15:05 [CC---] 213942 B 34455 bps (0) /dev/ttyUSB1 (1) 10.0.1.1
...We can see how it connects to the serial port (stream (0)), receives data and waits for connections on stream (1) (the -output stream) and how a client connects after a while.
Alternatively to the str2str command line tool the strsvr GUI program can be used in the same way:
The str2str and strsvr programs are part of the open source “RTKLIB”. The “rtkexplorer” version of that has the NTRIP caster functionality. It can be downloaded here:
https://github.com/rtklibexplorer/RTKLIB – source code
https://rtkexplorer.com/pdfs/manual_demo5.pdf – the manual (for all parts of “RTKLIB”)
https://github.com/rtklibexplorer/RTKLIB/releases – Windows binaries
Note that there are several versions of “RTKLIB” floating in the internet and/or are part of Linux distributions. Not all of them have a str2str (and strsvr) with the NTRIP caster functionality.
Another possibility with str2str is multiplexing a single RTK correction source to multiple clients. The source can be serial port, a raw TCP/IP connection or a NTRIP client. The str2str caster can handle multiple clients. Note that this does not work for VRS type correction sources.