ADR strange behaviour

1

Using loraserver 2.6.0
The node is using LRWAN 1.2.1 firmware from STMicroelectronics.
The node is configured to use ADR on.
Everything starts fine and the node is using DR5. Over time, although the SNR is always high (8-9) the DR goes down and eventually to DR0. I see the network server sending the following messages repeatedly. It seems the network server is requesting the DR to be set to 5 but it is not successful.
Another doubt: if the network server never sends an adr request with req_dr=4 or 3, 2, 1, 0 (checked all logs), how can the node reach DR0 ?

Apr 04 21:36:11 y-server loraserver[1419]: time=“2019-04-04T21:36:11Z” level=info msg="gateway/mqtt: uplink frame received"
Apr 04 21:36:11 y-server loraserver[1419]: time=“2019-04-04T21:36:11Z” level=info msg=“rx info sent to network-controller” dev_eui=0101010101190003
Apr 04 21:36:11 y-server loraserver[1419]: time=“2019-04-04T21:36:11Z” level=info msg=“device gateway rx-info meta-data saved” dev_eui=0101010101190003
Apr 04 21:36:11 y-server loraserver[1419]: time=“2019-04-04T21:36:11Z” level=info msg=“device-session saved” dev_addr=017f5b61 dev_eui=0101010101190003
Apr 04 21:36:11 y-server loraserver[1419]: time=“2019-04-04T21:36:11Z” level=info msg=“adr request added to mac-command queue” dev_eui=0101010101190003 dr=0 nb_trans=1 req_dr=5 req_nb_trans=2 req_tx_power_idx=5 tx_power=0
Apr 04 21:36:11 y-server loraserver[1419]: time=“2019-04-04T21:36:11Z” level=info msg=“requesting device-status” dev_eui=0101010101190003
Apr 04 21:36:11 y-server loraserver[1419]: time=“2019-04-04T21:36:11Z” level=info msg=“pending mac-command block set” cid=LinkADRReq commands=1 dev_eui=0101010101190003
Apr 04 21:36:11 y-server loraserver[1419]: time=“2019-04-04T21:36:11Z” level=info msg=“pending mac-command block set” cid=DevStatusReq commands=1 dev_eui=0101010101190003
Apr 04 21:36:11 y-server loraserver[1419]: time=“2019-04-04T21:36:11Z” level=info msg=“pending mac-command block set” cid=RXTimingSetupReq commands=1 dev_eui=0101010101190003
Apr 04 21:36:11 y-server loraserver[1419]: time=“2019-04-04T21:36:11Z” level=info msg=“gateway/mqtt: publishing downlink frame” qos=0 topic=gateway/00800000a0002529/tx
Apr 04 21:36:11 y-server loraserver[1419]: time=“2019-04-04T21:36:11Z” level=info msg=“device-session saved” dev_addr=017f5b61 dev_eui=0101010101190003
Apr 04 21:36:11 y-server loraserver[1419]: time=“2019-04-04T21:36:11Z” level=info msg=“downlink-frames saved” dev_eui=0101010101190003 token=26224
Apr 04 21:36:11 y-server loraserver[1419]: time=“2019-04-04T21:36:11Z” level=info msg=“backend/gateway: downlink tx acknowledgement received” gateway_id=00800000a0002529

2

If the node isn’t getting replies at a higher DR, the node side part of the ADR implementation would scale down to the slowest, longest range mode in the hope that it does get a response, and if it still doesn’t, it would stay there.

Do you have any indication of any downlink being successfully received byte the node? If not you probably want to try to get some debug output from the node as to when and with what settings it has the radio listening, and compare that to the gateway transmit logs. And if packets are being received but discarded, you want to see that too.

3

Thanx for the heads up and the explanation. I think you are right. The server is continuosly transmitting at DR0 but the node still doesn’t receive anything also at this datarate.
Anyway I don’t understand how the node can join the network if it is not receiving anything.

Probably I messed up with my node parameters (a LoRa 1.1.x version node). Should DEVICE_EUI and JOIN_EUI be the same?

#define LORAWAN_DEVICE_EUI               { 0x01,0x01,0x01,0x01,0x01,0x19,0x00,0x33 }
#define LORAWAN_JOIN_EUI                 { 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01 }


#define LORAWAN_APP_KEY                  { 0x2B, 0x7E, 0x15, 0x16, 0x28, 0xAE, 0xD2, 0xA6, 0xAB, 0xF7, 0x15, 0x88, 0x09, 0xCF, 0x4F, 0x3C }

#define LORAWAN_NWK_KEY                  { 0x2B, 0x7E, 0x15, 0x16, 0x28, 0xAE, 0xD2, 0xA6, 0xAB, 0xF7, 0x15, 0x88, 0x09, 0xCF, 0x4F, 0x3C }