I can see that ADRACKReq is set in the uplink packets, but I can’t see what TTN does with them. It just seems to ignore them. An explicit downlink message doesn’t cause any change either. I’ve seen ADR work on other devices (and ADR works for this device on other networks), but the one theory I have is that TTN will not do ADR with any devices which start off at SF12. I have shown this with my own mdot-based devices.
Jut to be sure: in LoRaWAN 1.0.x, that should only be set every 64 packets (and only if no downlink was received in the meantime). But for each uplink, the ADR bit should be set as well, so TTN knows it needs to keep track of the link quality.
So: is the ADR bit indeed set for every uplink?
Using an online LoRaWAN decoder you can easily check:
if ADR is set for every uplink (like if it has FCtrl = 0x80 = 0b10000000, hence has bit 7 for ADR set)
and if ADRACKReq is set for every 64th uplink (like if it has FCtrl = 0xC0 = 0b11000000, hence has bit 6 for ADRACKReq set)
and if any downlink is an ADR response (like† for me, after an ADRACKReq uplink, TTN would generate a downlink right away, but and ADR downlink could also be postponed for another 32 uplinks if TTN feels like that).
If the uplinks look fine: any chance the uplinks are received by multiple gateways, and TTN tells another gateway to send the ADR downlink, which is then somehow lost?
Note that at some point TTN will give up to not waste more downlinks†; such is then shown as “too many failed ADR requests” in the “trace” part of an expanded downlink in the gateway’s Traffic page in TTN Console:
† Well, actually the above screenshot still resulted in a downlink, which I linked to in the 3rd bullet above… I did not investigate; see Error: too many failed ADR requests.
Maybe it even gives up if it has tried to send ADR commands before your node even has set ADRACKReq, which I think can happen when the node is using SF12 despite a good link quality?
I am unable to get the sensor to register to the TTN application, although i can see the frames in the gateway traffic, it was working fine, but it stopped suddenly, i tried deleting the app and creating it again with no luck, any advice ?
You would have to make sure the AppEUI and AppKey are exactly as they were before since there’s no way to change them on the device. I expect the AppKey will be different each time it’s generated, but there seems to be an option to override it and paste in the old AppKey for that device.
Also make sure the sensor is properly reset to trigger a join. Setting the device to standby mode and back doesn’t trigger a join if it thinks it’s already joined. Using the magnet for 20 seconds will hardware reset it, triggering a join.
Thanks sir, I have thought about resetting it by holding the magnet for 20 sec, but won’t this reset the configuration also?, and unfortunately, these sensors were shipped configured and i don’t think we know how to reconfigure them again.
Using hardware reset doesn’t clear the configuration of the device, but does reset the session keys. No other options cause a Join message to be sent, so this is the only choice except maybe leaving the battery out, but flash storage would survive this and supercapacitors can complicate the process.
You must make sure you get your keys correct in the application, but for a quick check you can see the join attempt in the gateway traffic console.
Hi Ben, thanks so much for your help. It finally worked…
What i did is i let the newly created app generate the Dev EUI, at that moment i could see the join attempt in he gateway traffic and i could see that it has failed, then i manually modified the Dev EUI back to the sensors specific, the join was successful and the app worked.
I just have a quick question regarding the coverage, it seems that the sensor only work when it is extremly close to the gateway, i have tested the battery level and it looks fine.
I have contacted nemeus regarding this, and they send us a few models for an external antenna, but their seems no where to connect a SMA connecter on the PCB once i opened the sensor, is their some sort of modification needs to be done ?
We have had no range problems with the NIS-UL like that you describe. The external antenna model is currently being tested by a client and comes with a bulkhead SMA connector. The other versions I assume have a PCB or ceramic antenna but have achieved several km range without problems. Perhaps you have a faulty device? Is it an 868MHz model? Also be sure your gateway is multi-channel or you’ll be missing many messages.
Hi Ben,
Thanks again, We have a multitech outdoor unit, and i think all chanels are enabled, or atleast when i ran the ttn packet forwarder script i think it showed that.
I think @BoRRoZ has a fair point. The end application is quite an important part of the process, but probably not for here. If you’re a novice then I’d recommend using the decoder to make the fields easier to work with. Arjan has done a great job in splitting them into human readable fields for posting, otherwise you’ll have the additional problem of learning bitwise operations in PHP.