Deep sleep while waiting for LoRaWAN RX windows

[MortenGuldager]

My device is wasting quite some energy while waiting for the two LoRaWAN RX windows. Approximately 50%.
I had a look in the radiolib code but could not see if it should support deep sleep while waiting there.

Some measurements:
The full transmission is seen here. it takes 3 seconds and cost about 53mC

Here I have the cursor at the RS2 wait, which ofcause is approx 1 second long and cost 13.5mC.

I did not frame RX1 wait, but it is the same, in total 27mC

To comparison I framed a similar period where mcu is in deep sleep, which would have costed 19uC

Ah yes, I'm using an Microchip SAMD21 with a RMF95 module.

[StevenCellist]

@MortenGuldager there is one thing on my wishlist for RadioLib, which is exactly this, namely to add some kind of 'custom delay' callback. The problem however is how to support this properly. While you may be using SAMD, there are lots of folks out there using an ESP32, and, uh, well, how to say it... it definitely does not support deep sleep as a delay type. Moreover, the wakeup time from a sleep function varies between platforms with some being instantaneous, others taking a few milliseconds, which means lots of timing issues and support questions...

The 'do it yourself' fix is to modify your ArduinoHal::delay, with a suggestion along the following lines:

• use the normal ::delay() for any waiting period lower than say 50ms
• use some sort of ::sleep() for any waiting period longer than 50ms,

So in pseudo:

ArduinoHal::delay(timeMs) {
  if(timeMs <= 50) {
    ::delay(timeMs);
 } else {
    ::sleep(timeMs);
  }
}

In case of slow wakeup (but consistent clock), something like this may work:

ArduinoHal::delay(timeMs) {
  if(timeMs <= 50) {
    ::delay(timeMs);
 } else {
    start = millis();
    ::sleep(timeMs - 20);                  // reduce delay to make sure you wakeup in time
    if(millis() < start + timeMs) {
      ::delay(millis() - start - timeMs);  // if there's still some time left, do normal delay for remainder
    }
  }
}

[HeadBoffin]

This is a universal truth for modern devices with low power sensors across the whole LW eco-system. It doesn't come up often on the TTN forum, but it's well discussed, TL;DR: many have tried, almost all have failed.

This is mostly due to the lack of a decent RTC clock on a board so now the hardware has improved in recent years it's well worth a revisit - such that it's a medium priority item on my todo list for an STM32 implementation but as @StevenCellist, we have to figure out a way to do the callback or hack delay or similar so there is no scheme yet.

In the past I've used SAMD and it's sleep / wake times are reliable that I'd anticipate some success with the idea outlined above - you may need to widen the 'wiggle room' values to sleep for a nice round number that the MCU can handle, do some more busy-wait delay and then perhaps widen the Rx window slightly. Once working you can tune it until you're catatonically bored or happy - which ever comes first.

Wiggle room = scanGuard =

RadioLib/src/protocols/LoRaWAN/LoRaWAN.h

Line 851 in 2ca2ddf

RadioLibTime_t scanGuard = 10;

[HeadBoffin]

PS, what radio are you using? 55mA is half way between SX1276 & 1262.

PSS, the ultimate quick win is to alter Rx1 to 1 or 2 seconds if you have the infrastructure that will allow for it!

[MortenGuldager]

Ahh the 55mA is measured at the battery, so that includes the MCU. It's a RFM95 so SX1276.
I dont know how far down ADR has turned the transmit power, the gateway is about 10 meters away, one floor up. Might be all the way down at 8dBm