Centimeter-level GNSS: Episode II – Return of the PPP-RTK

Since our last post about centimeter-level GNSS, there have been some changes in the landscape. As a candidate we found very promising, but hard to implement, PPP-RTK with GEPOS had a tough standing in our verdict. We almost always put an asterisk after it, because the readily available platform compatibility was limited to Windows and Android. This changed, thanks to ongoing work from Geo++, improving platform compatibility and hands on information around the GEPOS format conversion tool ssr2obs. That improvement flips the equation on it’s head. So, what exactly does this entail?

Recap

There are three major ways to achieve centimeter-level GNSS: RTK, PPP, and PPP-RTK.

RTK

RTK receivers require correction data from a reference station close by. The correction data is derived from the difference between the reference stations current GNSS measurements and the expected measurements based on its known position.

• corrects all errors
• locally precise (< 30 km to reference station)
• correction data is unicast

PPP

PPP receivers compensate satellite errors using correction data and estimate remaining atmospheric delays. The satellite-specific correction data is derived from a global network of reference stations. For that reason the approach is globally applicable, so the parameters can be broadcast to all receivers, e.g., via satellite. This removes the need for close proximity to a reference station, but it comes at a cost: The receivers need some time to converge to a position fix, because resolving atmospheric delays requires a time series of measurements.

• corrects satellite errors
• estimates atmospheric delays (slow)
• globally precise
• correction data is broadcast

PPP-RTK

PPP-RTK is in principle like PPP. The core difference lies in additionally provided parameters for the atmospheric delays. These can be derived from a much denser regional network of reference stations. This results in a much lower convergence time and better stability compared to PPP.

• corrects satellite errors
• corrects atmospheric delays
• regionally precise (area covered by regional network of reference stations)
• correction data is broadcast

Correction Data

For all of these techniques the deciding question becomes where to source the correction data from. For RTK, SAPOS HEPS delivers excellent Germany-wide support, but at a cost, which is prohibitive for many applications. PPP corrections can be comfortably sources via satellite and it’s free when using GALILEO HAS, though needing a compatible (more expensive) GNSS module. In the case of PPP-RTK the GEPOS service promises free high accuracy correction data. The sole drawback for GEPOS is that it uses the correction data format SSRZ which is not supported by any current GNSS module manufacturer. This is where the mentioned format conversion tool ssr2obs comes into play. It transformed the PPP-RTK corrections to RTK corrections for regular RTK modules.

Improved PPP-RTK Support

After some exchange with Geo++, they informed us that they are launching a new webpage dedicated to the conversion tool ssr2obs. This now provides more information as well as two new downloadable tool binaries for Linux on ARMv6 and ARMv8-A (or newer), with minimal and reasonably old dependencies (GCC 11.1.0 or newer): These will run on many embedded Linux machines!

PPP-RTK Caveats

Apart from the positive development for PPP-RTK adoption in embedded Linux applications, there is also a caveat that came up with the format conversion strategy: The conversion tool requires additional satellite antenna correction data that is not distributed via the GEPOS SSRZ correction data stream. This becomes a major maintenance burden, because these corrections must be updated regularly, otherwise the positioning accuracy worsens. Unfortunately there is no way to simply download the latest satellite antenna corrections. Instead, device maintenance must include regular inspections of the current ssr2obs download package. If a change is found in the satellite antenna correction file it must be rolled out to all devices. There’s a sliver of hope though, because the ssr2obs manual states:

In the future, these satellite antenna corrections are planned to get embedded within the SSRZ stream itself.

Use-Cases

Revisiting the use-cases from our last article we find some changes.

Scenario A: You need the absolute best precision (1-2 cm)

There’s no competition to RTK in this field. So our last recommendation still holds.

Scenario B: You don’t need the highest precision

Previously we recommended considering PPP with GALILEO HAS, because it’s easy to setup and works even without a network connection. However, with the changes to the usability of PPP-RTK, we would instead recommend using PPP-RTK, if the device already has access to the internet. The benefits are higher precision and no convergence time at a lower per device cost.

Scenario C: You operate in rural areas with poor internet

This is very use-case dependent and we stick with our previous recommendation.

Scenario D: You want the cheapest centimeter-level GNSS (new)

Last time we already felt compelled to include this scenario, but with such complicated trade-offs we chose to leave it out. Now we can say, if you need Germany-wide service, you already have an internet connection, and your system can run ssr2obs, just use PPP-RTK with GEPOS. It gives you free correction data with the cheapest centimeter-level GNSS capable modules. If you operate in a smaller region, consider the local SAPOS HEPS instance instead.

Example Use-Case and Comparison

A numerical comparison between the technologies helps to get an overview. Keep in mind though, that this is simplifying things a lot. The breakdown can be found in Annex A.

Our example use-case is a municipal fleet tracking application with an assumed fleet size of about 1k – 10k devices, so with a tight balance between development cost and production price per unit, and multiple regional areas of operation. The devices have internet access for application data exchange which can be used for a correction data stream too.

Note: Shaded areas show uncertainty depending on scale or region of operation, or setup.

Closing Remarks

Despite it being our second post on the topic, we’re sure this is not the definitive answer. There is still movement in the landscape that is centimeter-level GNSS positioning in Germany. We want to close with a wish list of what we would love to see, so centimeter-level GNSS can become a commodity in Germany.

• Free-of-charge nationwide SAPOS: This would be the ultimate winner and we’re almost there, this mainly hinges on Rhineland-Palatinate (see our last blog post on the matter).
• SSRZ including satellite antenna correction data: This would immensely reduce maintenance overhead for PPP-RTK. For the time being it would help if there was a static URL where one can download the latest antenna correction data file.
• An open source implementation of the correction data conversion algorithm: Yes, that is a tall ask, but it would allow us to tailor it to micro controllers. Integrating that with a DAB+ receiver and power optimizing it would result in a neat package for many applications.

Bonus: Example PPP-RTK setup using GEPOS and NEO-F9P module

1. Get ssr2obs: The conversion from the SSRZ format, used by GEPOS, to RTCM MSM, which the NEO-F9P understands, is done by ssr2obs. Download it from the Geo++ website. Additionally you may need the software package provided for Windows, which contains some auxiliary files.
2. Setup the hardware: For testing we used a Holybro H-RTK NEO-F9P Rover. We connected it with a USB-UART-adapter to a development machine running Linux Mint.
3. Start ssr2obs: The following prompt makes ssr2obs connect to GEPOS and open an NTRIP server on port 18000 to provide the RTCM MSM correction data. Note that you should chose your own user name (not svnlb-test-gschwaer), which is useful if you have a support case with GEPOS. (Note: No registration required, use whatever you want.)
   

   $ ssr2obs +syst -n=SSRZ -z=bkg1.positioning-service.net:2101 -N=BKG-SSRZ-BRST-DE,svnlb-test-gschwaer: -eph=bkg1.positioning-service.net:2101 -NE=BKG-EPH-DE,svnlb-test-gschwaer: -i=18000 -o=- -ont -rtcmmsm -atx_sv=igs20.atx -re=0 -maxa=30 -dbcz=12 -II,ND=150 -TI,ND=150 -datumdef=etrf_adv-itrf.dat -ssrdatum=ITRF20 -refdatum=ETRF_R2025

   
   You may need the auxiliary files etrf_adv-itrf.dat and igs20.atx from the Windows software package.
4. Start the GNSS server: We use gpsd. We pass the URL of the NTRIP caster and port to our gpsd startup prompt. We use dummy credentials and connect to ssr2obs on localhost:
   

   $ gpsd -n -N -D 4 /dev/serial/by-id/USB-UART-adapter ntrip://dummy:dummy@127.0.0.1:18000/SSR2OBS 2>&1 | tee gpsd.log

   
   Unfortunately it doesn’t work out of the box, because ssr2obs does not send NTRIP compliant source tables. According to Geo++ support this is a planned feature. To fix this for now, we patch gpsd to always accept the connection to ssr2obs (check out how to build gpsd and git apply this patch: gpsd-ssr2obs.patch).
   After that modification it works. Checking with gpspipe we get:
   

   $ gpspipe -w | grep –line-buffered TPV | jq –unbuffered -c '{status, lat, lon, alt, ecefpAcc}'
   {"status":2,"lat":52.520805800,"lon":13.409289700,"alt":240.0950,"ecefpAcc":2.7200}
   {"status":2,"lat":52.520805800,"lon":13.409289700,"alt":240.0950,"ecefpAcc":2.7200}
   {"status":4,"lat":52.520804000,"lon":13.409288300,"alt":239.2280,"ecefpAcc":1.4800}
   {"status":4,"lat":52.520803300,"lon":13.409296500,"alt":239.0720,"ecefpAcc":1.2700}
   {"status":3,"lat":52.520826700,"lon":13.409303100,"alt":239.4270,"ecefpAcc":0.0200}
   {"status":3,"lat":52.520826600,"lon":13.409302900,"alt":239.4290,"ecefpAcc":0.0200}

   
   Interpretation: status (codes are gpsd specific): 2 = DGNSS, 4 = RTK float, 3 = RTK fix; lat/lon/alt: latitude, longitude, altitude; ecefpAcc: position accuracy estimate in meter.
   Note 1: Because ssr2obs converts the PPP-RTK corrections (SSRZ) to RTK corrections (RTCM MSM), the modem acts the same way it does when doing RTK.
   Note 2: It can take a couple seconds to acquire a fix. Under the hood, gpsd waits for a regular GNSS location fix and sends it to ssr2obs. Using that, ssr2obs can run it’s conversion algorithm with the SSRZ corrections from the GEPOS stream for the current (rough) location. It then supplies the resolved corrections as RTCM MSM messages back to gpsd. gpsd forwards the messages to the GNSS modem, which uses them in it’s localization engine to resolve an “RTK” fix.
   Note 3: The gpspipe traces above were modified for brevity and privacy.
   Note 4: If something doesn’t work right, you can try to guess what went wrong by enabling the ss2obs debug logs with the argument -debug=1, e.g., if you observe DNS lookup errors your internet connection might be down.

Annex A

RTK (own base, with internet):

• Accuracy: 5 (1-2 cm)
• Operating range: 1 (< 30 km around own base)
• Cheap to build: 1-4 (base setup, depending on area of operation)
• Cheap to operate: 1-4 (base maintenance, depending on area of operation)

RTK (local SAPOS, with internet)

• Accuracy: 5 (1-2 cm)
• Operating range: 3 (within federal state)
• Cheap to build: 5 (simplest setup)
• Cheap to operate: 1-5 (it depends on the federal state)

RTK (national SAPOS, with internet)

• Accuracy: 5 (1-2 cm)
• Operating range: 5 (nation wide)
• Cheap to build: 5 (simplest setup)
• Cheap to operate: 1 (monthly cost per device)

PPP (GALILEO HAS, no internet required)

• Accuracy: 3 (~20 cm)
• Operating range: 5 (nation wide)
• Cheap to build: 3 (expensive GNSS modules)
• Cheap to operate: 5 (no running cost or maintenance)

PPP-RTK (GEPOS, with internet)

• Accuracy: 4 (3-5 cm)
• Operating range: 5 (nation wide)
• Cheap to build: 4-5 (format conversion adds complexity)
• Cheap to operate: 4 (regular software updates required)

PPP-RTK (GEPOS, with DAB+)

• Accuracy: 4 (3-5 cm)
• Operating range: 5 (nation wide)
• Cheap to build: 1-3 (off the beaten track, expensive DAB+ modules + format conversion complexity)
• Cheap to operate: 4 (regular software updates required)

Notes:

• Values are based on the example use-case defined above.
• We omitted other relevant parameters, e.g., time to first fix, to keep it simple.
• Internet based services:
  • Operating range: Reception of internet via cellular may worsen the operating range.
  • Cheap to build: Internet link implementation complexity is not covered.
  • Cheap to operate: Internet link operating cost is not covered.