All about 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.

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.

Related pages

change later..

• Debugging NTRIP connection

• Streaming RTK corrections