If you are not using NMEA disregard.
I recently discovered what I think is a parsing error for the NMEA lat/long decimal minutes in the latest version(s) of the GPS library. I found this when doing van testing with 2.50 to check out the new IMU compensation. BTW, AHRS works great IF the magnetomer is working well (also something to keep in mind and you need to check magnetometer function before flying; also check that the 3 new gains at the top of the list are not zero).
Lat and Long jump about a minute at predictable locations. Interestingly, when the "#define WITH_NMEA_MODE 1" line is uncommented in AP_GPS_Auto.cpp the stock receiver shows the same issue. Also, when APM is restarted in a location known to have the problem, the problem goes away and nominal tracking occurs.
After reading several older posts (and one new one) it seems that some variation in sentences can be possible, problems have been seen with altitude parsing (fixed).... which pointed me to the parser and a compare for AP_GPS_NMEA.cpp with Arduplane 2.28 libraries that I know work with my Venus GPS. The code did get updated sometime after 2.28. I know 2.40 and 2.50 have the same code. I don't pretend to understand the code in this section, but I was able to merge 2.28 and pass van testing.
Point is, if you are using NMEA you should probably screen for this issue. Jumps of a km or so in position do bad things to heading to target. Of course this isn't a big deal if the plane is supervised.
Regards,
Larry G
Replies
Larry,
Thanks for this report. We made a code change suggested by one of the core developers to fix another NMEA issue..perhaps the two are related so I'll point that person at this post.
-Randy