Companion Power Optimizations and UI Support for XIAO NRF52

[fschrempf]

This is a collection of small changes that improve the power consumption for companion devices and adds UI (LED & user button) support for the XIAO NRF52 + Wio-SX1262.

The main change is calling RadioLibs PhysicalLayer::sleep() for all modules in case the system is powered off in the companion UI. This will ensure that the proper commands are sent to the module to put it into the lowest possible sleep mode. This results in very low power-off consumption and extended battery lifetime when powered-off, especially for NRF52-based companions.

Changes

Seeed SenseCAP T1000-E

• Put radio into sleep mode if companion is powered off. This significantly reduces the power-off consumption and increases battery life.

RAK WisMesh Tag

• Put radio into sleep mode if companion is powered off. This significantly reduces the power-off consumption and increases battery life.
• Enable DC/DC regulator. This reduces power-on consumption and therefore increases battery life.
• Enable blue status LED. This prevents an always-on LED and aligns the LED behavior with other devices like T1000.

Seeed XIAO NRF52 + Wio-SX1262

• Enable UI for companions based on this hardware, so user button and status LED can be used.
• Enable DC/DC regulator. This reduces power-on consumption by about 25% and therefore increases battery life.
• Enable user button including low-power off state with about 15 µA of power consumption from the battery.
• Fix status LED behavior for LED_STATE_ON=0 and enable status LED

Heltec T114

• Put radio into sleep mode if companion is powered off. This significantly reduces the power-off consumption and increases battery life.
• Enable DC/DC regulator. This reduces power-on consumption and therefore increases battery life.
• Disable LED and GPS in power off state.
• Currently untested

[daniel-j-h]

I can confirm the power drain even when I long-press the power button to turn the t1000-e off. I have observed this over the last weeks and when the device is fully charged and turned off the battery lasts only a day or so.

I have flashed this firmware on my device right now and will give it a try; I'll report back ina couple of days. If this works then it will massivle increase the usefulness of the t1000-e devices! Amazing find!

[SaschaKt]

24 hours later and turned on the t1000e and the battery is still at 100%. Great job

[fschrempf]

I changed this now to be based on the solution provided by @yarda in #1138. This allows us to get rid of the board-specific functions and implement the shutdown of the radio for all modules that have sleep() implemented in the RadioLib.

[yarda]

The T114 also works for me, after 8 hours of hibernation no voltage drop measured (through the telemetry).

[fschrempf]

Here is a successful CI build pipeline, just for reference: https://github.com/fschrempf/MeshCore/actions/runs/19596436013/job/56121657585.

[yarda]

I am running this patched firmware for several hours. The power consumption seems much better. The only thing I noticed: I didn't receive any LoRa packet for several hours after waking up the T114 from the hibernation via reset. It maybe that everybody here were just silent or there is something missing in the init code (by checking the code, I didn't find anything suspicious, it seems the SX1262 radio is reset in the findChip() that is called early in the init and the reset should wake it up from the sleep). I am able to ping other nodes and after the ping I started receiving some packets, so maybe it's just a coincidence, but I will do more testing.

[fschrempf]

@yarda Thanks for testing. I just did the following test on my RAK WisMesh Tag:

1. Flashing the current state of this branch
2. Power-off using button
3. Power-on using button
4. Waiting for incoming packets (watching RX log)

Result: I can see that there are packets incoming without me sending anything before.

[yarda]

I will give it another cca. 24 hours and I will report back. Here the mesh network is quite sparse, but it's improving :)

[yarda]

I will give it another cca. 24 hours and I will report back. Here the mesh network is quite sparse, but it's improving :)

It seems to work OK, just low traffic here :)

[fdlamotte]

looks good (at least not harmfull), but no time to test, sorry :/

actually I've never bothered to poweroff a node ;)

[yarda]

looks good (at least not harmfull), but no time to test, sorry :/

actually I've never bothered to poweroff a node ;)

I am running the patched code for several days and I didn't observe any problem on T114 (for T114 it would be also good to have #1123, which I also have applied on my test node).

This is not only about poweroff (where there is no need for the board to consume cca. 10 mA), but also lowers the board power consumption significantly at the runtime to cca. 50 %.

Btw similarly to the SX1262 according to the datasheet it seems the nRF can be also switched to the DC-DC mode with cca. 50 % power consumption, it would be worth checking whether the current code does it.

[fdlamotte]

Great, I'll just test on my t1000 and e-ink tracker then ;)

[yarda]

Btw similarly to the SX1262 according to the datasheet it seems the nRF can be also switched to the DC-DC mode with cca. 50 % power consumption, it would be worth checking whether the current code does it.

I mistakenly interchanged SX1262 and nRF52 in this comment, but it seems all is OK:

• nRF52 DCDC mode is enabled in the proposed patch, it should decrease the nRF52 current consumption to cca. 50 %
• SX1262 DCDC mode is already enabled in the code which should also decrease SX1262 current consumption to cca. 50 %

Regarding the SX1262, there is the following declaration in the RadioLib/src/modules/SX126X/SX1262.h:

virtual int16_t begin(float freq = 434.0, float bw = 125.0, uint8_t sf = 9, uint8_t cr = 7, uint8_t syncWord = RADIOLIB_SX126X_SYNC_WORD_PRIVATE, int8_t power = 10, uint16_t preambleLength = 8, float tcxoVoltage = 1.6, bool useRegulatorLDO = false);

And the begin is later called in the src/helpers/radiolib/CustomSX1262.h as:

status = begin(LORA_FREQ, LORA_BW, LORA_SF, cr, RADIOLIB_SX126X_SYNC_WORD_PRIVATE, LORA_TX_POWER, 16, tcxo);

I.e. the useRegulatorLDO is on its default value, which is false, which means the DCDC mode is used.

I.e. all seems OK.

[TepMan]

On my T1000 the power measurement seems not to work properly. The power goes from around 50 to 40% down to zero with in short period about 1-2 Hours. Yesterday evening, the battary was at 70%, this morning around 8:00 at was at 55%, around 10:00 system is off due to empty battery. After connecting the power cord, Systems starts up and is working properly and Loading.

[fdlamotte]

There is no device-specific conversion from battery voltage to percentage in the app, and interpolation is linear

I think t1000 shuts down as soon as the power goes below a certain level. I personally only follow bat voltage and try not to let it go below 3.6V (but at this level it drops very fast)

[TepMan]

There is no device-specific conversion from battery voltage to percentage in the app, and interpolation is linear

I think t1000 shuts down as soon as the power goes below a certain level. I personally only follow bat voltage and try not to let it go below 3.6V (but at this level it drops very fast)

Okay, but with the unpatched Firmware I had a nearly linear drain down to under 10% with device still working. And 3.6V seems to be very high to recharge, the nominal voltage is 3.7V, so you are around 90%?

[fschrempf]

On my T1000 the power measurement seems not to work properly. The power goes from around 50 to 40% down to zero with in short period about 1-2 Hours.

On my RAK WisMesh Tag this has been the default behavior with or without the changes in this PR. The voltage to SOC (state of charge) relation is highly non-linear and as @fdlamotte mentioned, the software doesn't take this into account.

Okay, but with the unpatched Firmware I had a nearly linear drain down to under 10% with device still working.

I don't see any relation to the PR here. Could it be that you are confused by the previous high power-off-state consumption? Before, you probably were seeing the battery getting drained fast during power-off. With the changes from this PR the battery will barely be discharged at all when powered-off.