Lora confirmation with RAK4631

WisBlock
1

Hi,

I’ve been wondering how the lmh_send() works with the confirmation parameter set to LMH_CONFIRMED_MSG.

my code uses a SoftwareTimer to wake up the device and push a semaphore which unblocks the loop(). It then does a GPS fix and send that info. After the sending, the device waits in the loop() again for a xSemaphoreTake(). This makes the NRF go into deep sleep.

I’m wondering how this works with confirmation enabled? Does the lora lib still retry, even though it’s in deep sleep?
In the code linked, i added some logic to check if the confirmation was received, this seems to work, but it feels a bit odd and wrong. So i’m wondering if my approach is wrong?

What i’d like to do is make sure a message is send and confirmed. Of course, this just to make sure the info is send when there’s a slightly bad reception.

2

Yes, it will work as expected. The result of the confirmed message will be shown in the LoraHelper::lorawan_conf_finished callback.

What you could do is to use the same semaphore to wake up from the callback, and use a flag to check the reason for the wakeup.

3

Thanks.

I’ve noticed that the serial output that i put in LoraHelper::lorawan_conf_finished only shows when the device wakes up again. That’s a bit odd… so, does the lora chip cache this and when the device is awake, it gets those interrupts?

Also, how does the confirmation stuff work? Does it send, wait for confirmation and retry? And if so - how often? Does the sleep state of the nrf matter at all?

4

Force sending the serial buffer by putting a Serial.Flush() after the Serial output. The information on serial might not be sent immediately when using semaphores and sleep.

1 Like
5

Thanks. I already have that :slight_smile:

The serial logging is the least of my issues. I’m more interested in understanding how the confirmation stuff works. I’ve noticed that the device retries the send by itself. So it feels/looks like lmh_send() with confirmation will push the message to the lora chip and that then retries until ACK is received. Why i think this: i can see lora messages being received by the gateway multiple times… (basically a situation where the antenna of the gateway is better and thus receives, but the lora node doesn’t receive the confirmation).

How does that part work? Even with ACK mode and checking if we receive ACK, i still seem to miss some of the messages. So i’m wondering if there’s a retry-time/amount and if i could just check in code and re-send the same message?

6

Confirmed message re-transmission is handled in the LoRaWAN stack itself.

In the Arduino library the number of retries can be set with lmh_setConfRetries(), default is 8.
The time between retries is handled by the LoRaWAN stack as well.

7

Ok, so there’s not really a good way to wait for confirmation and retry if it fails than.

Thanks - i did eventually also try to read all the source of the loradriver. It wasn’t that clear to me, so thanks!