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?
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.
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.
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…
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.
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.
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?
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.)
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?