bugfix: altitude parsing problem

[dronesalot]

Solved Problem

The NMEA format allows for multiple fix quality characters. The default implementation allows only 4 of these items to be parsed from the stream. When using a newer UM980 GPS unit, it supports 5 different types and causes the parser to mis-read the altitude message. This results in the GPS altitude jumping to 0 whenever a GNS message is received. This resolves the issue by ignoring any additional characters in the parsed message.

The PR also adds the ability to intrepret GLL messages from the GPS.

Fixes #23903

Solution

• fixes a bug in the NMEA parsing that is specific to newer GPS units

Changelog Entry

For release notes:

Feature/Bugfix Add parsing for the GLL message and fix a parsing bug in the GNS if posMode is more than 4 chars

[DronecodeBot]

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/um982-isnt-providing-heading-data/35195/29

[DronecodeBot]

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/local-position-dist-bottom-valid-toggling-issue/42326/4

[julianoes]

Thanks! Have you tested this with both the new and older version?

Or should I cross test with my UM982?

[dronesalot]

Thanks! Have you tested this with both the new and older version?

Or should I cross test with my UM982?

Not sure what you mean by older version.

I'm confident with the changes on this and any NMEA GPS receiver since the bug was the inability to properly parse a valid message that the UM98x will generated. I don't think testing with the UM982 is necessary since the fix was straightforward.

I have compiled and flown this with the 15.x branch, but not the 14. Unfortunately I keep missing the weekly developer meetings as it would be easier to describe and check in and present my future ideas for an updated parser.

[julianoes]

For next time, I'd do the rename of the fieldCount variable which is a refactor in a separate commit from the actual change/addition. That makes it easier to review and reason about.

I will merge this and add a few of my own fixes in another pull request. Would be good to get your testing on that too.

[dronesalot]

For next time, I'd do the rename of the fieldCount variable which is a refactor in a separate commit from the actual change/addition. That makes it easier to review and reason about.

I will merge this and add a few of my own fixes in another pull request. Would be good to get your testing on that too.

No problem with keeping refactoring in separate revisions. I can test your work if you like.

I've already gotten partway through a complete re-wite. So far, so good as it's less than 1/2 the size. Haven't figured out a good way to measure efficiency, but I'm going to guess at least 10x faster. When I have a pull request for that, the entire thing will be totally different.

[julianoes]

@dronesalot when you're rewriting this, you might consider that we want to pull it into PX4 as a separate driver, like it was done for Septentrio:

https://github.com/PX4/PX4-Autopilot/tree/main/src/drivers/gnss/septentrio