We've had some reports of poor GPS accuracy in 2.9.1 as compared to 2.8.1.  This discussion is to debate, test, conclude and if necessary fix issues related to GPS accuracy in 2.9.1.

Views: 23442

Reply to This

Replies to This Discussion

I guess we should start off with those 2.9.1 users who have been affected clearing up what they suspect could be worse and then we can come up with some tests to prove that it's worse (or not) and then we can drill down on the issues.

So some things I've heard include:

  • We have GPS3d lock but the position is moving around more than it did under 2.8.1
  • GPS outages occur more frequently than with 2.8.1

Anything else?

Next we can design some tests maybe side-by-side tests or maybe one-after-the-other tests of the two versions of the code and also think of some ways to measure the performance.

"We have GPS3d lock but the position is moving around more than it did under 2.8.1"

This is absolutely true IME. Noticed it and commented on another aspect of this about how 3D lock was "not quite right" compared to 2.8.1. I could clearly see 3D lock being lost and regained when it never should have been lost (probably the same issue as the second bullet-point). This is for sure at the APM end and not at the GPS end...that's as far as I got.

But I also noticed that the final or ultimate position location was actually better than previously, at least around here in an area apparently very good for sat coverage. MTK 3329 w. 1.9 FW.

So there are pros and cons from my POV: accuracy improved, reliability decreased. For my location and use, I'd have to prefer reliability.

What I've found this weekend (Using APM2 with in built Mediatek)

The GPS accuracy in loiter was much better at 2.91 even with a fair gusting wind it held within 2m. When I played the Tlog back later I found the loiter was good but about 5 meters away from where I actually was loitering. Normally the Tlog would get the positioning very accurately.  I ignored the error as it was not important but I've since noticed that the position is off by a few meters when just standing in my garden.

I don't know if this is a red herring or actually of some help. I'm upgrading to APM2.5 this weekend so i'll report back with results from that with an Lea-6

Last wednesday I did a flight on arduplane and I only got 6 sats the entire 15 min flight.  Even if my apm  had been sitting for 20 min before the flight on the roof of my car with a clear sight of the sky.  Normally I get 10-11 sats.

Also gps position was moving around more then usual, My plane travelled about 80m in a minute while sitting on the carroof.  I flew anyway and the mission went just fine, but as I said is was with a plane.

Later in the evening I downloaded the onboard logs, and while doing this I got 8 sats in my house...

Maybe there were some bad solarflares this week ?


I have been using the latest ArduRover2 v2.30 code with the latest libraries. I took my rover chassis outside and placed it at the home position at the front of my drive way with a clear view of the sky. At that time I had my 3DR 915MHz telemetry working and I was getting 6 sats according to the HUD in the MP. After a while I brought the chassis back into the house and to my amazement the HUD began reporting 8 sats and a much more stable rover icon. Though I can usually get 8 sats inside, it usually takes a lot longer than walking from the front of the drive way and into the house. Interesting!



Aha.  So I wonder if the complaints about accuracy or reliability are all related to the Mediatek GPS?  There were some changes made to the mediatek drivers to add support for the 1.9 firmware.  There is one small part of that change that makes it slightly less likely to recover from a bad message.

OK, I think we should do a test with the very same mediatek GPS (and maybe we will try a UBLOX too) plugged into two separate APMs one running 2.8.1 and the other running 2.9.1 and see if 2.9.1 is failing to read the messages some times.  We would need to run the mediatek with the 1.6 firmware but it would still give us the reliability test..but not the accuracy test.

Because the APM actually sends some configuration data to the GPS on start-up we could repeat the test twice for each GPS, once with 2.8.1 sending the config info, once with 2.9.1 sending the config info.  We could check if the config data is the same but also perhaps check the overall accuracy of the two runs against each other.

Good idea...I'd do it or at least help if I had more than one APM. I have already gone back and forth between 2.8.1 and 2.9.1 and GPS 1.6/1.9  a few times so I know it's no big deal to do that (I thought it might be at first).

What I meant above by "ultimate accuracy" of the GPS being better now: I leave the quad sitting in a spot that I can pin down to +/- a couple inches 2D-wise in the google maps for a half hour. The only possible position error is because sat pic is not directly overhead (but close). The position shown in MP is usually dead-on these days, I've never seen it that good before, usually 3-6 feet (~1-2m) off was the best I could do previously. However the track in MP can be all over the place from the time 3D lock is first reported until the readings settle down, and this seems to take noticeably longer than before. Not a problem AFAIK, just something I noticed.


If I test my MediaTek V2 GPS in the Terminal CLI, it always starts the first line with MTK19. What is the significance of the "19"?




     You're using a mediatek right?

The 19 tells you that APM is using the gps library which supports the mediatek firmware version 1.9.  That library actually supports the older version of the mediatek firmware as well (1.6) so in fact it doesn't tell you much except that you're using a mediatek.

From checking with Tridge, who knows a lot more about the GPS code than I do, there are some other changes that came with the new Mediatek 1.9 firmware code:

  • The old 1.6 firmware had a lot more filtering internally and would actually lie about it's GPS lock status.  Even after losing lock it would carry on reporting that it had lock but extrapolate it's position based on the gps's last recorded ground speed and direction.  In one test with the old 1.6 firmware a team member walked from his front yard into his house which has a metal roof and doesn't allow him to get a gps lock.  Instead of the gps reporting that it had lost lock, it instead reported that he'd walked out the other side of his house, across his neighbour's yard and kept going.  After about 1 minute it finally lost lock and reported that he was about 500m away from his real position.
  • The new APM side of the gps library turns on SBAS.  This only matters if you're using the 1.9 firmware on the GPS and generally should improve the position estimate but in some places in australia it's rumored to make things worse because you might accidentally pick up the japanese SBAS information (Australia apparently doesn't have it's own SBAS set-up).

Still investigating but that's a little bit of extra info on this topic.


Yes, the version that shipped with APM 2.5 when it first came out i.e. smaller board without battery.

It has always worked quite well I thought (I added a battery and "tuned" ground plane), but better (your comments below) is always nice.

Reply to Discussion


DIY Drones Monthly


Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2016   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service