RTKLIB solution accuracy

OK, so let’s say you’ve just gone out and collected some decent raw measurement data, everything looks like it is working properly and you get a nice-looking solution from RTKLIB, maybe something like this.

stdev1

The next thing you might want to know is how accurate is that solution?  Fortunately, RTKLIB does include accuracy estimates in the solution file.  These are expressed as standard deviations, one for each axis.  Here’s an example for a solution calculated in ENU (east/north/up) coordinates.  The sde, sdn, and sdu columns are the standard deviation estimates for each solution point and are given in meters.  If the solution were calculated in XYZ coordinates, the columns would be labelled sdx, sdy, and sdz.

stdev5

You can display these on the solution plot with RTKPLOT by setting “Error Bar/Circle” in the options menu to “Dots” or “Bar/Circle”.  You can see the gray lines in the plot below that represent the solution value plus and minus one standard deviation.

stdev2

Visually, I prefer to see three standard deviations plotted, rather than just one.  Three standard deviations represents 99.7% of the distribution, so the correct value should nearly always appear between the two gray lines.  One standard deviation, on the other hand,  represents only 68% of the distribution which is hard for me to attach any physical meaning to.  This can be easily changed in RTKLPLOT by replacing SQRT(s[j]) with 3*SQRT(s[j]) all three places it appears in the plotdraw.cpp file and recompiling RTKPLOT which gives this:

stdev3

Of course these are just estimates of the solution uncertainty made by the kalman filter in RTKLIB and we can not assume they are accurate without some analysis.  They are a function of the input parameters that set the input measurement uncertainties and process noises for the kalman filter.  These are all in the “stats” section of the input configuration file.  Even if these are all set to correctly match your actual configuration, there will be additional errors in these estimates caused by non-linearities in the system, non-gaussian distributions, and time-correlated measurements among other things.

So, let’s do a little analysis to get a feel for how useful these estimates are.  We’ll start with the above data set which includes eight hours of measurements from a stationary u-blox M8T receiver and a CORS reference station 8 km away.  I enabled fix-and-hold for ambiguity resolution with relatively low tracking gain (pos2-varholdamb=0.1).  I ran both static and kinematic solutions on the data, then turned off ambiguity resolution and re-ran the solutions to get examples of both fixed and float solutions for static and kinematic modes.

After running the solutions, I pulled the solution files into matlab for plotting and analysis.  Since the rover was stationary and I knew it’s precise location I was able to easily calculate the true errors.  I then plotted for each solution point, the absolute value of the errors and three times the standard deviation estimate for each point, similar to the above RTKPLOT plot.  The raw data is in E/N/U coordinates but I combined the East and North values into a single horizontal error and error estimate.  After finding that in some cases the error estimates were too low, I also plotted a line using double the error estimate, to see if that might be a usable value .  In the title of each plot I’ve included the percent of samples that were inside the error lines, the first number is for the undoubled estimate, the second is for the doubled estimate.  I also made one more modification to the error estimates by limiting them to a minimum value.   In the case of the static solutions, the RTKLIB error estimate will continue to decrease almost all the way to zero but this is not realistic since there are errors that are not visible to the solution.  I arbitrarily limited each horizontal axis standard deviation to no less than 5 mm, and the vertical axis to 1 cm.   I don’t have good justification for these particular numbers but do believe there needs to be some limits set.

For a perfect Gaussian distribution, plus or minus three standard deviations should include 99.7% of the data.  Given that these are not perfect distributions and will also contain outliers, I would consider the estimates useful if more than 95% of the data fell within them.

Here are the plots for the above data set run with static solutions, float on the left, and only the fixed values of the solution with ambiguity resolution enabled on the right.  The blue line is the actual error, the red line is the RTKLIB estimate, and the yellow line is double that.  The top plots are for the horizontal axes and the bottom plots for the vertical axis.  In the static cases, all the error lines dropped below the minimum estimate values I set above fairly quickly, so only the initial convergence of the float solution was really of any interest.   Still the error estimates in that region look somewhat reasonable, although the undoubled estimates are clearly optimistic. The undoubled estimates (red) are not visible on the plots where both estimates have dropped below the minimum and they get overwritten by the doubled estimate.

stdev8

Next are the same plots for the kinematic solutions.  Just to confuse you, I have accidentally put the float solution on the right this time.  Again, the solution with ambiguity resolution enabled (on the left) only includes points that were fixed.  These are more interesting than the previous plots since they are not dominated by the arbitrary minimum error estimate limits I added.  Looking at the float solution first, the undoubled estimates again look too optimistic with only 92.2% and 75.2% of the data within that limit.  At 100% and 99.6% the doubled values (yellow lines) appear to be better estimates.  For the fixed values on the left however the undoubled estimate percentages and plot lines appear to be fairly reasonable.

stdev7

In one last example, I used a different data set, this one is one of the sample data sets on my website which was taken with two M8T receivers, one on each end of a kayak out on the ocean.  In this case we know that the distance between the two receivers will remain constant so we can use that information to do a similar analysis as above.  Because the kayak is moving in all three axes with the waves we can not separate the horizontal and vertical components but can do an actual error to estimated error comparison for the three axes combined.

The float solution is back on the left again, just the fixed values from the ambiguity resolution enabled solution on the right.  Based on the calculated percentages and the shapes of the curves, it seems fairly reasonable to again choose the doubled estimates for the float solution and the undoubled estimates for the fixed values.  Even with the doubling, the percent of solution values within three standard deviations is still only 88.5% which is rather low but most of the outliers were in the initial convergence where we might expect more issues.

stdev6

So, based on these few examples I do see correlation between the RTKLIB error estimates and the actual errors, not as much as I would have liked, but there is some.   Maybe these adjustments I made would hold up for other cases as well, but I would not have a lot of confidence without trying more examples first.

Clearly these error estimates can not be taken at face value.  Do they have any value?  It probably depends on what you are trying to do with them.  If you are just trying to get a rough idea of the accuracy of the measurements, especially if it is in a statistical sense, and you have done some previous analysis with similar data sets, then you can most likely derive some value from them.  If the absolute accuracy of a single measurement is important to you then you will probably need to find another solution.

What about trying to adjust the input configuration parameters (measurement and process noises) to make the accuracy estimates more accurate?  You may be able to make small improvements but I suspect they will not be significant enough to avoid post-solution adjustments.  You will also find that adjusting these parameters will affect the quality of the solution and it will be difficult to optimize for both.

I am interested, though, if anyone has any ideas for simple (or at least only moderately complicated) code changes that could be made to RTKLIB to improve these estimates or any other ideas on how to improve them.

 

 

 

Advertisements

Online RTKLIB post-processing demo service

Recently, while experimenting with low cost dual frequency receivers, I discovered a few of the free online post-processing PPP services available from various academic and government organizations such as OPUS, CSRS, and AUSPOS.  These are a great way to easily compute a fast and accurate precise location for your base station for kinematc RTK/PPK work if you are using a dual frequency receiver.  I’ll leave the details to another post but bring them up here because they were the inspiration for a much more modest version I have put together for generating online PPK solutions using RTKLIB.

In this case, the intent is not so much to actually generate useful solution data, as it is to give new or potential RTKLIB users a chance to try out the software while avoiding some of the learning curve associated with setting it up and running it on their computer.

The PPP online services generally have a web page interface to upload the data and specify configuration options.  They then email the results to you a short time later.  To keep the implementation simple, the RtkExplorer online service works entirely through email.  You send the data and any custom config options in an email and it will email you a solution.  It runs entirely off of a single old laptop setup in the spare bedroom so is not capable of processing enormous amounts of data but hopefully will be able keep up with what I expect to be modest demand at the most.  My son has been back from college for the summer and is much better at coding things like Google APIs than I am, so he actually did most of the work with a little direction from me.

My hope is not only that it may be helpful to a few people getting started with RTKLIB, but also that it will help me improve the demo5 version of RTKLIB.  By seeing more data sets, especially those using low-cost receivers, I hope to better understand how people are using RTKLIB and what limitations they are running into.  So, even if you are already an RTKLIB expert, but run into a data set that you think it should have done a better job with, please submit it and get it added to the database.  I am sensitive to privacy issues, so while I may use relative position plots from the data to demonstrate issues in my posts, I will never share any absolute position information or anything else that would identify where the data came from.

Also, to help me evaluate how the demo5 version of code is working, and to provide a comparison for those who might be interested, two solutions are computed and plotted, one with the latest demo5 code and the other with the latest version of the official 2.4.3 code.

To help the user spot possible reasons for a poor solution, the observations for both base and rover are also plotted, along with some guidelines on common data quality issues to look for.  The solution files and configuration files for both solutions are also attached for more detailed analysis.

Before running the solutions, the data is briefly analyzed for receiver type and sample rate.  If it can be determined that both receivers were u-blox M8Ts, then the solution defaults to continuous ambiguity resolution and GLONASS AR enabled.  Otherwise, the solution defaults to both AR settings set to fix-and-hold with relatively low tracking gain.  Either way it defaults to kinematic mode and forward only solution.  Configuration inputs that are sample rate dependent are adjusted for the sample rate unless they are specified separately by the user.

If the user would like to run with any of the RTKLIB input configuration parameters set to something other than the selected defaults, that can be done by adding the appropriately set line from the config file to the body of the email.  This allows the user to specify a static or combined solution or any other variation that can be specified through the configuration file.  Any antenna types that are included in the ngs14.atx file can be specified.

For the time being, the only raw binary format that is supported is u-blox.  All other data must be in RINEX form.

Once I have a little more confidence that everything is working properly I will post a link and instructions to the rtkexplorer.com website but for now I’ll give some quick instructions here.

RTKLIB Demo Instructions

Send an email to rtklibexplorer@gmail.com that follows these rules:

  1. The email subject must include the words “rtklib demo”
  2. The base and rover data must be in attached files , either separate or zipped together and the total attachments must be less than 25 MB
  3. If the files are zipped, zip the files directly, not the folder that the files are in. (This is a temporary restriction until I improve the code)
  4. The rover files must have the letters “rov” in the file names
  5. The base files must have the letters “base” in the file names
  6. Valid file extensions are .ubx, .*nav, .obs, and .yy* where yy is the year (e.g.   .17o)
  7. At least one navigation file from either the base or rover must be included as well as observation files from both rover and base.
  8. If the base observations are in a Rinex file, the approximate base position in the header must be valid  and  in XYZ coordinates  (This is a temporary restriction until I improve the code)
  9. Config values are optional and should be copied by line directly from the config file into the body of the email, one to a line (e.g.    pos1-posmode = static)

If you’ve done everything right (and everything on my end is working properly), about five minutes after you have sent the email, you should receive a response with observation and solution plots and attached solution and config files.  Here is an example response I received after sending in one of the M8T data sets from a recent post.

 

 

email1

email2

 

Hopefully everything will just work the first time, but please be patient if there are a few glitches getting started.  I will be monitoring the emails closely at first and will try to keep things running smoothly as much as possible.

So, go ahead and give it a try, and help me iron out any last few bugs and also develop a database of data sets for further demo5 code development.

PPK vs RTK: A look at RTKLIB for post-processing solutions

The “RTK” in RTKLIB is an abbreviation for “Real-time Kinematics”, but RTKLIB is probably used at least as often for “PPK” or “Post-Processed Kinematics” as it is for real-time work.  In applications like precision agriculture, where the solution is part of a real-time feedback loop, RTK is obviously a requirement, but in many other applications there is no need for a real-time solution.  For example, drones are often used for collecting photographic or other sensor data but only need precision positions after the fact to process the data.  PPK is simpler than RTK because there is no need for a real-time data link between GPS receivers and so is often preferable if there is a choice.  The downside of course is that if there is something wrong with the collected data, you may not find out until it’s too late.

For the most part, RTKLIB solutions are identical regardless if they are run on real-time data (RTK) or run on previously collected data (PPK).  The most significant exception to this rule is what RTKLIB calls the “Filter Type”.  This is selected in the configuration and can be set to forward, backward, or combined.  Forward is the default and this is the only mode that can be used in real-time solutions.  In forward mode, the observation data is processed through the kalman filter in the forward direction, starting with the beginning of the data and continuing through to the end.  Backward mode is the opposite,  data is run through the filter starting with the end of the data and continuing to the beginning.  In Combined mode, the filter is run both ways and the two results are combined into a single solution.   This mode is set using the “Filter Type” box in the Options menu if using one of the GUI apps, or with the “pos1-solytpe” input parameter in the configuration file if using a CUI app.

There are two advantages to a combined solution over a forward solution.  First of all, it gives two chances to find a fix for each data point.  Let’s say there is an anomaly in the middle of the data set that causes the solution to switch from fix to float and not come back to fix for some period of time.   It may cause both the forward and backward solutions to lose fix but they will lose fix on opposite sides of the anomaly.  By combining the two solutions we are likely to get a fix for everywhere except right at the anomaly.  Another case where it often helps is in recovering the beginning of a data set.  Let’s say the first fix didn’t occur until five minutes into the data set.  With a forward solution, you would need to guarantee that nothing important happened during that five minutes, but with a combined solution, the backward pass will normally provide a fix all the way to the very beginning of the data set so there is no lost data.

The second advantage of the combined solution is that it provides an extra level of validation of the results.  To understand how this happens, it’s important to understand how RTKLIB combines the forward and reverse solutions.  For each solution position point there are three possibilities; both passes are float, one is float and one is fix, or both are fixed.  If both passes generate a float position, then the combined result will be a float with a value equal to the average of the two positions.  If one is float, and the other is fix, the float is thrown away and the fix is used.  In the case where both are fixed, then RTKLIB will attempt to validate the result by comparing the two values.  If they differ by less than four sigma, then the result will be a fix, otherwise it will be downgraded to a float.  Either way, the value will be the average of the two positions.  This degrading the solution type when the answers from opposite directions differ provides an increased confidence in the solution, at least for points for which we got two fixed values.

I will show a couple examples of the differences between forward and combined modes.  The first example is a more typical case and demonstrates how combined mode will normally give you a higher fix percentage while at the same time increasing confidence in the solution.

The plots below were taken from an M8N receiver on a sailboat using a nearby CORS station as base.  With ambiguity resolution mode set to fix-and-hold, I was able to get a solution with nearly 100% fix except for the initial convergence, but I would prefer to use continuous ambiguity resolution because of the higher confidence of the solution.  In the position plots below, the top was run in forward mode, the middle in backwards mode, and the bottom in combined mode, all in continuous ambiguity resolution mode.

combined1

As you can see the forwards and backwards mode solutions are not bad but both have gaps of float in the middle as well as floats during the initial acquisition.  The combined solution though has almost 100% fix rate and in addition includes the additional confidence knowing that every point found the same solution when running the data in opposite directions.

This second example comes from a data set posted on the Emlid Reach forum with a question on why the combined solution was worse than the forward solution.  In the plots below, the top solution is forward, the middle is backward, and the bottom is combined.

combined2

This data was GPS and SBAS only, so had a fairly low number of satellites, also included a mix of poor observations and the solution was run with full tracking gain (i.e fix-and-hold with the default gain).  Both forward and backward runs found fixed (green) solutions and tracked them all the way through the data set.  However, at least one of them was most likely a false fix, causing the fix to be downgraded to float (yellow) for most of the combined solution as can be seen be seen in the bottom plot.

To confirm this, the plot below shows the difference between the forward and backward solutions.  As you can see, the two differ by a fairly substantial amount and it is not possible from this data to know which one is correct.

combined3

In this case, turning off fix-and-hold and running ambiguity resolution in continuous mode sheds some light on what may be going on.  The plots below are again forward, backward, and combined.  This time the forward solution loses fix early on and never recovers it, whereas the backwards solution maintains a fix through the whole data set and is probably correct since without fix-and-hold enabled, it is very unlikely to stay locked that long to an incorrect solution.  The backward solution is also consistent with the beginning of the forward solution, since the combined solution remains fixed in the early part of the data set where both forward and backward solutions are fixed.

combined4

Again, this can be confirmed by looking at the difference between the forward and backward solutions.  In this case they agree everywhere that both are fixed.

combined5

As this example demonstrates, if post-processing is an option, it often makes sense to run in combined mode with continuous ambiguity resolution instead of forward mode with fix-and-hold enabled.  The additional pass will increase the chances of getting a fixed solution without the risk of locking onto a false fix that fix-and-hold can cause.  Even if you find you can not disable fix-and-hold completely, it may allow you to reduce the tracking gain (pos2-varholdamb)

So one last question is why are there still some float values in the middle of the combined solution? We would expect that since the backwards solution is fixed and the forward solution is float, that the combined solution should just become the backwards solution and all but the very end should be fixed.

The answer to this question turns out to be the way the reverse pass of the kalman filter is initialized.  I have chosen in the demo5 code to not reset the filter between forward and reverse passes if continuous ambiguity resolution is selected.  If fix-and-hold is selected then the demo5 code does re-initialize the kalman filter between passes.  This is different from the release code which always resets the filter between passes.

In this case, the results would have been slightly better if the filter were re-initialized but most of the time I find that allowing the filter to stay converged avoids a large gap in the backwards solution during the active part of the data set where the filter is reconverging. With fix-and-hold enabled I have found the chance of staying locked to an incorrect fix is too high and so it is better to reset the filter.  This is a recent change and hasn’t yet made it into the released version of demo5 but I should get it out soon.  The current version of the demo5 code (b28a) does not reset the filter for either case.

Modifying the if statement in the existing code in postpos.c to match the line below will give you the newest behavior.  Removing the if statement altogether will cause the filter to always be reset and will match the release code.

combined6

The other factor to consider when deciding whether to run the filter type in forward or combined mode is that combined mode will take nearly twice as long to run since it is processing each data point twice.  Most of the time this shouldn’t be an issue since it is not being run in real-time.

So to summarize, my recommendation would be to use combined mode if you do not need a real-time solution as the only real cost is a small amount of additional computation time and it will give you both higher fix percentages and more confidence in those fixes.

Comparison of Swift Piksi Multi to u-blox M8T

 

I recently described an experiment in which I mounted a Tersus BX306 receiver and a u-blox M8T receiver on top of a car and collected simultaneous data while driving around in a parking lot and on residential streets.

In this post I will describe a similar experiment, this time with a Swift Piksi Multi receiver and a u-blox M8T receiver.  In the previous experiment, I had to use a CORS reference station as the base station for the Tersus receiver since I did not have a second full L2 receiver to use as a local base.  I do have two Swift receivers however, so in this experiment I was able to use matched local bases for both rover receivers.  The base receivers were both connected through an antenna splitter to a single dual frequency GPS500 antenna that comes in the Piksi evaluation kit and that was mounted on the roof of my house.

The two rover antennas were both mounted on top of my car.  The Piksi was using a Tallysman 3872 dual frequency antenna and the u-blox M8T was using a Tallysman 1421 antenna, the same antennas I used in the previous Tersus/u-blox experiment.

Here are the raw observations for both rovers, M8T on the left, and Piksi on the right.  Green indicates dual frequency measurements, yellow just a single frequency.  The red ticks indicate cycle slips.  The relatively slip-free region in the middle was collected in the parking lot with very open sky views.  The data before and after this region was collected on the residential streets with more obstructed views and hence more cycle slips.

u-blox M8T                                                                         Swift Piksi

swift_m8t2

As I mentioned before in my earlier description of the Piksi receiver, it uses the new civilian L2C code rather than the standard L2 code for the L2 measurements.  This code is only available on the newer satellites, right now about half of them support it.  Also, the Piksi firmware currently supports only the GPS satellites.  In this particular data set, four of the six GPS satellites were broadcasting L2C codes which meant the Piksi is working with ten measurements from six different satellites.  The M8T, on the other hand, with GPS, GLONASS, SBAS, and Galileo enabled had 19 measurements from 19 different satellites.  In both cases, since they were matched receivers, all measurements were available for ambiguity resolution.

Like the Tersus receiver, the Swift Piksi can only process solutions real-time, it has no capability to post-process data.   I configured the Piksi receiver to save the raw measurements to a USB drive on the receiver and to save the real-time solution in NMEA format to a PC connected to the rover over the serial port.  I set up NTRIP servers for the base stations  and used a hot spot on my cell phone for the real-time data link between receivers as I described in this post.  I then compared the Swift real-time solution to RTKLIB post-processed solutions of the Swift measurements and the u-blox measurements.  I also did run the u-blox solution in real-time and believe it was nearly identical to the post-processed solution I show here but unfortunately I overwrote the solution file with a post-process run so wasn’t able to compare them directly.  I did verify that the real-time u-blox solution had nearly 100% fix before I lost it.  I also tried to re-run a simulated real-time solution with RTKNAVI using the time-tag files but unfortunately it looks like some of the recent changes ported in from the release code have broken this capability.  I need to look into this further but it looks like while attempting to fix some existing incompatibilities in the tag files between the 32 bit and 64 bit versions of RTKLIB, the 32 bit version was broken.  In theory, the real-time solution and the post-processed solutions should be nearly identical, the only difference being the slight delay of the base data over the cell-phone link, so I don’t expect this to have a significant affect on the results.

Given that the M8T has nearly twice as many measurements to work with as the Piksi, I would expect the M8T results to be better than the Piksi and that indeed is the case.  The Swift internal RTK solution did a good job when the car was in the parking lot with nearly unobstructed views as you seen in the middle plot where the zigzag section is all fixed (green).  On the residential streets, the solution bounces back and forth between fix and float.  It is interesting that when the internal solution reverts to a float solution, it becomes quite noisy relative to the RTKLIB float solution as you can see in the z-axis.  The RTKLIB solution for the Piksi data is not as good as the internal Swift solution.  This may be a combination of an imperfect match of cycle-slip definitions between Swift and RTKLIB and RTKLIB not taking full advantage of the dual-frequency measurements.

swift_m8t3

I don’t think there were any real surprises here.  Until the Piksi receiver adds firmware support for the other satellite constellations and until more GPS satellites support the L2C codes, the Swift receiver is going to have difficulty matching the results of receivers with more measurements.  In the long-term, the L2C code is a good choice, especially for moving rovers because it is a stronger signal and a more robust code than using the encrypted L2 code, but in the short term I’m not sure I would recommend this receiver, at least for this sort of application.  It is still the least expensive dual frequency receiver available as far as I know, so it may still be the right choice for other applications.

Like my previous comparison, this was all based on a single set of data and is not intended to be a comprehensive analysis, more of a first impression.  If anyone disagrees with any of this or can add more details, please respond in the comment section below.

If anybody would like to compare the data themselves, I have uploaded the data and the config files I used to process the data to the “Sample Data Set” section of my website.

New code, new gps data

I’ve just released the b28 version of the demo5 code.  It includes all of the updates in the b28 update of the official RTKLIB 2.4.3 code.  It also now supports both Tersus and Swift low cost dual frequency receivers.  The Tersus updates were part of the official 2.4.3 release although I did make a few changes to fully support the L2 measurements as well as some changes to the makefiles to get all apps to build.  The Swift receiver support is based on code I pulled from the Swift RTKLIB Github page.  I suspect the receiver specific RTKLIB code for both receivers could use some improvements in translating from the raw binary formats to the Rinex/internal observation formats but at least this is a starting point.  The executables are available from the download section at rtkexplorer.com.  The source code is available on my Github page.

I’ve also uploaded some data sets comparing the Swift Piksi Multi and the u-blox M8T as well as between the Tersus BX306 receiver and the u-blox M8T.  This data is also available from the download section at rtkexplorer.com.

 

 

Tersus/M8T moving rover comparison

In my last couple of posts I compared a u-blox M8T single frequency receiver to a Tersus BX306 dual frequency receiver for a static rover using a fairly distant CORS receiver for base data.  Both receivers had over twenty raw phase measurements, but the Tersus receiver had much better overlap with the CORS receiver with twelve measurements available for ambiguity resolution (GPS L1 and L2) while the M8T had only six (GPS L1).  Not surprisingly, the Tersus provided a much better solution than the M8T.  I also compared the RTKLIB solution and the internal Tersus RTK solution and showed that they appeared to be roughly comparable.

In this post, I will add a second M8T receiver and compare a M8T to M8T short baseline solution to the Tersus to CORS longer baseline solution.  While this may not sound like a fair comparison, it could be a reasonable choice given that two M8T receivers are still significantly less expensive than one Tersus receiver.   Also, to make things more interesting,  I will use a moving rover this time rather than a stationary one.

For the experiment, I mounted both receivers in a car, each with it’s own antenna on the roof.  Given that we are making a comparison to a relatively expensive solution I felt it wouldn’t be unreasonable to add $20 to the M8T solution and upgraded its antenna from the standard $20 u-blox antenna I usually use to a Tallysman 1421 antenna available at Digikey for $42.   For the Tersus receiver I used a Tallysman dual frequency 3872 antenna which I believe is roughly a $200 antenna.  For the M8T base station, I used the same antenna on my house roof as in the previous experiment which gave a baseline less than 1 km for most of the M8T pair solution whereas the Tersus/CORS baseline was roughly 16-18 km.  For RTKLIB post-processing, I also ran a solution using base data from the nearest CORS station which gave a baseline of 7-9 km but I couldn’t use this data for the Tersus internal RTK solution because it is not available real-time.   Also, it should be noted that I collected all this data a few weeks ago before Tersus released their most recent firmware so it was all done using their previous version.

I chose a driving route very similar to the one I used for this M8N to M8T comparison in which I drive through a residential neighborhood with a moderate tree canopy.  This time I added a section of the route in a parking lot with no tree obstructions.  The parking lot is intended to be a low-stress environment and the neighborhood streets a moderate-stress environment.  Here’s a Google Earth image of the previous route to give a feel for the terrain.  Unfortunately this map feature no longer works in RTKLIB because Google has discontinued the API to Google Earth.

 

walker1

In this case the M8T  was receiving signals from the GPS, GLONASS, SBAS, and Galileo satellites and started the data set with a total of 21 phase measurements.  All of these can be used for ambiguity resolution since the two receivers are identical hardware.   The Tersus receiver measured only GPS and GLONASS but for all but a couple of satellites got both an L1 and an L2 measurement.  It started the data set with 24 phase measurements of which I would expect that only the 14 GPS phase measurements are available for ambiguity resolution because the receivers are not identical.

The previous time I ran this experiment I was able to get a nearly 100% fix solution from both the M8N and the M8T  receiver pairs but had to use some solution tracking gain (fix-and-hold) to achieve that.

In this case, with the extra Galileo satellites and the more expensive antenna, I was able to get nearly 100% fix using continuous ambiguity resolution instead of fix-and-hold. Continuous AR has the advantage of reducing the chances of locking to a false fix and is normally a preferrable solution if it is achievable.  The only float part of the solution was at the very end of the route where I parked the car underneath a large tree.

Here are three versions of the M8T receiver pair solution all run with continuous ambiguity resolution.  In all the plots, green is a fixed solution and yellow is a float solution.  The top left solution was run with 5 Hz measurements which is what I normally use for moving rovers.  I then realized that the Tersus data was only 1 Hz, so I re-ran the M8T solution after decimating the raw data down to 1 Hz (the latest Tersus firmware supports 5 Hz RTK solution).  The decimation can sometimes cause problems because the cycle slips aren’t always handled properly in the decimated data but in this case it seemed to work fine as can be seen in the plot on the top right.   The only noticeable difference is that the 1 sec data took a little longer to get to first fix.  This is less important in post-processed solutions because the solution can always be run in combined (forward/backward) mode which will usually get a fix for the beginning of the data.  This can be seen here in the bottom left solution which was run in combined mode.

ter_kin1

The zig-zag line from 21:22 to 21:26 is the lower stress circles in the parking lot followed by the moderate stress route through the residential neighborhood.

Next, let’s look at the Tersus solutions.  The internal Tersus RTK solution was run with the Tersus default settings.  The user interface for the Tersus console app is much simpler than RTKLIB so there are many fewer options to play with.  For most users this is probably an advantage because it avoids the rather overwhelming array of options that RTKLIB gives.   The RTKLIB solution was run with continuous ambiguity resolution with settings very similar to the M8T solution, just adjusted for dual frequency.  The internal solution is on the left and the RTKLIB solution on the right.

ter_kin2

The two solutions are fairly similar, both did well in the lower stress parking lot environment but struggled with the moderate stress on the residential streets.  The internal solution did a little better with scattered fixes in the latter part of the data.

Comparing differences between the internal and RTKLIB solutions and between the Tersus and M8T solutions for only the fixed points, it looks like most of the errors between the different solutions when they have a fix are small.  The Tersus/M8T differences are indicated by the distance from the circle as I have described before. I’m not too worried about the DC offsets between them.  It is somewhat tricky to get all the offsets correct and I did not spend a lot of time on that.  It is likely to be a issue with coordinate differences or handling of antenna offsets that explains the DC shifts.

ter_kin4

The above Tersus RTKLIB solutions were run with only GPS ambiguity resolution as I would not expect the GLONASS measurements to be useful for ambiguity resolution because of the inter-channel bias differences between the non-identical receivers.  However I was surprised to find that I did get fixes with the GLONASS ambiguity resolution set to “On” in the RTKLIB configuration file.  The solution was slightly worse than the GPS-only AR but I did verify that the GLONASS satellites were included in the ambiguity resolution.  I’m not quite sure what to make of this observation, whether or not it makes sense to include the GLONASS measurements in the ambiguity resolution, but I suspect it makes sense to leave them out for the reason mentioned above.

ter_kin5

I then ran another RTKLIB post-processed solution using the Tersus and base station data from a closer CORS base station.  This was to see how reducing the baseline affected the answer.  Here’s the result from a base station that is only 7-9 km away.

ter_kin6

Even though we reduced the baseline by a factor of two the solution only got slightly better and time to first fix actually increased.  This suggests that the long baseline may not be the primary reason for the poorer Tersus solution.

My suspicion is that it is a combination of two things,  at least for the RTKLIB solutions.  First of all I believe there is a mismatch between how RTKLIB interprets a cycle slip flag and how the cycle slip flag is defined in the Rinex spec.  The problem is that RTKLIB resets the phase bias estimate in the same epoch as the cycle slip is logged regardless of whether the receiver has had time to relock or not.  This can cause large errors in the bias estimates if the receiver flags a cycle slip before it has recovered from it.  In some of my earlier posts I have described having the same problem with the M8T receiver but in that case I have made some changes in the u-blox specific RTKLIB code to delay the cycle slips until the receiver has re-locked.  Something similar may need to be done for other RTKLIB receiver specific code  including the Tersus or it may be possible to modify the main RTKLIB code to better interpret these cycle slip flags.

Maybe more important, though, is the difference in the measurements between the two receivers.  As mentioned before, the M8T receiver has 21 phase measurements all of which can be used for ambiguity resolution while the Tersus has 24 of which only 14 can be used for ambiguity resolution assuming we don’ t try and use the GLONASS satellites.  Note, though, that there are only seven different satellite-receiver paths for the Tersus since each satellite is providing two measurements.  This compares to the 21 satellite-receiver paths for the M8T receiver where each satellite only provides a single measurement.  Now imagine that the receivers are under a partial tree canopy and four of the satellites are obstructed for both receivers.   The M8T will lose four measurements and still have 17 to work with but the Tersus receiver will lose 8 measurements and only have six to work with.  This is a significant disadvantage and I suspect can explain a large part of the difference in results.

If I had used a local Tersus base station, then the matched Tersus receiver pair would enable use of the GLONASS satellites for ambiguity resolution.  In the case of four obstructed satellites, the two cases would be much more similar with 17 available measurements for the M8T and 16 for the Tersus.  As more satellites were obstructed the M8T would start to gain a bigger advantage since the Tersus would lose two measurements for each obstructed satellite and the M8T would only lose one.  Of course the M8T would tend to have more obstructed satellites than the Tersus since it has more satellites to start with that can be obstructed.  That would work in favor of the Tersus reciever.  It’s hard to say which would give a better solution but my suspicion would be that if the cycle slip handling issue in RTKLIB was fixed the two solutions would be fairly similar when calculated with RTKLIB.  I don’t know enough about the internal Tersus RTK engine to predict how it would do.  Hopefully I can get my hands on a second full dual frequency receiver and run this experiment soon.

Although I ran this experiment at a random time without looking at the satellite alignment first, it may be that the satellite alignment was such that it accentuated this effect.  Note in the observations (Tersus on the top, M8T on the bottom) that the Galileo (Exx) and SBAS (Ixx) satellites have less cycle slips than any of the other satellites.

ter_kin7

Looking at the skyplot for those observations we see that three of the four Galileo satellites are at very high elevations which will tend to be blocked less from nearby trees. This would have helped the M8T solution since the Tersus receiver did not have access to these high elevation satellites.

ter_kin8

I will try to summarize what I think this data suggests but let me first emphasize that this is by no means intended to be any sort of rigorous analysis.  I don’t have the time, resources or knowledge to do that.  Instead, please take these as no more than the sharing of my thought process as I try to understand some of the differences between single and dual frequency RTK solutions.

Rover to CORS or other traditional dual frequency receiver:  Tersus has a significant advantage over the M8T both because of more matched measurements and opportunities to take advantage of the nature of the dual frequency measurements.  This advantage applies both to the RTKLIB solution and the Tersus solution although I suspect the Tersus solution takes better advantage of the dual-frequency measurements.  The advantage also increases as the baseline increases.

Matched pair of receivers with short baseline:  Good results with the RTKLIB solution will be limited to low stress environments for a pair of Tersus receivers because of limitations in the cycle slip flag handling.   With the M8N and M8T, RTKLIB can also handle moderate stress environments because of receiver specific changes in the RTKLIB cycle slip handling code.   Relative to a Tersus/CORS combination, the M8T matched pair solution will in general be superior for short baselines because of more matched measurements.

Matched pair of receivers with long baseline:  The data in this experiment doesn’t cover this case but as the baseline increases the dual frequency receiver pair should have a greater advantage because of the additional information that can be derived from the dual frequency measurements.

From a cost trade-off perspective, this suggests that the ideal way to combine these receivers might be to build the base with both an M8T single frequency receiver and a Tersus dual frequency receiver, both sharing a single antenna.  The rover would then be a second M8T receiver.  This would give the advantage of the dual frequency receiver for locating the absolute position of the base using long baseline solutions to distant reference stations or even PPP solutions while taking advantage of the matched pair of lower cost receivers for the moving rover piece of the solution.

 

RTKLIB with a Tersus BX306 dual frequency receiver

[Update 6/27/17:  There is a significant error in the data in this post.  I used the RINEX files from the CORS website for the base station data for the post-processing solutions described below. These contain only GPS data.  However, the real-time stream I used from UNAVCO for the same receiver contains GLONASS observations as well.  I did not realize this when I compared the Tersus real-time solution to the RTKLIB post-processed solution and concluded that the Tersus solution was better than the RTKLIB solution.  Once I re-processed the RTKLIB solution with the GLONASS measurements, the two solutions were much more similar.  See the following post for more details]

Last post I finished up by comparing some raw observation data collected from a moving rover with both Tersus and Swift receivers.  Before analyzing that data I will start with some static data collected simultaneously with the Tersus receiver and a u-blox M8T, both connected to a dual frequency antenna through a signal splitter.

I’d like to compare the RTKLIB solution for the Tersus data with the solution from the internal Tersus RTK engine as well as compare solutions for the Tersus data to solutions with the u-blox M8T data.  Since Tersus does not provide any post-processing tools I needed to run the experiment in real-time.  For the base data I used the closest available CORS station with real-time data access.  This was a GPS only station located 17 km from my home.  This makes it a fairly challenging exercise both because of the long distance between receivers and the small number of base station measurements.

The Tersus receiver does not offer a configuration setting for static or kinematic mode, it always assumes the receiver may be moving.  To put both receivers on equal footing, I also set up RTKLIB for a kinematic solution with continuous ambiguity resolution .  Therefore, although the rover was not actually moving, neither the internal Tersus RTK engine or RTKLIB knew this, and both treated it as if it were a moving rover.  To make the experiment more interesting, I intentionally obstructed the antenna view fairly severely every few minutes to simulate a rover passing under a heavy tree canopy or other obstruction.   I did this because I wanted to compare how well the RTKLIB and internal solutions recovered from losing a fix.

In addition, the location of the “rover” antenna was not ideal.  It was located on one edge of a low angle sloping roof.  This meant partial blockage from the roof as well as a few nearby trees and probable multipath from a few metal vents on the roof.  As always, I choose non-ideal conditions to add stress to the solution and make it more representative of real-world conditions.

Here are the raw observations, M8T above and Tersus below (yellow are single freq measurements, green are dual freq)

ter_static1

I show only the GPS observations since they are the only ones with matching observations in the base station data and hence the only ones that double differences can be calculated for.  At the beginning of the data set, the M8T has six GPS observations (all L1) and the Tersus has twelve (L1+L2).  The points where I obstructed the antenna are obvious in both data sets from the cycle slips.  The additional cycle slips seen in the Tersus data occur on the L2 observations for the most part.

First let’s look at the M8T RTKLIB solution.  With only six double difference observations and a 17 km baseline, the opportunity to resolve the ambiguities is just too limited and nearly the entire solution is float rather than fix.  In some similar data sets the solution may be better than this, but in general I find when using only the L1 GPS satellites there is very little margin and the results can vary tremendously from run to run.

ter_static4

 

Here are the solutions for the Tersus receiver.  Yellow/Green is the internal solution and Olive/Blue is the RTKLIB solution.  They are both significantly better than the M8T solution with fixes acquired reasonably quickly then broken by the antenna obstructions, followed by a re-acquire.

ter_static3

 

In this case having 12 double-differenceable observations to work with instead of 6 makes a huge difference, and for this particular comparison, there doesn’t seem any point in spending more time examining the M8T solution.

What is more interesting is the differences between the internal solution and the RTKLIB solution.   The Tersus advertises a 60 second time to first fix and most of the time, it achieved that easily even with the long baseline, significantly outperforming the RTKLIB solution which often took two minutes or more to recover. In the worst case however, (around 1:00 in the above plot), RTKLIB did significantly better than the internal solution acquiring a fix in just over two minutes while the internal solution required over eight.  I think this must be a glitch in the Tersus firmware.  For this excercise I used the new firmware just released last week but it does not appear to be perfect yet.  They acknowledge that they are still maturing the firmware and it should improve with time.  I don’t know what they are doing differently in their internal solution from the RTKLIB solution that gives them significantly faster re-acquire times, but if I had to guess, I would suspect that they are taking better advantage of the dual frequency measurements as I discussed in my previous post.

Here is a zoom in of the previous plot showing some of the higher frequency smaller amplitude differences.  I don’t believe the small DC offsets are significant, they most likely come from me not paying close attention to the various offsets in the setup.  Notice that the Tersus solution often loses fix momentarily where the RTKLIB solution stays fixed.  This may just be a more conservative approach in the Tersus solution to declaring a fix.  The momentary float values do not appear to add much error to the solution.

ter_static2

The above example was done with a fairly distant reference station to meet our requirement for real-time base station data. What if we don’t need real-time?  There are many more CORS stations available for post-processing than real-time so that often means being able to use a closer base station, maybe one that is more likely to have GLONASS satellites as well.  In my case, the closest CORS station is only 7 km away and does have GLONASS measurements as well as GPS.  The receivers are not identical so the GLONASS measurements can only be used for the float solution, not for ambiguity resolution, but they should still help some.  Here are the results using that base station.  Yellow/Green is the Tersus RTKLIB solution and Olive/Blue is the M8T RTKLIB solution.

ter_static5

Clearly more satellites and shorter baselines helps.  At this point the Tersus solution is still better than the M8T solution but the difference is not as dramatic.

So to summarize, this one example suggests that given the case of a single local receiver working with a distant reference station, there could be a significant advantage in using a Tersus dual-frequency receiver over a u-blox M8T single frequency receiver and that there is also an advantage in using the internal real-time RTK solution over the RTKLIB solution.  Part of this advantage is simply because the satellite set that the dual frequency receiver uses (L1+L2) better matches what is available from the reference stations and allows for more double difference pairs.

It would be unwise to conclude too much from this one example but hopefully it at least provides a little insight in how the two receivers and the two RTK engines differ.

So this example was a comparison between one dual frequency receiver and one single frequency receiver, both paired with a fairly distant base station.  In the next post I will compare a pair of matched local single frequency receivers to the same dual frequency receiver again paired with a fairly distant base.