Only 1 of 97 messages reaches my gateway

Hello everyone. I have a very strange issue with my RAK4631 :thinking:

I have a RAK7258 gateway configured to forward the messages via MQTT to my ChirpStack setup. I have various other LoRaWAN devices that work fine with my setup and I haven’t every experienced any bigger issue with it, but then I started to build a small sensor box based on RAK4631.

I am using a RAK4630-R (RUI3) and configured the LoRaWAN stuff like this:

api.lorawan.nwm.set(RAK_LORAWAN);
api.lorawan.njm.set(RAK_LORA_OTAA);
api.lorawan.band.set(RAK_REGION_EU868);
api.lorawan.deviceClass.set(RAK_LORA_CLASS_A);
api.lorawan.cfm.set(RAK_LORA_NO_ACK);

Then I have a periodic timer to trigger sending a message every minute:

api.system.timer.create(RAK_TIMER_0, send_lorawan_message, RAK_TIMER_PERIODIC);
api.system.timer.start(RAK_TIMER_0, 60 * 1000, NULL);

It builds a CayenneLPP message and sends it:

void send_lorawan_message(void *) {
  lpp.reset();

  lpp.addTemperature(1, 12.37);
  lpp.addRelativeHumidity(2, 56.78);

  api.lorawan.send(lpp.getSize(), lpp.getBuffer(), 1);
}

When running my sketch, the first three minutes, everythings works fine. The device sends the messages, my gateway receives them and forwards them via MQTT to ChirpStack. But then… Have a look at this screenshot. It is from ChirpStack:

You do not see the first three messages, but you see some other messages. Have a look for the FCnt. You’ll see a difference of 97:

  • 2913 - 2816 = 97
  • 2816 - 2719 = 97
  • 2719 - 2622 = 97
  • 2622 - 2525 = 97
  • 2525 - 2428 = 97

And that’s exactly my problem. I only get 1 of 97 messages :man_shrugging: What happens to all the other messages in between?

I already tried to run my sketch with another timer interval and it seems like it is not a timing issue. It seems to be a counter issue :thinking:

  • interval 30s → one message every 48.5 minutes
  • interval 60s → one message every 97 minutes
  • interval 120s → one message every 194 minutes

I do not plan to send a message every minute or every 5 minutes (maybe every 15 or 30 minutes), but it feels really weird that 96 messages do not show up anywhere :man_shrugging: I’ve already checked the gateway logs, but couldn’t see anything helpful.

When enabling message confirmation:

api.lorawan.cfm.set(RAL_LORA_ACK);

I see +EVT:SEND_CONFIRMED_FAILED in the logs, for each of the 96 messages that do not reach my gateway. That message shows up ~15 seconds after sending.

The registered send callback (via api.lorawan.registerSendCallback()) receives status 4 which stands for LORAMAC_EVENT_INFO_STATUS_RX2_TIMEOUT from what @beegee said.

If you have any idea on this issue, anything I should try, if you need another screenshot, you want me to test and/or reconfigure something, please tell me! I would really like to understand and fix this issue!

Here’s the channel plan of my RAK7258 gateway:

Pulled out my old EU868 gateway and setup a Chirpstack for EU868 and unfortunately I can confirm the problem. After join 3 uploads work, then the RAK4631 RUI3 says continuously +EVT:SEND_CONFIRMED_FAILED until (in my case) 104 packets later the packets are received again.

I don’t see that problem on AS923-3 (difficult to test on other bands).

I have to push this into R&D for them to check.

Ah great, thanks for having another and deeper look into my issue. Good to know that this is a more general problem and not a problem on my side :sunglasses:

I found one difference to your problem.
After the big gap of ~100 lost packets, it continued to send normally.

Still not sure if it is because of my crappy EU868 gateway.

But I forwarded the problem to our R&D guys.

1 Like

When looking at your screenshot, it seems like you have a configured interval of 30s. Try using 60s.

I experienced more issues when using higher intervals (>=60s), less when using intervals <60s.

Can you try to switch ADR off.

AT+ADR=0

or as API call api.lorawan.adr.set(0);

Looks good so far :wink:

Tested the following intervals:

60s interval = :white_check_mark: (8 messages)
120s interval = :white_check_mark: (4 messages)
900s interval = :white_check_mark: (5 messages)

Our R&D guys said they have to look into the problem with ADR on. It could be that ADR is forcing a low DR with a limited payload, but not sure why it would not return an error if you are trying to send the data.

Hope in the next release the ADR problem will be fixed.