RAK811_LoraNode ADR not working properly


I have RAK811-HF with latest at-command firmware (
I have seen a strange behaviour with ADR, it start to send uplink messages and the server lowers down the TxPower to minimun (7) of the node and changes DR to 5 (SF7 / 125 kHz), so far so good.

But always after 64 uplinks messages the node start to use the max TxPower (0) and then it never lowers down.

I suppose this behaviour is incorrect.

How can i solve this?


You should set TX_power by AT command “at+set_config=pwr_level:7” to change txpower with minimun(7),Default is max(0).

But i don´t want to force it. It´s supposed to be set by the ADR server downlink message. And it works at firsts, but after 64 uplinks messages the node changes it to max(0) unilaterally

Hi @rayman18.
What regional config are you using?

Hi @velev
I´m using EU868

It’s curious that it matches the value of the variable EU868_ADR_ACK_LIMIT = 64

After 64 uplinks messages the node is normal.

Hi @Nicholas,

Look at the last one, the interval is quite a lot bigger, right ?

Hi @rayman18.
Yes,EU868_ADR_ACK_LIMIT = 64 ,this issue indeed depend on this parameter. The following screenshot is taken from the document LoRaWAN-Specification-1.0.2.pdf

If ADR=Enable(The default is enable),and AdrAckCounter >=EU868_ADR_ACK_LIMIT txPower will be set MAX_TX_POWER. We have test to send frame more than 69 times and never occur this issue .So this issue should mean that the node does not receive a downlink frame

I´m sending unconfirmed uplink messages to avoid frame lost. (at+send=0,2,53B12E78)

This is the log of the behaviour:

TxSuccessCnt:1, Join
TxSuccessCnt:2, TxPower=0, DR0 ,tm=1319
at+recv=2,0,0 ,downLinkCounter=0
TxSuccessCnt:3, TxPower=0, DR5 ,tm=52
at+recv=2,0,0 ,downLinkCounter=0
TxSuccessCnt:4, TxPower=2, DR5 ,tm=52
at+recv=2,0,0 ,downLinkCounter=1
TxSuccessCnt:5, TxPower=4, DR5 ,tm=52
at+recv=2,0,0 ,downLinkCounter=2
TxSuccessCnt:6, TxPower=6, DR5 ,tm=52
at+recv=2,0,0 ,downLinkCounter=3
TxSuccessCnt:7, TxPower=7, DR5 ,tm=52
TxSuccessCnt:8, TxPower=7, DR5 ,tm=52
TxSuccessCnt:9, TxPower=7, DR5 ,tm=52
TxSuccessCnt:10, TxPower=7, DR5 ,tm=52
TxSuccessCnt:11, TxPower=7, DR5 ,tm=52
TxSuccessCnt:12, TxPower=7, DR5 ,tm=52
TxSuccessCnt:13, TxPower=7, DR5 ,tm=52
TxSuccessCnt:14, TxPower=7, DR5 ,tm=52
TxSuccessCnt:15, TxPower=7, DR5 ,tm=52
TxSuccessCnt:16, TxPower=7, DR5 ,tm=52
TxSuccessCnt:17, TxPower=7, DR5 ,tm=52
TxSuccessCnt:18, TxPower=7, DR5 ,tm=52
TxSuccessCnt:19, TxPower=7, DR5 ,tm=52
TxSuccessCnt:20, TxPower=7, DR5 ,tm=52
TxSuccessCnt:21, TxPower=7, DR5 ,tm=52
TxSuccessCnt:22, TxPower=7, DR5 ,tm=52
TxSuccessCnt:23, TxPower=7, DR5 ,tm=52
TxSuccessCnt:24, TxPower=7, DR5 ,tm=52
TxSuccessCnt:25, TxPower=7, DR5 ,tm=52
TxSuccessCnt:26, TxPower=7, DR5 ,tm=52
TxSuccessCnt:27, TxPower=7, DR5 ,tm=52
TxSuccessCnt:28, TxPower=7, DR5 ,tm=52
TxSuccessCnt:29, TxPower=7, DR5 ,tm=52
TxSuccessCnt:30, TxPower=7, DR5 ,tm=52
TxSuccessCnt:31, TxPower=7, DR5 ,tm=52
TxSuccessCnt:32, TxPower=7, DR5 ,tm=52
TxSuccessCnt:33, TxPower=7, DR5 ,tm=52
TxSuccessCnt:34, TxPower=7, DR5 ,tm=52
TxSuccessCnt:35, TxPower=7, DR5 ,tm=52
TxSuccessCnt:36, TxPower=7, DR5 ,tm=52
TxSuccessCnt:37, TxPower=7, DR5 ,tm=52
TxSuccessCnt:38, TxPower=7, DR5 ,tm=52
TxSuccessCnt:39, TxPower=7, DR5 ,tm=52
TxSuccessCnt:40, TxPower=7, DR5 ,tm=52
TxSuccessCnt:41, TxPower=7, DR5 ,tm=52
TxSuccessCnt:42, TxPower=7, DR5 ,tm=52
TxSuccessCnt:43, TxPower=7, DR5 ,tm=52
TxSuccessCnt:44, TxPower=7, DR5 ,tm=52
TxSuccessCnt:45, TxPower=7, DR5 ,tm=52
TxSuccessCnt:46, TxPower=7, DR5 ,tm=52
TxSuccessCnt:47, TxPower=7, DR5 ,tm=52
TxSuccessCnt:48, TxPower=7, DR5 ,tm=52
TxSuccessCnt:49, TxPower=7, DR5 ,tm=52
TxSuccessCnt:50, TxPower=7, DR5 ,tm=52
TxSuccessCnt:51, TxPower=7, DR5 ,tm=52
TxSuccessCnt:52, TxPower=7, DR5 ,tm=52
TxSuccessCnt:53, TxPower=7, DR5 ,tm=52
TxSuccessCnt:54, TxPower=7, DR5 ,tm=52
TxSuccessCnt:55, TxPower=7, DR5 ,tm=52
TxSuccessCnt:56, TxPower=7, DR5 ,tm=52
TxSuccessCnt:57, TxPower=7, DR5 ,tm=52
TxSuccessCnt:58, TxPower=7, DR5 ,tm=52
TxSuccessCnt:59, TxPower=7, DR5 ,tm=52
TxSuccessCnt:60, TxPower=7, DR5 ,tm=52
TxSuccessCnt:61, TxPower=7, DR5 ,tm=52
TxSuccessCnt:62, TxPower=7, DR5 ,tm=52
TxSuccessCnt:63, TxPower=7, DR5 ,tm=52
TxSuccessCnt:64, TxPower=7, DR5 ,tm=52
TxSuccessCnt:65, TxPower=7, DR5 ,tm=52
TxSuccessCnt:66, TxPower=7, DR5 ,tm=52
TxSuccessCnt:67, TxPower=7, DR5 ,tm=52
TxSuccessCnt:68, TxPower=7, DR5 ,tm=52
TxSuccessCnt:69, TxPower=7, DR5 ,tm=52
TxSuccessCnt:70, TxPower=7, DR5 ,tm=52
TxSuccessCnt:71, TxPower=0, DR5 ,tm=52
at+recv=2,0,0 ,downLinkCounter=4
TxSuccessCnt:72, TxPower=0, DR5 ,tm=52
TxSuccessCnt:73, TxPower=0, DR5 ,tm=52
TxSuccessCnt:74, TxPower=0, DR5 ,tm=52
TxSuccessCnt:75, TxPower=0, DR5 ,tm=52
TxSuccessCnt:76, TxPower=0, DR5 ,tm=52
TxSuccessCnt:77, TxPower=0, DR5 ,tm=52
TxSuccessCnt:78, TxPower=0, DR5 ,tm=52
TxSuccessCnt:79, TxPower=0, DR5 ,tm=52
TxSuccessCnt:80, TxPower=0, DR5 ,tm=52
TxSuccessCnt:81, TxPower=0, DR5 ,tm=52
TxSuccessCnt:82, TxPower=0, DR5 ,tm=52
TxSuccessCnt:83, TxPower=0, DR5 ,tm=52
TxSuccessCnt:84, TxPower=0, DR5 ,tm=52
TxSuccessCnt:85, TxPower=0, DR5 ,tm=52
TxSuccessCnt:86, TxPower=0, DR5 ,tm=52
TxSuccessCnt:87, TxPower=0, DR5 ,tm=52
TxSuccessCnt:88, TxPower=0, DR5 ,tm=52
TxSuccessCnt:89, TxPower=0, DR5 ,tm=52
TxSuccessCnt:90, TxPower=0, DR5 ,tm=52
TxSuccessCnt:91, TxPower=0, DR5 ,tm=52
TxSuccessCnt:92, TxPower=0, DR5 ,tm=52
TxSuccessCnt:93, TxPower=0, DR5 ,tm=52
TxSuccessCnt:94, TxPower=0, DR5 ,tm=52
TxSuccessCnt:95, TxPower=0, DR5 ,tm=52
TxSuccessCnt:96, TxPower=0, DR5 ,tm=52
TxSuccessCnt:97, TxPower=0, DR5 ,tm=52
TxSuccessCnt:98, TxPower=0, DR5 ,tm=52
TxSuccessCnt:99, TxPower=0, DR5 ,tm=52
TxSuccessCnt:100, TxPower=0, DR5 ,tm=52
TxSuccessCnt:101, TxPower=0, DR5 ,tm=52
TxSuccessCnt:102, TxPower=0, DR5 ,tm=52
TxSuccessCnt:103, TxPower=0, DR5 ,tm=52
TxSuccessCnt:104, TxPower=0, DR5 ,tm=52
TxSuccessCnt:105, TxPower=0, DR5 ,tm=52
TxSuccessCnt:106, TxPower=0, DR5 ,tm=52
TxSuccessCnt:107, TxPower=0, DR5 ,tm=52
TxSuccessCnt:108, TxPower=0, DR5 ,tm=52
TxSuccessCnt:109, TxPower=0, DR5 ,tm=52
TxSuccessCnt:110, TxPower=0, DR5 ,tm=52
TxSuccessCnt:111, TxPower=0, DR5 ,tm=52
TxSuccessCnt:112, TxPower=0, DR5 ,tm=52
TxSuccessCnt:113, TxPower=0, DR5 ,tm=52
TxSuccessCnt:114, TxPower=0, DR5 ,tm=52
TxSuccessCnt:115, TxPower=0, DR5 ,tm=52
TxSuccessCnt:116, TxPower=0, DR5 ,tm=52
TxSuccessCnt:117, TxPower=0, DR5 ,tm=52
TxSuccessCnt:118, TxPower=0, DR5 ,tm=52
TxSuccessCnt:119, TxPower=0, DR5 ,tm=52
TxSuccessCnt:120, TxPower=0, DR5 ,tm=52
TxSuccessCnt:121, TxPower=0, DR5 ,tm=52
TxSuccessCnt:122, TxPower=0, DR5 ,tm=52
TxSuccessCnt:123, TxPower=0, DR5 ,tm=52
TxSuccessCnt:124, TxPower=0, DR5 ,tm=52
TxSuccessCnt:125, TxPower=0, DR5 ,tm=52
TxSuccessCnt:126, TxPower=0, DR5 ,tm=52
TxSuccessCnt:127, TxPower=0, DR5 ,tm=52
TxSuccessCnt:128, TxPower=0, DR5 ,tm=52
TxSuccessCnt:129, TxPower=0, DR5 ,tm=52
TxSuccessCnt:130, TxPower=0, DR5 ,tm=52
TxSuccessCnt:131, TxPower=0, DR5 ,tm=52
TxSuccessCnt:132, TxPower=0, DR5 ,tm=52
TxSuccessCnt:133, TxPower=0, DR5 ,tm=52
TxSuccessCnt:134, TxPower=0, DR5 ,tm=52
TxSuccessCnt:135, TxPower=0, DR5 ,tm=52
TxSuccessCnt:136, TxPower=0, DR5 ,tm=52
at+recv=2,0,0 ,downLinkCounter=5
TxSuccessCnt:137, TxPower=0, DR5 ,tm=52
TxSuccessCnt:138, TxPower=0, DR5 ,tm=52
TxSuccessCnt:139, TxPower=0, DR5 ,tm=52

As you can see after downLinkCounter=3 (ADR downlink from server) it takes 64 messages sent until TxPower changes to 0. After that it receive a downlink message from server, but then the power never changes.

Also you can see the server always sends a downlik after 64 uplinks.

You should better refer to LoRaWAN-Specification-1.0.2.pdf about the introduction of ADRACKReq.The source code about AdrAckCounter must be less than or equal to EU868_ADR_ACK_LIMIT(64), if the node received a downlink frame the AdrAckCounter can be reset. But if it equals to EU868_ADR_ACK_LIMIT(64),the ADRACKReq bit will be true,and txPower will always be EU868_MAX_TX_POWER(0).Please see the source code and modify the function RegionEU868AdrNext() if you need at RegionEU868.c.

@leopold Thanks for the answer
So this behavior is what is expected in LoRaWAN-Specification-1.0.2? Is it considered correct?

The problem is that AdrAckCounter never reset…

@rayman18, AdrAckCounter is reset after received a downlink frame .So if you send a confirm frame but never received any downlink from server,the AdrAckCounter could be increase every retransmission until AdrAckCounter upto EU868_ADR_ACK_LIMIT(64).

“The problem is that AdrAckCounter never reset…” is due to the node never received the downlink frame from sever.

But the node receives a downlink.
After TxSuccessCnt:71 it receives one downlink and the downLinkCounter increases to 4.
Also after TxSuccessCnt:136 another downlink is received and downLinkCounter set to 5.

Thats why i dont understand it…

Also in the function RegionEU868AdrNext() i don´t see any place where AdrAckCounter resets. Only on if( datarate == EU868_TX_MIN_DATARATE ) but the datarate is actually at EU868_TX_MAX_DATARATE so it will never reset it.

I don’t know why you received “at+recv=2,0,0”. In our demo firmware “at+recv=2,0,0” means send an unconfirm frame successfully whether received downlink frame or not. and did not increase AdrAckCounter.

The AdrAckCounter will be reset after received a downlink frame .you could see function OnRadioRxDone() at LoRaMac.c.

Well, i tried to simplify the log, but actually this is received through the serial port:
After at+send=0,2,53B42E78 ( TxSuccessCnt:71) this is received in serial port:

sequenceCounterDiff = 1,downLinkCounter=4
skipIndication = 0

And after at+send=0,2,53B42E78 (TxSuccessCnt:136) this:

sequenceCounterDiff = 1,downLinkCounter=5
skipIndication = 0

Also after TxSuccessCnt:201 uplink frame, the node ouputs this:

sequenceCounterDiff = 1, downLinkCounter=6
skipIndication = 0

The rest of the at+send commands only outputs as it should:


The firmware is in DEBUG to be able to see more info, that´s why the node outputs more info through the serial interface.

Yes,we retest t send unconfirm frame following your issue .And after EU868_ADR_ACK_LIMIT(64) uplink frames , AdrAckCounter increase to EU868_ADR_ACK_LIMIT(64) ,so txPower=EU868_MAX_TX_POWER.

I guess that LoRaWAN maybe verify the network is still connected after repeatedly send unconfirm frame .Then set ADRACKReq bit request downlink frame from server to confirm the network is still connected,but the node have set txPower=EU868_MAX_TX_POWER.

If you don’t want to change the txPower, maybe you need to modify the protocol yourself.

1 Like

@leopold Thanks for the support