ESP32/LoRa: SX1276 leaving continuous receive mode when ESP32 enters deep sleep - Page 1
Forum section: electronics / general

author: jds8086
author_rank: Newbie
timestamp: May 30, 2022, 10:39:17 pm
content: Hardware: Heltec Wifi 32 LoRa V2Platform: PlatformIO/ArduinoI've gone a day and a half at this one so far. I managed to make things work with light sleep, but not deep sleep. What i am trying to do is to put the ESP32 into deep sleep mode and have it wake on GPIO26 (LoRa rx,tx complete), in other words, i want the SX1276 to listen for and inform the ESP32 of a new incoming message while the ESP32 is in deep sleep. First i'll share the code that is working (with light sleep):Code:#include "Arduino.h"#include "heltec.h"#define BAND 915E6 //you can set band here directly,e.g. 868E6,915E6String packSize = "--";String packet;void cbk(int packetSize) {packet = "";packSize = String(packetSize,DEC);for (int i = 0; i < packetSize; i++) {packet += (char) LoRa.read();}Serial.println(packet);}void setup() {Heltec.begin(false /*DisplayEnable Enable*/, true /*Heltec.Heltec.Heltec.LoRa Disable*/, true /*Serial Enable*/, true /*PABOOST Enable*/, BAND /*long BAND*/);LoRa.receive();delay(10);gpio_wakeup_enable(GPIO_NUM_26, GPIO_INTR_HIGH_LEVEL);esp_sleep_enable_gpio_wakeup();}void loop() {esp_light_sleep_start();Serial.println("Incoming Message");int packetSize = LoRa.parsePacket();if (packetSize) {cbk(packetSize);}LoRa.receive(); // Evidently the LoRa radio has to be put back into continuous recieve mode \after waking up the ESP32 from sleep, otherwise it will not raise DIO0 to \which indicates RX is done (new message has arived).}And here is my attempt (failed) with deep sleep:Code:#include "Arduino.h"#include "heltec.h"#define BAND 915E6 //you can set band here directly,e.g. 868E6,915E6String packSize = "--";String packet;void cbk(int packetSize) {packet ="";packSize = String(packetSize,DEC);for (int i = 0; i < packetSize; i++) {packet += (char) LoRa.read();}Serial.println(packet);}void setup() {Heltec.begin(false /*DisplayEnable Enable*/, true /*Heltec.Heltec.Heltec.LoRa Disable*/, true /*Serial Enable*/, true /*PABOOST Enable*/, BAND /*long BAND*/);LoRa.receive();esp_sleep_enable_ext0_wakeup(GPIO_NUM_26, 1);delay(10);int packetSize = LoRa.parsePacket();if (packetSize) {cbk(packetSize);Serial.println("Message Processed");}Serial.println("Starting deep sleep");//rtc_gpio_hold_en(GPIO_NUM_26);esp_deep_sleep_start();}void loop() {}The LoRa radio is not sending DIO0 high to indicate a new message is "in", i am assuming it is leaving continuous receive mode but not sure how to keep this from happening. I have verified that GPIO26 will wake the ESP32 when 3.3v is applied, and have an LED on GPIO26 to indicate when it is high.

author: jds8086
author_rank: Newbie
timestamp: June 05, 2022, 01:46:04 am
content: After two days on this i've verified that there is no change on the SPI bus between light & deep sleep modes. The only thing that has come to light is that for some reason when i started looking at pin 14 (to pin 7 on LoRa NRESET) something strange happened. I hooked my logic analyzer to it then all the sudden everything that wasn't working started working (DIO0 was going high while the ESP32 was in deep sleep mode). So i though this must be some kind of pull up/down issue here that shows when the uC goes to sleep, but after going down that path, that does not appear to be the issue. Trying to pull it up/down has no effect, the only thing that seems to have the effect is having a decently long wire hooked to the pin just floating in air, or a short wire that i am grabbing the end of with my hand. Someone please enlighten me on this one.

author: jds8086
author_rank: Newbie
timestamp: June 05, 2022, 01:56:33 am
content: I just found that setting INPUT_PULLUP on that pin right before going into deep sleep did the trick.

author: jds8086
author_rank: Newbie
timestamp: June 05, 2022, 02:07:35 am
content: This is one hell of a roller coaster.. I put my amp meter in line with the power and found that it was drawing more power than it had before in deep sleep. I pulled the power from the sending device and a couple of seconds later the current draw dropped where it should be but now the problem is it doesn't wake back up when i start sending again! If i remove INPUT_PULLUP from pin 14 i notice that it drops to the lower current draw instantly, so for some reason pulling that pin up keeps it awake for a couple of seconds. Or the ESP32 is actually going into deep sleep and the radio is what is pulling the power, seeing around 11mA.EDIT: I found that calling LoRa.receive() (puts radio into continuous rx mode) before going to sleep made it so that there can be any amount of delay between receiving messages and it will still wake up. I saw over the SPI bus that before going to sleep it was putting the radio into single receive mode. If my understanding is correct, in this mode it will wait x amount of time and if it doesn't see anything it will put the radio into standby or sleep mode can't remember which now. I think this explains 11mA draw until i stop sending it messages then it drops to ~1.5mA. So i guess maybe i'm just not going to be able to get that ~1.5mA draw and still be able to wake up when a message comes in.

author: Marco
author_rank: Super Contributor
timestamp: June 05, 2022, 02:53:18 am
content: Shouldn't you be calling rtc_gpio_deinit at start of setup to allow the DIO connected pin on the microcontroller to be used normally again? AFAICS esp_sleep_enable_ext0_wakeup reassigns it to RTC.The nReset pin could be getting glitched during deep sleep, with the capacitance it resists the glitch. Maybe you could assign the pin to RTC (rtc_gpio_init) before deep sleep? That way it should remain functioning fully normally.PS. some of the code in Heltec.begin could be pulsing the reset pin too, you probably want to set a flag and not call it every wakeup.

author: jds8086
author_rank: Newbie
timestamp: June 05, 2022, 02:54:03 pm
content: Using rtc_gpio_init(GPIO_NUM_14) didn't seem to have the same effect as pinMode(14, INPUT_PULLUP), it would not wake up that way. I didn't see any noise on that pin either but i just had a logic analyzer, not a scope connected to it. I've ran into another roadblock with this which is that when it wakes back up, it resets LoRa and the packet that we woke up for is now gone lol. I attempted to only do certain parts of the LoRa initialization unless it was a fresh (non irq) wakeup, but haven't yet been able to make it work right. I get messages as they come in but it is instantly waking up as soon as it goes to sleep which i believe the cause of that is DIO0 is not going low after the packet is read in to the uC. That is a whole different story though.