Mirrors/MeshCore-Solo
1
0
Fork 0
mirror of https://github.com/MarekZegare4/MeshCore-Solo.git synced 2026-08-04 03:06:12 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs(features): add battery/power optimization backlog item

Browse Source 
Capture the plan to multiply battery life via radio power technique (the
dominant draw is continuous RX, not the framework): CAD-based RX windowing
(~10-15mA → ~3-5mA, behind a setting due to the latency tradeoff) and
Adaptive Power Control, inspired by the ZephCore Zephyr port but stayable in
this Arduino tree. GPS power gating explicitly excluded — the device is a
live navigator/trail recorder. Deferred until trail polishing is done; prefer
adopting upstream nRF52 powersaving work.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Jakub
2026-06-04 14:26:48 +02:00
co-authored by Claude Opus 4.8
parent b64eda234f
commit 4f39203790
1 changed files with 39 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
FEATURES.md
+39
View File
@@ -339,6 +339,45 @@ A fuller position-centred navigator (you fixed at screen centre, fixed/preset
zoom, pan) is a larger separate feature; start with the rotate-the-fit version zoom, pan) is a larger separate feature; start with the rotate-the-fit version
if pursued. if pursued.
### 📋 Battery / power optimization (CAD RX windowing + APC) — after trail polish
Goal: multiply battery life **without losing functionality**. The dominant
draw on this node is the radio in **continuous RX** (always-on `startReceive()`
with boosted gain in [`RadioLibWrappers.cpp`](src/helpers/radiolib/RadioLibWrappers.cpp));
the MCU already sleeps between iterations (`sd_app_evt_wait()`/WFE in
[`NRF52Board.cpp`](src/helpers/NRF52Board.cpp)), so the framework is not the
bottleneck — the radio is. The win is framework-agnostic and can land in this
Arduino tree while keeping the Solo UI and upstream sync.
Inspired by **ZephCore** (Zephyr MeshCore port, https://github.com/liquidraver/ZephCore),
whose battery edge comes from radio/peripheral power technique, not the kernel:
- **CAD-based RX windowing** — the biggest lever. Instead of continuous RX, use
the SX1262 RX-duty-cycle / Channel Activity Detection to briefly sample for a
preamble, then sleep, repeat. ZephCore quotes ~10–15 mA → ~3–5 mA RX. RadioLib
supports CAD / `startReceiveDutyCycle`. **Tradeoff:** slightly higher receive
latency / a small sensitivity hit — acceptable for a companion, must be a
toggle/setting so users who want lowest latency can keep continuous RX.
- **Adaptive Power Control (APC)** — drop `tx_power_dbm` dynamically when link
quality (SNR/RSSI of acks) allows; raise it back when needed.
- **Config-level wins** (mostly already exposed): BLE off when idle, OLED
auto-off (e-ink idle ≈ 0), longer advert intervals.
**Explicitly out of scope: GPS power gating.** ZephCore powers the GNSS only
during a fix; this device is used as a *live* navigator + trail recorder, so GPS
stays continuously powered. Don't gate it.
Cross-check: MeshCore upstream is already moving here too
([PR #1238 NRF52 powersaving](https://github.com/meshcore-dev/MeshCore/pull/1238),
[docs/nrf52_power_management.md](docs/nrf52_power_management.md), duty-cycle
enforcement since companion v1.14.1) — prefer adopting/merging upstream work over
a parallel implementation where possible. Note ZephCore's licence before copying
any code verbatim (architecture inspiration is fine).
Sequencing: **deferred until the trail/waypoints/nav polishing is finished.**
First step when picked up: profile with a PPK2/meter to confirm RX is the hog,
then prototype CAD windowing behind a setting and measure before/after.
### SOS broadcast ### SOS broadcast
Configurable in Settings › System › SOS: Configurable in Settings › System › SOS: