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.