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.
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:
- Drotek UBlox Zed-F9P with dual-band antenna
– https://store.drotek.com/rtk-zed-f9p-gnss
– https://www.csgshop.com/product.php?id_product=265 - Hex Here+ GPS (based on uBlox M8P)
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:
Conclusion
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.
