Hello,
I am currently developing a LoRa-based Wireless Sensor Node, uplink communication works quiete well.
But everytime my sensors sends an uplink to my application, the application is scheduling and sending immediately a downlink.
I am sending UNconfirmed uplinks.
Can someone help me to solve where this is coming from?
What i have already checked:
NO integrations
NO ADR
empty queue (checked with CLI)
Maybe it helps to know, that if i schedule a downlink manually, it will not be sent and it remains into the queue!
EDIT:
Device: LAMBDA62-8D breakout board (Semtech SX1262)
Driver: Semtech’s SX126x driver implementation
It is configured as:
What is the device, what software stack/library are you running on the node? How configured - at the device and in NS device registration? Did it previously work ok and this is new operating situation or is it a new node?
It is a customized/self-developed device with a LAMBDA62-8D breakout board (Semtech SX1262) on it.
Driver is Semtech’s SX126x driver implementation.
It is configured as:
Class A
LoRaWAN Specification 1.0.2
Europe 863-870 MHz (SF9 for RX2 - recommended)
ABP
Yes, it previously worked without sending downlinks.
Yes, look at the pic you posted for the end device, to the left where you blacked out, it tells you, select the actual message and you will get more info.
Okay i see.
But where is it coming from, as i already told, i have unconfirmed uplinks, no integrations, no ADR and an empty queue.
I am confused about the source of this downlink.
Is there something i didn’t consider which could trigger downlinks?
As already suggested, view the details of the downlink to see exactly what it contains.
Probably this is the network configuring some important additional settings on your node.
If the node is not correctly acknowledging these configurations, they will continue to be sent, rapidly exceeding the fair use policy (really it would be good if TTN were to stop trying at some point, and maybe just report errors while refusing to pass on data from your device, but even so it’s still your responsibility to use only nodes which correctly implement LoRaWAN by correctly processing and acknowledging configuration commands).
That drives the radio - what are you using for the LoRaWAN MAC? And which version?
As the MAC command is to set the Rx1 delay and you are using ABP, you may never get the downlink if the code is set to a different delay. Which is why OTAA is recommended.
