My networklayer settings.
Repeated join requests means the node is not receiving the replies. Until the node successfully receives and processes the reply you will not see real data.
Can you connect to node to your computer as described in the manual to check the messages and firmware version?
I’m still digging that manual now…Seems that I need to order a “USB toTTL adapter to connect to LGT-92for using AT command” first before I can answer your question.
I saw in the corner of my eye the messages are changing:
16:06:34 Link ADR request enqueued
16:06:34 Link ADR request enqueued
16:06:34 Device status request enqueued
16:06:34 Successfully scheduled data downlink for transmission on Gateway Server
16:06:34 Schedule data downlink for transmission on Gateway Server Rx1 Delay 5 * info
16:06:34 Store upstream data message
16:06:34 Forward data message to Application Server MAC payload AF9B67016AB6621EB8CFB8
FPort 2 SNR -12.8 RSSI -119 Bandwidth 125000
That means the node has successfully joined and you should see received data in the application.
Turns out you really need to also buy the USB-to TTL converter, and Firmware Flashprogrammer for this device. In meanwhile I found out i have v1.6.0 firmware and then this should be the code, and should be uploaded under the “Upload” section of the Payload formatters:
//The function is :
function Decoder(bytes, port) {
// Decode an uplink message from a buffer
// (array) of bytes to an object of fields.
var latitude = 0; //gps latitude,units: °
if (bytes[0] !== 0) {
latitude = (bytes[0] << 24 | bytes[1] << 16 | bytes[2] << 8 | bytes[3]) / 1000000; //gps latitude,units: °
} else {
latitude = 0; //gps latitude,units: °
}
var longitude = 0;
if (bytes[4] !== 0) {
longitude = (bytes[4] << 24 | bytes[5] << 16 | bytes[6] << 8 | bytes[7]) / 1000000; //gps longitude,units: °
} else {
longitude = 0; //gps longitude,units: °
}
var alarm = (bytes[8] & 0x40) ? "TRUE" : "FALSE"; //Alarm status
var batV = (((bytes[8] & 0x3f) << 8) | bytes[9]) / 1000; //Battery,units:V
if (bytes[10] & 0xC0 == 0x40) {
var motion_mode = "Move";
} else if (bytes[10] & 0xC0 == 0x80) {
motion_mode = "Collide";
} else if (bytes[10] & 0xC0 == 0xC0) {
motion_mode = "User";
} else {
motion_mode = "Disable";
} //mode of motion
var led_updown = (bytes[10] & 0x20) ? "ON" : "OFF"; //LED status for position,uplink and downlink
var Firmware = 160 + (bytes[10] & 0x1f); // Firmware version; 5 bits
var roll = (bytes[11] << 8 | bytes[12]) / 100; //roll,units: °
var pitch = (bytes[13] << 8 | bytes[14]) / 100; //pitch,units: °
var hdop = 0;
if (bytes[15] > 0) {
hdop = bytes[15] / 100; //hdop,units: °
} else {
hdop = bytes[15];
}
var altitude = (bytes[16] << 8 | bytes[17]) / 100; //Altitude,units: °
return {
Latitude: latitude,
Longitude: longitude,
Roll: roll,
Pitch: pitch,
BatV: batV,
ALARM_status: alarm,
MD: motion_mode,
LON: led_updown,
FW: Firmware,
HDOP: hdop,
Altitude: altitude,
};
}
These examples I found here: Dragino Download Server ./downloads/LGT_92/
The example code on their support site seems to be somewhat screwed up. I needed to “fix” it.
A bit off topic. I received my lgt92 this week. It already had the latest firmware 1.6.5. I was able to join it to V3 without any problem.
But the GPS is terrible. My unit is a LGT92-LI-EU868, firmware v1.6.5 EU868, hardware v1.6.5, GPS ublox-MAX7. I have to set FTIME to 5 minutes to get location fixes when I have it in my car or around my neck outdoors. Indoors I never get a location fix. How is your GPS working, and what hardware version do you have?
I really just got it working v.1.6.4, don’t know hw version. But it seems to take a long time to get a location fix indeed, maybe that’s why the thing was so cheap 
I’m waiting for my TTL > USB so I can program the thing to transmit more the 1 times an hour and also enable or disable other sattelite services beside GPS then I know for shure.
Then my next challenge is to get the GPS values to Home Assistant, which does not work yet. If everything works, i’ll take a look for a unit with faster-GPS. The Things Network - Home Assistant
This only works with a certain hw version. The version I have with the ublox max7 does not support this. I was advised by dragino to set the pdop to 7, meaning it will fix faster but with a very large inaccuracy. I will try this later today.
By the way: some settings can be done using lorawan downlink, so you could alraedy try some of the settings without the need for the serial adapter.
Do you have an example script for changing a value via TTN downlink? Where to input it? If i’d know how to start I’d maybe can figure it out myself how do the rest with the manual.
GPS are like your lover, you can’t just turn them on & off on demand.
It takes 12.5 minutes minimum to download the almanac which is valid for a number of months - this gives rough positions of the entire satellite constellation and enables a warm fix which is typically 20 seconds.
So the almanac allows the GPS to have a good idea of what to ‘look’ for. Once it has a connection to a satellite, it can then start picking up the ephemeris for that satellite which holds data for the coming 30 minutes. This takes 30 seconds for each satellite once the GPS is receiving the satellite’s signal.
So the ephemeris allows the GPS to know precisely what to expect if it’s powered down and then re-queried in the next 29 minutes, giving a hot fix which could be a second but at worst could be 20s. Turn on 31 minutes later, it reverts back the almanac.
If the time between GPS queries is longer than 30 minutes, it will need a warm fix (20 seconds) and then 30s to download the ephemeris if you want that to hand (which you don’t if you are not going to ask for a fix again in the next 30 minutes).
GPS queries more frequently than 30 minutes will need to be on for 30+ seconds towards the end of your 30 minute sliding window so it can pick up the ephemeris. You can do what you like in the first 29 minutes, but if you want to be sure of a hot fix on minute 31, it will need time to download. Obviously this data is coming down all the time so it may have accumulated enough, but it’s very hard to tell without all sorts of arcane AT commands. Or just testing, try running the GPS for five seconds after you’ve got your hot fix and see how that fairs. The different chipsets as well as the antenna’s will all have different levels of success.
TL;DR: You can’t just turn on a GPS and get a good fix without letting it collect the data it needs.
5 Likes
In the user manual you can find the supported downlink commands. You need to convert it to Bas64 (online tool: Hex to Base64: Encode and decode bytes online - cryptii).
E.g.: the command to disable motion mode (so always do GPS fix at every interval) is A5 00. Converted to base64 this is pQA=. You can enter it through the Things webinterface:
This will be downloaded to the unit on the next time it reports itself to the network. I have found that you can only send one command at a time. (hence the replace downlink queue). Use Fport 2 and enable the confirmed downlink
Some other commands:
set 60s interval AQAAPA==
set 5 min interval (=default): AQABLA==
set motion mode off: pQA=
set motion mode 1 on (default): pQE=
3 Likes
And to make things easier for me I used Node-red and the MQTT interface to do all this in a more user friendly way. Also I use Node red to give me some nice graphs and tracking map.
1 Like
Where is this downloaded from? Is it coming with the GPS signal? Because I am very sure it is not downloaded over LoRaWAN.
In my tests I am doing a fix every 5 minutes. So this should result in a hot fix after the first time. But it doesn’t. It takes 3 to 5 minutes every time…
Yes - it would only come over LoRaWAN if you’d programmed the downlinks for that …
As it happens, most smartphones use A-GPS, A for Assisted, where they download the almanac & ephemeris data over the internet.
Have you previously left the device on for about 20 minutes with clear view of the sky. It’s not how often you fix or ask for a position, it’s how much the unit has time to do it’s job before it’s shut down.
The acid test for any GPS unit is outside where you can put your arm up at 55° and not point at anything substantial in the sky and leave it alone for about 30 minutes. That should get you 5 or 6 satellites minimum with about ±5m accuracy.
I have left it alone hanging outdoors for hours…
I now start to suspect it never fully downloads the almanac. To preserve power it goes into sleep mode right after it gets a fix and reports that over the LoRaWAN.
Yup, that’s what people do, seems very reasonable thing to do, but ends up with just fragments. The almanac is good for 180 days, so at least once every couple of months the GPS needs to run for 20 minutes with good view of the sky - so once you get a good fix, leave it be for 15 minutes.
Sometimes it’s worth powering up the GPS for 30 seconds every 25 minutes to get the ephemeris data so you always get a hot fix - although that needs refining if a satellite you have ephemeris data is out of view, which means the almanac is used to find the missing satellite - you need 4 for a goodish fix.
This may be a better power strategy than turning on less frequently but then needing more time to get the fix in the first place. Hmmm, something to try that I hadn’t thought of (mostly as I now have decent set of power monitors) to see if this is the case.
Summary:
First run for at least 15 minutes with good view of sky - this can be done pre-deployment on desktop power as long as the deployment zone is within 100km or so
Subsequent runs, hot fix as required but at least once every 25 minutes wait for a minimum of 4 satellites and let it run for 30 seconds from when you’ve got the 4th satellite.
If occasional fix requirements, ensure the GPS is on for 15 minutes once every couple of months to ensure it has a good clean copy of the almanac.
If the GPS has been dormant for a while (you will know this either via RTC or the reported time from the first satellite), then run it for 15 minutes so it has a good clean copy of the almanac.
Bear in mind that the ephemeris and almanac are moving data, so it can’t piece together yesterday pieces with todays.
That is something you can change to the GPS being on all the time IIRC. That will of course drain the battery fast(er).
@kersing @descartes you seem to think I have full control over how the unit behaves 
But I am using the Dragino LGT92 with the default firmware. I am a simple user that can just about manage to set the available AT commands. I am not able or capable to programm the unit in the ways you propose. Turning the GPS on all the time for instance is not a setting that is available with the factory firmware.
But if you are a software developer and would like to rewrite some of the code to test for yourself, you can. The firmware is open source: GitHub - dragino/LGT-92_-LoRa_GPS_Tracker: Software Source code for LoRa_GPS_Tracker
Yes it it is: AT+FTIME=0
Also depends on how you are using the device - if it’s for your own use, just run it with FTIME=0 once every two months for a full almanac, the rest of the time you can run with the default of 150 seconds.
Or find a programmer to alter the published source code!
2 Likes
Ah, I didnt spot that one. Will definitely give that a try.
Thx!