Comparing the u-blox F9P to the Comnav K803 receiver

In my last post I compared the internal u-blox F9P RTK solution to an RTKLIB demo5 RTK solution for a couple of cases, one with easy and one with moderately challenging conditions. In this post I will extend that comparison to some more difficult conditions, specifically under more dense tree foliage. To make things more interesting I will add a pair of ComNav K803 eval boards to the experiment.

The ComNav K803 is a relatively new module from Comnav that supports triple frequencies, L1, L2 , and L5. It is more expensive than the u-blox F9P at about $1000, but should have higher performance. ComNav generously gave me two of these boards for evaluation purposes.

As far as user interface goes, they are very similar to the older K501G or K708 ComNav boards and I was able to configure the K803 boards using RTKLIB command files very similar to what I previously described for the K708 in this post.

Here is a photo of the ComNav board on the left and the Ardusimple F9P board on the right. The ComNav board is inside a plastic case which is a nice feature. It is supposed to work with just the USB port for power and communication but I did not find this to be reliable and had to fall back to using the RS232 port with USB adapter for communication which is why the photo shows two cables for the K803. ComNav is aware of the issue and hopefully they will sort this out relatively soon.

In my previous experiment, I used a nearby CORS station for the base which limited the solution to GPS L1/L2, GLONASS L1/L2, and Galileo L1 and also extended the baseline to several kilometers . To take full advantage of both receivers available constellations and bands in this experiment, and to minimize the baseline, I used local base receivers for this experiment.

I used two Harxon geodetic GPS-500 antennas, one on the roof as base and one for the rover which was located on a tripod in an area underneath some moderate tree foliage. Both antennas were fed to an antenna splitter and then to an F9P receiver and a ComNav receiver. I tested three locations, each one further under the trees and so more challenging than the previous one. To avoid too much complexity in the experiment, I did not run a real-time RTKLIB solution but logged the F9P and ComNav raw data for post-processing.

Like in the previous experiment, I disconnected the antenna and then reconnected it multiple times to measure the time to first fix (TTFF) for both receivers. The plot below shows only the fixed epoch results for the first two locations. The F9P results are in green, and the ComNav in blue. The constant offset between the two is not real, I accidently configured the ComNav receiver to use a self-surveyed approximate position for the base location instead of an independently determined precise position.

Fix epochs for u-blox F9P (green) and ComNav K308 (blue) for location 1 and 2

In the first and least challenging rover location, both receivers performed well. The average ComNav TTFF was slightly faster, but both were below 20 seconds.

In the second location, both receivers were were still providing usable results but the ComNav receiver started to become noticeably better than the F9P. Average TTFF was 54 seconds for the F9P and 12 seconds for the ComNav receiver. In addition, the F9P had a couple of short false fixes and intermittent float after first fix that were not present in the ComNav data.

Here is the data for the third and most challenging location. Again, the F9P results are green and the ComNav results are blue.

Fix epochs for u-blox F9P (green) and ComNav K308 (blue) for location 3

In this case the differences were quite significant. The ComNav reliably found the same location on each re-acquire but more than 50% of the F9P fix epochs were false fixes, sometimes in error by several meters.

I also ran the RTKLIB demo5 solution with the same config settings as in the previous post. The results are below for the first two locations. The RTKLIB fixed epochs are in green and the ComNav fixed epochs are in blue. The performance at the first (least challenging) location was similar between RTKLIB and the F9P internal solution but the RTKLIB solution struggled with the second location and for the third location did not find any fixes except for a single short false fix. At least in these conditions it looks like there is still some room for improvement in the RTKLIB solution. However, it is also true that it did not get as much false fixes as the F9P solution which is important as well.

Fix epochs for u-blox F9P RTKLIB solution(green) and ComNav K308 (blue) for location 1 and 2

As in my other experiments, this is just a quick comparison of relative performance and is not intended to be any type of in-depth analysis.

To summarize the results, The u-blox F9P is a very capable dual-frequency receiver for easy to moderately challenging conditions, but for the most challenging conditions you will still get better performance from a more expensive receiver.

9 thoughts on “Comparing the u-blox F9P to the Comnav K803 receiver”

  1. Hi, I know this is a bit of an old post, but I was just wondering if you were using an f9p with the gps-500 antenna as the base, and then it was just the rover that had another gps-500 split to the f9p and k803?

    The question I’m looking to answer is would I expect to have this increased rover performance if I was using an f9p as my base?

    Like

    1. In my experiment, I was using both an F9P and a K803 receiver attached to the base antenna so I was comparing an F9P->F9P L1/L2 solution to a K803->K803 L1/L2/L5 solution. With a K803 rover and F9P base you would be losing the L5 signals in the solution but would still have the improved electronics and RTK processing in the K803, so I would expect a solution somewhere between the two.

      Like

  2. Hi, nice documentation and very informative. I always thought F9P is the best. I even compared it to top of the range Trimble receivers. For GIS type of applications F9P was unbeatable. In my region it can get a fix even inside tall buildings. Though I never tested at this detail for false fixes. For a CORS with GPS+GLONASS only you think K803 will perform well?

    Like

  3. In my opinion we for some use cases we are regressing if we accept hardware that can avoid rtklib entirely. I’m saying this from the perspective of very high reliability needed on surveying (<5cm error for sure but also practically never a false fix). That can be done to some extend on rtklib with an ratio thresh of at least ~4 (depended on other factors it may differ) but I keep hearing that those hardware solutions can have false fixes which can be unacceptable even if they are rare.

    Like

  4. Harxon GPS500 is a dual band antenna. Can it be understood that the K803 superiority does not come from its triple band capacity but from better electronic design than ZED-F9P?

    Like

    1. Hi Jean. Yes, you bring up a very good point that I neglected to mention in my post. I was concerned about using a dual-freq antenna with a triple-freq receiver but I did look at the C/No values of the L5 signals coming from this combination and they were very similar to the L1 and L2 values and did not show any other signs of lower quality (e.g. more cycle slips). I suspect the improved results of the K803 are due to a combination of triple frequency, better electronics, and better multi-freq solution algorithms, all things that you would expect in a higher cost receiver.

      Like

  5. Hello. There is a new firmware released (601A) for k803 a few weeks ago with substantial difference in performance. Is this the firmware used in this comparison?
    If not, could you please re-evaluated the performance of k803 based on the new firmware?

    Like

    1. Hi Atsimeri. I was not able to determine the version of FW on my K803 but I would assume it is not the latest. I searched online for the 601A firmware but was not able to find it. That said, in this experiment, the K803 performed extremely well so it would be difficult for it to improve its performance.

      Like

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.