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
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’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).
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=***
From FW version v1.6.4 it is possible to get HDOP and ALTITUDE in order to be sent via webhook to ttn mapper. Through serial commands enable motion sensor for roll, pitch, altitude and hdop with:
Post above yours refers to V1.6.4 not the 1.4.4 you call out - is that a typo or do you needs to update f/w?
I use an LGT-92 at 1.52 as a regular work horse for TTNMapping and community coverage checks + Cayenne/MyDevices views (though that seems to have broken over last day or two! - just in process of deleting and re-registering to see if it fixes it)
Happy Mapping! (Note even 1.4.4. should be well able to contribute without updates/enhancements IIRC…be sure to set up correct decoder version to match your f/w version…)
UPDATE: After submitting I noticed reference to Tracker D vs original so comments may not apply in each part - there have been other threads wrt Tracker D on the TTN Forum tht may be worth visiting - Search is your freind
Thanks i just noticed that I was using Dragino TrackerD which has same casing as LGT-92. TrackerD does not provide altitude. I am using it with TTNmapper. Kind regards
(Note even 1.4.4. should be well able to contribute without updates/enhancements IIRC…be sure to set up correct decoder version to match your f/w version…)