[Bug]: When GPS lock is lost, position is still reported over MQTT with lat and long of 0,0.

[alandsidel]

Category

Other

Hardware

T-Beam

Firmware Version

2.2.21.7f7c5cb

Description

When a device acting as an MQTT gateway sends a position report for a node with a satellite fix, it looks as follows (JSON):

{
  PDOP: 191,
  altitude: 187,
  ground_speed: 1,
  latitude_i: REDACTED
  longitude_i: REDACTED
  sats_in_view: 8,
  time: 1708024383
}

However, if the device loses it's fix, reports are still periodically sent which look like this:

{
  latitude_i: 0,
  longitude_i: 0,
  time: 1708021680
}

I have not investigated protobuf output, only JSON at present, but the MQTT.cpp source file looks like it's doing the right thing as far as not including fields that aren't present in the protobuf.

This is causing some quality-of-life issues on the development end, as there isn't an immediate indication that the position is invalid, and in fact, 0, 0 certainly is a valid position, though a remote one unlikely but not impossible to be visited by mesh nodes.

My immediate thought for a solution would be to either suppress reports that do not have a GPS fix, or add a field to the payload to indicate that there is no GPS fix. The device knows there is no fix, as it indicates "No Sats" on screen 3 and "No GPS Lock" on screen 4.

I don't want to simply filter out results of 0, 0, or those without the sats_in_view key, as both of those could be legitimate reports from some current or future device. The issue is that the GPS fix status, which the device does know, is not being provided -- at least to MQTT in the JSON package.

Relevant log output

No response

[alandsidel]

I should add that while this is true:

the MQTT.cpp source file looks like it's doing the right thing as far as not including fields that aren't present in the protobuf.

It's possible the reverse may not be; there may certainly be fields in the protobuf that aren't being sent to MQTT, as the MQTT send function is hard coded to look for specific fields. If new fields have been added, or were missed initially, they may be in the protobuf and not the MQTT output.