Previously I collected some data with a pair of ComNav K708 receivers and compared the internal real-time ComNav position solution with a real-time RTKLIB solution from a pair of u-blox M8T receivers. The results showed, at least for the moving rover case, that the two were quite similar. In this post I will post-process the ComNav raw data with RTKLIB and compare the results both to the internal ComNav solution and the M8T post-processed RTKLIB solution . The ComNav receiver configured to sell for sub-$1000 is setup to receive only GPS and GLONASS L1 and L2 frequencies so this is how I ran this test. The M8T will also receive Galileo and SBAS satellites so I included these in the M8T solutions.
RTKLIB is not able to directly process raw binary ComNav data, but I had configured the receivers to output the raw data in RTCM3, then converted this to Rinex using RTKCONV, so this was not a problem.
Before we can get a solution however, we need to deal with the issue that the ComNav GPS L2 observations are a mix of L2 and L2C as seen in the RINEX observation data below.
RTKLIB handles multiple code types for the same frequency like this by choosing the code with higher priority as set in the code priority table in rtkcmn.c. Unfortunately this choice is made for the full data set, not each individual observation, so the lower priority observations are thrown out even for epochs when the higher priority code observations are not present. There is an option in the ComNav configuration to force all observations to L2 and this would have been one solution to the problem. However, in theory, the L2C code should be more robust than the L2 code, so using L2C when we have the option as the ComNav default setup does is probably the right choice.
I was not able to find any simple fix for the RTKLIB code or configuration that would allow it to process both observation types so I simply edited the list of observation types in the RINEX file headers and changed “C2X L2X S2X” in the list to “C2W L2W S2W”. With this change, all the observations are now described as L2 and none will be thrown out. It would be a problem if we were mixing L2 observations from the rover with L2C observations from the base, but since both will be consistently L2 or L2C, the differences should cancel, and this should not cause any significant errors in the solution.
I looked at three data sets, all from a moving rover with a local base station. The first data set is configured as described in my earlier post, with both the M8T and the ComNav rover receivers sharing the same antenna. In the second two data sets, the rovers are connected to separate antennas. I ran with continuous ambiguity resolution set and GLONASS ambiguity resolution enabled for all solutions. The only change I made from the default ComNav config settings was to change the “rtkquality” setting from “quick” to “normal” since I had trouble with false fixes when it was set to”quick”.
First of all, let’s compare the ComNav internal solution to the ComNav RTKLIB solution. Here’s the internal solution on the left, and the RTKLIB solution on the right. In this case RTKLIB had a little higher fix rate at 76.8% vs the internal solution at 68.8%.
What I found more surprising was that the internal solution did not stay fixed for the circles I drove in the parking lot from 23:37 to 23:40. Normally I rarely have trouble maintaining 100% fix for this part of the route since there are very few trees here and the sky views are almost 100%.
Here’s a comparison of the difference between the two solutions.
I expect the difference to be near zero for all fixed sections and for the most part this is true. There is an exception though between 23:32 and 23:33. I don’t have an absolute reference to compare to so I can’t be absolutely certain which is correct and which is in error. However I can compare to the M8T solution and in this case the ComNav RTKLIB solution nearly exactly matches the M8T solution so I am fairly certain that it is the internal ComNav solution that is wrong. This error is fairly large and is most likely caused by a false fix. Also, in general, the error in the U-D axis is fairly large in both cases relative to what I am used to, but is worse in the COMNAV internal solution. Below is the difference between the RTKLIB u-blox and RTKLIB ComNav solutions on the left, and the difference between the RTKLIB u-blox and internal ComNav solutions on the right, both for the U-D axis only.
Here is the M8T RTKLIB solution for comparison. Fix rate was 81.8%, just slightly higher than the ComNav RTKLIB solution.
One advantage of post-processing the data over a real-time solution is that solutions can be run in combined mode where the result is a combination of running the solution through the kalman filter forwards and backwards. Here’s the combined mode results, ComNav on the left, and M8T on the right.
In this case both solutions were near 100% fix. ComNav does sell post-processing software that would probably also let you do the same thing but I do not have a copy of it and don’t know how much it cost.
The results for the second two data sets with separate antennas showed similar differences to this one so I’ll include the plots here but won’t go into any detailed analysis. In both sets of plots, the left is the ComNav internal solution, the middle is the ComNav RTKLIB solution, and the right is the M8T RTKLIB solution.
The biggest difference in these two data sets is that the M8T results were slightly worse relative to the ComNav results than in the above example but this is most likely because the antennas were separate and I used a low-cost single feed L1 antenna instead of the higher performance dual feed L1 antenna I prefer to use in these comparisons. There is a good description here of why the dual-feed antenna should give better results.
It is always dangerous to conclude too much from a single experiment but this data does support what I have found in my other single frequency to dual frequency comparisons. For short baselines with a pair of matched receivers and moving rovers, an L1+L2 GPS/GLONASS solution tends to be similar in performance to a L1-only GPS/GLONASS/SBAS/Galileo solution. I expect this would be less true for longer baselines and stationary receivers.
rtklibexplorer 