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

[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?

[basiccode12]

@basiccode12 So your board is Xiao Wio S3.

Does it show battery percentage?

https://core-electronics.com.au/xiao-esp32s3-meshtastic-lora-wio-sx1262-wireless-communication-device.html?gad_campaignid=17417005429

this is mine...to avoid confusion.

no batt percent. I dont think its capable of it, which is suprising considering it comes with dedicated batt pads. I just measure manually.

[basiccode12]

@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.

I didnt measure for 30 mins, but that makes sense.

[IoTThinks]

@basiccode12: My periodically adverts still work fine on Heltec v3 with this PR.

The repeaters will wake up every 30 minutes to check it is time to send periodically adverts.
Or even when it is waken up by LoRa messages, it will loop a few times and check if it is time to send periodically adverts.

[beachmiles]

This build was working great for me with the TX LED off version Ive been testing with. Unfortunately after finally moving my repeater to the roof I my noise floor shot up and I started getting the dreaded -120db noise floor bug.

With it on the roof and a great view of the city and surrounding mountains and my noise floor shot up to -60 to -70 and now is locking up at -120 and Im getting much fewer successfully traceroutes.
My cavity filter doesn't seem to be helping too much unfortunately.

Setting agc.reset.interval to 8 got me better performance but the noise floor lockup at -120 seems to destroy RX performance until I manually reboot. Even after disabling agc.reset.interval by setting it back to 0 and rebooting I still managed to get the noise floor lockup at -120.

Hopefully this powersaving mod and this fixagcreset mod can join forces soon! Sounds like it may be in the works and already being tested by @towerviewcams. Hope its successful and looking forward to the results!
https://github.com/weebl2000/MeshCore/tree/fixagcreset

[IoTThinks]

@beachmiles I will do a merge with AGC reset PR today.

You prefer dev or main branch?

[beachmiles]

@IoTThinks I dont know enough between dev and main to make an informed choice. I am looking for the most stable version with the highest chance of success. But it looks like a build was made merging 1569, 1600 and 1687 already. Gonna test it out now.
#1743 (comment)

[towerviewcams]

@IoTThinks I dont know enough between dev and main to make an informed choice. I am looking for the most stable version with the highest chance of success. But it looks like a build was made merging 1569, 1600 and 1687 already. Gonna test it out now. #1743 (comment)

So far its fantastic on 3, V4 in my lab and now 1 on a high noise tower site.

tomorrow morning I'll know for sure as this takes 24hrs to really test

[terminalvelocity23]

After some more testing I can confirm that with this PR the repeater becomes much more sluggish in all aspects. I can't reliably login into the administrative interface, the UI throws timeouts with things like neighbor tabl, requesting LoRa settings and the like more often than not, and the CLI is slower, too. The ACKs to my outgoing messages get delayed to 10 seconds or so.
With powersaving off everything returns to normal.
With powersaving off, I can see reliable CLI behavior, 10/10 command successes. With it on, it's only 8/10 with significant delays.

[IoTThinks]

@terminalvelocity23 I suggest you can try this PR alone to test the behavior instead of mixing many PRs.
Please help to test the bin for Heltec v3 here.
It is main MeshCore + this PR.
https://github.com/IoTThinks/EasySkyMesh/releases/tag/PowerSaving13

Btw, how many hops you use to remote manage your repeater?
What are your agc reset interval and int.thresh?
I would like to simulate what you have experienced.

[h0lad]

I'm just building the latest release for my own hardware and will throw it on the roof

[terminalvelocity23]

@terminalvelocity23 I suggest you can try this PR alone to test the behavior instead of mixing many PRs. Please help to test the bin for Heltec v3 here. It is main MeshCore + this PR. https://github.com/IoTThinks/EasySkyMesh/releases/tag/PowerSaving13

Btw, how many hops you use to remote manage your repeater? What are your agc reset interval and int.thresh? I would like to simulate what you have experienced.

I don't have a V3 on hand anymore, but I have a V4. Zero hops, it's a direct route from client to repeater, they're like 5 meters apart from each other (the tx power on a client is set to 3 dBm to avoid overloading the receiver on the repeater). agc.reset.interval is 8, int.thresh 15, af 5, txdelay 0.5, rxdelay 0.5, direct.txdelay 0.

I'll flash your firmware to my V4 and give it a try.

[IoTThinks]

@towerviewcams May be the mixed of 3 PRs has some side effects.
Let me explore the source code of the other two PRs.

In the meantime, you may test with PS 13 on Heltec v4 first.
This is to confirm this PR works.

If there is anything we can improve to make 3 PRs live together, we will improve it. :)

[terminalvelocity23]

So far it works fine on the bench, the only hiccup is the occasional CLI freeze (2 out of 10 or so). I've put it in place of my main repeater, let's see how it will handle the load. It's connected to a 5 element Yagi through a cavity BPF, height above ground is about 50 meters, so it hears quite a lot of packets.

[terminalvelocity23]

After 40 minutes of testing it went deaf, stuck at -120 dBm. The responsivity is alright though, no complaints here. Looks like this PR alone isn't the one to blame for the sluggishness.

[IoTThinks]

@towerviewcams Let me explore AGC PR and see how to make AGC and PowerSaving work together tomorrow.
dev...weebl2000:meshcore:agc-powersave
No worry.

[etienn01]

@IoTThinks Your branch works well on my Heltec V4 but if I pick up the changes on top of the current dev branch (b67decf), there is something weird going on, looks like each command gets the reply from the previous one.

See on the screenshot below, the first ver gets no reply, then clock shows ver output, get tx shows clock output, etc.

Also login only works on the second try.

100% repeatable, and I'm sitting next to the repeater.

• agc.reset.interval is 0
• int.thresh is 0
• af is 1.0
• txdelay is 0.5
• rxdelay is 0.0
• direct.txdelay is 0.2

That's maybe the same symptom described by @terminalvelocity23

[IoTThinks]

@etienn01 Really.
Let me check.

I guess there is some weird change in dev.

[IoTThinks]

I have built this PR with AGC reset PR
#1743 (comment)

It works fine for Heltec v4 repeater.
Let me examine the recent commits in dev.

[etienn01]

@IoTThinks it looks like it's caused by #1795

hasPendingWork() calls getOutboundCount(0xFFFFFFFF).
The new countBefore implementation uses if ((int32_t)(_schedule_table[j] - now) > 0) continue;

With now = 0xFFFFFFFF, for any typical schedule time T: (int32_t)(T - 0xFFFFFFFF) = (int32_t)(T + 1) -> always positive for the first ~24 days of uptime.

So every queued packet is treated as "in the future" and skipped.

(thanks to Claude Code for the analysis)

[IoTThinks]

@etienn01 Nice catch.
I guess something weird with hasPendingWork or LoRa.sleep in AGC.

Old one happens to be correct for 0xFFFFFFFF

int PacketQueue::countBefore(uint32_t now) const {
  int n = 0;
  for (int j = 0; j < _num; j++) {
    if (_schedule_table[j] > now) continue;   // scheduled for future... ignore for now
    n++;
  }
  return n;
}

Current one fixed wrap around but seems to have bug for now=0xFFFFFFFF

int PacketQueue::countBefore(uint32_t now) const {
  int n = 0;
  for (int j = 0; j < _num; j++) {
    if ((int32_t)(_schedule_table[j] - now) > 0) continue;   // scheduled for future... ignore for now
    n++;
  }
  return n;
}

Proposed fix?

int PacketQueue::countBefore(uint32_t now) const {
  if (now == 0xFFFFFFFF)
      return _num;   // Return all

  int n = 0;
  for (int j = 0; j < _num; j++) {
    if ((int32_t)(_schedule_table[j] - now) > 0)
      continue;
    n++;
  }
  return n;
}

[IoTThinks]

Or just use count() and ignore the bug =)
Let me test both cases.
You may go ahead and do testing for your discovery.

class PacketQueue {
mesh::Packet** _table;
uint8_t* _pri_table;
uint32_t* _schedule_table;
int _size, _num;

public:
PacketQueue(int max_entries);
mesh::Packet* get(uint32_t now);
bool add(mesh::Packet* packet, uint8_t priority, uint32_t scheduled_for);
int count() const { return _num; }
int countBefore(uint32_t now) const;
mesh::Packet* itemAt(int i) const { return _table[i]; }
mesh::Packet* removeByIdx(int i);
};

[etienn01]

Testing this now, seems to work 👍

int PacketQueue::countBefore(uint32_t now) const {
  if (now == 0xFFFFFFFF)
      return _num;   // Return all

  int n = 0;
  for (int j = 0; j < _num; j++) {
    if ((int32_t)(_schedule_table[j] - now) > 0)
      continue;
    n++;
  }
  return n;
}

There are a few places where getOutboundCount is called with 0xFFFFFFFF.

[terminalvelocity23]

I wonder if your powersaving code will work for room servers. Right now powersaving mechanism from main doesn't appear to work for them, mine's pulling 68 mA in standby.

[etienn01]

Now running this PR #1687 with #1877, all is good 👍