How do pin the SF to a certain value on the LHT65? Have not found a clear answer in the manual. I have range problems and like to pin it to SF12.
SF12 significantly restricts the number of packets you can send a day, maybe 20 max ?
You have to disable ADR
AT+ADR=0
after that you can set the datarate:
AT+DR=5
Please consider the restrictions mentioned before by @LoRaTracker and @arjanvanb.
As the battery isn’t replaceable and SF12 sends for quite a long time you’ll transform your sensors worthless in a short time. So, what’s the matter with ADR?
Hello,
I have a Dragino LHT65, but I can’t connect it to Objenious network in France (Spot platform).
Is it possible?
Sounds like that is not The Things Network so may-be use another forum?
Hello,
I use two LHT65 with the TTN Indoor gateway.
I try different frequencies on the sensor. In all cases the packets are received and logged (TTN gateway page) by the gateway.
However, only packets received on channel 0 (868.1 MHz) are forwarded to TTN.
Is this a known feature?
If packets are listed on the gateway page they are in the TTN backend and have been forwarded to TTN.
Do you mean you are only seeing packets on that one frequency in the application page? If so, can you open the details and check the EUI of the gateway matches your TTIG?
This is most definitely not normal behavior for a TTIG.
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.