Transmission fails after 120-140 sends messages rak11700


I have a rak11720 breakout board but after around 120-140 send messages i just get this message every time a send should be a lora transmission:

23:35:01.102 → Data Packet:
23:35:01.102 → 0x74 0x65 0x73 0x74
23:35:01.146 → Sending is requested
23:35:09.257 → Sending failed
23:35:09.257 → +EVT:SEND_CONFIRMED_FAILED(4)

I dont get any data so its not a confirmation problem. At first i throat that it was something in my costume arduino code, but i have just run a test in the lorawan otaa example and it gives the same result. I have checked the incoming data in my gateway and have come to the conclusion that the node dont send a message. Are there anyone else there have run into this issue and have a solution?

Hi Oscar,

What RUI3 version do you use? I have RAK11722 (RAK11720 for WisBlock) with the latest RUI3 version V4.0.5 running without problems.

What is your send interval?

Hey Beegee

I first discovered the problem on V4.0.3. But have since tried both V4.0.4 and V4.0.5 and i still have the same problem.

I have tried some different send intervals (20-, 60-, 120-sec) and the problem starts around 120-140 sends on all the intervals.

Is this RAK11720 on a custom PCB? Or is it our Breakout Board or WisBlock Core module?
I cannot reproduce your problem.

Nope it is the standard breakout board form rak. Link: RAK11720 Breakout Board | RAK11721 – RAKwireless Store

What region do you use?
What datarate did you set?
Is ADR enabled?
How often did you set confirmed message retry number?
How far is the gateway from the node?

  2. Not set so as it is in standard mode
  3. Yes set to 1 also as standard
  4. Retry is set to 1 as it is in the loRaWan_OTAA eksampl
  5. The gateway is 10 meters away

Can you change in the LoRaQAN_OTAA example the TX finished callback to get more information about the error:

void sendCallback(int32_t status)
    if (status == RAK_LORAMAC_STATUS_OK) {
        Serial.println("Successfully sent");
    } else {
        Serial.printf("Sending failed with %ld\n", status);
 * enum type for LoRa Event (value of status)

Two more things:

Can you enable debug with AT+DEBUG=1 and switch off ADR with AT+ADR=0 and see if things change and what the additional debug output says.

Now i get this:

09:55:45.989 → Data Packet:
09:55:45.989 → 0x74 0x65 0x73 0x74
09:55:46.037 → Frequency:868100000
09:55:46.037 → Rx1Frequency:868300000
09:55:46.037 → RxCFrequency:869525000
09:55:46.037 → RxC Datarate:0
09:55:46.037 → ChannelsDatarate:5
09:55:46.037 → AdrAckCounter:17
09:55:46.037 → ChannelsTxPower:6
09:55:46.037 → Sending is requested
09:55:54.115 → Sending failed with 4
09:55:54.115 → +EVT:SEND_CONFIRMED_FAILED(4)

So if i understand it correctly it is a rx1 timeout?

It is a RAK_LORAMAC_STATUS_RX2_TIMEOUT, which means it didn’t receive the expected ACK in neither of the two RX windows.
So either the packet was not sent or the LNS didn’t acknowledged the receive of the packet.

Can you try to switch off ADR and see if it anything changes.

Have tried with it both on and off and have not have any luck.

Thank you for trying. That gives me all information I needed.

I will open a issue ticket with our R&D team to check the problem.

Hey when do you think there are a solution? have gust tried with some costume boards a have made and the same problem accouris.

Hey again.
Any updates?

Sorry, I have no updates. It is still marked as open in the R&D ticket system.

Hey beegee

I have made some discoveries of my own, after way too many hours unfortunately. After working with it I started to knowtes that the rssi was getting worse and worse and then after 120 transmissions stopped getting picked up by the gateway. I then tried to send AT+TXP=0 to the board and then the gateway startet picking it up again. Now i have implemented it in my software so the sensor is setting the txp awry time a send is happening. Please let me know you thoughts.

Best regards Oscar

The TX power on the node could be influenced by ADR which changes TX power and datarate.
ADR is enabled by default, you might try to disable it through the API call api.lorawan.adr.set(false); on the RAK11700.