My understanding of a gateway is that it forwards packets from the sensors to TTN.
I added the EUI of the gateway in the application settings, but without any effect. The packets that now arrive at the gateway on the frequency 867.5 MHz do not appear in the application.
The gateway forwards the packets to TTN, in the TTN console you can view those packets in the gateway part for the console of the gateways you own. Next TTN tries to match the packets with an application and forwards them if a match is found.
As you seem to be seeing packets in the application (please confirm) the application has been created correctly and the devices have been added correctly to the application.
In the application data you can view the uplink packets and their detailed data, I was asking to open the details and look at the gateways listed there. There should be one or more gateways listed with the gateway EUI.
Please delete the gateway EUI from the application as it is not needed there.
Things to keep in mind: you will only see data in the console that is received while the page is open. The TTN console does not list historic data (unless the data storage has been enabled for an application in that case the application page might show recent packets listed historic)
Both LHT65 have the same APP EUI A0 00 00 00 00 00 01 00. If I set the APP EUI on the LHT65 with the frequency 867.5 MHz to the value of the application, the data packets of this sensor are also displayed in the application.
Your LHT65 devices should be configured to use OTAA and 8 channels as delivered from factory, not 1 channel. Please reset the LoRaWAN configuration to use 8 channels to comply with the standard.
I have an lht65 connected to my ttn indoor gateway that is working fine, send the data to cayenne (my devices) and to the storage integration. I can see the messagebin the console and decode the payload.
The problem is when I try to move the lht65 away from my gateway… I live in Milano (Italy) and I drive around the city (taking a look at the network coverage) but I was unable to get the lht65 connected to the ttn network.
As soon as I returned at home It start again to send data.
Any idea?
thank you
First, hopefully you are not creating a new “connection” as in OTAA session during this, but merely experimenting within the existing connection. OTAA re-joins are something you want to avoid having happen on more than the rarest occasions of maintenance.
What spreading factor is your node running at? If you are using ADR, then when close to the gateway it would have adjusted to a fast, short range spreading factor such as SF7 or SF8. To work at a longer range it would need to be at a slower spreading factor. Given enough time, and ADR node would eventually slow down to this, but it might take a substantial number of hours (quite possibly more than a day) to make the adjustment.
Typically for mapping people will use a fixed spreading factor rather than ADR. Using SF12 even if it is legal in your location isn’t really considered proper unless achieved via ADR. Probably something like SF10 with brief packets several minutes apart would be good for range testing.
First, thnk you for the answer.
Of course I’m not creating new connection, but just moving the lht65 around the city.
How can I know the actual sf? and how can I change it?
Sorry but I’m nuwbie and just approching the technology.
thnk you
For the packets that get through, you would see this on the TTN console or in the metadata of a feed you were getting from it.
Most nodes would log it via a serial UART when they transmit, but if/how they do so is device unique.
This would be unique to your particular node. Look into its command set / source code and see what options are available to force a spreading factor rather than use ADR.
The lht65 has ADR enabled and will be instructed by TTN to adjust to a better spreading factor upon transmission of the first packet as it starts out at SF12. After a few days it will be set to minimized power consumption and highest transmission speed when used with a gateway close by.
Additional ‘issue’ is the build in antenna which is small to be able to fit the case.
This device is not particularly suited for mapping purposes. The lgt92 (battery powered version with external antenna) is a better option.
Thank you, so if the lht65 is in ADR I can try switch off my local gateway and wait if it’s get connected with another gateway in the city, correct?
Now the transimitted payload is “spreading_factor”: 7
Thankk you
Correct, but keep in mind in a city the average gateway will only cover 500m to 2km. So that only works if there is another gateway close to you. And ADR might take days to switch to a spreading factor where it becomes usable.
Switching of your gateway and restarting the lht65 would be a faster option. However if there is no coverage it can not join the network and will use more battery on join attempts.
ok, I’ll try, thank you so much
Hello, I’m just wondering if somebody can help me with Dragino LHT65 sensor connection. I use LPS8 gateway, which is set up in TTN console. The status is connected. I tried to register LHT8 however the status is not seen. I entered DEV EUI, APP EUI and APP KEY values that was on a sticker of a box.
The gateway shows in traffic some data under “join”. Also it shows the same APP EUI and Dev EUI that are supplied on a sticker of LHT65 box. I’m not sure where I stuck. Any ideas? Thanks,
So you have set up an application & registered the device, right?
When creating the App TTN will have auto generated an APP EUI. Have you used the manage EUI’s settings to add the one for your device to the available list and then selected that from the list for the device registration? (Example: As I highlighted to another user on this post Dragino LSN50 help - #12 by cslorabox) Does the Join Req you see in GW console data show your APP EUI as also shown in that linked example? Have you double checked the typing in of all the keys you listed?
Yes, I added APP EUI in manage euis and also deleted the one that TTN generated for me. Yes, GW console data shows my APP EUI. I triple checked the typing. Any other ideas?
If the devEUI and AppEUI match you have a typo in the AppKey. However validate the EUIs match by copy/pasting the information in the join request and in the device registration to a text editor to compare them, swapping to characters or mistaking a capital B and 8 is easily done. (Those kind of mistakes can happen to the AppKey as well, check it carefully)
Kersing and Jeff-UK, thank you so much, it is working now. I spent half of my day trying to connect that.
Kersing especially for you thanks again for pointing of mistaking B and 8. That was an issue.
Thanks again guys.
easily mistaken 
Not being 18 anymore I find it helpful to take a picture with my iPad so I can zoom in.
Glad you got it working.
I used a magnifying glass to see it was B instead of 8.
Thanks again.