# Dragino LHT65 and network coverage

**URL:** <https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434>\
**Category:** End Devices (Nodes)\
**Created:** [November 4, 2019, 7:19pm UTC](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434 "2019-11-04T19:19:09Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![LoRaWAN-Itzum](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/lorawan-itzum/32/25844_2.png) [@LoRaWAN-Itzum](https://www.thethingsnetwork.org/forum/u/LoRaWAN-Itzum)\
**Post date:** [December 22, 2019, 11:08pm UTC](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/21 "2019-12-22T23:08:26Z")

</div>

Recently I have got one Dragino LPS8 gatway and two LHT65 Sensors. I started them up at home near to the gateway and could finally connect both to the TTN. One mistake I made was to miss to put in the “APP KEY” beside the “APP EUI” and “DEV EUI” on the TTN Console. “APP KEY” and “APP EUI” are printed on the sticker inside the small carton box. So there is no need to reprogram the “APP KEY” to the one generated by TTN. You simply can overwrite it in the TTN console by the one from the sticker.

**Regarding coverage:** One of the sensors I moved arround 1km. I was disapointed about that it does not connect to TTN anymore. Today I think I found the reason for this in the specification lorawan1\_0\_2-20161012\_1398\_1.pdf. There is written “Adaptive Data Rate control may not be possible when the radio channel attenuation changes fast and constantly”. This likely happend to the sensor due to the move by car 1km far away from the gateway without any transmission (was set to 10min period).

With the second sensor I checked out the scenario by moving it to the cellar of my house. Same situation. In the logread of the gateway, I saw that the LHT65 was sending with spread factor SF7 and 14dBm (EU variant) before. This seems to be to less. After I restarted the sensor in the cellar by pressing the button \> 5sec it got connected with SF12. Sensor back in the first place, the SF went back to SF8. So adaption works fine in this direction.

In case there was already a connection to TTN and the attenuation is changed rapidly, activate the device again.

---

<div class="post-metadata">

**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\
**Post date:** [December 23, 2019, 9:57am UTC](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/22 "2019-12-23T09:57:29Z")

</div>

> [@LoRaWAN-Itzum](#):
>
> So there is no need to reprogram the “APP KEY” to the one generated by TTN.

Very true. But just curious: did you get the same non-unique AppEUI `A000000000000100` like the others in this topic? Also, I’m starting to wonder if people get different values for the AppKey…

---

<div class="post-metadata">

**Author:** ![LoRaWAN-Itzum](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/lorawan-itzum/32/25844_2.png) [@LoRaWAN-Itzum](https://www.thethingsnetwork.org/forum/u/LoRaWAN-Itzum)\
**Post date:** [December 23, 2019, 10:43pm UTC](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/23 "2019-12-23T22:43:58Z")

</div>

I have got the same AppEUI `A000000000000100`. This looks to be ok. See: [Addressing and Activation](https://www.thethingsnetwork.org/docs/lorawan/addressing.html). I do think that the application is the LHT65 itself.

Unfortunately my **coverage issue** could not be solved by activation of LHT65 (placed outdoor in a wooden beehive) once again, 1km far away from my indoor Dragino LPS8 gateway (placed in 2. floor under the roof top made from concrete roof tiles). This is not that far away, isn’t it? The area is a standard settlement with houses in the same height as my one.

I am at a loss. Does anyone know, how to improve the range (beside outdoor gateway or antenna)? Is it that [Over-the-Air Activation (OTAA)](https://www.thethingsnetwork.org/docs/lorawan/addressing.html#over-the-air-activation-otaa) is not possible on that range and I should try [Activation by Personalization (ABP)](https://www.thethingsnetwork.org/docs/lorawan/addressing.html#activation-by-personalization-abp)? Any experience with simliar setup would be helpful as well 😊

---

<div class="post-metadata">

**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\
**Post date:** [December 24, 2019, 5:07am UTC](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/24 "2019-12-24T05:07:50Z")

</div>

> [@LoRaWAN-Itzum](#):
>
> I have got the same AppEUI `A000000000000100`. This looks to be ok. See: [Addressing and Activation](https://www.thethingsnetwork.org/docs/lorawan/addressing.html). I do think that the application is the LHT65 itself.

No, it’s not okay: an application is not defined by a device type. Even a single customer should be able to define multiple applications using the very same device types. Also, this is not even a valid AppEUI, and who knows if Dragino or another manufacturer isn’t using the very same AppEUI for another device type. See [my earlier answer above](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/12).

That said, it’s nice, and weird, that this works for some of you (at least with the current version of the TTN stack) while others needed to change the AppEUI to get things to work. I’d not risk having to fix this later though, and I’d give the devices a proper AppEUI before deploying them.

As for coverage: the activation method does not matter. if ABP works but OTAA does not, then such only implies that uplinks work but downlinks don’t, or not that well. In that case ADR would not work either (and you’d need to explicitly program basic network settings as well). Also, just to be sure you know: [you should not do an OTAA join very often](https://www.thethingsnetwork.org/forum/t/how-often-should-a-node-do-an-otaa-join-and-is-otaa-better-than-abp/11192), and [once joined there’s no difference between OTAA and ABP](https://www.thethingsnetwork.org/forum/t/otaa-then-abp/12377/5).

Maybe [Gateway queries & ranges](https://www.thethingsnetwork.org/forum/t/gateway-queries-ranges/11215) helps, but it’s a long read.

---

<div class="post-metadata">

**Author:** ![tom-iotexperts](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/tom-iotexperts/32/35697_2.png) [@tom-iotexperts](https://www.thethingsnetwork.org/forum/u/tom-iotexperts)\
**Post date:** [December 24, 2019, 11:32am UTC](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/25 "2019-12-24T11:32:07Z")

</div>

@VictorMarinus are you happy with the sensing of the device, accuracy ? What temperature range are you measuring ?

---

<div class="post-metadata">

**Author:** ![LoRaWAN-Itzum](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/lorawan-itzum/32/25844_2.png) [@LoRaWAN-Itzum](https://www.thethingsnetwork.org/forum/u/LoRaWAN-Itzum)\
**Post date:** [January 6, 2020, 9:22pm UTC](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/26 "2020-01-06T21:22:04Z")

</div>

Thank you @arjanvanb for your support. I read [Gateway queries & ranges](https://www.thethingsnetwork.org/forum/t/gateway-queries-ranges/11215) and also came across [The BIG and SMALL ANTENNA topic part 1](https://www.thethingsnetwork.org/forum/t/the-big-and-small-antenna-topic-part-1/7880/33) and [The BIG and SMALL ANTENNA topic part 2](https://www.thethingsnetwork.org/forum/t/the-big-and-small-antenna-topic-part-2/15419).

Conclusion for my issue is, that there is only the solution to replace the antenna. Currently I am looking for a collinear antenna with 1,4m height, e.g. [DELOCK 12504 (LoRa, Outdoor, N-Buchse 8 dBi)](https://www.reichelt.de/delock-antenne-lora-outdoor-n-buchse-8-dbi-weiss-delock-12504-p216253.html) and to connect it by 3m CFD400 cable [DELOCK 13021 (WLAN Kabel, N Stecker, RP-SMA Stecker)](https://www.reichelt.de/wlan-kabel-n-stecker-rp-sma-stecker-delock-13021-p178697.html) and [SMA-REV-Adapter](https://www.reichelt.de/sma-rev-adapter-sma-rev-bu-auf-sma-st-sma-rev-bu-sts-p79094.html) to the LPS8 indoor Gateway. Currently I do not want to install it as outdoor antenna because of high effort for lightning protection.

I would be happy about any comments on the selected parts and other alternatives (available in Germany). Thank you!

---

<div class="post-metadata">

**Author:** ![LumpiStefan](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/lumpistefan/32/35697_2.png) [@LumpiStefan](https://www.thethingsnetwork.org/forum/u/LumpiStefan)\
**Post date:** [April 13, 2020, 5:39pm UTC](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/27 "2020-04-13T17:39:40Z")

</div>

Hello Guys.  
It will be great if you‘re able to assist me as well. I‘m running a Dragino OLG-02 and I have 3 Dragino LHT65 Sensors.  
The gateway is Running properly and is listed in the TTN as online. When I try to connect a LHT65 sensor, i do not geht valid data.  
In the console i can see Device traffic, but just „Join request“ and „Join accpet“. No other data.  
For the application i can see for that sensor just activation packets…  
What is Running wrong and how can I fix it?

Regards  
Stefan

---

<div class="post-metadata">

**Author:** ![LoRaTracker](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/loratracker/32/48502_2.png) [@LoRaTracker](https://www.thethingsnetwork.org/forum/u/LoRaTracker)\
**Post date:** [April 13, 2020, 5:58pm UTC](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/28 "2020-04-13T17:58:49Z")

</div>

> [@LumpiStefan](#):
>
> Dragino OLG-02

Do you mean the LG02, if so;

Thats not supported for use on TTN, this is on the Web page for the LG02;

**For Private LoRa Protocol, Not recommend for LoRaWAN use.**

---

<div class="post-metadata">

**Author:** ![LumpiStefan](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/lumpistefan/32/35697_2.png) [@LumpiStefan](https://www.thethingsnetwork.org/forum/u/LumpiStefan)\
**Post date:** [April 13, 2020, 6:11pm UTC](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/29 "2020-04-13T18:11:28Z")

</div>

I know, that this gateway is not optimal, but isnˋt ist enough for some testing?  
Do you think, the gateway is causing the problem? What will be a cheap alternative device for europe frequency? As i only want to connect 3 sensors it must not be that „Professional“. Sadly there is no other available gateway that can be used by me.

---

<div class="post-metadata">

**Author:** ![kersing](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/kersing/32/44777_2.png) [@kersing](https://www.thethingsnetwork.org/forum/u/kersing)\
**Post date:** [April 13, 2020, 6:13pm UTC](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/30 "2020-04-13T18:13:54Z")

</div>

> [@LumpiStefan](#):
>
> Dragino OLG-02

That is not a LoRaWAN gateway.

> [@LumpiStefan](#):
>
> but just „Join request“ and „Join accpet“.

After the accept you node will use any of 8 channels and one of the possible spreading factors within that channel. Chances of that combination matching your non compliant gateway which listens at far fewer channels and spreading factors are about 2 percent.

---

<div class="post-metadata">

**Author:** ![kersing](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/kersing/32/44777_2.png) [@kersing](https://www.thethingsnetwork.org/forum/u/kersing)\
**Post date:** [April 13, 2020, 6:15pm UTC](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/31 "2020-04-13T18:15:10Z")

</div>

Get a TTIG (the things network indoor gateway) or LPS8 from Dragino.

---

<div class="post-metadata">

**Author:** ![LoRaTracker](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/loratracker/32/48502_2.png) [@LoRaTracker](https://www.thethingsnetwork.org/forum/u/LoRaTracker)\
**Post date:** [April 13, 2020, 6:31pm UTC](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/32 "2020-04-13T18:31:24Z")

</div>

> [@LumpiStefan](#):
>
> I know, that this gateway is not optimal, but isnˋt ist enough for some testing?

No.

Appreciate the problem, these devices are not LoRaWAN compliant and the manufacturer does not recommend them for TTN use.

When powered up they can disrupt the connections of compliant nodes, you may not know the problems you are causing.

So given that, how likely is it that the TTN forum will now publish information or provide support to get them working ?

---

<div class="post-metadata">

**Author:** ![LumpiStefan](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/lumpistefan/32/35697_2.png) [@LumpiStefan](https://www.thethingsnetwork.org/forum/u/LumpiStefan)\
**Post date:** [April 16, 2020, 11:02am UTC](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/33 "2020-04-16T11:02:01Z")

</div>

I just want to give a short update. I´ve replaced the gateway by a Dragino LSP8 as suggested. That solved my problem. Sensor is no sending data.  
Thanks for your support…

Stefan

---

<div class="post-metadata">

**Author:** ![weradis](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/weradis/32/45845_2.png) [@weradis](https://www.thethingsnetwork.org/forum/u/weradis)\
**Post date:** [May 6, 2020, 7:18am UTC](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/34 "2020-05-06T07:18:45Z")

</div>

No sure if this is the right topic, but it does concern a LHT65. I received two pieces and connected with success however I do see something strange happening. One unit started to receive downlinks after 64 successfull uplinks. The downlink seems an empty message targeted for port ‘0’. The other LHT65 is not receiving these downlinks. There is nothing in the visible downlink queue … what to do, I expect these downlinks to have negative impact on the battery life.

---

<div class="post-metadata">

**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\
**Post date:** [May 6, 2020, 7:53am UTC](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/35 "2020-05-06T07:53:48Z")

</div>

> [@weradis](#):
>
> One unit started to receive downlinks after 64 successfull uplinks. The downlink seems an empty message targeted for port ‘0’.

That’s ADR and is telling your device to change its settings. Assuming the device is handling it, it might actually improve your battery life. See [What are these port 0 downlink messages?](https://www.thethingsnetwork.org/forum/t/what-are-these-port-0-downlink-messages/22330)

But if the device keeps getting the same downlink over and over again, then something is wrong. It might not receive the downlink, it might not process it, or it might be using ABP (or OTAA, with last join before October 2019) [for which TTN has a bug in some fallback](https://github.com/TheThingsNetwork/ttn/issues/767#issuecomment-599450573).

---

<div class="post-metadata">

**Author:** ![shinebar](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/shinebar/32/35697_2.png) [@shinebar](https://www.thethingsnetwork.org/forum/u/shinebar)\
**Post date:** [May 6, 2020, 7:59am UTC](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/36 "2020-05-06T07:59:36Z")

</div>

Concerning the Spreading Factor: On my devices I disabled ADR. as it burned the battery by a staircase effect. In a quite regular interval the SF got up to 12 and then back to 7. Tested this with two devices in 10m distance to the gateway, so reception wasn’t a problem. Just pinned the SF to 7 and now everything is fine. Anybody else with this problem?

![image](https://www.thethingsnetwork.org/forum/uploads/default/original/3X/9/c/9cda7ae1993c53c57da1e499c9287d80b07b61bc.png)

---

<div class="post-metadata">

**Author:** ![weradis](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/weradis/32/45845_2.png) [@weradis](https://www.thethingsnetwork.org/forum/u/weradis)\
**Post date:** [May 6, 2020, 8:16am UTC](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/37 "2020-05-06T08:16:19Z")

</div>

Thanks Arjan, TTN keeps sending these messages for just the one device, so something must be wrong. Devices are using OTAA without any issues …

---

<div class="post-metadata">

**Author:** ![bl00dy](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/bl00dy/32/36752_2.png) [@bl00dy](https://www.thethingsnetwork.org/forum/u/bl00dy)\
**Post date:** [June 5, 2020, 11:53am UTC](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/38 "2020-06-05T11:53:29Z")

</div>

Hello,

I have LHT65, I connect it to thethiungnetwork. But receiving errors. I use cayenne lpp.

{“error”:“Unable to decode payload fields: cayennelpp: unknown type”}

any help?

---

<div class="post-metadata">

**Author:** ![weradis](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/weradis/32/45845_2.png) [@weradis](https://www.thethingsnetwork.org/forum/u/weradis)\
**Post date:** [June 8, 2020, 8:41am UTC](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/39 "2020-06-08T08:41:10Z")

</div>

You can find a decoder example [here](http://www.dragino.com/downloads/index.php?dir=LHT65/payload_decode/)

---

<div class="post-metadata">

**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\
**Post date:** [June 8, 2020, 9:18am UTC](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434/40 "2020-06-08T09:18:49Z")

</div>

> [@weradis](#):
>
> decoder example [here](http://www.dragino.com/downloads/index.php?dir=LHT65/payload_decode/)

The v1.7 version uses:

```javascript
//SHT20,temperature,units:℃
TempC_SHT:((bytes[2]<<24>>16 | bytes[3])/100).toFixed(2),

```

That yields a text result. To convert to a proper JSON number (which will output `5` for `"5.00"` and `5.1` for `"5.10"`), [prefix with a plus](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Arithmetic_Operators#Unary_plus):

```javascript
// SHT20 temperature; unit: °C
// Sign-extend to 32 bits to support negative values, by shifting
// 24 bits to the left (16 too far), followed by a sign-propagating
// right shift of 16 bits, to effectively shift 8 bits. And unary plus
// operator to convert string result of toFixed to number:
TempC_SHT: +((bytes[2]<<24>>16 | bytes[3])/100).toFixed(2),
// SHT20 humidity; unit: %
Hum_SHT: +((bytes[4]<<8 | bytes[5])/10).toFixed(1),

```

Actually, as dividing by 100 should never yield excessive decimals in JavaScript, I’d remove the `toFixed`. (This would be different for, e.g., multiplying by `0.01`, like `2224 * 0.01` yields `22.240000000000002`, while `2224 / 100` is simply `22.24`.)

(There are a few more occurences in that code.)

And aside, the following:

```javascript
//DS18B20,temperature,units:â„ƒ
TempC_DS:
{
  "1":((bytes[7]<<24>>16 | bytes[8])/100).toFixed(2),
}[bytes[6]&0xFF], 

```

… could be written as:

```javascript
TempC_DS: bytes[6] === 1 ? 
  +((bytes[7]<<24>>16 | bytes[8])/100).toFixed(2) : null

```

Still ugly, but that’s due to using `return` without any temporary variables. I’d use some `switch-case` instead.

⚠ I ~~wonder if~~ think the `0xFF` in `bytes[6] & 0xFF` is an error. It has no effect. All other code uses `0x7F` instead.

[Previous page](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434.md?page=1)

[Next page](https://www.thethingsnetwork.org/forum/t/dragino-lht65-and-network-coverage/31434.md?page=3)
