I recently received my my Xiao ESP32S3 & SX1262 combo. I’m using it for a lora P2P battery powered project. The lora side all worked as expetced. However I had issues with Deep Sleep current usage. Using the following code to test.
First,
I used a bench supply @3.8V connect to the battery pads on the underside of the ESP32S3 in series with an ampmeter.
I removed the lora sx1262 module connected via the B2B connector
Current reading 15.9 micro amps - all good!
Next,
I replaced the lora sx1262 into the B2B connector. The current reading in deep sleep is 2.2mA. Too high for sustainable battery use.
Effectively I’ve ruled out the green led and it’s external pull down resistor and the External switch on GPIO1 as the issue. As the ESP only draws 15.9Micro Amps. The issues is the excessive current draw, when the sx1262 is in circuit.
Grateful for any input
#include "driver/rtc_io.h"
#include <RadioLib.h>
#define USE_EXT0_WAKEUP 1 // 1 = EXT0 wakeup, 0 = EXT1 wakeup
#define WAKEUP_GPIO GPIO_NUM_1 // Only RTC IO are allowed - ESP32 Pin example
RTC_DATA_ATTR int bootCount = 0;
// Pins number for SX1262 Chip
#define LORA_MISO 8
#define LORA_SCK 7
#define LORA_MOSI 9
#define LORA_CS 41 //NSS
#define LORA_DIO2 38
#define LORA_DIO1 39 // irq
#define LORA_RESET 42
#define LORA_BUSY 40
const uint8_t greenLed = 6;
void setup() {
Serial.begin(115200);
delay(1000); //Take some time to open up the Serial Monitor
++bootCount;
Serial.print("Boot number");
Serial.println(bootCount);
delay(500);
pinMode(greenLed, OUTPUT);
digitalWrite(greenLed, HIGH);
delay(500);
digitalWrite(greenLed, LOW);
SX1262 radio = new Module(LORA_CS, LORA_DIO1, LORA_RESET, LORA_BUSY);
esp_sleep_enable_ext0_wakeup(WAKEUP_GPIO, 1); //1 = High, 0 = Low
rtc_gpio_pullup_dis(WAKEUP_GPIO);
rtc_gpio_pulldown_en(WAKEUP_GPIO);
//Go to sleep now
Serial.println("Putting Radio to Sleep");
radio.sleep();
Serial.println("Going to sleep now");
esp_deep_sleep_start();
}
void loop() {
}
Yes. I’ve got radio.sleep() in the code posted.
I’ve had some success by externally pulling NSS high with a 10K resistor. I’m yet to fully test it but the current in deep sleep is now 20 micro amps.
Interesting, removing radio.sleep() raises the current usage to 330mA in deep sleep. Cheers
So looks like that was the issue, and can be marked as the solution by @msfujino , please do. Also please edit the Posts and use the Code tags " </> " above , just paste it in there. Makes it easier to read and allows others to find it fast. 20uA. is pretty stellar iMO
What is the distance your getting , If I may ask?
Sounds good any Sensors?
Thanks PJ.
Sorted the formatting.
The application only requires a distance of 200mtrs, up and over a hill. It performs very reliably for such a low cost mcu and radio.
Solution - Pin 41 on the XIAO ESP32S3 connects to NSS on the SX1262 via the B2B connector (sense) . The pin is active LOW for Chip Select (CS/NSS) it needs to be held high via a 10K ohn resistor. Pin 41 isn’t physically accessable on the ESP32S3. So if you couple the boards together via the B2B connector the only way to hold it high is solder a lead from NSS on SX1262 to 3v3 via 10K resistor.
It’s only an issue if you want to achive ~20uA Deep Sleep current.
Hope that helps someone !
I have measured the sleep current and there is a phenomenon that I do not understand.
After executing radio.sleep(), wait 5 seconds and then execute esp_deep_sleep_start(), but it appears that radio is not sleeping during these 5 seconds. When S3 sleeps, the overall sleep current is 10uA, as expected.
The module I am using is slightly different from the one you are using, but the basic operation should be the same.
I am applying 3.8V to the S3 battery pad and measuring at ppk2.
It is 5 seconds to measure the current when only SX1268 sleeps
.
I’d try putting a delay between radio.begin() and radio.sleep() maybe the radio is in an indeterminate state when sleep() is called?
Putting delay() has no effect.
I will do some more research.
EDIT:
Since the current of radio is as small as 1 mA compared to the 30 mA of S3 current, the current just seemed to change very little when
radio.sleep() was executed.
PJ 
