ADR is disabled but still have too many downlink messages


I have the problem that the CS Server generates downlink messages for -almost- every uplink message generated from the devices, despite that the ADR function is disabled in the CS_Network_server.toml file.

The configurations for a US915 deployment is:

  • CS Gateway bridge installed on a RPI4 with a RAK2245.
  • The MQTT Broker (mosquitto), CS App Server, CS Ntw Server, Redis and DB are installed with docker in a single Debian server
  • The end devices are a LoPy4 and a RAK7200, both with the same issue.

Down to up, the second uplink and downlink message have the following information (sorry i had to merge all captures in a single image due to first post limitations):

The trace on the server side (using command sudo tcpdump -i lo -AUq port 1700) shows the uplink and immediate downlink messages. I’m sure the message is broadcasted as I can see it using an SDR dongle.

In order to move forward I must fix the generation of so many unnecessary downlink messages.

In advance my appreciation for any help to solve this problem.

Please check the content of the downlink frmPayload, with fPort: 0, it contains the mac-commands that are sent to the device. Then you need to find out why the device never confirms these mac-commands.


Thanks @brocaar for your advice. The issue is solved ( or better said a workaround) with the following changes in the end device:

    1. Change the device type to type C.
    1. Use the callback function to look for Tx and Rx events instead of using a polling method (for those using the lopy 4 look into the implementation in lorawan-regional-examples that is included in pycom-libraries-master->examples).

These changes are very specific to the board I’m using with micropython and for now I can’t dive into the protocol layers in order to understand why the device does not listen to mac commands always.

I’ll like to know if CS has a way to limit the number of downlink messages (including protocol related) as a breaker in case of end node misbehavior.

There is a handler which limits the number of downlink mac-commands in case these are always nACKed, I believe the default is 3 errors per mac-command CID.

Again, I would recommend looking into the downlink mac-commands that are sent in the frmPayload or fOpts. Maybe you have made a config error and the device is dropping the mac-commands.

1 Like