Dragino LHT65 and network coverage

End Devices (Nodes)
21

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.

1 Like
22

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…

1 Like
23

I have got the same AppEUI A000000000000100. This looks to be ok. See: Addressing and Activation. 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) is not possible on that range and I should try Activation by Personalization (ABP)? Any experience with simliar setup would be helpful as well :blush:

24

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.

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, and once joined there’s no difference between OTAA and ABP.

Maybe Gateway queries & ranges helps, but it’s a long read.

1 Like
25

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

26

Thank you @arjanvanb for your support. I read Gateway queries & ranges and also came across The BIG and SMALL ANTENNA topic part 1 and The BIG and SMALL ANTENNA topic part 2.

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) and to connect it by 3m CFD400 cable DELOCK 13021 (WLAN Kabel, N Stecker, RP-SMA Stecker) and SMA-REV-Adapter 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!

27

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

28

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.

29

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.

30

That is not a LoRaWAN gateway.

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.

31

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

32

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 ?

33

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

1 Like
34

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.

35

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?

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.

36

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

37

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

38

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?

39

You can find a decoder example here

1 Like
40

The v1.7 version uses:

//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:

// 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:

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

… could be written as:

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.

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