Initialize (begin) instance of SX1278 without reset (after deep sleep)

[sacculus]

Hi
Is it any procedure to initialise instance of SX1278 without reset LoRa chip?
I'd try to put MCU (esp32) in deep sleep when LoRa modem (sx1278) in receive state.
When packet received MCU is woken up by extX wake up source with dio0 line. But begin() method of instance SX1278 resets LoRa chip and its state lost, so cant read received packet, its size, RSSI etc. Without initialize I can't read resieved data too, because there is not control SS line of SPI.
Temporary I commented out code with reset in SX127x::findChip routine but sure that is not the best decision to change library code...
Is it any right way to do this?
I think I am not first who plays with power saving of LoRa boards.

Thank you!

[jgromes]

The reset in begin method is quite intentional - the assumption is that you're only calling begin() after power-on reset, when the SX127x device is in an unknown state.

However, I'm not sure why would you want to call begin() on wakeup of the ESP32 in the first place? I would only call begin once, after the power-on reset.

EDIT: Also, this doesn't seem like an issue - converting to a discussion instead.

[DarkZeros]

I am reviving this discussion since i have exactly same issue. I will try to fix it myself and propose a PR.

The issue is that ESP32 can set EXT1 /EXT0 wakeup to IRQ (DIO1) and enter deep sleep.

This saves huge amounts of power, but when a packet is received, the module state needs to be restored without the initialization (memory is fully reset expect RTC memory). And the SX126x does not know about the ESP32 being in deep sleep.

[StevenCellist]

Depending on how power constrained you are, you may be able to survive on light-sleep. On most boards, lightsleep can go down to 2mA or a bit lower, which compared to the radio staying in Rx (12mA) isn't bad at all. Plus it saves all the hassle of re-initializing everything.

[DarkZeros]

I am working on a solar powered project, therefore every uA I can save is welcomed.

The ESP32 itself uses 1mA in light sleep and 0.1uA in deep sleep.
The radio uses 4.5mA in receiving state. Therefore it is a 25% power save.

Technically it is possible to save/restore the key members of the Module class, into RTC memory, or flag the fields accordingly. I will keep you posted on the progress.

[StevenCellist]

You are replying on a topic that mentions SX1278 which has a reported Rx power consumption of 12mA. 4.5mA sounds suspiciously like an SX1262 instead. So that is something to watch out for.

Moreover, why not use an STM32? It is absurdly more power-efficient nor does it lose its RAM contents. No need to do any sort of RTC hackery with possibly very tough to solve bugs.

[DarkZeros]

Yes, it is a SX1262.
Unfortunately i am too advance in the project now to change the main MCU for a STM32.

But so far the esp32 has been great, managing to run on average with just 5uA (as long as i keep the deep sleep as much as i can, around 99.5% of the time)

[HeadBoffin]

I will try to fix it myself and propose a PR.

As @jgromes said in 2022, this isn't an issue or a bug so there isn't anything really to fix - you can get the reason for wake from the ESP32, if it's wake from sleep because of external interrupt, just don't call radio.begin() and proceed directly to reading the packet from the radio - it really is that simple.

[StevenCellist]

Exactly why are you creating a custom ArduinoHAL, as well as a Module, as well as a Radio? Where did you get that from? The examples here definitely don't show it. No need for any of that - just check the wiki on how to setup your radio with a custom SPI instance. Way smaller chance of weird stuff happening! (Link from the FAQ on the wiki.)

[DarkZeros]

Exactly why are you creating a custom ArduinoHAL, as well as a Module, as well as a Radio? Where did you get that from? The examples here definitely don't show it. No need for any of that - just check the wiki on how to setup your radio with a custom SPI instance. Way smaller chance of weird stuff happening! (Link from the FAQ on the wiki.)

I did it in an attempt to keep all the object's memory in RTC (persistent), however I failed, since it doesn´t work and fails the same way as just:
SX1262 Lora::kRadio = new Module(HW::Lora::Cs, HW::Lora::Dio1, HW::Lora::Rst, HW::Lora::Busy, SPI, Lora::kSpiSettings);

[HeadBoffin]

Sounds like progress, once it's working I'm sure some collective input on tidy up can be done.

[jgromes]

@DarkZeros I think the fundamental problem you will run into is that it is not possible to retrieve the SX1262 state from the device itself. For example, when we change the spreading factor, we send a command to the SX1262 device. However, there is no command to retrieve the currently configured spreading factor. That's why RadioLib needs a whole bunch of state variables in RAM (intialized on startup) to keep track of the device state.

ESP32 loses RAM in deep sleep, so the state of the SX1262 device is unknown after waking up, and the only way to get it into a known state again is running begin again. Even if you manage to make it working by re-initializing the ESP32 side of the connection (which is what SX126x::modSetupBasic is essentially doing), you will run into issues with the library thinking the device is in state A, but in actuality it's in state B. The only (hacky!) workaround I can think of is to run SX126x::modSetupBasic to get SPI communication working, then reading the packet contents (if there is one) and then doing a full reinit with begin().

[DarkZeros]

Hi, I managed to avoid the recreation of the objects, and keep everything in RTC RAM!

RTC_DATA_ATTR std::optional<SPISettings> kSpi;
RTC_DATA_ATTR std::optional<ArduinoHal> kHal;
RTC_DATA_ATTR std::optional<Module> kModule;
RTC_DATA_ATTR std::optional<SX1262> kRadio;

void setup() {
  if (!kRadio) {
    ESP_LOGE("lora", "initialize");
    // Construct the RadioLib objects just once in RTC mem
    kSpi.emplace(2'000'000, MSBFIRST, SPI_MODE0);
    kHal.emplace(SPI, *kSpi);
    kModule.emplace(&kHal.value(), HW::Lora::Cs, HW::Lora::Dio1, HW::Lora::Res, HW::Lora::Busy);
    kRadio.emplace(&kModule.value());
    kRadio->begin(434.0, 125.0, 9, 7, 0x12, 10, 8, 0, false);
    kRadio->startReceive();
  }
  
  // Perform basic initialization, set back the GPIO and IRQ
  kHal->pinMode(kModule->getIrq(), kHal->GpioModeInput);
  kHal->pinMode(kModule->getGpio(), kHal->GpioModeInput);
  kModule->init();
}

The output shows that during deep sleeps the constructors are not called, and data is received properly calling read():

E (64) lora: initialize
E (65) : SX1262 contructor
E (1979) lora: listening
E (31) lora: wakeup
E (32) lora: data: Hello World! #0
E (31) lora: wakeup
E (32) lora: data: Hello World! #1

The trick resides on the std::optional<>, without it, the constructor will always be called on the object memory.
Using std::optional properly wraps the memory for RTC, and survives across deep sleep, and retains the object's values.
I still need to manually call init() on the module and set the 2 pin modes of the pins that are normally done in modSetup(). Since those are lost, Luckily having access to the underlying objects from outside means I can do that without modifying the RadioLib at all.

My question is, i this safe? Will I run into any issues with it?
Is the IRQ handling properly setup this way or am I missing something? Do I need to re-set the Interrup handling or is it fine if I just leave the IRQ uninitialized and go back to sleep?

After aproximately 100-200 packets my lora device stops receiving, so I am not sure if there is something I broke configuring it this way. Or it is just that I have a bug somewhere else in my code.