GPS positional accuracy III


Hi all,

this is a short follow-up on my previous tests (I, II) with u-blox different u-blox M8 GPS modules.
This time I'll report about a survey campaign of several days with different copters and GPS. After processing the data I was surprised about the positional accuracy so I decided to share some numbers.

We used two copters running AC 3.3. One with an M8N and the other with an M8T GPS. The survey was conducted over a period of 4 days.

Six orthomosaics were overlapping:

Dataset   Day time
A         3   10:40
B         1   11:20
C         4   12:00
D         4   10:20
E         4   11:00
F         1   10:00

The orthomosaics were generated using direct georeferencing, i.e. without any RTK processing or ground control points. Hence, the final accuracy, or to be more precise the spatial offset between the maps, is a function of the accuracy of a single GPS and the image processing pipeline.

Since the flights were conducted over 4 days with different GPS and copter setups, the positional offset shows the overall GPS accuracy that can be achieved with M8 GPSs. The processing chain was the same for all datasets. However, there is for sure some influence as well. [I'll provide more details about image processing in my next blog post.]

Flight altitude was 50-60 m. Images were taken using a Canon S110. The size of the survey locations ranges form 5 to 25 ha (12-60 acre). The length of the entire area covered by the orthomosaics (from A to F) is 2.7 km (1.7 miles).

The maximum spatial offset between the orthomosaics is 1.2 m (3.9 ft). The average is 0.87 m (2.9 ft).

Overlay   Offset
A vs B    0.8 m / 2.6 ft
A vs C    0.6 m / 2.0 ft
B vs C    1.2 m / 3.9 ft
B vs D    0.4 m / 1.3 ft
D vs E    1.1 m / 3.6 ft
E vs F    1.1 m / 3.6 ft

Based on my previous tests I expected a much lower accuracy of about 2-4m maximum spatial offset. But it seems that both, the M8 GPS as well as the image processing pipeline, are pretty accurate and stable.

My next tests will be on RTK post-processing as well as the (promised) bench comparison between different M8 versions and antennas.

Best regards,

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones


  • @Simon,

    thank you for your reply.

    Could you explain me why RTCM2 or 3 is more efficient than raw data transmitted as

    Hex or ASCII ?

    RTK-Lib has already been implemented into Linux run microcontroller.

    I am developing all-software solution since GPS supporting RTBLib is priced $500+ ,

    not fit for $1000 drone.

    Ok, I need GPS ground control station since error correction feed brodcasted via Internet is subject to registration and other time-limited restrictions.

    Frankly speaking a new GPS protocol could embed GPS ionospheric error into

    raw data transmitted via each satellite of GPS system and such approach has been supported for years but correction data are encrypted, not intended for public use.

    GPS ionopsheric error in Australia amounted 5-10 metres in 24h cycle, so

    such GPS accuracy is not fit to control small drone.

  • @darius If you are really concerned about data rate/volume you could consider converting raw to a more 'efficient' format such as RTCM V2 or V3.

    I believe that RTK-Lib authour was looking to do this conversion, but carrying a 'PC' might be more than your payload allows. Maybe the conversion could be hard coded into a small micro.

  • @Michael - Swift Radioplanes

    Thanks for the information Michael, I'll give it a go.  Perhaps what I was reading they were referring to the SD card. It would be exciting if it does record RAWX, then after the GPS is post processed the GPS would have less error than timing errors.

  • @Thorsten,

    thank you, excellent GPS accuracy evidence.

    I have spent the last day and night studying  GPS L1 ionospheric error in Australia and I found GPS fix positional offset up to 8m as a rule in 24h cycle.

  • T3


    this is a screenshot of the image trigger locations:


  • @Thorsten,

    thank you

    So what is a size of single sample 

    and how does it affect post-processing accuracy estimation if you select 1Hz vs. 5Hz ?

    I was offered 1Hz - 25Hz switchable GPS unit

    Tried hard to get GPS binary protocol and failed what I get is Sirf binary protocol only.

    Prof. Takasu is busy with his RTKLib, no response yet.

    The only sample comes with his RTKLib.

    I just need to know if I select 25Hz GPS I get raw data refreshed and clocked every 1/25s

    or not.

    It may take me a week of study to estimate real ionospheric delay for the selected region.


    # links are not clickable since #suffix gets lost

  • T3


    have a look http://copter.ardupilot.com/wiki/arducopter-parameters/#raw_data_lo...

    It is 1Hz vs. 5Hz

    You need an M8T to record RAWX data.

  • @Adam - Swift Radioplanes,

    could you provide me with info on RAW data volume sent by RTK GPS ?

    In theory you can limit total volume enabling raw data every 10 minutes for 1 minute.

    I am studying now ionospheric contribution to GPS geolocation error for single-

    frequency unit, which ranges between 1m and 5m.

    I was offered to buy 2 RTK GPS set but not sure of data volume size to decide if radio or

    3G can handle it live.

  • T3


    Sure I'll post an overlay the next days


    Yes, as Michael du Breuil said (and implemented) it is possible for sure.

    @Michael Oborne,

    yes, sure! Still, I think it is amazing that the final product is that accurate.

  • Developer

    @Adam Kroll - Set GPS_RAW_DATA to 1 and you would be recording every RXM-RAWX message from the GPS to the uSD card. The uBlox driver automatically moves to a higher baud rate for communicating with the GPS when GPS_RAW_DATA is set to ensure that it has sufficient bandwidth (does require a restart to take effect). I've done multiple test flights with this setup and haven't had a problem. You do have to ensure however that you have a fast uSD card (at least a more perfomant one then 3DR provides) or you have to disable a lot of the other logging messages (which is the approach I took when logging).

This reply was deleted.