Note: Explain for feature detail can be found in manual.
v1.5:
The v1.5 has a lot of change compare with the previous version. After upload to v1.5, user need to run AT+FDR to reset it to factory default for proper use.
*Add AT+FTIME to set GPS fix timeout
*Set location info to 6 decimal for higher accurancry, Payload structure change.
*Improve positioning accurancry by change the GPS fix logic.
*Support downlink command for change of : AT+CHE, AT+CONFIRM, AT+MD
*Add AT+LON to enable/disable LED flash.
*Add feature, so the tracker will send a uplink packet immedietely when Alarm is active.
*Add movement detect feature.
Test done today. I have two LGT92. One as ever work well and work well with the new firmware. The second LGT92, never find GPS data. And V1.5 don’t fix it. I know my second LGT92 is break about GPS.
I also own a LGT92 and it even finds GPS-signals indoor. Maybe there is something wrong with the GPS-antenna. If you know how to do just open the case and have a look at the antenna and its connection to the board.
I own a LGT-92 since two months. I also experience a terrible gps accuracy outside (using firmware 1.5); it gives me very often more than 100 meters error.
Is there an AT command to tell this device to only submit a ‘good’ gps measurement (ignore less reliable gps measurements) ?
well, my phone app navigation shows a red, orange and green gps ‘quality’ indicator icon. Probably the number of satellites used for the position calculation?
I only want to use something like those ‘green’ / good estimates to be transmitted by the lgt-92 , not low quality gps estimates made by a limited amount of satellites that gives me those 100 m errors. Would be great if that accuracy setting could be customized.
Hello @CABT & welcome to the forum. Please note that the language for the forum is English. If you feel you must post in your own language please also post in English …if in doubt GIYF
Thanks for the tip! Seems pdop default value is 3.0. So, now I just set a new value to 2.0 and let me see if gives better results.
Btw, I use the downlink payload to set new settings and could not find info about this pdop format. Found out from github AT+PDOP has downlink code AD and the message value must be multiplied by 10 before making it a 3 bytes hex
Since the update either latitude or longitude is always 0
Glad that i changed TTNMapper integration for the apllication into an experiment. The result looks strange.
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.
