Repeater CPU Idling #1238
Repeater CPU Idling #1238
Conversation
|
I intended to do the same before. So I ended up just do some power saving trick to keep the power down to 8.5mA with few code changes only. Hope we can push the power down more for NRF52 |
Yes, there is no real sleep mode for NRF52 so either put the CPU in idle to save power or shut it down completely. The latter requires full reinit at wakeup.
In which case? With the MCU shut down and only the RF module running in RX mode? That would be in that ballpark, yes.
Sorry, I don't get what you mean here.
Actually it doesn't look complex to me at all. It's pretty straight forward. Instead of letting the CPU run continuously, it stops it and resumes it after the idle interval is over or a packet is received. What exactly looks complex to you?
What "trick" would that be? Do you mean And if it would work, it would do the same thing: put the CPU in idle, right? My approach does it in a platform-agnostic way, which is better IMHO. |
|
This feature has been long overdue. I tested it a bit with Heltec t114 (no screen) repeater. With stock FW I am seeing around 12 mA idle current on my cheap usb power meter. It is actually quite good - it used to be around 17 mA with stock FW not so long ago. Then I flashed FW from this branch and immediately went for "set idle.interval 10000". Now my cheapo usb meter shows current at 0 mA, which occasionally jumps briefly to 10 mA while idling. If I send a message from my companion then the repeater wakes, repeats and then goes back to idling. Now, the 0mA is probably just an artifact of my usb meter. I will try some additional tests tomorrow, but what I see so far - the power consumption at idle is noticeably lower and repeater still seems to be repeating messages and responding to admin commands etc What is the intended reasonable idle interval? Something like 1 to 3 seconds? |
|
May be I will add the CLI for esp32 based boards. Should we share the same CLI to enable/disable power saving to both esp32 and nrf52? Like set powersave 1? In your PR, you set the idle period? How about wake up period? |
|
@ngavars You have to measure the current at the battery cable by power meter. A usbc, it needs to turn on unneccessary components like uart chip, led... |
In my opinion we should use the same approach for ESP32 and NRF52 altogether. You should be able to take my generic implementation and simply add the
What would that be good for? A single parameter that sets the length of the sleep/idle interval is enough. If set to zero (default) there is no change compared to the current implementation in the main branch. Repeater admins can then decide if they want to save power by increasing the interval.
The idle interval is the time the CPU is idling/sleeping. The wake interval is hardcoded to five seconds or three minutes after reboot or after CLI activity. I don't think this needs to be a parameter for the user to change. |
The |
|
@ngavars Thanks for testing by the way! |
mtlynch
left a comment
mtlynch
left a comment
There was a problem hiding this comment.
I'm just a user sharing my thoughts and have no authority in this project.
Thanks for your review anyway! Very much appreciated! |
fschrempf
force-pushed
the
repeater-power-opt
branch
from
ba6e6aa to
1dfb6d7
Compare
|
I've had this running on my test repeater (RAK4630) for 3 days now and I can't see any negative or unexpected results. I currently do not have any ESP32 hardware to test, so if someone would be willing to help out that would be very much appreciated! 😃 |
Serial1 is always true. If we want to check for the presence of a GPS receiver, we need to check if any data was received. Signed-off-by: Frieder Schrempf <frieder@fris.de>
If no GPS was detected, revert the hardware to the initial state, otherwise we may see conflicts or increased power consumption on some boards. Signed-off-by: Frieder Schrempf <frieder@fris.de>
The idle.interval parameter defaults to zero (no CPU idling). Setting it to a non-zero value allows apps to idle or even use sleep modes for the given amount of seconds before continuing the processing loop. This allows to reduce the power consumption. This is added as generic CLI parameter to later be used by app code for different kind of roles such as repeaters and companions. Signed-off-by: Frieder Schrempf <frieder@fris.de>
There is no reason to not use the reset pin as the RAK4630/31 module has it connected internally. Signed-off-by: Frieder Schrempf <frieder@fris.de>
This adds a method hasOutboundPackets() to the Dispatcher class to return if any outbound packets are queued. Signed-off-by: Frieder Schrempf <frieder@fris.de>
This adds a new method blockTaskUntilRXEvent() which uses a FreeRTOS semaphore to stall the calling task until a packet has been received. Signed-off-by: Frieder Schrempf <frieder@fris.de>
Use the idle.interval parameter to stall the loop to save power. The loop is halted for the given amount of seconds before continuing the processing. Only receiving packets will cause an interruption of the idling. Unfortunately it's not easily possible to interrupt the idling on user input such as CLI activity or user button inputs as those things are currently not interrupt-driven. Therefore the UI and the CLI will remain unresponsive during sleep. After booting the CLI will be available for three minutes before the first sleep interval and if a CLI command is issued this period will be extended for another three minutes. On a RAK4631 repeater this can reduce the power consumption during RX mode from around 12 mA to around 7.5 mA. Signed-off-by: Frieder Schrempf <frieder@fris.de>
fschrempf
force-pushed
the
repeater-power-opt
branch
from
1dfb6d7 to
37d0fe1
Compare
Can you attach/upload somewhere an bin file for v3 for testing? |
|
@SaschaKt You can find an archive with all repeater firmwares built by the GitHub CI here: https://github.com/fschrempf/MeshCore/actions/runs/20347701758/artifacts/4916433935 |
I flashed it. Sorry for feedback after a few seconds. for v3 the powersaving is not so efficient like Iotthinks solution. I'm measuring over Usb-C and the consumption goes down from 48mA to 39mA with your solution, with Iotthinks solution it goes down to 13mA measured over Usb-C. Measuring on battery input pins will be a few mA less. I don't think that the combination of both solutions will give more power saving because I think that Lightsleep at esp's with iotthink solution also reduce CPU activity |
|
@SaschaKt Thanks for testing! This is the expected behavior. This PR does not (yet) include the code for ESP32 sleep. And yes, the combination of both solutions won't give more power savings for ESP32 than #1107. The reason for my PR is that it provides a generic approach that is also applicable for other platforms than ESP32 while still providing the possibility to be extended by platform-specific sleep. If your test shows a slightly reduced power consumption and the repeater still works fine that's a success. |
It works, I could go normal to cli and start OTA and flash with Iotthink variant again. Now again 13mA. 39mA is still too much. nrF have per default enabled power saving internally and are at the small consumption level, with tweaking maybe a few mA savings. But esp's needs an enabled lightsleep to be useful as a repeater. The advantage of an nrF is that still with enabled BT the power consumption is not noticeable higher then without. Where is the problem to have two power routines, one for esp's and one for NRFs? Also Iotthink made powersavings for nrF too which will reduce from 12.5 to 8.5mA, that's about 32% |
@SaschaKt I think we are talking past each other. There is no problem here. What I want to achieve is a two step solution:
Apart from the differences mentioned in #1107 (review) this is purely a strategic difference from what #1107 does. |
You're right. I can confirm that with v3 the powerconsumption goes from 48mA to 39mA. That's an improvement..I hope that it would not interfere with hardware specific power saving ontop like iotthink has made..this has to be tested |
5 participants
In order to reduce the power consumption of repeaters in general, this introduces a new CLI parameter
idle.interval. The default value is zero which results in unchanged behavior. Setting it to a non-zero value causes the processing loop to be halted for the given amount of seconds.During the idle interval the CLI and the UI (if available) will be unresponsive. The RF module will be kept in RX mode and upon receiving a packet, the interrupt will cause the processing loop to continue immediately before going back to idle after all outgoing packets have been transferred.
On a RAK4631 repeater this can reduce the power consumption during RX mode from around 12 mA to around 7.5 mA.
This can be extended later to use CPU sleep modes (if the platform allows it) to reduce the power consumption further similar to what is proposed in #1107.
I will let this run on my test repeater for some days and then remove the draft status of this PR if everything looks good.
Feedback, tests, reviews and questions welcome!