ADR is disabled but still have too many downlink messages

Setup and configuration
1

Hi

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):

Server 001
Server 001745×1539 315 KB

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.

2

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.

2 Likes
3

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.

4

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