LGT-92 reports locations at 24.35°N, 24.35°E

[jpmeijers]

In the TTN Mapper database there are invalid measurements recorded from LGT-92 devices. These invalid measurements are reported at location 24.35,24.35.

Please use 0,0 as a placeholder location when the GPS does not have a fix.

[jpmeijers]

The same is happening at coordinates:

• 24.350000,24.350000
• 42.056000,42.056000
• 1.016666,1.016666
• 3.016666,3.016666
• 9.033334,9.033334
• 17.016666,17.016666
• 18.016666,18.016666
• -0.000001,-0.000001

Multiple devices are affected, pointing to an issue with this device model (hardware or firmware).

[tormodvolden]

Do you have any information on the firmware version reported in these cases?

On the LGT-92 firmware versions that I have tried (e.g. 1.6.5 which reports as "164") the no-fix value is (0,0).

[jpmeijers]

Unfortunately all I have to go on is the data users send to TTN Mapper, which does not include the firmware version.

It is likely that the issue reported here was the cause and that this is fixed now. But I'll keep an eye on this to make sure.
TheThingsNetwork/lorawan-stack#4668

[tormodvolden]

I see in the firmware source code that also all 0xFF's can be written to the coordinates payload, but I don't know in which case this goes over the air. It could very well correspond to your (-0.000001,-0.000001) data points. The fractional nature of your other numbers may suggest number interpretation of non-number data, which I guess could be related to your linked issue.

For the firmware version, actually only the minor version e.g. "4" is sent over the air. It is up to the payload decoder to add 150 or 160... So if you know the version already, you may get it right :)

[jpmeijers]

lgt92-tracker-2021-06-22to24.csv

Here an example device. Have a look at the data at:
2021-06-22 18:49:08.293574 +00:00
2021-06-22 18:49:08.293574 +00:00
2021-06-24 01:22:44.391936 +00:00
2021-06-24 01:22:44.391936 +00:00

I only receive the already parsed data from TTN, so there is no way to get anything else than what is in this CSV. Unfortunately I also do not own a Dragino tracker to do a test myself.

[tormodvolden]

I think I have solved this issue in the firmware in my branch at #34
The coordinates seems all clean now, whereas I previously had some odd values from time to time. In my case it was sentences like this:
$GNGGA,165040.000,,,,,0,00,25.5,,,,,,*7C
where the missing coordinates are empty strings which were mistakenly scanned with unchecked sscanf(), allowing uninitialized stack variables to be used for calculating "phantom" coordinates.