The image below is some of Flood Network’s sensors producing data and using your decoder. We already decode in our application, but it’s very useful for debugging on TTN. I included a device which was woken from standby too to check wakeup codes. (Note that the sensor with an erroneous voltage measurement is using the old pre-Nov 2017 packet format which has now changed.)
This would be immensely helpful on the wiki, but I believe the wiki is only editable by Nemeus staff. I will send this on to them.
Now if someone can fix the fact they’re stuck at SF12, but only on TTN then that’d be fantastic.
I guess you know how to tell if ADR is enabled, and if TTN is trying to command the nodes to change their settings? (If ADR is enabled and the device is at SF12, then I think TTN will initiate a downlink when it cannot piggyback on a confirmation requested by the node, or a downlink scheduled by the application, and even if the node did not request an ADR downlink.)
Are they using the same LoRaWAN port number for their different formats?
Hi Arjan, this works a treat! Thank you so much for taking the time to look into this. I’ll also pass this on to Nemeus to see if they can update their wiki to be more user friendly.
I will test new downlink formats to get different measurements etc.
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.
† Well, actually the above screenshot still resulted in a downlink, which I linked to in the 3rd bullet above… I did not investigate; see