I have a single ABP device and I noticed loraserer is generating DOWNLINK UnconfirmedDataDown for every UPLINK UnconfirmedDataUp received. The device is not requesting ACK and there’s no DOWNLINK scheduled for this device, no coding / decoding functions configured at all.
The DOWNLINK is being transmitted to the air I confirmed with RTLSDR, however, the device itself is not receiving anything.
The device is a class A running on LMIC/ATMEGA328 so I set MAC ver 1.0.2 in the device profile section.
Can somebody answer what is this DOWNLINK? is it some kind of beacon used by class B or C?
Here’s a sample. I upgraded to latest loraserver since I was running very old version and now the DOWNLINK does not use the same frequency as it generally used to which was 923300000.
I still see an UnconfirmedDataDown for each UnconfirmedDataUp here’s a sample of an UPLINK and DOWNLINK which I’m still trying to to understand what it is, perhaps it’s part of the LoraWan protocol and is expected.
Is this the LoRaWAN frames under the device or gateway page? It is best to use it under the device page as it will decode the mac-commands for you.
As you can see the downlink fOpts is set, so most likely the Network Server is sending a mac-command to your device and your device is not sending an acknowledgement back, causing the Network Server to send it over and over again to the device.
The adrAckReq does not cause the NS to send back an ADR request to the device. It will assure the NS will send a downlink back to the device, even if it is an empty downlink. Please refer to the LoRaWAN Specifications for full details on how this works and why this is there.
Thanks Brocaar, inspecting the frame from the device page I see the device is sending ADR True so that DOWNLINK from NS is a LinkADRReq. The report below helped. I will investigate the device.
Ok, not sure what the problem is again. I thought the Lora Network Server was sending DOWNLINK LinkADRReq because the Node was sending ADR: True. Now I disabled ADR on the node and the very first frame received by the NS generates a DOWNLINK with RXParamSetupReq even though the device is ABP activated not OTAA. My concern is that all the UPLINKS are generating DOWNLINKS and there are restrictions I should abide.
thanks, not sure what MAC request the node or Lora NS is initiating. Configuring disable_mac_commands=true stopped the DOWNLINKS for now, I still need to investigate what’s acutally going on.
Perhaps the server missed the end-device RXParamSetupAns because it is transmitted up on a different frequency and you are using a single-channel gateway?
In my case those downlink packages were sent if either “adrAckReq” or “adr” were set to true.
Adding LMIC_setAdrMode(0); and LMIC_setLinkCheckMode(0); to the LMIC initialization fixed the problem.
