You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
andPDOP
readings.To Reproduce
Expected behavior
Meshtastic should respect the
FixType
andPDOP
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:
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: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
The text was updated successfully, but these errors were encountered: