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.

egnosErr

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.

 

 

 

 

 

Advertisements

Initial look at the ComNav K708 receiver

ComNav was kind enough to recently lend me two of their K708 receivers for evaluation.   I also have a Tersus BX306 receiver that was given to me earlier by Tersus for evaluation.  Both of these are relatively low-cost dual frequency receivers that offer full GPS L2 support., unlike the SwiftNav receiver I evaluated in my previous posts which is GPS L2C only.  I have described the Tersus BX306 before in a previous post but last time I was not able to evaluate it with a local base since I did not have a second dual frequency receiver that supported L2.  Tersus has also just recently released their new V1_19 firmware so I included that in this evaluation.   As usual I’ve also included  a pair of u-blox M8T receivers to use as a baseline.

Here’s a photo that shows the three receivers each with their associated serial port and power cabling.  The u-blox M8T is on the left, Tersus BX306 in the center, and ComNav K708 on the right.  The ComNav receiver is actually only the smaller daughter board in the center of the larger board, everything else is part of the very sturdy but rather clunky dev kit.

rcvrs3

The Tersus BX306 is priced at $1699 but lower priced versions are available. For example, the BX305 supports GPS L1/L2 but Glonass G1 only, and the BX316R is GPS L1/L2 and Glonass G1/G2 but provides only raw observations for post-processing.  Both of these options are priced at $999.

The ComNav K708 is similar to the better known K501G but newer and more capable.  ComNav doesn’t list their prices on their website but they have told me that both the K501G and the K708 configured to be equivalent to the K501G (GPS L1/L2 and GLO G1/G2) are available for less than $1000.

Both the Tersus and the ComNav receivers come with GUI console apps which are good for initially getting familiar with the receivers.  However each had their unique quirks and I found myself fairly quickly abandoning them for the more familiar quirks of the RTKLIB apps.  Managing three simultaneous real-time solutions involving five separate receivers while also logging raw observations for all five was actually quite challenging and I made a couple of unsuccessful runs before I got everything working at the same time.

I found that the key to turning this into a manageable and automated process was replacing each of the different manufacturer’s GUIs with an RTKLIB stream server (STRSVR) and a plotter (RTKPLOT) each with it’s own dedicated .ini file.  Eliminating the GUIs also gave me a better understanding of exactly what the receivers were doing and what the GUIs were doing.

STRSVR provides a standardized, always visible red/yellow/green indicator for each stream along with a continuously updated bps number that indicates not only that the connection is alive, but that data is flowing.  This allowed me to tell at a glance that all streams were flowing and that all the log files were being updated.  Using the “-t” option in the command line to specify a title for each window also helped keep things straight.

Both receivers are configured by sending Novatel-like ASCII commands over the serial port and these can be added to the STRSVR Serial “Cmd” window and saved to a “.cmd” file, similar to configuring the u-blox receiver.  Notice in this example, I also sent a reset to the receiver every three minutes which was a convenient way to automate the testing of acquisition times.

strsvr1

I connected both dual frequency rover receivers to my laptop, using two COM ports for each one and using a USB hub to get enough ports.  I set up both receivers to output NMEA solution messages and raw RTCM observation messages on COM1 at 5 Hz and accept RTCM base station data on COM2.  Both receivers have decent reference manuals to describe their command set but I also found this Hackers Guide to the K501G from Deep South Robotics quite useful for getting started.

For reference, here are the commands I used to configure the Tersus rover:

fix none
unlogall
log com1 gpgga ontime 1 nohold
rtkcommand reset
log com1 gpgga ontime 0.2

log com1 rtcm1004 ontime 0.2
log com1 rtcm1012 ontime 0.2
log com1 rtcm1019 ontime 1
log com1 rtcm1020 ontime 1
interfacemode com2 auto auto on

saveconfig

and here are the commands I used for the ComNav rover:

interfacemode compass compass on
unlogall com1
fix none
refautosetup off
set cpufreq 624
rtkobsmode 0
rtkquality normal
set pvtfreq 5
set rtkfreq 5
log com1 gpgga ontime 0.2 0 nohold
log com1 gprmc ontime 2 0 nohold
log com1 rtcm1005b ontime 10
log com1 rtcm1004b ontime 0.2
log com1 rtcm1012b ontime 0.2
log com1 rtcm1019b ontime 2
log com1 rtcm1020b ontime 2
interfacemode com2 auto auto on

saveconfig

My intent was to setup the receivers in default RTK mode with a 5 Hz output for NMEA solution messages and RTCM raw observation and navigation messages.  The one exception to default was that I found the “rtkquality” setting on the ComNav receiver defaulted to “quick” which was giving me false fixes, so I changed this to “normal” and that seemed to fix the problem.

By setting things up this way, I only need to click on the correct combination of icons (each tied to it’s own .ini file) from my RTKLIB menu to bring up the correct windows and a few more clicks to start the streams in a simple and repeatable way.

dualFreq3

I’m jumping ahead a little bit, but here is a screen capture of the rover-connected laptop streaming two NTRIP sets of base station data to the rovers while simultaneously logging and plotting the computed solutions for all three rovers along with raw observations for all five receivers,  and also computing an RTK solution for the M8T receivers with RTKNAVI.

Capture3

I should mention that there was one very annoying bug that was introduced to STRSVR in one of the recent RTKLIB releases that gives an error if a data file already exists instead of an overwrite dialog but I did fix this and add it to a new demo5 b29b code release available at the download page on rtkexplorer.com.  The new release also includes a fix for another bug that prevented the “-i” command line option to specify a config file for RTKPLOT from working properly.

I then setup the second ComNav receiver as a base station for both dual frequency rovers and used a single COM port to stream RTCM messages from the receiver to a PC.  I used an STRSVR window on the PC to stream the messages to a NTRIP caster using the free RTK2GO NTRIP caster service as I have previously described.  I used ComNav AT330 antennas for both the base and rovers with the rover antenna shared by all three rover receivers.   I did not have enough connector hardware to share the base antenna so used a separate u-blox antenna for the M8T base receiver.

The next step was to collect some data.  I started with a relatively simple challenge, a static rover with a reasonably open sky view and a short baseline.  The ComNav and Tersus solutions both assume the rover may be moving so I set up the M8T solution as kinematic as well.

Let’s first look first at the ComNav solution compared to the M8T solution.  Both solutions were computed real-time.  RTKPLOT will plot NMEA data but it did not seem to like the mix of NMEA and RTCM data in the same file.  To deal with this, I wrote a simple matlab script to strip the NMEA messages from the log file and put them in a separate file.  Below I have plotted only the Up/Down axis for both receivers just to avoid too much data,  the M8T is on top, and the ComNav below.  Each of the larger breaks in the fix was caused by me disconnecting then reconnecting the antenna to force a re-acquire.

comnav1

The M8T configuration was identical in the left and right plots, but the ComNav “rtkquality” parameter was set to “quick” in the left plot, and “normal” in the right plot.  It’s not as obvious here as it is in the other axes but the third ComNav fix in the left plot is a false fix and had over 0.2 meters of error in the N/S axis.  Changing the “rtkquality” parameter to “normal” seemed to help and I did not notice any more false fixes after making that change.

The ComNav receiver typically achieved a fix very quickly regardless of the “rtkquality” setting, usually in less than 30 sec although in one case it took a minute and a half.  This was noticeably faster than the M8T receiver, which took from 1 to 3 minutes each time in this example to achieve a first fix.

The scales are the same in the two sets of plots, so as you can see, the ComNav fixes are a fair bit noisier than the M8T fixes.  I don’t know why this is but it is something that I hope to investigate more.

Unfortunately I got a mix of good and not so good results from the Tersus receiver.   I did not see this behavior in my previous evaluation so I’m fairly certain this is not a problem with the hardware.  I suspect it has something to do either with my setup or with the new firmware.  I am going to hold off on sharing any of the Tersus data until I understand better what is going on.

Next, for a more challenging test, I moved the rover antenna to a spot with fairly poor sky views located between several large trees.  The sky view directly above the antenna was clear but a large percent of the overall view was blocked.   Again, I just plotted the Up/Down axis with the M8T position solution on the top and the ComNav solution on the bottom.

comnav2

I disconnected and reconnected the antenna three times in this experiment.  The M8T did not get a fix in the first try before I gave up after 12 minutes, but it did after 13 and 11 minutes in the second two tries after briefly getting a false fix in the second try.  Definitely marginal conditions for the M8T.  The ComNav receiver did significantly better with two fixes in less than 3 minutes and one in 9 minutes.  The errors were relatively large in the first fix but based on the other two axes it was not a false fix.  You can also see that the ComNav third fix was noticeably noisier than any of the other fixes on either receiver, again for unknown reasons.

For the third part of the experiment I moved the receivers into my car and attached the antenna to the roof and collected data for three spins around the neighborhood.  The results are plotted below.  In each case the M8T real-time solution is on the left, and the ComNav is on the right.  In the data in the first row, I shared a single antenna for all three receivers.  For the data in the second and third row I used separate antennas.  I did not change any of the config settings for any of the receivers between these runs and the above runs except that the rtkquality setting was still set to “quick” for the ComNav receiver for the second and third rows.

 

 

 

comnav5

 

comnav6

comnav7

I have not had a chance to look at this data closely but at first glance, from a fix percentage perspective only, I don’t see significant differences between either of the receivers.  The obvious advantages the ComNav receiver demonstrated in faster fixes in the static tests did not seem to carry over to the moving rover case.  I do plan to look at the raw data more carefully to see if I can understand better why this is.  For whatever reason, the Tersus receiver seemed to perform better with a moving rover than it did with a static rover, and was very similar in fix percentage to the other two receivers in this part of the experiment.

Next I planned to post-process the raw data through RTKLIB to better understand what is going on but as usual, nothing is as simple as you hope for, and I ran into another issue.

Both the Tersus and the ComNav receiver report a mix of 2W and 2X  measurements for the raw GPS L2 measurements.  If the satellite supports the newer L2C code it locks to that and reports a 2X code, if not, it locks to the older L2  and reports a 2W code.   You can see this in this example observation epoch from the Rinex conversion of the ComNav receiver RTCM output.  The left three columns are the L1 measurements, the middle three columns are the L2 (2W) measurements and the right three columns are the L2C (2X) measurements.  You can see that all the GLONASS satellites report L2 measurements only but that the GPS satellites are a mix of L2 and L2C measurements.

comnav4

This is new for the Tersus receiver, it did not do this when I evaluated it with the older firmware.  For the ComNav receiver, this is the default behavior but it is possible to change this through a command to specify L2 only, no L2C.  As far as I can tell, the Tersus only supports the mixed L2/L2C mode.  All the data I collected for this experiment was in the mixed L2/L2C mode.

Unfortunately RTKLIB does not like this format and throws away all of the L2C measurements.  It is possible to fool RTKLIB into using all the measurements by changing the 2X’s in the “Obs Types” list in the file header to 2W’s but I haven’t looked yet at to what extent mixing the code types affects the solution or how to avoid throwing away the L2C data without editing the header.

I will leave a more detailed analysis of the data to a future post.  My initial impression from these results though, is that although there are some obvious advantages with the ComNav receivers, replacing a pair of low cost single frequency receivers with a pair of low cost dual frequency receivers does not magically make the challenges of precision GNSS go away and that it will still require close attention to the details and recognition of their limits to get good results with either set of receivers.