To support PowerSaving for all ESP32-based repeaters and NRF52-based repeaters. #1353

IoTThinks · 2026-01-09T11:31:34Z

Hi all,
This PR is to add PowerSaving for all ESP32-based repeaters and NRF52-based repeaters including 4 boards with old SX1276.

To support PowerSaving for all ESP32-based repeaters and NRF52-based repeaters.
To add flag RADIO_SX1276 to support PowerSaving for SX1276. SX1276 uses DIO0 to wakeup MCU instead of DIO1
To expose LoRa pins at platformio.ini instead of header files
When BLE is enabled on NRF52, Powersaving will be skipped as same as when enabling WiFi on ESP32. This is to allow OTA in powersaving mode.

Credits:
(12 Jan 2026) In latest approach, I use hardware and software events instead of SuspendLoop and ResumeLoop to avoid deadlock issue.

I have adopted neat sleep/wakeup using SuspendLoop and ResumeLoop from Mr. Fschrempf and the check of HIGH-level DIO1 to prevent deadlock from Mr. 4np at NRF52 Repeater Powersaving. Thanks a lot.
However, I implemented our own style as same as PowerSaving for ESP32 to have a similar architecture for powersaving. The code should be simple, effective and consistent for all ESP32 and NRF52 boards.

Known issue:

ESP32-based repeaters may have the clock drift forward while NRF52-based repeaters may have the clock slowdown. This is due to inaccurate / slow clock during sleep. We will improve on this issue, however it may be a cosmetic bug for now.

Testing:
I have tested the change with main branch and achieve 10mA for ESP32-based repeaters and 6mA for NRF52-based repeaters.
Some kind friends have tested boards with SX1276 working.

After the merge to dev, I have compiled 29 boards and confirm no compilation error. I have tested the merged code and it worked for Heltec v3, v4 and RAK4631.

Heltec_v3_repeater Heltec_WSL3_repeater heltec_v4_repeater LilyGo_T3S3_sx1262_repeater
T_Beam_S3_Supreme_SX1262_repeater Tbeam_SX1262_repeater Station_G2_repeater Station_G2_logging_repeater
Xiao_C3_repeater Xiao_S3_WIO_repeater Heltec_Wireless_Tracker_repeater heltec_tracker_v2_repeater
RAK_4631_repeater SenseCap_Solar_repeater Heltec_t114_repeater t1000e_repeater
Xiao_nrf52_repeater LilyGo_T-Echo_repeater LilyGo_T-Echo-Lite_repeater ProMicro_repeater
WioTrackerL1_repeater Heltec_mesh_solar_repeater RAK_WisMesh_Tag_repeater ThinkNode_M1_repeater
Mesh_pocket_repeater
Heltec_v2_repeater LilyGo_T3S3_sx1276_repeater Tbeam_SX1276_repeater LilyGo_TLora_V2_1_1_6_repeater

Heltec v3 and RAK 4631 in PowerSaving mode

This is a RAK4631 repeater with PowerSaving in action: Sleep at 6mA, wakeup when a LoRa packet comes, process it, wake up for 5s and go to sleep again.

Power.Saving.for.RAK4631.in.action.mp4

…repeaters.

…es DIO0 to wakeup MCU instead of DIO1

fschrempf

@IoTThinks Thanks for your work! As I have already posted a solution for the sleep implementation for NRF52 in #1238 before, would you mind rebasing your work onto the latest version of this PR?

src/helpers/radiolib/RadioLibWrappers.cpp

src/helpers/NRF52Board.cpp

fschrempf · 2026-01-09T20:56:16Z

src/helpers/NRF52Board.cpp

+  uint8_t sd_enabled;
+  sd_softdevice_is_enabled(&sd_enabled); // To set sd_enabled to 1 if the BLE stack is active.
+
+  if (!sd_enabled) { // BLE is off ~ No active OTA, safe to go to sleep


Instead of checking for the softdevice, I would rather implement a generic mechanism to prevent the sleep which can be used in other cases too. See fe17894.

I would love to have consistent approach for ESP32 and NRF52.
In ESP32, we don't have "enterSleep" and "preventSleep".

I think we need to keep thing simple and effective.
This code works not only for OTA, but also for repeaters with WiFi or BLE active due to any reasons.

You seem to miss the point. The mentioned commit from my PR implements an easy and straight-forward way in the BaseBoard base class, that can be used by all board types. Your implementation is specific to ESP32 and can only be used from inside the board class.

I would have same "sleep" methods for ESP32 and NRF52.

In #1238 I floated the idea to use safeToSleep. This could easily be implemented in a generic manner by adding it to MeshCore.h and overriding it in ESP32 as well as NRF52 (or even specific variants if necessary ). Pseudo patch:

diff --git a/src/MeshCore.h b/src/MeshCore.h index b52ac21..a0ea11b 100644 --- a/src/MeshCore.h +++ b/src/MeshCore.h @@ -59,6 +59,11 @@ public: virtual void enterSleep(uint32_t secs) { if (!prevent_sleep) sleep(secs); } + virtual bool safeToSleep() { return true; } virtual void preventSleep() { prevent_sleep = true; } virtual uint32_t getGpio() { return 0; } virtual void setGpio(uint32_t values) {}

With your changes moving the DIO1 pin configuration from the header files into platform.io the safeToSleep method should probably only require implementation in the NRF52Board.h and ESP32Board.h. Pseudo patch:

diff --git a/src/helpers/NRF52Board.h b/src/helpers/NRF52Board.h index f187242..fac7fc3 100644 --- a/src/helpers/NRF52Board.h +++ b/src/helpers/NRF52Board.h @@ -16,6 +16,11 @@ public: virtual void reboot() override { NVIC_SystemReset(); } virtual void sleep(uint32_t secs) override; virtual void onRXInterrupt() override; virtual bool safeToSleep() override { return digitalRead(P_LORA_DIO_1) == LOW; } };

IoTThinks · 2026-01-12T04:54:36Z

To fix the memory leaking for SoftwareTimer, to perform internal testing and to let the community to do beta test for NRF52-based repeaters.
I will push the fix to this PR this week.

fschrempf · 2026-01-12T06:20:17Z

Ok, let me try to put wakeupTimer in NRF52Board as you suggested.

I've already done that work in #1238. There is no reason to reimplement my suggestions. Please, just use my branch and add your commits on top.

IoTThinks · 2026-01-13T09:13:47Z

Let me and some friends in busy-traffic areas test to use a simpler but more robust implementation without SuspendLoop, ResumeLoop and not touching setFlag for NRF52 repeaters.
I will push another implementation here in a few days.

IoTThinks · 2026-01-13T15:08:17Z

I have pushed the change to implement power saving for NRF52 to use System-Idle On instead.

fschrempf

As you are somehow seeking to provide an alternative solution for #1238, can you at least mention in the description how your solution works and what benefits it has over the one in my PR? Thanks!

Also, can you please try to separate your changes logically into multiple commits and not chronologically stack each improvement as new commit on top of the previous one? As I mentioned before this is what git rebase --interactive and git push --force are made for.

I know that a lot of people do it like this, but this is not how git is intended to be used and it makes it impossible to have useful history in the end. And it leads you to copy code from my branch discarding the authorship (which can be seen as somewhat disrespectful among developers) instead of just doing git cherry-pick from my branch.

This is also something I wish the maintainers would take more into account when reviewing/merging PRs.

examples/simple_repeater/MyMesh.cpp

src/helpers/radiolib/RadioLibWrappers.cpp

src/helpers/NRF52Board.cpp

IoTThinks · 2026-01-14T01:05:46Z

can you at least mention in the description how your solution works and what benefits it has over the one in my PR? Thanks!

I did mention in the PR. Thanks a lot.

However, in my yesterday proposed solution, I don't use these methods any more.
I have changed the solution approach to use safer hardware / software events instead.

IoTThinks · 2026-01-14T07:23:29Z

I have put in changes to implement light sleep for ESP32 without changing setFlag at all.

To put back missing code board->onAfterTransmit();

fschrempf

I see you did a force-push, but the commits are still not separated properly. If you need help doing it, feel free to ask.

One more thing: You always begin your comments end commit subjects with "To ...". This doesn't really makes sense. Just leave out the "to" and state your changes in an imperative way.

fschrempf · 2026-01-14T08:05:27Z

variants/heltec_v2/platformio.ini

  -D WIFI_DEBUG_LOGGING=1
  -D WIFI_SSID='"myssid"'
  -D WIFI_PWD='"mypwd"'
-  -D OFFLINE_QUEUE_SIZE=256  


This shouldn't be removed, right?

fschrempf · 2026-01-14T08:05:57Z

variants/lilygo_tlora_v2_1/platformio.ini

  -D WIFI_SSID='"ssid"'
  -D WIFI_PWD='"password"'
  -D WIFI_DEBUG_LOGGING=1
-  -D OFFLINE_QUEUE_SIZE=256  


This shouldn't be removed, right?

src/helpers/ESP32Board.h

fschrempf · 2026-01-14T10:08:36Z

src/helpers/ESP32Board.h

-      }
+    // To configure GPIO wakeup
+    esp_sleep_enable_gpio_wakeup();
+    gpio_wakeup_enable((gpio_num_t) wakeupPin, GPIO_INTR_HIGH_LEVEL); // To wake up when receiving a LoRa packet


Remove the gpio_num_t cast. It's not needed.

fschrempf · 2026-01-14T10:09:32Z

src/helpers/ESP32Board.h

+#if defined(ESP32) && defined(RADIO_SX1276) && defined(P_LORA_DIO_0) // SX1276
+    gpio_set_intr_type((gpio_num_t)P_LORA_DIO_0, GPIO_INTR_POSEDGE);
+#elif defined(ESP32) && defined(P_LORA_DIO_1) // SX1262
+    gpio_set_intr_type((gpio_num_t)P_LORA_DIO_1, GPIO_INTR_POSEDGE);
 #endif


This whole block can be replaced with a single line

Suggested change

#if defined(ESP32) && defined(RADIO_SX1276) && defined(P_LORA_DIO_0) // SX1276

gpio_set_intr_type((gpio_num_t)P_LORA_DIO_0, GPIO_INTR_POSEDGE);

#elif defined(ESP32) && defined(P_LORA_DIO_1) // SX1262

gpio_set_intr_type((gpio_num_t)P_LORA_DIO_1, GPIO_INTR_POSEDGE);

#endif

gpio_set_intr_type(wakeupPin, GPIO_INTR_POSEDGE);

fschrempf · 2026-01-14T10:09:42Z

src/helpers/ESP32Board.h

+    gpio_set_intr_type((gpio_num_t)P_LORA_DIO_1, GPIO_INTR_POSEDGE);
 #endif
+
+     // To disable CPU interrupt servicing


Suggested change

// To disable CPU interrupt servicing

// To enable CPU interrupt servicing

fschrempf · 2026-01-14T10:10:29Z

src/helpers/NRF52Board.cpp

 #if defined(NRF52_PLATFORM)
 #include "NRF52Board.h"
-
+#include "nrf_sdm.h"


I don't think we need this, do we?

src/helpers/NRF52Board.cpp

fschrempf · 2026-01-14T10:12:38Z

src/helpers/NRF52Board.cpp

+  uint8_t sd_enabled;
+  sd_softdevice_is_enabled(&sd_enabled); // To set sd_enabled to 1 if the BLE stack is active.
+
+  if (!sd_enabled) { // BLE is off ~ No active OTA, safe to go to sleep


fschrempf · 2026-01-14T10:18:51Z

src/helpers/NRF52Board.cpp

+  uint32_t startTime = millis();
+
+  // To wake up when a LoRa packet comes or sleep timeout. Safe to 49-day overflow
+  while (digitalRead(P_LORA_DIO_1) == LOW && (millis() - startTime < secs*1000)) {


What about the boards with DIO0 interrupt instead of DIO1? The digitalRead(P_LORA_DIO_1) would be incorrect in this case, right?

As mentioned above we could use a getIrqPin() function to retrieve the correct pin.

IoTThinks · 2026-01-14T10:58:34Z

I see you did a force-push, but the commits are still not separated properly. If you need help doing it, feel free to ask.

I did force-push to fix some simple missing codes.
Let the code being reviewed for a while, then we can start over clean.
I don't like rebase actually.
Startover from heavily reviewed and commented code is faster and cleaner.

And clean PRs are usually approved faster. :D

One more thing: You always begin your comments end commit subjects with "To ...". This doesn't really makes sense. Just leave out the "to" and state your changes in an imperative way.

Well, if you don't like then I will not include the "To..."
It is the style rather than sense.

fschrempf · 2026-01-14T11:01:53Z

I did mention in the PR. Thanks a lot.

I know, thanks. If FOSS developers work on the same topic and take over work from each other they usually credit by taking the commits with the original authorship.

I have put in changes to implement light sleep for ESP32 without changing setFlag at all.

Ok, good idea. I think we can do it like this.

fschrempf · 2026-01-14T11:04:14Z

It is the style rather than sense.

Ok, maybe. To me it sounds awkward and I've never seen this style elsewhere. But maybe that's just me...

fschrempf · 2026-01-14T11:05:13Z

Let the code being reviewed for a while, then we can start over clean.

Ok, do as you like.

IoTThinks · 2026-01-14T11:14:53Z

@fschrempf Thanks a lot for your comprehensive reviews.
I appreciate your great effort.

Since, the code for lightsleep for esp32 and NRF52 have changed.
I will let my boards to run a while this week to make sure they are stable.
And wait for reviews from other friends here.

Then I will make a final clean push.
Thanks a lot.

4np · 2026-01-14T17:58:24Z

@IoTThinks , thanks for the work here :) I'll test this out on my RAK repeater.

I was thinking if it would be good to show how much the repeater has slept on the repeater stats to get some insight. Could very well be added in some other PR of course.

IoTThinks · 2026-01-15T02:38:05Z

I was thinking if it would be good to show how much the repeater has slept on the repeater stats to get some insight. Could very well be added in some other PR of course.

Hi @4np,
It is a nice suggestion.

No idea if we can change the repeater stats on our own. Or we need help from MeshCore app developer.
Let me check on that.

CLI is surely possible.
There are many "hidden" CLI commands which are not suggested by Command help of MeshCore app.

IoTThinks · 2026-01-15T02:56:45Z

I know, thanks. If FOSS developers work on the same topic and take over work from each other they usually credit by taking the commits with the original authorship.

@fschrempf: Oh, I see.
I would love to have your authorship and your valuable improvements in the PR too.
Let's work together in the final push.

4np

I had a look at the changes and provided some -minor- feedback.

4np · 2026-01-15T08:34:52Z

src/helpers/NRF52Board.cpp

+  uint8_t sd_enabled;
+  sd_softdevice_is_enabled(&sd_enabled); // To set sd_enabled to 1 if the BLE stack is active.
+
+  if (!sd_enabled) { // BLE is off ~ No active OTA, safe to go to sleep


In #1238 I floated the idea to use safeToSleep. This could easily be implemented in a generic manner by adding it to MeshCore.h and overriding it in ESP32 as well as NRF52 (or even specific variants if necessary ). Pseudo patch:

diff --git a/src/MeshCore.h b/src/MeshCore.h index b52ac21..a0ea11b 100644 --- a/src/MeshCore.h +++ b/src/MeshCore.h @@ -59,6 +59,11 @@ public: virtual void enterSleep(uint32_t secs) { if (!prevent_sleep) sleep(secs); } + virtual bool safeToSleep() { return true; } virtual void preventSleep() { prevent_sleep = true; } virtual uint32_t getGpio() { return 0; } virtual void setGpio(uint32_t values) {}

With your changes moving the DIO1 pin configuration from the header files into platform.io the safeToSleep method should probably only require implementation in the NRF52Board.h and ESP32Board.h. Pseudo patch:

diff --git a/src/helpers/NRF52Board.h b/src/helpers/NRF52Board.h index f187242..fac7fc3 100644 --- a/src/helpers/NRF52Board.h +++ b/src/helpers/NRF52Board.h @@ -16,6 +16,11 @@ public: virtual void reboot() override { NVIC_SystemReset(); } virtual void sleep(uint32_t secs) override; virtual void onRXInterrupt() override; virtual bool safeToSleep() override { return digitalRead(P_LORA_DIO_1) == LOW; } };

4np · 2026-01-15T08:38:10Z

src/helpers/ESP32Board.h

+
+    // MCU to enter light sleep
+    esp_light_sleep_start();
+    Serial.println(esp_sleep_get_wakeup_cause());


Probably it's better to use the MESH_DEBUG_PRINTLN function:

Suggested change

Serial.println(esp_sleep_get_wakeup_cause());

MESH_DEBUG_PRINTLN(esp_sleep_get_wakeup_cause());

4np · 2026-01-15T08:43:19Z

src/helpers/NRF52Board.h

  virtual float getMCUTemperature() override;
  virtual void reboot() override { NVIC_SystemReset(); }
+  virtual void enterLightSleep(uint32_t secs);
+  virtual void sleep(uint32_t secs) override;


Why do we need 2 functions, it looks like all can be implemented inside sleep()? In case we do want 2 functions, I don't think enterLightSleep() should have public visibility.

IoTThinks · 2026-01-15T08:57:43Z

@4np Thanks a lot for review.

I will fix for some feedbacks and will check how much changes if using safeToSleep.

h0lad · 2026-01-15T16:01:48Z

I just profiled this with my rusty old Nordic Power Profiler II.

Looks good so far! Makes repeaters finally competitive to our Mesthastic colleagues.

It reduced the idle consumption from ~26mA to most times sleeping with 7.5-8mA.

Hardware: HT-CT62 (ESP32C3 + SX1262) <- 3.0V LDO <- TI BQ25185 <- Nordic Power Profiler II (3.7V)

Without Patch

With Patch

h0lad · 2026-01-15T16:11:10Z

When implementing please keep in mind hat we also have the RAK3172 in the 'variants'. It's a ST STM32WLE55C based device. This one is still missing a power saving implementation - it's on my list of looking deeper into it but my schedule is a bit too tight right now.

IoTThinks · 2026-01-16T00:47:32Z

@h0lad Is RAK3172 repeater compilable now?

Last time, it is not compilable when I try.

Thanks for testing.
So it works for esp32c3.

IoTThinks · 2026-01-16T02:29:40Z

@h0lad Are you able to compile for RAK3172?
Last time, I can use RadioLib and stm32duino for it.

4np · 2026-01-16T08:56:48Z

@IoTThinks , rak3x72_repeater compiles for me (on macOS), but it fails on mergebin:

Do not know how to make File target `mergebin'. Stop.

$ FIRMWARE_VERSION="adhoc-$(date +"%Y%m%d%H%M")" sh build.sh build-firmware rak3x72_repeater
...
Building .pio/build/rak3x72_repeater/firmware.bin
========================================= [SUCCESS] Took 10.47 seconds =========================================

Environment       Status    Duration
----------------  --------  ------------
rak3x72_repeater  SUCCESS   00:00:10.472
========================================== 1 succeeded in 00:00:10.472 ==========================================
Processing rak3x72_repeater (board: rak3172; platform: platformio/[email protected]; framework: arduino)
-----------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/rak3172.html
PLATFORM: ST STM32 (19.1.0) > BB-STM32WL
HARDWARE: STM32WLE5CCU 48MHz, 64KB RAM, 224KB Flash
DEBUG: Current (stlink) External (jlink, stlink)
PACKAGES:
 - framework-arduinoststm32 @ 0.0.0
 - framework-cmsis @ 2.50900.0 (5.9.0)
 - toolchain-gccarmnoneeabi @ 1.120301.0 (12.3.1)
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 25 compatible libraries
Scanning dependencies...
Dependency Graph
|-- SPI @ 1.1.0
|-- Wire @ 1.0.0
|-- RadioLib @ 7.5.0
|-- Crypto @ 0.4.0
|-- RTClib @ 2.1.4
|-- Melopero RV3028 @ 1.2.0
|-- CayenneLPP @ 1.6.1
|-- Adafruit Little File System Libraries @ 0.11.0
|-- Adafruit BusIO @ 1.17.2
|-- ed25519
|-- nrf52
Building in release mode
*** Do not know how to make File target `mergebin' (~/Developer/MeshCore/mergebin).  Stop.
========================================== [FAILED] Took 1.13 seconds ==========================================

Environment       Status    Duration
----------------  --------  ------------
rak3x72_repeater  FAILED    00:00:01.130
===================================== 1 failed, 0 succeeded in 00:00:01.130 =====================================

Something else that came up in talks with other MeshCore users is that some have a GPS inside their repeaters and use the GPS for location and clock sync. In the PRs we may have overlooked this use case.

Does GPS support low power sleep?
If so, how long will it take to regain a fix and / or update the clock?
Should the wake-up work time interval change from 5s to whatever duration the GPS requires to do its work?
If GPS isn't put to sleep, does it keep doing its job while ESP32 / NRF52 is sleeping?

Or should power saving be unsupported altogether in the case a GPS is present?

IoTThinks · 2026-01-16T10:55:25Z

@4np Let me check the code to understand the behaviour of a GPS module during the current sleep.

My guess now is MCU will sleep and GPS may not sleep.

For repeaters, GPS may be mainly for time sync as the position is quite stationary.

Btw, I still think we should remove time in repeaters.

IoTThinks · 2026-01-16T11:05:22Z

@4np This is RAK4631 repeater with GPS module from RAK.
With GPS module => 44mA. Nearly same as Heltec v3 with no GPS module at 57mA. It defeats the purpose of saving 6mA and waste 32 mA for GPS module.
Without GPS module => 12mA by default.

Although we may optimize code for GPS module to ... sleep more, I still think GPS module for repeaters is not neccessary as we actually do not need "time" for repeaters.

However, let me check what is the behavior now.

h0lad · 2026-01-16T11:05:24Z

I can compile the RAK3172 here (Opensuse Thumbleweed) without problems. Even build a energy harvester PCB for it - runs fine!

Only the power consumption is a bit problematic: the STM32WLE55C sucks around 14mA while hanging in Idle without power saving.

Building in release mode
Checking size .pio/build/rak3x72_repeater/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [==        ]  22.2% (used 14528 bytes from 65536 bytes)
Flash: [========  ]  79.2% (used 181696 bytes from 229376 bytes)

IoTThinks · 2026-01-16T11:08:08Z

I can compile the RAK3172 here (Opensuse Thumbleweed) without problems. Even build a energy harvester PCB for it - runs fine!

Only the power consumption is a bit problematic: the STM32WLE55C sucks around 14mA while hanging in Idle.
Building in release mode
Checking size .pio/build/rak3x72_repeater/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [==        ]  22.2% (used 14528 bytes from 65536 bytes)
Flash: [========  ]  79.2% (used 181696 bytes from 229376 bytes)

Love to see RAK3172 working.
You use the default platformio.ini from MeshCore's main, right?
I'm on PlatformIO Windows, btw.

By right, RAK3172 can sleep very well as it is STM32.

h0lad · 2026-01-16T11:10:10Z

By right, RAK3172 can sleep very well as it is STM32.

Yes. The STM32W- and the newer STM32U-series have the "sleep very deep and wake up extremely fast" in their silicon blood.

You use the default platformio.ini from MeshCore's main, right?

I can compile the main and your branch without problems.

Maybe give it a try with K/X/Ubuntu 24.04.x - it's pretty much the industrial standard for embedded development until the next LTS from Ubuntu is being released.

IoTThinks · 2026-01-16T11:16:51Z

Ok, let me try the RAK3172.

IoTThinks added 2 commits January 9, 2026 17:38

To support PowerSaving for all ESP32-based repeaters and NRF52-based …

e30b611

…repeaters.

To add flag RADIO_SX1276 to support PowerSaving for SX1276. SX1276 us…

ea42140

…es DIO0 to wakeup MCU instead of DIO1

fschrempf reviewed Jan 9, 2026

View reviewed changes

IoTThinks marked this pull request as draft January 12, 2026 04:53

IoTThinks marked this pull request as ready for review January 13, 2026 15:05

fschrempf suggested changes Jan 13, 2026

View reviewed changes

examples/simple_repeater/MyMesh.cpp Outdated Show resolved Hide resolved

src/helpers/radiolib/RadioLibWrappers.cpp Outdated Show resolved Hide resolved

src/helpers/NRF52Board.cpp Show resolved Hide resolved

IoTThinks force-pushed the MCdev-PowerSaving-for-all-ESP32-NRF52-repeaters branch from 7b0546a to c8e7727 Compare January 14, 2026 00:32

IoTThinks added 2 commits January 14, 2026 07:47

To expose LoRa pins at platformio.ini instead of header files

07b0c72

To implement power saving for NRF52 using System-Idle On

67a4398

IoTThinks force-pushed the MCdev-PowerSaving-for-all-ESP32-NRF52-repeaters branch from c8e7727 to 67a4398 Compare January 14, 2026 00:50

IoTThinks requested a review from fschrempf January 14, 2026 02:34

To implement light sleep for ESP32 without changing setFlag

f988eb3

To put back missing code board->onAfterTransmit();

IoTThinks force-pushed the MCdev-PowerSaving-for-all-ESP32-NRF52-repeaters branch from 9879bd4 to f988eb3 Compare January 14, 2026 07:31

fschrempf suggested changes Jan 14, 2026

View reviewed changes

fschrempf mentioned this pull request Jan 14, 2026

NRF52 Repeater Powersaving #1238

Open

4np reviewed Jan 15, 2026

View reviewed changes

IoTThinks mentioned this pull request Jan 15, 2026

Added powersaving to all ESP32 boards with RTC-supported DIO1 #1266

Merged

	// To disable CPU interrupt servicing
	// To enable CPU interrupt servicing

	Serial.println(esp_sleep_get_wakeup_cause());
	MESH_DEBUG_PRINTLN(esp_sleep_get_wakeup_cause());

To support PowerSaving for all ESP32-based repeaters and NRF52-based repeaters. #1353

Are you sure you want to change the base?

To support PowerSaving for all ESP32-based repeaters and NRF52-based repeaters. #1353

Conversation

IoTThinks commented Jan 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fschrempf left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

IoTThinks commented Jan 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fschrempf commented Jan 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

IoTThinks commented Jan 13, 2026

Uh oh!

IoTThinks commented Jan 13, 2026

Uh oh!

fschrempf left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

IoTThinks commented Jan 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

IoTThinks commented Jan 14, 2026

Uh oh!

fschrempf left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

IoTThinks commented Jan 14, 2026

Uh oh!

fschrempf commented Jan 14, 2026

Uh oh!

fschrempf commented Jan 14, 2026

Uh oh!

fschrempf commented Jan 14, 2026

Uh oh!

IoTThinks commented Jan 14, 2026

Uh oh!

4np commented Jan 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

IoTThinks commented Jan 9, 2026 •

edited

Loading

IoTThinks commented Jan 12, 2026 •

edited

Loading

fschrempf commented Jan 12, 2026 •

edited

Loading

IoTThinks commented Jan 14, 2026 •

edited

Loading

4np commented Jan 14, 2026 •

edited

Loading

4np left a comment •

edited

Loading

h0lad commented Jan 15, 2026 •

edited

Loading

h0lad commented Jan 15, 2026 •

edited

Loading

IoTThinks commented Jan 16, 2026 •

edited

Loading

4np commented Jan 16, 2026 •

edited

Loading

h0lad commented Jan 16, 2026 •

edited

Loading

IoTThinks commented Jan 16, 2026 •

edited

Loading

h0lad commented Jan 16, 2026 •

edited

Loading