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

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.