On the serial console the GPS Date seems to be valid
Roll=1.82 Pitch=3.03 Altitude:26.2M
[2117186]North: 52.xxxxxx
[2117187]East: 9.xxxxxx
[2117189]PDOP is 2.71
[2117189]Satellite: 6.10
It is a problem with the new payload decoder.
With the decoder for version 1.50 longitude can be decoded.
Edit:
I have modified line 56 to “if(bytes[5] !== 0)” and the Decoder for 1.6.4 works as expected.
Edit2:
I have made a second modification in the payload decoder.
In the “validation if clause” i have replaced the 0 value against “” like this:
else { latitude="";//gps latitude,units: ° }
Especially in Alarm (on button long press) messages the transmitted position was “Latitude”: 0.000000, “Longitude”: 0.000000 , a valid GPS Position.
The empty Value is not visualized on a map and for me a much better solution.
These low accuracy issues seem to happen often, but I wonder what these inaccuracies are being compared to as a source of truth? How do you know where you are and why it’s wrong? Something as simple as a map projection could be throwing these out by a long way. Unless you have a decent knowledge of how GPS technology works and spatial/mapping theory, I feel like a lot of these issues could be pointing towards projection and gps limitations that are worked around easily if you have a background in spatial science? Curious.
It’s not to complicated to achieve a good accuracy using GNSS. You need an antenna with a free view to the sky and some time. I have a GNSS L1, E1, G1 antenna on the roof and some uBlox M8 modules as receivers.
Using SBAS you can also increase accuracy. imho an accuracy of less than 2m horizontal and 5m vertical can be achieved with this equipment when measuring the position over a long time (a few hours).
But if you have to switch off the power of the GNSS-module for energy-reason as most LoRaWAN-modules do, this will influence the accuracy.
Yes engelking did replace that line. This comes from a change in byte length for latitude / longitude. If you compare the byte lengths in LoRa_GPS_Tracker_UserManual_v1.4.3 with newer versions you see there was a point in time where the lengths changed from 3 (1.4.3) to 4 (> 1.4.3). So bytes[4] was first byte of longitude and now is last byte of latitude. byte[5] is now first byte of longitude. The change works with my LGT-92 just fine.