Servers by jDrones

Comparing a uBlox F9P with a M8P with RTK

Google Photos
This is a followup to the post from yesterday which compared a uBlox M8P and a uBlox F9P without external corrections. In this post I will compare the same two GPS modules but this time I have supplied high quality RTCM 3.2 correction data from a local NTRIP server (2.9km from the test location at my house).
The RTCM was injected using MissionPlanner to connect to a free NTRIP server that is part of the auscors network. Similar services are available in many countries all over the world.

Using MissionPlanner makes using an NTRIP server extremely easy, and the results are very good if you have a server close to the location where you are flying. The specific auscors server I used for this test was SYM14.
A NTRIP server works by providing access to realtime RTCM correction data from a high quality GPS base station, the same data you would get if you setup your own RTK base station, but much easier to use and avoiding the need to buy a separate RTK capable GPS to act as the base.
For this test I used the same test position as location 3 from yesterdays post. It is a location in my back yard, with moderate tree cover.
Google Photos
I chose this location not just because it is convenient for me (although of course it is!) but also because when I’ve previously done RTK tests I know it is boring to test a location with clear view of the sky in all directions. In such an ideal location RTK does extremely well, and you get constant results within a few centimeters no matter whether you use a newer dual-band GPS or an older single band GPS. What is much more interesting is to test how well the newer GPS performs when it has some significant signal obstruction and a few multi-path opportunities off buildings.

Test Setup

As for the tests yesterday, the GPS modules used were:

The two modules were connected to the same Hex CubeBlack running ArduPilot, with the M8P GPS as GPS1 and the F9P as GPS2.

Gaining RTK Lock

I deliberately ran the modules for 40 minutes without the RTK corrections to see how they were performing on the day and check it was similar to yesterday. Then I enabled RTCM data from the NTRIP server for nearly 5 hours before disabling the RTCM corrections for 20 minutes at the end to see the effect of removing the corrections.
You can see the whole test here with the altitude measured by the two GPS modules over time.

The left hand axis shows the AMSL height in meters. The right hand axis shows the GPS status, where 3 is an ordinary 3D fix, 5 is a RTK-Float solution and 6 is a RTK-Fixed solution. A value of 4 indicates a SBAS solution (that didn’t occur in my tests), but can also indicate a very poor RTK solution.
There are a few striking things in this graph:

  • the time when RTCM corrections are first supplied is extremely clear, with the altitude solution becoming a lot more consistent very quickly (within a few seconds). You can see that the F9P GPS goes to a RTK-Fixed solution immediately, whereas the older single-band M8P gets a less accurate RTK-Float solution.
  • after 20 minutes both GPS modules briefly go back to normal 3D fix. I suspect I had a short network outage at that time causing the RTCM stream to stop. More on that later.
  • for most of the 5 hour test the F9P kept a RTK-FIxed solution, whereas the M8P only occasionally managed a RTK-Fixed, but did keep a RTK-Float solution.
  • when I disable the RTCM stream at the end of the test the accuracy reverts to normal 3D fix levels one minute after the RTCM stream stops (both modules revert at the same time, indicating they must have the same internal timeout).

Now for the horizontal accuracy:

On the left axis we see the horizontal error in meters. On the right axis we have the GPS status (same as above). The improvement in accuracy of the F9P dual-band over the M8P is extremely clear both for the portion with a RTK fix and for the part without RTK.

RTK Fix Accuracy

Lets look more closely at the parts where both modules had a RTK fix. First altitude:

and now horizontal error:

For altitude we see the F9P changes around +/- 10cm whereas the M8P changes over about +/- 30cm.
The difference in horizontal error is even clearer. The F9P averages around 3cm horizontal error with a max deviation of 10cm. The M8P moves by about 1 meter.
I should note that the exact “correct” position was obtained using the 5 hour average of the F9P position as I don’t have any way to survey it any more accurately. It is quite possible that it had a systematic error, so really we can only infer how much movement we see from these results rather than absolute error. It is very clear that the F9P gets a much more consistent position than the M8P does.

RTCM Outage

The short network outage gives us a nice example of what happens if you stop feeding your RTK GPS the correction data it needs. It will keep a pretty good lock for about one minute, then revert to a normal 3D fix (or possibly SBAS fix if there is a SBAS satellite in view). This is one disadvantage of using a NTRIP service - if you have your own RTK base GPS then you are less likely to get an outage.
Let’s look at what happens on the outage with altitude:

On the outage both GPS modules revert to a 3D fix and their error immediately jumps up to the meter range. When the RTCM data is restored it takes nearly 14 minutes before the F9P gets a RTK-Fixed solution again, but it does get a RTK-Float solution quickly.
Now the horizontal error:

On loss of RTCM data we go to a 3D fix and the error jumps to over 1.5 meters. When RTCM data is restored we get a RTK-Float solution and error on the F9P quickly drops below 1 meter. After 14 minutes we get the RTK-Fixed solution on the F9P and the error drops sharply to a few centimeters.
So if you are relying on RTK GPS for precision landing then you really need to ensure your correction data stream is reliable. If what you are trying to do is mapping then using post-processed PPK is likely to be much more reliable.

GPS Reported Accuracy

Another important piece of data that a GPS gives you is the reported accuracy. A uBlox GPS will tell you the estimated accuracy in vertical position, horizontal position and velocity. These numbers matter as they are used for GPS blending weights in ArduPilot and inside the EKF (influencing the weighting of the GPS).
The uBlox has always been known as an “optimistic” GPS, with reported accuracies much better than what it actually achieves. I was interested to see if the F9P was the same.
Here is the reported horizontal and vertical accuracy for the uBlox M8P over the whole test.

On the left axis we have horizontal accuracy in meters (in red) and vertical accuracy in meters (in green). The number of satellites is on the right hand axis in blue. During the non-RTK part the claimed accuracy is a bit optimistic, by about a factor of 4x. This is common for a uBlox M8. Once it gets a RTK-Float solution it improves the claimed accuracy down to around 1 to 2cm, which is wildly optimistic given the solution varies by about 40cm.
Now the F9P:

The F9P claims accuracy of about 70cm vertically and 40cm horizontally when it doesn’t have a 3D fix. This is optimistic, but not quite as bad as the M8P. Once it gets a RTK-Fixed solution it claims an accuracy of 1cm, which isn’t far off in absolute terms from the real horizontal accuracy of around 3cm, but is still off by 3x as a multiplier. The lesson is that GPS reported accuracies need to be looked at with scepticism.
If we just look at the part of the data where the F9P has a RTK-Float solution you can see the optimism is as bad as the M8P. It reported both horizontal and vertical accuracies of around 5cm, but was off by about 60cm horizontally and over a meter vertically.

Speed Accuracy

The final accuracy that is reported is velocity, which is reported in ardupilot as GPA.SAcc (speed accuracy).
Here is the reported speed accuracy of the two GPS modules in m/s:

Interestingly the F9P reports around the same speed accuracy no matter what fix type it has, whereas the M8P claims much better speed accuracy when it has a RTK-Float fix.
Despite being less confident of its velocity estimate, the F9P did produce better results for speed. Here is the reported speed for the M8P in red and F9P in green (in m/s):

The F9P is clearly producing less noisy speed estimates which should translate into better position hold performance.
For vertical speed the F9P also wins, but not by as much:


The uBlox Zed-F9P is as big an improvement for RTK as it is for uncorrected positions. I suspect it is going to be very popular for anyone wanting precision flight.


Nice pics, graphs, and thx especially for comparing the self-reported accuracy of both receivers – this is very interesting.

1 Like

wow that was very informative.
I know zip about RTK and I apologize if this is a dumb question…But I am good at them. Can the uBlox F9p be used as a direct replacement for a standard GPS like a Zubax GNSS for instance.


Thank you Tridge very interesting,so in a nut shell if we buy the Dronetek Ublox Zed F9P and the antenna and use the NTRIP we have a very accurate system equal of RTK,all I can say is wow,maybe Tridge you could do a laymans wiki or point this daft old scotsman in the right directtion of setting up Ntrip,your A supper star

1 Like

Are you suggesting Marty that if I had a Zubax GNSS GPs I could just simply grab an F9P and have better performance.

1 Like

thanks Marty for the private message. I won’t worry about F9p for the time being.


Zubax uses m8 ublox chip, so yes you’ll get much better performances just switching over to f9 chip, both in normal use and in rtk use.

Hey @Corrado_Steri thanks for that.
Are you aware of any F9 based GPS that are readily available. I know sparkfun sells one but it needs a 3.3vdc supply and thats a little harder to come by on most UAV’s.

Many thanks for the work you’re putting into this @tridge .
You are answering many questions that have arisen over the Ublox claims on the new F9P.

1 Like

Note that a number of hardware vendors that sell ArduPilot compatible equipment are working hard on uBlox F9P based GPS modules. I think we will be spoilt for choice soon.
Right now I’m only aware of one (this one) that is in a form factor suitable for a moderately sized aircraft, but I’m sure there will be more soon. I have not tested that one myself either.


I am waiting for a uavcan implementation, possibly with a RM3100 compass :slightly_smiling_face:
Thank you @tridge for the great work.


Thanks tridge.
That seems a bit large. I have a Zubax now and it;s 55 mm x 55 mm and this one
is 70 x 70
So I will wait a bit but thanks. I am a fan.

1 Like

I think f9 gps will be a little bigger than the ones based on m8 because of the double freq antenna

@tridge @Corrado_Steri I had a Dronetek Ublox Zed F9P with me when I attended the Conference. It is smaller than the one from gsgshop and readily available. They also sell a RM3100 compass that I also have.
I did not test the RM3100 unit yet.

And then there is this one:


yep, that is the one I used. It is nice, but the need for an external antenna makes it a bit impractical for many aircraft, especially as they don’t sell an antenna for it suitable for a aircraft

yes, could be nice, it does depend a bit how it is priced though

1 Like

Thanks all.
Since this is new I will wait a bit before I jump in. It’s only a matter of time before the market is flooded with F9P GPS. Just a 70x70 format is very large and perhaps more then most uav’s can support.

1 Like

You might add a sheet of aluminum foil beneath your antenna to see if that improves the results. I noticed a 6 dB gain in signal strength when I put the Here+ base station antenna on a sheet of aluminum foil.


interesting! thanks for the tip

1 Like

Aluminium or copper foil ?
Some years ago I remember the use of copper foil

I believe copper is actually ideal, but aluminum foil is effective as well and everybody has it in their kitchen pantry. :slight_smile:

Servers by jDrones