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