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:
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
I have logs from flying with 2.8.1 in the same general location. Would those logs help any?
Also, I'm going to try and upgrade the mediatek to 1.9 before I fly again. I don't foresee any problems but if I brick the mediatek can I add the ublox to the APM2.0 without problem? A non-functioning media tek will not interfere will it?
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.
You're using a mediatek right?
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.
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"?
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.