Added PowerSaving for all ESP32-based repeaters#1687
Added PowerSaving for all ESP32-based repeaters#1687IoTThinks wants to merge 9 commits intomeshcore-dev:devfrom
Conversation
|
Still need to fix for those TBeam boards. |
|
@towerviewcams Here you go. This PR should be for ESP32-based repeaters only.
Testing steps for ESP32-based repeaters
Please help to test. |
|
For Heltec v4, when doing "start ota", the current may jump to ...750mA then down to 124mA. It should be ok for battery. |
|
+1 testing atm |
|
V4 testing on two boards results: *fresh flash 1.13 firmware, powersaving delay is 22 seconds, then drops to 11.6mA sleep. 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 |
|
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); 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. |
|
@beachmiles This is required in deepsleep as I understand. rtc_gpio_hold_dis This PowerSaving uses light sleep. |
|
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. The bright white LED is still flashing during communication which it ideally wouldn't be doing while in powersave. 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? |
|
@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. |
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. |
|
@towerviewcams @beachmiles Likely very minimum power saved if turn off led after TX.
It makes sense.
Let me see if the code can access powersaving_flag. |
|
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! |
|
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. 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. |
Please clarify, this PR fixes the bug that prevents your powersaving PR from working properly? Do I understand it correctly? |
Yes, the node was going to sleep while there were packets queued to send. Been running this PR on top of dev branch for two weeks, no issues. |
|
I've too gave it a try again, and it seems that now it's working as intended with AGC patch and whatnot. I've got 14 mA standby current for V4 versus 50+ mA in stock. |
|
Can we please consider merg into dev on this. Many have tested and works great. The 12 second sleep delay is killing solar in busy mesh and preventing firm 14 from being used. thankyou for looking into this, we need your help. |
|
With @weebl2000 help building a 1.14.0 merge with this PR, I've tested on 3 devices and have some findings so far. All testing shown is on Heltec V4. Below is testing history for 1.14.0 vanilla as well as the recent dev merge --dev_plius_pr1687--. What I'm seeing is on all three hardware variants operation was stable for 36 hours on 1.14.0 with no uptime resets. Clocks were all maintained. On all three hardware variants running dev_plius_pr1687 I have seen at least 1 reset in a 8 hour operating period with at least 3 resets on one of the devices. I will note some of the rests seem to occur during administration login as login will timeout, then work on second try. I'll keep running these tests to see how frequent the resets are. The far left node in the table has repeat turned off to see if it's related to repeating or not while the other two have it turned on. I've verified the time on the node was correct every time a reset has occurred. So far all nodes have maintained time correctly through the resets. 
Pulling telemetry directly following shows <1m uptime indicating a reset occurred during login. Below is an example of this: 
|
|
@towerviewcams If possible, please monitor PowerSaving 14 (powersaving on) vs. PowerSaving 14 (powersaving off) to compare the amount of resets. Thanks a lot. |
Yes, testing now as we speak. 2 hours into it! |
|
Latest update, all 3 nodes are still resetting. Clock time has been maintained through resets. I adjusted advert interval last night and it didn't seem to resolve the reset issue. I'm surmising at this time that any wakeup activity may trigger a reset. I saw another instance of one node resetting due to querying. The 1st node exhibited this when I queried it a second time. 
|
|
@AI7NC No idea due to sudden current spike due to the combo of wakeup, TX and LED on. Led On during TX creates sudden voltage drop. |
|
@towerviewcams @AI7NC I disabled LED on/off during tramission to keep the voltage stable. LED on/off is good for debug but bad for TX as it creates voltage drop which may brownout the boards with high TX power like Heltec v4. |
|
Note that testing on the same hardware with same parameters running 1.14.0 vanilla, I didn't see any rests on the same 3 nodes over 36 hours. 
|
The current draw of a LED is minimal, less than 1 mA, unless my scope is lying to me. Compared to the draw of the transmitter at full power, of a V4 no less, it's likely a non-issue. I too experience sudden resets with #1687, but I thought it might be some conflict between different experimental patches like dynamic CR and this to blame. Pulled a clean codebase, applied #1687 to test it in isolated environment. In my case brownout is out of the question, because the repeaters run off mains with battery backup. |
All of my V4 boards have the current limit diodes removed from both LED. They are very bright. I know they don't draw much, but, every small amount helps. So, having the option to turn them off software is great. I don't think it would cause a brown out. I still have the crash / brown out even with them physically disabled. |
Yes, I saw the node you just set up reset last night and it reset a few hours after you set it up in the early evening as well so it's likely unrelated to the LEDs. Here's the data so far. Three nodes have reset, I've loaded the 14.1 on two nodes after they reset. The longest running nodes are still on 14.0 though so far. Note we have some nodes on BMS>Battery, one directly on a 10A power supply at 4.2V, and another directly on a trio of 18650 batteries in parallel. Trying to get a mix of hardware to see if something power related shakes out. 
|
So, for today's testing, the freshly-pulled dev branch with this PR applied rebooted at least three times, maybe more. I'm running it on a V4 off mains with battery backup, tx 22, af 1, txdelay 0.5, rxdelay 1, multi.ack 1, powersaving on. The clock is not being reset, interestingly enough, and this board doesn't have an RTC soldered in yet. I'm flashing your firmware v 1.14.1 now. |
Can you try this one? It's basically this PR with some fixes. (see open PR on IoT's fork) |
Sure, I'll do it tomorrow, gonna give that v. 1.14.1 a fighting chance. It works fine on the bench, but on air it's a different story. |
|
I will get back to this PR next week. Having some fun with ESP32-companions at 10mA. Same as stock NRF52 companions. |
|
Final report. First takeaway was the LED disabled didn't seem to prevent resets. Both of my nodes running 14.1 reset. I'll probably use this firmware for now anyhow as the LEDs are just using power unnecessarily. The second takeaway is the node running 14.0 with power saving turned off has not reset after nearly 30 hours. So this combined with my results from 3 nodes running 1.14.0 for 30 hours plus confirms to me that something within the PS routine is causing the node to restart. Edit forgot the spreadsheet |
I concur, my repeater has crashed about 17 hours in. Clock did reset this time to 1 March 2026.
Flashing your version now. |
|
@weebl2000 your firmware has crashed a hour in, this time keeping the clock correctly :( |
Thanks for testing, the problem might be something else then. Perhaps easiest is to have some debug lugging from around when it crashes. |
It crashes even on the bench without appreciable network load. I have no idea how to get a debug log from it, because if there's one thing powersaving mode does reliably, it's breaking serial connections. Does Meshcore have some internal logging capability other than packet log? |
|
Some odd stuff is going on with my test repeater with your firmware, @weebl2000. Its adress is 5F and my main repeater is AF, take a look: It's been sitting on my desk at minimal power with a 2dbi antenna. It's odd af I'd say. |
Very strange, best revert to the one one IoT made or the dev_plus_pr1687 for now 😂 |
|
@terminalvelocity23 @AI7NC Are you using power supply to test? For a sudden spike from sleep to 750mA for Heltec v4, some power supply units can not keep the voltage stable during current spike. |
|
@terminalvelocity23 Why so many 5f? 
|
I do not show any voltage drops during TX. That aside, only one of four nodes used for testing in parallel was on power supply. All others were on battery >= 10ah. All had the same results, there was no correlation to more reboots on PS vs battery. The only correlation that was clear was if PS was off in 14/14.1 there was no rests while with power saving on there was resets. |
This is from @weebl2000 fork of your PR with PS 14. I've no idea why and how.
2A power supply with 7000 mAh battery backup. It doesn't reset on main or dev. |
Similar, here's my testing on 1.14.0. No resets across the same hardware used for testing power saving. 
|
12 participants
Hi friends,
This is the cleanup PR for this old PR #1353
The changes are below:
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.