Further comparison between ComNav and u-blox RTK solutions

In my last post I showed that the new 3.6.5 ComNav firmware greatly improved the internal ComNav real-time RTK solution.  However there was still a significant discrepancy n the U-D axis results between the ComNav solution and an RTKLIB/M8T solution. Here are the differences between the ComNav internal solution and an RTKLIB solution for two u-blox M8T receivers connected to the same antennas as the ComNav receivers.  In this experiment, the base station was an antenna mounted on my roof and the rover was an antenna mounted on top of my car while driving around a residential neighborhood.

As you can see, the vast majority of the measurements in the horizontal axes (E-W and N-S) differ by less than two centimeters.  This represents the combined error of both solutions, the error in either solution by itself is smaller, so I consider this a good match.  In the U-D axis though, the two solutions often differ by over 10 cm.  The vertical errors will generally be roughly double the horizontal errors, but they should not be this large, so this warrants further investigation.

In the above plot, the errors are plotted as a function of time, and in this perspective, the errors appear to be a random drift.  I noticed however that the largest errors seemed to occur when the rover was most distant from the base, so I plotted the U-D error as a function of distance to base instead of time.  This is what it looks like plotted this way.

Clearly, there is a very strong linear relationship between baseline and error.   This immediately made me suspect an issue with coordinate systems.

I had previously seen a somewhat similar problem in the vertical axis when I had collected data from a sailboat and found that one side of the lake was nearly a meter higher than the other side!  In this case the issue was simply that the plots were in ENU coordinates which represent a plane tangential to the surface of the earth rather than a surface that followed the curvature of the earth.  The surface of the lake of course follows the curvature of the earth so will not appear as equal height when plotted on a flat plane.  With a local base station, the differences between the two tend to be small, but in my case I was using a fairly distant base which magnified the difference.

However, in this case, both solutions were saved in LLH coordinates, and although converted to ENU coordinates by RTKPLOT, any effect from the coordinate transformation should be equal for both solutions.   So that’s not the answer.

After a little digging into the ComNav documentation I found that it reports solution heights in geodetic height, not ellispodial height.  This means they are relative to a geoid model of the earth, rather than a simpler ellipsoid model.   The geoid model approximates a surface with equal gravitational force at all points.  The ellipsoidal model, on the other hand, is simply an ellipsoid that approximates the shape of the earth.  Of course, it would be too simple if there were only one ellipsoid model and one geoid model, and in fact there are multiple different versions of both types of models.  Fortunately RTKLIB and ComNav both default to using the WGS84 ellipsoid and the EGM96 geoid, so this simplifies things at least a little bit.

In RTKLIB, the solution height can be chosen to be outputted in either ellipsoidal or geodetic height using the “out-height” config parameter.  I usually set it to ellipsoidal height and that was what it was set to for this experiment, so this is at least part of the answer.  However, the geoid model and the ellipsoidal model differ by about 16.27 meters in my location, while the two solutions only differed by about 0.1 meters , so the explanation is a little more complicated than just changing this setting.

But first let’s start by doing that.  Here is the difference in U-D measurements after recalculating the RTKLIB solution with the “out-height” config parameter set to “geodetic”.

Interesting, with both solutions calculated in geodetic mode, the time varying error has disappeared completely, but now the DC offset between the two models (16.27 meters) has appeared instead!

This appears to be caused by how the two solutions interpret the base station location.  It seems that RTKLIB is interpreting the base station height as ellipsoidal regardless of the output format of the solution.  This seems reasonable, otherwise you would have to change the base station location when you changed the format of the solution.  ComNav, on the other hand, looks like it always interprets the base station height as geodetic, which isn’t wrong either, as long as you are aware of it.  I can eliminate the difference between the solutions either by specifying the ComNav base station location with geodetic height or, alternatively, the ComNav “UNDULATION” command does have a parameter to specify an offset to the geodetic model which probably would work as well.

So, with this change, I now have a very good match between two quite independent solutions.  The first solution is using ComNav receiver hardware and ComNav solution algorithms with GPS and GLONASS satellites using the L1 and L2 measurements.  The second solution is using u-blox M8T receiver hardware and RTKLIB solution algorithms with GPS, GLONASS, Galileo, and SBAS satellites using only the L1 measurements.   Although it is not impossible that there is some systematic error that affects both solutions, I do find it quite encouraging to see such good matches between two solutions with so many differences in inputs.

If you are interested in reading a more detailed discussion of the challenges of using geoid models in GNSS solutions as well as links to discussions of similar challenges with horizontal coordinate systems, see this article.

 

 

 

U-blox announces the F9 platform with L1/L2/L5 frequencies supported

https://www.u-blox.com/en/press-releases/u-blox-announces-u-blox-f9-robust-and-versatile-high-precision-positioning-technology

Improved results with the ComNav K708 receiver

In a recent post, I compared a pair of ublox M8T single frequency receivers to a pair of ComNav K708 dual frequency receivers.  For static rovers, the more expensive ComNav receivers showed a definite advantage with much faster times to first fix.  I was less impressed however with the ComNav results for a moving rover, especially since I have read several very positive reviews of the ComNav K501G receiver.  The K708 is supposed to be a newer model that is similar in capability and price to the K501G.

My comparisons of the internal ComNav real-time solution to an M8T RTKNAVI real-time solution showed very little difference between the two.  Digging into the data a little deeper, the results were actually more disappointing.  If I cut off the beginning and end of the data where the rover wasn’t actually moving, then the comparison between the two solutions looked like this, with the ComNav receivers on the left and the M8T receivers on the right.

Fix percentage for the ComNav receivers was 73.3% and for the M8T receivers it was 84.5%.  Comparing the two solutions where they were both fixed showed very little difference between the two so I think they were roughly equivalent in accuracy where they had a fix but the single frequency M8T solution was fixed a higher percent of the time.

I sent the results to ComNav and asked if they had any feedback or suggestions.  I got a very detailed answer in reply and a new firmware to try.  My receivers were running firmware version 3.5.7 and they had apparently also seen similar issues with this code.  They sent me firmware version 3.6.5 in a Windows executable form that made it very easy to upload to the receivers.

I then re-ran a repeat of the previous experiment comparing the two receiver pairs with a moving vehicle, shared antennas, and short baseline.  I was very pleased to see that the ComNav results were significantly better this time!  I actually had to deviate from my normal testing route to find some more challenging roads since I was getting near 100% fix rate on both the real-time internal ComNav solution and a RTKNAVI M8T real-time solution.  Fortunately I was able to find some narrower streets with larger trees that was able to differentiate the two solutions.  Here are both solutions for the full route, ComNav on the left, and M8T on the right.  The M8T solution was similar to the previous run with a 87.8% fix rate but the ComNav fix rate jumped to from 73.3% to 95.8%.

Focusing on the more challenging part of the route showed an even bigger difference with the ComNav fix rate at 90.0% (left) and the M8T fix rate at 61.1% (right)

Comparing the two solutions for the fixed points showed a good match everywhere outside of the most challenging area, so I don’t believe there were any significant false fixes in that part of either solution.  In the more challenging section there were a couple of what looked like false fixes in the M8T data, the longest one lasted for about 6 seconds.  They are visible as the shorter green blips on the right plot in the U-D axis.

Here’s a couple spots from Google map images that show what the more challenging environment looked like.  Of course, the leaves are off the deciduous trees now so it is a little less challenging now than when these pictures were taken.  I am surprised though that the differences between summer and winter are not as great as I would have expected.

 

 

 

 

 

 

 

Post-processing the M8T data using combined mode (running the kalman filter forward and backward over the data) does help some.  Running a post-processed solution this way increased the overall fix rate from 73.3% to 86.9% and eliminated any false fixes over 1 second.   Better, but still not as good as the ComNav solution.

Here is the difference between the real-time ComNav internal solution, and the RTKLIB post-processed M8T solution for the fixed points.  This is the combined error of the two solutions, so the error in each individual solution will be less than this.  The two solutions are quite independent given that they were computed with different software, measured with different receivers, and used different sets of satellites (GPS/GLO L1+L2 vs GPS/GLO/GAL/SBAS L1).    The E-W and N-S errors look quite small, the U-D error is a little bit larger than I would like to see, but it is difficult to know if this error is equally spread out between the two solutions or dominated by one solution.

I am not used to seeing this type of low frequency error in the U-D axis.  If I compare the U-D axis between the post-processed M8T and ComNav solutions (different receivers/different satellite sets) , I do not see this slow drift of +/-0.1 meters.  I’ve plotted it below. This makes me a little suspicious that it is coming from the ComNav solution but it is far from convincing proof.

(Note 2/26/18:  It turns out that this difference in the U-D axis is because the ComNav solution uses geodetic height and the RTKLIB solution in this case was set for ellipsoidal height.  The mean difference between geodetic height and ellipsoidal height cancelled out because the base location was specified in ellipsoidal height but the variation between the two still appears as error between the two solutions)

To process the ComNav raw observations with RTKLIB I had to make the same edits to the headers of the observation files that I described in my previous post.  This is to prevent RTKLIB from throwing away the L2C data.  After making these edits and running a combined solution on the data, I get this solution.

Unfortunately, with only 68.5% fix rate, this is not nearly as good as the ComNav internal solution.  I hope to investigate this further to see if there are any improvements to the config settings or to the code that might help.  For now, though, I would not recommend using RTKLIB to post-process raw ComNav data, at least for more challenging data sets like this.

However, if you can work with the real-time solution, then I will say that this was a significant milestone in that it was the first moving rover experiment where I have compared a low-cost dual frequency receiver to an M8T and found the dual frequency receiver to be significantly better!

I believe that ComNav sells software for post-processing their data so that might be an option as well for those that don’t want the limitations of real-time data processing.

That’s it for the general analysis.  For anyone interested in the details of the experiment setup I should mention a couple things.   I did describe the setup in more detail in my previous post and for most part the setup here was the same.  However, this time, I did change the default dynamics mode from “foot” to “land” using the command “rtkdynamics land”  This is intended for land vehicles with speeds up to 110 km/hr and seemed more appropriate for my experiment.  The manual says this setting is only for advanced users and recommends most users leave it at the default setting of “air” but my receivers seemed to default to “foot”.   Also, the command I used previously to set the rtk quality level, “rtkquality normal” has been changed in the new firmware to “rtkqualitylevel normal”.  This change has not made it to the user manual yet.   ComNav recommends leaving this set to “quick” for moving rovers and only using “normal” if needed to avoid false fixes for static rovers.  For this experiment I left it set to “normal”, mostly because I forgot about it before running the experiment.

The new firmware is not yet available on the ComNav website but they tell me it will be available soon.  In the meantime, you can email them to request it.