Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BUG: Invalid GPS positions when using UBX protocol #397

Closed
a-f-G-U-C opened this issue Sep 16, 2020 · 1 comment
Closed

BUG: Invalid GPS positions when using UBX protocol #397

a-f-G-U-C opened this issue Sep 16, 2020 · 1 comment
Assignees
Labels
bug Something isn't working

Comments

@a-f-G-U-C
Copy link
Contributor

a-f-G-U-C commented Sep 16, 2020

Describe the bug
Tbeam T22_V1.1 with Meshtastic (v1.0.0 and older) sends invalid GPS position messages to the network, when the NEO-M8N GPS is unsynced, ignoring the GPS FixType and PDOP readings.

To Reproduce

  • degrade the GPS signal by blocking the antenna
  • factory-reset the GPS
  • load the Meshtastic firmware and watch the messages in a terminal
  • as soon as the GPS starts returning non-zero lat/lon values, Meshtastic will accept them as valid and broadcast them to the network...
  • ...even though the GPS FixType is still 0, by Meshtastic's own admission.

Expected behavior
Meshtastic should respect the FixType and PDOP indications of the GPS and only broadcast positions that are the result of a valid GPS fix.

Additional context
Root cause is probably here:
https://github.com/meshtastic/Meshtastic-device/blob/b0c82dcb5b273b2394eb4244da1ff69f8b2dec57/src/mesh/MeshService.cpp#L295-L296
This assumption "!zero lat/long means valid" is false, as the UBX protocol returns transient non-zero lat/lon values during the acquisition phase, which are not valid for positioning purposes.
However, this conditional should probably not even exist in this form at the mesh protocol level, as the GPS class already provides the hasLock() function for this precise purpose (... I assume)

Replacing the condition above with:

    if (gps->hasLock()) {

fixed this problem for me. However...

REGRESSION WARNING
Haven't checked, but at a quick look, the fix may cause a regression in NMEA mode, as the NMEA code doesn't appear to properly implement the hasValidLocation flag. If that is the case, then this (untested) may help:

    uint8_t fixtype = reader.fixQuality();
    hasValidLocation = ((fixtype>=2) && (fixtype <=5));

Paste it somewhere inside this block, to ensure hasValidLocation is always up to date:
https://github.com/meshtastic/Meshtastic-device/blob/b0c82dcb5b273b2394eb4244da1ff69f8b2dec57/src/gps/NEMAGPS.cpp#L23-L25

@geeksville
Copy link
Member

thanks for the great investigation and writeup!

@geeksville geeksville self-assigned this Sep 16, 2020
@geeksville geeksville added the bug Something isn't working label Sep 16, 2020
@geeksville geeksville added this to To do in Meshtastic work via automation Sep 16, 2020
@geeksville geeksville moved this from To do to In progress in Meshtastic work Sep 16, 2020
@geeksville geeksville moved this from In progress to Done in Meshtastic work Sep 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
No open projects
Development

No branches or pull requests

2 participants