LGT-92 integrations - ok with ttnmapper?

I recently wanted to integrate my LGT-92 with ttnmapper. However, the device payload seems to be missing crucial properties to make it work nicely with ttnmapper. The requirements as per the ttnmapper documentation are

  1. A JSON object containing the keys “ latitude ”, “ longitude ” and “ altitude ”. In addition the JSON object must contain one of the following keys “ hdop ”, “ accuracy ” or “ sats ”. Using a Payload decoder function the raw payload can be decoded into a JSON object with the required keys.

The LGT-92 payload provides neither altitude nor hdop, accuracy, or sats.

Can/shall I still use the ttnmapper integration? What are convenient altarnatives to quickly plotting the LGT-92 coordinates onto a map?

Yes the LGT-92 is missing the required information.

If you are on the flat land you could get the altitude information by the GPS of your phone and hardcode the altitude into the JSON object.
It’s the same with the other values. I had an accuracy of round about 15 meters with the LGT-92 with the 1.4 firmware but this should be better with the firmware 1.5.x which I test tomorrow.

I just updated my device to 1.5.1 yesterday and some minutes ago to 1.5.2. The new 1.5.2 firmware was uploaded on 27th December with additional bugfixes (not specified in the changelog - which is bad).

I still hope Dragino changes the LGT-92 firmware so the required details for TTNMapper will be included in the future. The “Quectel GPS L70 R” (which seems to be used in the LGT-92) should provide the required details in the NMEA 0183 data. In the documentation is reads “The default output message of L70 has the following six sentences: RMC, VTG, GGA, GSA, GSV and GLL.”.
The altitude is in GGA (including latitude and longitude) and the other details (HDOP, satellites) can be found in GSA.

I hope so, too. I already sent them a request to that effect and got some encouraging feedback from Edwin.

The firmware is open-source and I meanwhile also found this: https://github.com/dragino/LGT-92_-LoRa_GPS_Tracker/issues/4

What service/application do you use to plot the LGT-92 coordinates onto a map?

Those paremters, altitude, longitude, altitude, HDOP and number of satellites are all in GGA.

I’m pretty new to the LoRa topic myself but have 20 years of development experience in different languages.
Currently I don’t have any code to handle the data and put it on a map. I might write something small in the next couple of weeks using Java with an embedded webserver, so the data is shown on a map (at least the position with a popup info - using leaflet) when you point the browser to the embedded webserver. As I also need to download the data from the temporary storage so I first will start with this part (storing it in a PostgreSQL database with partitioning and as we have geo data I will also use the PostGIS extension = basically the database setup OpenStreetMap is using).

You are absolutely correct. The GGA sentence includes everything required, the GSA sentences also include details but are not needed.
I checked the firmware code at github today and saw a couple of requests which all make sense.This includes the “fall detection” event for old people. I worked several years at a university near research company where we had a “smart home for old people and persons with disabilities” where we also had a sensor for it (including an additional button for emergency calls). Combining it with the GPS sensor makes sense.

Back to the firmware topic. The gps.c class includes everything required as well (gps.altitude, gps.HDOP, gps.usedsatnum, etc.). I have to fully read everything but it seems to be doable preferable with some options to turn it on and of using AT commands (as also suggested in the issues/requests).

1 Like

Most of those GitHub issues are mine. Hopefully Dragino will take note as they’re more likely to be widely used than the fall detection.

If anyone wants to update the firmware I’d suggest issuing a pull request and seeing if they incorporate it. Sadly I don’t have time right now

Due to lack of TTN coverage I’m currently unable to test but myDevices/Cayenne looks really neat. LGT-92 is one of the plethora devices they support out of the box.

For TTN Mapper, you can control the minimum GDOP value for 3d position accuracy at which the device will decide to send a gps reading. Needs the very latest firmware.

I’m wondering if it’s reasonable in that case to send a hard coded HDOP to TTNMapper to ensure inclusion in the model. One for @jpmeijers

Have you tried sending messages to TTN Mapper that does not contain hdop? In general I would rather accept messages without hdop values, than ones with hard-coded values.

Scanning through this thread I believe it should have always worked as is.

Yes - it works without but I’m noting your comments on purging data without HDOP more often as its not as accurate.

Would it be useful to have a way to communicate what device we are tracking with or perhaps a minimum accuracy level we can pass? I’m thinking hardcoding for instance Tracker=Dragino and MinGDOP=***