Every uplink generates a downlink

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?

Thanks!

Could you inspect the content of this downlink in the lorawan frames tab of the device?

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.


Hi, notice that adrAckReq is true in Uplink, that should cause server to send ADR request, see https://www.thethingsnetwork.org/docs/lorawan/adr.html

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.

1 Like

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.

Automatic Unwanted DataDown Packets #228

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.


An ABP device should still respond to mac-commands. I suspect the issue is that your device does not respond to these mac-commands.

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?