Added PowerSaving for all ESP32-based repeaters

[IoTThinks]

Hi friends,
This is the cleanup PR for this old PR #1353
The changes are below:

1. (New) Let ESP32-based repeaters to sleep immediately receiving and process a LoRa packet
2. (New) Added detailed response for powersaving CLI
3. Supported sleep for all ESP32-based repeaters
4. (New) Reduced time drift ESP32-based repeaters in power saving
5. Added getIRQGpio to return DIO1 (SX1262) and DIO0 (SX127x)
6. Fixed DIO0, DIO1 and RESET for Heltec v2. This is to allow Heltec v2 to do power saving. Well, I have a lot of requests to support Heltec v2.
7. Added getIRQGpio to return DIO0 for Lilygo T3S3 SX1276
8. Added getIRQGpio to return DIO0 for Lilygo TLoRa SX1276

I have tested with RAK4631, Heltec v3, Heltec v4 and Heltec V4 with ESPNOW.
I will set this as Draft to see if I miss anything and let all of my repeaters to run for a while.

Thanks a lot and have a nice day.

[IoTThinks]

Still need to fix for those TBeam boards.
Will do it tomorrow.

[IoTThinks]

@towerviewcams Here you go.
These files are for UPGRADE from existing repeater firmware.
https://github.com/IoTThinks/EasySkyMesh/tree/main/firmware/Testing/PR-1687

This PR should be for ESP32-based repeaters only.
I have tested RAK4631 to ensure the PR does not break PowerSaving in NRF52.

• powersaving on => It should tell you to have effect immediately.

Testing steps for ESP32-based repeaters

• powersaving on => It should tell you to to wait 2 minutes to see the power reduction. Around 14mA for Heltec v4. Around 10mA for Heltec v3.
  When receiving a LoRa packet, it will process and sleep again immediately.
• For heltecv4 with bridge, it will say "Bridge not supported" and will not go to sleep.
• powersaving off => Returns Off
• powersaving => To see status On or Off
• start ota => It will skip sleep and stay at 120mA. You can do OTA as normal. After automatically reboot, the powersaving will automatically run after 2 minutes from boot.
• clock => for time drift, around 1 minute/24 hours.

Please help to test.
Thanks a lot.

[IoTThinks]

For Heltec v4, when doing "start ota", the current may jump to ...750mA then down to 124mA.
So if the power supply is not stable for spike or set at low voltage (3.6-3.8v) the "start ota" may fail to start.
I see this happen even if "powersaving off".

It should be ok for battery.

[cra0]

+1 testing atm

[towerviewcams]

V4 testing on two boards results:

*fresh flash 1.13 firmware, powersaving delay is 22 seconds, then drops to 11.6mA sleep.
**testing/PR-1687 flashed over the 1.13 firmware and sleep is FAST! after packet process, sleep is immediate. 11.6mA
(version shows 1.12 29-Jan-2026) on the test bin for PR1687) FYI. I know this file is new because powersaving now reply with "On - After 2 minutes".

I have also verified that the receiver sensitivity remains normal with my lab test companion set to -9 power and the V4 has rssi of my test signals at -117 setup in a RF cage (normal RX level for V4 in my test cage). Also checked to make sure GC1109 has power on VCC pin full time-yes. So the LNA is always on.

Now running live on the mesh here in Oregon USA. repeating packets normally working good.

Next for Rak!

**Update
Testing 2, 4631 rak boards with new stock 1.13 works great and sleep is immediate at 4mA

[beachmiles]

There is a chance that rtc_gpio_hold_dis will release this pin P_LORA_PA_EN to its default state which is off. May want to put the rtc_gpio_hold_dis function after setting the pin. There could be an extremely short blip on waking up after deep sleep that may not really show too much during testing but is not ideal.

pinMode(P_LORA_PA_EN, OUTPUT);
digitalWrite(P_LORA_PA_EN,HIGH);
rtc_gpio_hold_dis((gpio_num_t)P_LORA_PA_EN);

The esp32 docs are not super clear on this rtc_gpio_hold_dis function and may be missing some detail that the gpio_hold_dis function had Discussion about it here.
#1600 (comment)

[IoTThinks]

@beachmiles This is required in deepsleep as I understand.

rtc_gpio_hold_dis

This PowerSaving uses light sleep.
So during lightsleep, GPIO states and RAM are intact / unchanged.

[beachmiles]

Initial testing on this firmware is very good with VERY low power usage during sleep (6.7mA at 5.095V / 34.2 mW) and its extremely quick in going back to sleep after handling traffic.
Nice job!!

The bright white LED is still flashing during communication which it ideally wouldn't be doing while in powersave.
I believe this is the P_LORA_TX_LED pin?
Ideally a check for powersaving_enabled flag could be done before running this function,
_board->onBeforeTransmit();

Otherwise you'd have to put the check in each of the onBeforeTransmit functions in all of the variants cpp files. Save a little bit of juice and reducing this small current spike during TX could help keep the PA voltage a bit more steady giving slightly better TX performance?

[mikecarper]

@beachmiles can you remove the led on code and measure the power difference? If it's small then chasing this down might not be worth it; if it's significant then this is important

[towerviewcams]

@beachmiles can you remove the led on code and measure the power difference? If it's small then chasing this down might not be worth it; if it's significant then this is important

I remove the current limit resister on all my boards. Might be a small amount but why have a light show in a sealed box that no one can see. Buy areas like Oregon is now the benefit is a bit more then slow areas.

[beachmiles]

@beachmiles can you remove the led on code and measure the power difference? If it's small then chasing this down might not be worth it; if it's significant then this is important

Will try to see if I can compile it with it off and do some testing. I am not only concerned about saving a tiny bit of power but also ensuring there is no VCC / 3.3V voltage drop with the bright LED on why transmitting as that same rail is used by the PA chip which could degrade its TX signal strength.

[IoTThinks]

@towerviewcams @beachmiles Likely very minimum power saved if turn off led after TX.

but also ensuring there is no VCC / 3.3V voltage drop with the bright LED on why transmitting as that same rail is used by the PA chip which could degrade its TX signal strength.

It makes sense.
I actually love to see the led on during TX for ...debugging :D
Generally, the LED seems to be ON for Heltec boards only.

Ideally a check for powersaving_enabled flag could be done before running this function,
_board->onBeforeTransmit();

Let me see if the code can access powersaving_flag.

[Theo-Marshall]

This works great for my ESP32C6 board. Current from 38 mA down to 6.5 mA, basically just spending energy on keeping the sx1262 in RX!

[beachmiles]

Excuse my continued editing of this post. My original findings were bad as I was disabling the PA as well as the LED so was seeing way better power savings with the PA off.

I couldn't easily access the powersaving_flag inside RadioLibWrappers.cpp so I just commented out the LED turning on in HeltecV4Board.cpp and built and flashed to my v4.

With the LED on during TX I am seeing ~3.5W spikes that drops the voltage from my 5V usb power supply from 5.09V all the way down to 4.78V.

Edit 3. @mikecarper Having the LED turned off lowers this TX peak to 3.35W and the 5.09V voltage dropping to 4.83V.
So the powersavings with the LED off only saves~150mW during TX blasts which is still not insignificant.

Im guessing the onboard 3.3V regulator is handling this voltage drop without its 3.3V output dropping too far, but Im fairly sure its 3.3V output is not going to be steady during these short blasts of the LED which could slightly decrease the PA signal strength.

Maybe this powersaving flag could be a uint8 instead of a bool so you could set different levels of powersaving for folks that want LEDs flashing and still have decent powersaving. I def love LEDs when I am debugging/troubleshooting but not when its sealed inside a box powered by a battery.

This is the build I finally got working with only 1 line commented out that turns on the LED on the heltec v4 variant.
meshcore_Heltec_v4_Repeater_PR1687_wLED_Off_v3.zip

[mikecarper]

The savings here are significant. Great find @beachmiles. With powersaving on, led off makes a lot of sense; I don't think we need to make a setting here. If you want blinking lights just turn powersaving off.

[IoTThinks]

I am willing to off the led in powersaving on.
Still finding a way to reach the powersaving_enabled flag in Heltec v3 and v4.
Do you have any suggested simple fix for this?

BTW, if this is bad not because of power consumption but because of the voltage drop during TX.
Then the LED should not be on during TX at all regardless powersaving is on or off.

[IoTThinks]

@Theo-Marshall Thanks a lot for your testing.
Glad it works as my Xiao C6 has not reached me yet.

[IoTThinks]

@mikecarper @beachmiles Confirmed having lower voltage drop via USB cable when LED is on. Measured by realtime usb monitor.
However, this issue happens even in main power and may affect TX.
Actually, the main power will be less stable to current spike like LED compared to battery.

So I suggest we or any friends here propose a way to turn off LED for all boards in all modes instead of just in powersaving mode.

Many boards have this features. RAK4631 does not have it.

[basiccode12]

@IoTThinks Hi, my apologies on a little confused.

Some places say seeed esp32s3 + WIO works, some say it works with a pin hack. Some say its not working. Any chance I can get an update or eta (no hack).

[IoTThinks]

@basiccode12 This new PR requires no pin hack / change for Xiao Wio S3 combo.
This combo has a 30-pin connector link.

You may try the bin here.

https://github.com/IoTThinks/EasySkyMesh/releases/tag/PowerSaving13

Please note Xiao S3 (non Wio) + Wio Sx1262 is different.
This combo uses basic GPIOs only.
It is supported too in the link.
I will create a PR for this combo too.

[basiccode12]

@basiccode12 This new PR requires no pin hack / change for Xiao Wio S3 combo. This combo has a 30-pin connector link.

You may try the bin here.

https://github.com/IoTThinks/EasySkyMesh/releases/tag/PowerSaving13

Please note Xiao S3 (non Wio) + Wio Sx1262 is different. This combo uses basic GPIOs only. It is supported too in the link. I will create a PR for this combo too.

Thanks!, 66mA for 2 mins then to 9mA on a 30 pin connector type. Went straight back to sleep after repeat.
----> The only thing i noticed is there were no adverts in sleep. Is it supposed to wake for adverts? Has anyone else noticed this?

[IoTThinks]

@basiccode12 All esp32 repeaters will wakeup every 30 minutes to check if to send adverts.

Last version, periodically adverts were sent correctly.

This version sleep after a few cycles after wakeup.

Let me monitor the adverts.

[IoTThinks]

@basiccode12 So your board is Xiao Wio S3.

Does it show battery percentage?

[IoTThinks]

@towerviewcams Thanks for your testing and confirmation.
Your Heltec v4.3 still can achieve 6.4mA with both LNA and FEM LNA off.

@fizzyfuzzle I have commited the changes to this PR and did a rebased so more friends can do testing with it.
I have just tested briefly this PR again and it still works on my Heltec 4.2

I will closely monitor the feedback of power consumption for Heltec v4.3.
If 18-20mA, then something is not right.
Enjoy.

[towerviewcams]

I achieve 5.7 if both are off as mentioned above

[towerviewcams]

@IoTThinks Is this now merged to PS 14.1?

[mikecarper]

Great work everyone! Can we get a new release soon with these changes in? https://github.com/IoTThinks/EasySkyMesh/releases

[fizzyfuzzle]

@IoTThinks Thanks again for your work (and all other people involved offcourse ;)

Just out of interest, why isnt the interrupt pin check code like this:

    // Skip sleep if there is a LoRa packet
    if (gpio_get_level(wakeupPin) == HIGH) return;

    // Disable CPU interrupt servicing
    portENTER_CRITICAL(&sleepMux);
    ...

[IoTThinks]

@towerviewcams Yes, I pushed to PS14.1 just now. https://github.com/IoTThinks/MeshCore/tree/PowerSaving-v14.1
Changes: IoTThinks@8223a42

@mikecarper Let's slow down a bit today for more people to do testing.
I will do a release for PS 14.1.1 tomorrow.

For now you can use this bin file: https://github.com/IoTThinks/EasySkyMesh/tree/main/firmware/Testing/2026-04-03-PowerSaving14.1-TEST
Enjoy.

[IoTThinks]

@IoTThinks Thanks again for your work (and all other people involved offcourse ;)

Just out of interest, why isnt the interrupt pin check code like this:

    // Skip sleep if there is a LoRa packet
    if (gpio_get_level(wakeupPin) == HIGH) return;

    // Disable CPU interrupt servicing
    portENTER_CRITICAL(&sleepMux);
    ...

@fizzyfuzzle The root reason is:

• We want to support sleep for all ESP32 boards.
• RTC wakeup (supports Rising High wakeup) is only available for a few boards with RTC DIO1 such as Heltec v3, v4 but not Xiao S3, T-Beam... This is what we did in the current main MeshCore.
• GPIO wakeup only supports wakeup on High or low and it is prone to ISR flood if the wakeupPin stays HIGH for long time.

If we use the above code, wakeupPin's state can be changed by another ISR. E.g: a packet comes and ISR set the wakeupPin to HIGH righ after the check.

So for the above code:

• During checking, wakeupPin is LOW (no packet). Ok to proceed.
• Immediatly after the if, a packet comes and ISR set the wakeupPin to HIGH
• Then execute the dangerous command gpio_wakeup_enable((gpio_num_t)wakeupPin, GPIO_INTR_HIGH_LEVEL); This command has the side effect to set the wakeupPin to trigger on HIGH.
• Since the wakeupPin is HIGH now, the board will hit ISR flood on HIGH events. => Interrupt WDT reset.

So we use this as extra protection, we may not want any ISR to sneak in and change the state of wakeupPin before we decide to sleep the board or not.
HIGH event will wakeup and stablize ESP32, set back wakeupPin to rising high then let ISR to continue to run immediatly after to process the packet.
The wakeupPin is rising high now. Then ISR can execuse once and no ISR flood.

 // Disable CPU interrupt servicing
    portENTER_CRITICAL(&sleepMux);

    // Skip sleep if there is a LoRa packet
    if (gpio_get_level(wakeupPin) == HIGH) {
      portEXIT_CRITICAL(&sleepMux);
      delay(1);
      return;
    }

    // Configure GPIO wakeup
    esp_sleep_enable_gpio_wakeup();
    gpio_wakeup_enable((gpio_num_t)wakeupPin, GPIO_INTR_HIGH_LEVEL); // Wake up when receiving a LoRa packet

    // MCU enters light sleep
    esp_light_sleep_start();

    // Avoid ISR flood during wakeup due to HIGH LEVEL interrupt
    gpio_wakeup_disable(wakeupPin);
    gpio_set_intr_type(wakeupPin, GPIO_INTR_POSEDGE);

    // Enable CPU interrupt servicing
    portEXIT_CRITICAL(&sleepMux);

Hope it does not confuse you more. 👯

[fizzyfuzzle]

@IoTThinks Thanks for the explanation 👌 I already assumed it was coded like that for a reason ;) makes perfectly sense now 🤓

[IoTThinks]

For more curiosity.
For the first Interrupt WDT reset, I may forget to do the cleanup before the "return"

 // Skip sleep if there is a LoRa packet
    if (digitalRead(wakeupPin) == HIGH) {
      // Avoid ISR flood during wakeup due to HIGH LEVEL interrupt
      gpio_wakeup_disable(wakeupPin);  <===========
      gpio_set_intr_type(wakeupPin, GPIO_INTR_POSEDGE); <===========
      interrupts();
      return;
    }

For the second attempt (the CPU panics), I guess FreeRTOS does not like forceful noInterrupts/Interrupts for esp_light_sleep_start();
So I change to use portENTER_CRITICAL/portEXIT_CRITICAL to be safer for FreeRTOS and esp_light_sleep_start();

[fizzyfuzzle]

@IoTThinks thanks for the info again 👌

BTW I think I found why my power consumption was slightly increased after switching between Dev branch and your main branch builds (and back), I think it turned on the radio.rxgain somewhere between my switches because of this PR which is applied on Dev branch #2124

So if that setting is indeed taking like 0.5mA on a total of 5.7mA that might indeed be what I have noticed ;)

So that mystery is also solved 😅

[towerviewcams]

I have 2 repeaters at tower sites that have this firm. No resets. Longest running is 11 hrs.
So far so good!

@IoTThinks Also, seems to respond to admin login faster on first try. might have something to do with sleep and the clock stuff? not sure but I know Kevin said something about that this might decode packets better at first decode waking up? Well, I can say its faster and on first try so far each time.

[IoTThinks]

@towerviewcams Great.

Yes, it should sleep and wakeup less abruptly.

[AI7NC]

Up to 53 hours over here, looking good. I haven't looked at amps as it's in a tree but I suspect everybody else has looked at that. 73, Nathan Campbell, AI7NC

…

On Wed, Apr 8, 2026 at 9:07 PM IoTThinks ***@***.***> wrote: *IoTThinks* left a comment (meshcore-dev/MeshCore#1687) <#1687 (comment)> @towerviewcams <https://github.com/towerviewcams> Great. Yes, it should sleep and wakeup less abruptly. — Reply to this email directly, view it on GitHub <#1687 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASMB24MYMJYODNCPKBTUPET4U4OZXAVCNFSM6AAAAACVBSMOL2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEMJRGM4DOMJTGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[IoTThinks]

Hi friends,
I have released PowerSaving 14.1.1 .
Please search for 14.1.1 bin files for Esp32 boards.
09 April 2026 - v14.1.1: Fixed reset issue in high traffic locations for ESP32-based repeaters and room servers.
https://github.com/IoTThinks/EasySkyMesh/releases/tag/PowerSaving14.1

The Power Saving code for ESP32 repeaters is the same as in this PR.

[towerviewcams]

I'm at 21 hours at a very busy, high noise repeater site and everything is running great! This location would not run 8-10 hours before. Well done Kevin!

[eureekasigns]

Edit - seems to be working on a WROOM based chip!

Board is a Circuitmess Chatter2. Initial files here. Testing repeater build.

This is really cool thank you

#1268

[terminalvelocity23]

I'm building it with my patches and deploying across the board.

[AI7NC]

Up to 3 days now on the tree repeater. (V4.2)

[towerviewcams]

1 day 22 hours on a 4.3 and running strong. Remote admin login is fast and first try through multiple repeaters now. very fast response. This is great. thank you Kevin @IoTThinks

[terminalvelocity23]

FYI it's still crashing when built with dev. Panic / exception reset.
So, when dev gets merged into main, it'll break it again.

[mihlit]

Hi, I did some tests with Xiao esp32c3 and Xiao esp32c6 boards. It improves power consumption a lot. I did a lot of measurements for these and other boards with nordic power profiler.

Power consumption-wise it works perfectly, but when powersaving is enabled and kicks in (after two minutes), sx1262 becomes deaf. Normally, signal strength of nearby repeater 10 km away is around 10-11 dB both ways. With powersaving, received signal drops to -6 dB. Disabling powersaving fixes it again. Noise floor (at least the value reported in repeater status) does not change. Using agc workaround agc.reset.interval has no effect. Any idea what could be happening here?

Note: I'm running up-to-date IoTThinks/MeshCore PowerSaving-v14.1 branch. I'm not 100 % sure if this is 1:1 with what is present in this PR.

[IoTThinks]

@towerviewcams We only merge with MeshCore main for stability.

[IoTThinks]

@mihlit I will take a look.
However, the powersaving for repeater is the same with this PR.

Which boards are you using?
Agc works fine on my Heltec v3 and 4.2.

[towerviewcams]

@towerviewcams We only merge with MeshCore main for stability.

absolutely. I did not question that sir

[terminalvelocity23]

@towerviewcams We only merge with MeshCore main for stability.

Doesn't dev get merged into main when it's time for a new release? The git tree tells me so, for example, look at this commit.
It's not like I've merged every PR out there, only those which are already merged into dev and likely to be merged into main when the time comes.

[towerviewcams]

If the pulls are shown in the commits page then it merges into dev and the next day is available via Nightly firm. Then once a new main merge happens dev is pulled forward.

[IoTThinks]

@terminalvelocity23 Just curious, this PR has not been merged into Dev.
How do you do the testing this PR with nightly firmware?

@towerviewcams I will monitor it. Do you have the nightly firmware you are testing?
Not sure if they get the update from this PR?

Usually, we will release a new PS firmware 1 week after MC release.
So we can know the issue is due to MC main and fix accordingly in PS firmware.

[towerviewcams]

@IoTThinks There must be some confusion here. I haven't asked any questions regarding this PR.

[IoTThinks]

@terminalvelocity23 This PR is not merged into dev yet.
Is this PR included in the build of the nightly builds?

We love to fix a potential issue before it is getting merged into main.
However, we may need some information how the nightly builds are created.