To support lightsleep for Heltec V3/v4 repeater to achieve 9mA power consumption #1107
Conversation
|
Works like a charm. Should be standard on all esp repeaters or possible to turn on/off via commandline |
|
This is a substantial improvement, bringing the v4 down to about 4.9wH/day (extrapolated from a 15 minute bench test consuming 0.040Wh) at near-idle conditions (about a 30% cycle range on a 2600mAh 18650 cell); even light-sleep should bring ESP32-based boards close to compact/cheap solar viability in middling latitudes. It shouldn't be too hard to adapt for companions as well. Quibbles, though: it's on by default and breaks the serial CLI on sleep. That makes configuring a new board fiddly; consider either a config latch to enable powersaving mode, or disabling it when serial input is detected. |
|
@aqua I have just made some changes to make the board awake for 2 minutes (instead of 30s) in first boot / restart to support Repeater setup via USB. I tested and think 2 minutes is enough. Serial CLI in Meshcore app works for me as it will send LoRa packets which wake up the board and the serial connection. |
|
Yes, we have a POWERSAVING_MODE flag in the ini file. Yes, we can detect if an UART connection is connected to delay the sleep. 
|
You can flash the official version, configure it and then update with the mod. Maybe there can be implemented a cli command to switch on/off powersaving for all esp repeaters!? Maybe it is not always needed. A powersaving for companion will not work in my opinion because of BT is needed. |
|
@SaschaKt You now have 2 minutes instead of 30s to setup a Repeater via Serial USB. When we refresh the Repeater Setup page, the esp32 will be resetted and we have another 2 minutes to do the settings again. After that, it will sleep after 5s. |
Hi Kevin. I noticed with the v3 and v4 that the clock go ahead, the longer the running time. A normal reboot via cli doesn't set the clock to the 2024 Standard time so it is not possible to sync the clock (because time can not be synched if it is correct or ahead). Can you modify the CLI "clock Sync" so that it is always syncing? It is interesting why the clock goes ahead, do you have noticed? |
|
Let me monitor. Let me sync clock and let it run. By right, the clock of esp32 is not accurate. It will drift... |
|
@SaschaKt You check time using clock CLI, right? 
|
I look at the Request Status page and in cli. The time goes ahead and cannot be synced. Only resetbutton on v3 sets it to 2024, the v4 is not in the near so I can't hit the reset button |
|
@SaschaKt My Heltec v3's clock works fine for 2 hours. Let me monitor a day and see. How far is the drift in one day should I expect? |
|
Let me explore and test to use a more accurate clock in light sleep. rtc_clk_slow_src_set(RTC_SLOW_FREQ_8MD256); |
|
https://analyzer.letsme.sh/node/7E7662676F7F0850A8A355BAAFBFC1EB7B4174C340442D7D7161C9474A2C9400 This is cougar; probably the most busy node in all of MeshCore with roughly 110 neighbors. The granularity is 10s; there are savings to be found even here |
|
I just want to add my +1 to this change. I've got my own private branch BLE companion that does lightsleep anytime the Bluetooth isn't connected, periodically waking up to allow reconnect. This would make it easier to keep my private branch in sync with main. |
variants/heltec_v3/HeltecV3Board.h
Outdated
|
|
||
| void sleep() override { | ||
| if (WiFi.getMode() == WIFI_MODE_NULL) { // WiFi is off ~ No active OTA, can go to sleep | ||
| enterLightSleep(1800); // To wake up every 30 minutes or when receiving a LoRa packet |
There was a problem hiding this comment.
Can I suggest moving the sleep durations as a parameter, and in milliseconds?
This sort of policy seems like it would be application dependent -- e.g. 30 minutes makes sense for a repeater, but I'm experimenting with a power saving companion where 30 minutes is way too long. Moving it into a parameter to sleep() would let the 30 min duration remain in the repeater code.
There was a problem hiding this comment.
The 30-minute is to wake up every 30 minutes to do periodically jobs like adverts.
Other times, it will go to sleep every 5s.
There was a problem hiding this comment.
Ok let me make sleep period as a parameter of sleep().
There was a problem hiding this comment.
@cparen I have added "secs" for sleep().
I think sleep duration in seconds is good enough. Deepsleep uses seconds too.
Yes, it is better to keep the 30 minutes wake up in repeater code.
|
Works great on Heltec v4 |
|
@cparen Yes, please create your own PR for companion. I would love the powersaving for BLE companion. |
|
@mikecarper The dashboard looks awesome. Looks like an ISP operator even this is P2P network. |
Updated sleep duration and wake-up conditions for power saving.
Updated sleep function to accept a duration parameter for light sleep.
|
does the clock reboot firmware also contain the sleep code and dispatcher ? |
|
I flashed the low power updated bin you provided and it appears to have fixed the problem from what I see |
Yes, the clock reboot firmware contains the sleep code and dispatcher. |
Wow, that's great. Thanks a lot for your feedback. |
|
I wasn't able to reproduce any savings with a v4. Here's a screen shot of power analysis before: And after applying this MR to a local branch. The quiescent current is 59mA in both cases. Do you have any suggestions? Or, perhaps, a bin file for the v4 that I could test to ensure that it's being compiled as you expect? |
I can tell you that it works perfect. This works only for repeaters, do you have flashed a repeater or do you try it for an companion? The bin file you can download under https://github.com/IoTThinks/MeshCore/releases/download/PowerSaving07/repeater-heltecv4-powersaving07.bin |
|
I tried with the bin you linked to and got exactly the same results. |
Have you tried another v4? Is the v4 maybe charging the battery if you measure over the Usb-C port (red led must be off)? It takes 2 minutes for the first sleep after switching on or rebooting |
|
Ah, ok. that's the ticket. I didn't know you have to wait 2 minutes. |
|
@hpux735 Yes, for first boot or after hard reset, have to wait 2 minutes to attempt to light sleep. |
|
This is interesting. We can convert all ESP32 boards from another mesh to become MeshCore repeaters at 9mA. Much lower than any NRF52 boards with BLE at 14+ mAh. There is an unfair advantage of Meshcore repeater: It does not use BLE at all. Therefore, sleep is much easier and effective to reduce power. Btw, you need to unplug the GPS module. This module uses 40mA! |
|
@IoTThinks would this also work for a g2? |
|
@mikecarper This PR won't work for Station G2 as the board uses non-RTC GPIO 48 for DIO1. 
RTC pins is up to GPIO21 only. |
|
Can the same change be included for the Heltec V2 as well please? Any changes for V3 / V4 should also be equally applicable for the V2 since that is also esp32-based. |
Put lastActive to initialise in setup() Checked next sleep with millisHasNowPassed
|
Added changed as required by reviewers.
|
|
@MikesAllotment Actually, this PR is applicable for many ESP32-based boards as long as the DIO1 of these boards wire to RTC pin. BTW, I have checked Heltec v2. So yes, this PR will work for Heltec v2. Please help to unzip the file to bin, then flash this bin to see if it works for your Heltec v2. |
fschrempf
left a comment
fschrempf
left a comment
There was a problem hiding this comment.
@ripplebiz @IoTThinks May I suggest to merge #1238 first, then implement the board.sleep() for ESP32 on top of this afterwards?
This PR has the following disadvantages in my opinion:
- it adds another compile-time option
POWERSAVE_MODEwhich makes build configuration even more complex - it changes the general behavior for specific boards while other boards use the old behavior which might create confusion for (non-technical) users
- it doesn't allow to opt-out of this feature without recompiling the firmware
- it's a platform-specific solution for ESP32, while we could have a similar generic solution with platform-specific extensions
| } | ||
|
|
||
| // To get the current pending outbound packets at Dispatcher | ||
| int MyMesh::hasPendingWork(uint32_t now) const { |
There was a problem hiding this comment.
Remove the now parameter. It's not used.
There was a problem hiding this comment.
-
This PR 1107 is much older than PR 1238.
In my PowerSaving fork, NRF52 is enjoying 8.5mA power consumption for a while.
All these stuff will be pushed after this PR is approved. -
Last time, I'm thinking to use CLI to enable/disable powersaving mode.
However, I believe powersaving mode should be the default and built-in feature.
For IoT world, power saving is actually a must.
There was a problem hiding this comment.
@fschrempf We may just change the comment to become " To get the current pending works"
Or yes, just make it int MyMesh::hasPendingWork() const {
// To get the current pending outbound packets at Dispatcher
int MyMesh::hasPendingWork(uint32_t now) const {
There was a problem hiding this comment.
You either have to remove the now parameter, or pass it on to getOutboundCount(). Keeping it without using it doesn't make sense.
| -D MAX_NEIGHBOURS=50 | ||
| ; -D MESH_PACKET_LOGGING=1 | ||
| ; -D MESH_DEBUG=1 | ||
| -D POWERSAVING_MODE=1 |
There was a problem hiding this comment.
I don't really like the fact that we are enabling this for specific boards only. I know this can be rolled out to other boards later, but it will likely be confusing for some users if some boards show a different behavior than others (for example CLI accessibility after the initial 2 minute period).
There was a problem hiding this comment.
Well, we will have power saving to all boards soon by default. All will have the same powersaving behaviors.
However due to large user base of MeshCore, we would like to see the impact of the change to Heltec v3/v4 first.
Removed blank lines due to merge of conflict. Co-authored-by: Frieder Schrempf <34034373+fschrempf@users.noreply.github.com>
|
To cleanup and create another PR for clean state. |
Please, as I mentioned before: Just use |
It is my preference. |
|
@IoTThinks Ok, feel free to cherry-pick the commits you need from my branch: https://github.com/fschrempf/MeshCore/commits/repeater-power-opt/ |
Ok. The solution with Unfortunately when testing you
Yes, I agree it should probably the default at some point. Still, I think it makes sense to have it opt-in at first and then make it the default later. And having it runtime-configurable makes sense e. g. for people who don't care about power savings but need serial CLI to be active all the time. But I guess it's best to let the maintainers decide what they prefer. |
What do you mean with CLI? Serial CLI? Because the CLI over Lora works, and no power saving after reboot for 2 minutes for configuring via serial cable. Also we can turn ota mode via Lora admin on so the lightsleep is off and then should cli via serial be possible.CLI via serial is for the mostly users only needed when configuring after new flashing. When serial is on (what I think is not possible while lightsleep) then the powerconsumption will be higher |
|
@SaschaKt @fschrempf A new PR is coming. So let's refresh it with comments from reviewers and added new CLI to on/off powersaving mode instead of hardcoded built parameter. Merry Chirstmas everyone. 👯 |
15 participants
Hi all,
This PR is to allow Heltec v3 and v4 repeaters to save power down from 47mA to 9mA most of the time.
One 2500mAh can help to last 2 weeks for Heltec v3 and v4.
First advert and periodically adverts (if set) are working.
OTA via WiFi works too.
The code should be applicable to all ESP32-S3 MCUs.
We can move the code upstream. However, at this stage, I put at Heltec v3 and v4 first.
Thanks a lot.