Using SBAS satellites with RTKLIB

I’ve had a few SBAS related questions and issues crop up recently so I thought it would make a good topic for a post.  There are a few tips and tricks to using the SBAS satellites in RTKLIB solutions.   I will try to cover the ones I know about here.

SBAS is short for “Satellite Based Augmentation Systems”.  For anyone not familiar with the details, there is a good description of them at Navipedia.  Different parts of the world use different SBAS systems.  In this post I will focus on the WAAS system over North America and the EGNOS system over Europe but the basic ideas should apply to any SBAS system.

First of all, it’s important to understand that the SBAS satellites can be used by RTKLIB in two fundamentally different ways.  One is to use the correction information transmitted by the SBAS satellites to reduce ephemeris, clock, and atmospheric errors.   The other is to use the pseudorange and carrier phase observations from the SBAS satellites as additional measurements.

The correction information is contained in encoded messages from the SBAS satellites.  These messages can be translated from the raw receiver binary file into an *.sbs file using RTKCONV or CONVBIN if working with post-processed solutions or they are available in the raw binary receiver output if working with real-time solutions.  The pseudorange and carrier phase observations are generated for the SBAS satellites from the raw signals just as they are for the other satellites.

Usually in RTKLIB, at least for short baseline RTK solutions, the ephemeris, clock, and atmospheric data come from the broadcast messages provided by the non-SBAS satellites.  The solution sources for this information is selected in RTKLIB with the “pos1-sateph”,  “pos1-ionoopt” and “pos1-tropopt” input parameters.  If “sbas” is chosen for any of these options, then RTKLIB must have access to the SBAS messages.  For post-processing this means that the *.sbs file must be specified in the command line or configuration settings, for real-time solutions it should be available if the receiver is locked to the SBAS satellites and outputting the SBAS messages.

For short baselines, differencing will eliminate most of the errors and there will be little or no advantage to including the SBAS corrections to the broadcast data.  For longer baselines, error cancellation will not be as complete, and there will be an advantage in using the SBAS corrections to directly remove the errors.  However, for the most part, SBAS provides corrections for the GPS satellites only, not for any of the other constellations.  In addition, RTKLIB will not allow use of a mix of corrected and uncorrected observations.  This means that enabling SBAS ephemeris corrections will cause the solution to ignore all non-GPS satellites, usually resulting in a poorer solution, not a better one.

As a general practice, it is always a good idea to look at the measurement residuals with RTKPLOT to quickly verify which satellites were used in a solution and more important, which were not.  The residuals information is in the “out.pos.stat” file.  If you don’t see the “Residuals” option in RTKPLOT or don’t have this file in your output directory then that most likely means that you did not have residuals enabled in your output options.  In this case, another way to verify you did not lose any satellites is to compare RTKPLOT plots of the “number of valid satellites” before and after enabling one of the SBAS options.  By the way, this problem also occurs when using precise ephemeris data downloaded from IGS or other online sources if it does not include data for all of the constellations used in the solution.

I don’t know exactly why RTKLIB doesn’t allow a mix of corrected and uncorrected observations but I suspect that biases between the corrected and uncorrected observations may degrade the solution.

Since I always include all available constellations in my solutions and tend to work with short baselines I have generally not found the SBAS corrections to be particularly useful.  The one exception is for RTKLIB PPP solutions where precise data is very important and SBAS is an easy way to get relatively precise information, especially if internet access is not available (Thanks to JB for pointing this out in a comment to one of my recent posts).

The other way to use the SBAS satellites in RTKLIB solutions is to include their pseudorange and carrier phase measurements in the solution in the same way they are used for the non-SBAS satellites.  The SBAS observations may not be quite as accurate as the other satellites but this is taken into account by the weighting factors RTKLIB uses for measurements from different constellations.  The extra measurements will increase the robustness of the solution, particularly in the case of a moving rover where many satellites may be unusable due to cycle slips.  To enable the SBAS observations to be included in the solution, check the SBAS box in RTKPOST or set bit1 in the “pos1=navsys” input parameter.  I almost always enable this option in my solutions and would recommend others do the same if possible.

This works for the SBAS satellites over North America (WAAS) but unfortunately does not work for the SBAS satellites over Europe (EGNOS).  The EGNOS satellites are marked as unhealthy in their ephemeris data and so RTKLIB ignores them.  In theory, a solution containing EGNOS observations should be identical with SBAS satellites enabled or disabled since RTKLIB is supposed to ignore the unhealthy satellites.  Unfortunately this is not quite true, and RTKLIB does not entirely ignore them.  I think this is a bug rather than a feature but have not looked into the details.  Specifically though, I see that the unhealthy satellites affect the initial phase bias estimates of all the other satellites.  Whenever I find bugs like this, I am always concerned that they are something I have introduced into the demo5 code with my changes, so I always rerun the solution with the 2.4.3 release code.  In this case, I see the same bug (but worse) in the release code.  Here is a comparison of the difference between two solutions for a data set that includes EGNOS observations, one with SBAS enabled, and one with it disabled.   The left plot is for the 2.4.3 release code and the right plot is the demo5 code.  Only GPS satellites are enabled and ambiguity resolution is disabled in both cases to simplify the comparison.


In both cases, enabling the EGNOS satellites caused a transient at 13:06 but as you can see the transient is much larger in the release code.  Both are undesirable though and it is important to turn off SBAS observations in the solution if your receivers are tracking EGNOS satellites no matter which code you are using.  In this particular example, even with the smaller transients in the demo5 code, they were large enough to cause a false fix when ambiguity resolution was enabled.

Since I am located in the U.S. I don’t work much with EGNOS observations but I was curious to understand why they are not usable.  Doing a little research online, I found multiple references to using ranging observations from EGNOS satellites.  Some said it was not possible to use them and others said that if you ignore the unhealthy flag they will work fine.

It turns out that RTKLIB has an option to force unhealthy satellites to be used in the solution.  It is not exactly intuitive, as you force a satellite to be included by putting it in the list of excluded satellites with a”+” in front of the satellite number, but this is documented in the user manual.

The data set above had observations from only one EGNOS satellite but the SBAS satellites are differenced with the GPS satellites so this shouldn’t be an issue.  I went ahead and forced this satellite to be included and re-ran the solution.  Here is the result.  This time I plotted both solutions on top of each other, one in which SBAS observations are disabled (yellow), and one in which they are enabled and forced to be used (green).egnosErr2

Clearly in this case, forcing use of the EGNOS observations made things significantly worse.  Apparently using them requires a little more than just ignoring the unhealthy flag but I don’t know any more than this.  If anyone has successfully included the EGNOS observations in their solutions, I would be curious to know more about how you did it.

That’s about it for tips and tricks I can think of related to SBAS.  If anyone has other tips, or can answer any of my unanswered questions above, or can provide information on some of the SBAS systems I didn’t mention, please leave a comment.







15 thoughts on “Using SBAS satellites with RTKLIB”

    1. The more recent versions of the demo5 allow mixing corrected and uncorrected observations. If the SBAS ephemeris is not available for a given satellite, the code will use the broadcast ephemeris instead.


  1. Hi I’m trying to use V2.4.3 (b34) to monitor GNSS and SBAS performance from a static site with a single receiver providing RTCM 3.3 data (GPS+GLO+GAL+BDS+SBAS). I’ve connected to an available NTRIP stream offering this data (set as the rover) and I’m able to calculate the performance of the GPS+GLO+GAL constellations independently, but I can’t seem to apply the SBAS corrections. I have tried using single and DGPS modes, with GPS and SBAS options selected (iono/trop options changed, L1 only), but with no success. I expect I’m doing something wrong that means the software observes the EGNOS sv as additional ranging sources (as I get SV38 appear in the list), as outlined in this article. I’m in Europe so there’s no ranging data from the EGNOS sv and this isn’t used.

    Can anyone advise on what I may have got wrong/need to set to calculate the GPS+EGNOS corrected solution?



    1. Hi Alan. I have not used RTKLIB to process SBAS corrections from an RTCM stream and am not sure how well this is supported. I would suggest logging the RTCM stream using STRSVR or other logging tool and then processing it with RTKCONV to see if you can generate a *.sbs file which is what RTKLIB uses to store the SBAS corrections. If you are able to generate a valid sbs file then you should be able to at least post-process the data with the SBAS corrections. I believe the SBAS corrections are transmitted on an RTCM3 stream using the SSR messages and so in theory RTKLIB should support this but maybe someone who has more experience with this can comment. The SBAS satellites are also providing observation and ephemeris data so it’s important not to confuse this data with the corrections data.


    2. Al, I’m having the same issue with GPS plus SBAS into RTKNAVI. Did you find a solution? I can see in the RTK Monitor window that SBAS is being received and decoded, but it doesn’t seem to apply the corrections no matter what I try.


      1. Hi Don. The RTKLIB RTK/PPK solutions do not support SBAS corrections, they are supported only for the PPP solutions. The RTK/PPK solutions rely on double-differencing to cancel the errors rather than addressing them directly. This may be why you are not seeing corrections applied.


  2. Hi Toni. If “S36” is how the SBAS satellite is reported in your Rinex file, then your changes to the config file should work. I went back to my data and re-tested using your exact config file changes (except using “S20” in my case) and confirmed the SBAS satellite came and went in the stats file with this change.

    The broadcast orbit info should be in your rinex navigation file so should be no need to use a downloaded file, unless you expect it to have extra info not in the broadcast navigation messages from the sats? Did you try without the extra navigation file you downloaded? If not, I would try that. It’s possible the different format of the navigation data in the additional file is confusing RTKLIB.


    1. Hi Tim, thanks for your reply!

      I am not sure if I understand your comment about the navigation files. As far as I know, there is a different Rinex navigation file for every satellite system. That’s why I am calling rnx2rtkp with the list of files as follows:
      ./rnx2rtkp -k configfile.conf -o outputfile.pos -y 2 rinexfile.obs brdc[DDD]0.[YY]n brdc[DDD].[YY]g BRDCDDD0.YYl M1[SV][DDD]0.[YY]h

      I also tried without the M1[SV][DDD]0.[YY]h file, but to no avail.


      1. Ok, I just realized I could use the Rinex3 navigation files with the multi-constellation data in this version of RTKLIB (I didn’t know it). So I tried that, with no additional orbits, but still RTKLIB wouldn’t use EGNOS.


        1. Hi Toni. It should be OK to downloaded the broadcast navigation files and feed those to RTKLIB but the oribital info in those files is also available in the navigation messages sent by the satellites. In most cases it is easier to enable your receiver to decode the navigation messages from the satellites than it is to download the files from the internet. Either way, though, the info should be the same.

          Do you see pseudorange and carrier phase measurements for S36 in the observation file. They should be listed in the 2nd and 3rd column after the satellite number as shown in bold below.

          > 2016 10 23 12 30 39.6000000 0 17
          R21 19700412.825 -4412632.251 1 1033.066 43.750
          G22 20722644.026 -2949535.218 1 750.791 43.500
          S20 38689423.892 -376573.316 1 142.393 36.250

          If you see the data there, then I would enable the debug trace to level 3 (“-x 3” on the command line) and look at the details in the trace file to see if you figure out what is going on.


          1. I am using Rinex format for this tests and would like to stay with this files (and not the receiver’s binaries for obs+nav), but thanks for this advice.

            I do indeed observe the measurements for the EGNOS satellites in the input Rinex (version 2 in my case).

            Running RNX2RTKP with the “-x 3” trace level allows me to see that the number of read SBAS measurements is zero (isbs=0 for all epochs).

            Please find all the data used for this test in the following Dropbox link, should you be interested in looking further into it:

            It was run as follows:
            ./rnx2rtkp -k configfile.conf -o outputfile.pos -y 2 -x 3 rinexfile.obs BRDC00IGS_R_20173560000_01D_MN.rnx


          2. Hi Toni. I actually do see the EGNOS satellite data in your .stat file. RTKLIB internally assigns numbers 120 to 142 to the SBAS sats and for some reason does not translate them back to the text form (.e.g “S23”) for the output as it does for the other sats. In this excerpt below from your .stat file, the last line for sat 123 is your EGNOS sat. Since you ran only a “single” solution, there is not much data of interest in the stat file or trace file, other than the fact that is was used. If you ran an RTK solution there would be much more relevant information about each sat in both the stat file and the trace file.


            The “isbs=0” in the trace file indicates that you were not using SBAS corrections (the actual SBAS message data) as opposed to the psuedorange and carrier phase measurements from the SBAS sat.

            Hope that all makes sense.


  3. Hello Tim,

    thanks for this post. I am trying to replicate your results with EGNOS pseudo-range and carrier for positioning, but I can’t get to have RTKLIB (2.4.3 b29) use the SBAS satellites.

    I am providing the following settings in the config file:
    pos1-navsys =15
    pos1-exclsats = +S36 # that’s the only visible SBAS satellite in my input rover Rinex

    And using the SBAS broadcast orbits downloaded from here, particularly the file corresponding to S36

    But the stats file only shows GPS, Glonass and Galileo PRNs.

    How did you manage to have RTKLIB use EGNOS? Am I missing any additional setting?

    Thanks in advance,


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: