LoRaWan - sleep procedure

[michapr]

Hi,

testing the persistent end device with deep sleep procedure I think about, that after sending the message the device could go into light_sleep until the receive window - for save energy.

What do you think, would it be possible?

Thanks,
Michael

[StevenCellist]

Whatever you like - you can literally do whatever you want before and after a sendReceive(). Unplug your device, throw it out the window, calculate the millionth decimal of pi, do some deepsleep or lightsleep!

[michapr]

Hi,

no, I mean inside the procedure:

int16_t LoRaWANNode::sendReceive(String& strUp, uint8_t port, String& strDown, bool isConfirmed, LoRaWANEvent_t* eventUp, LoRaWANEvent_t* eventDown) {
  // send the uplink
  int16_t state = this->uplink(strUp, port, isConfirmed, eventUp);
  RADIOLIB_ASSERT(state);

  // wait for the downlink
  state = this->downlink(strDown, eventDown);
  return(state);

Before waiting for the downlink - this are, for my understanding, 5 seconds, where the system is waiting for the RX-window.
During this time the device could go into light_sleep (without loosing states and values) and save energy.

Or I'm wrong?

[StevenCellist]

If you would be so inclined to save power there, you may want to use a separate uplink() and downlink(), but you have to really really really make sure you call downlink() in time, otherwise your device is stuck waiting forever. But I don't plan on doing that sort of stuff within sendReceive() as that is really platform dependent and may have unwanted side effects for a lot of users.

[HeadBoffin]

There is a small % of battery life that could be saved but the timing has to be absolutely, factoring in elements including the ramp up time of the main oscillator(s) etc. I've only ever achieved this when I have a rock solid RTC on the MCU that I can ask for 4 seconds of sleep and be totally sure that on wakeup the system ticks / clock are in sync with the sleep time - most sleep modes tend to disable the tick as that's an interrupt at a higher level so you either have to add on the ticks or adjust the value of when to open the window. Calibration is possible but as I said, the RTC must be solid and certainly not temperature sensitive.

You can open the Rx window a bit earlier to compensate for any timing errors but that usually wipes out your power saving and very probably puts you in deficit.

[michapr]

Hi,
I'm speeking now about ESP32S3+SX1262 (Heltec WSLV3) only - as you said, it depends very on hardware...

Want only to show, what is possible, and that it can make sense to make it ;)...
Original cycle:

I have now only added a light sleep before RX windows without any additional settings/optimisations (here 4.5 seconds) - so that the main components will still work.
Energy saving for this time is about 108mAs (for 4 seconds sleep) - the full process take about 250mAs without this sleeping.

Calculating this over the time with quiet current (15uA) and 6 sendings/hour it will save about 35% of energy - so more as a "small % of battery life" ;)...
(in my case, tested with two devices)

Device is stable working, have tested of course with downlinks from TTN interface

Only want to show that it can make sense to try it for battery devices - depending on the used hardware of course.

[StevenCellist]

Given that you have the hardware and the software knowledge - that's why there is a separation possible from sendReceive() into uplink() and downlink()! But generally, we will always discourage this separation to unexperienced users. Which you will probably understand :)
But - hack away! Glad to see that you got it working and yes, it does save useful current :)

[michapr]

Yes, I like very your library! Thank you very much for your hard work!

[HeadBoffin]

Most excellent! Must admit, I hadn't thought about savings on a multi-uplinks per hour - I'll adjust my spreadsheet!

Only want to show that it can make sense to try it for battery devices - depending on the used hardware of course.

Sure, as above, I've done it (with SAMD on LMIC), but trying to help someone get it done via forum/discussions is a special sort of hell that I don't want to revisit.

Will have a good look at light sleep mode - I'm more AVR, SAMD & STM32 focused with work - but the more I've been working with @StevenCellist on RadioLib the more I can see the goodness of ESP32 (apart from the space taken by three versions of the RISC-V compilers!).