meshtastic / firmware

Meshtastic device firmware
https://meshtastic.org
GNU General Public License v3.0
3.37k stars 825 forks source link

BUG: Invalid GPS positions when using UBX protocol #397

Closed a-f-G-U-C closed 4 years ago

a-f-G-U-C commented 4 years ago

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

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 commented 4 years ago

thanks for the great investigation and writeup!