Cut NRF52 bluetooth power usage by 300% - testers needed! by phaseloop · Pull Request #8858 · meshtastic/firmware

phaseloop · 2025-12-04T11:39:09Z

According to Nordic online power profiler and general industry recommendation for low power BLE devices (see below), this change should reduce raw bluetooth subsystem power usage by at least 300%.

In advertisement mode (no phone connection) simulated current drop should be from 146 uA to 56 uA for the RF layer only.

When phone is connected to node (theoretical) yield should be around 400% as node is allowed to skip up to 5 extra interrogation/keep-alive frames longer if there is no data to send (so called slave latency).

Physics behind it:

https://docs.silabs.com/bluetooth/2.13/bluetooth-general-system-and-performance/optimizing-current-consumption-in-bluetooth-low-energy-devices

Changes introduced:

increase advertisement frame interval from 152.5 ms to 417.5 ms for slow discovery mode - which is still in the lower range of available BLE intervals and way within values recommended by Apple (link in the source code). For many low power BLE devices intervals starts above 500 ms.

This change to be in effect was confirmed by nRF Connect logs. I don't see any visible impact on Meshtastic app connection/discovery times to node or general Android visibility of the device.

increase Slave Latency factor to 5 (from default value of 0), which means node can freely ignore up to 5 keep-alive frames from a phone when it has no data to transmit - and it will not affect anything with connection stability. Which means we don't need to waste power sending BLE frames that do nothing.

Screenshot by SiLabs from link above:

While this is a generic industry knowledge and we know power savings are there, it would be good if someone with a decent power profiler can check how theoretical yield looks in practice. It would be great if other people can test this change with their phones and nodes.

Those are still pretty conservative settings so we can have further fun once this is verified to be stable across general population.

I suppose similar change to ESP32 may bring much drastic power savings.

🤝 Attestations

I have tested that my proposed changes behave as described.
I have tested that my proposed changes do not cause any obvious regressions on the following devices:
- Promicro/NiceNanoV2 - Faketec custom board

thebentern · 2025-12-04T13:17:55Z

@phaseloop are you on the discord? We can probably engage more testers there,

phaseloop · 2025-12-04T14:08:24Z

@thebentern I joined discord now, I'll ping you there

neopiccolorat · 2025-12-04T22:24:03Z

Would this be the fix to the drainage of phone battery some of us experienced?

phaseloop · 2025-12-04T22:49:32Z

Can you share more specifics? Which phones and boards, etc? I would expect this to happen with esp32 because bluetooth timings set there are crazy and if phone stack does not support timing renegotiation I would pretty much expect it to drain battery fast.

rbomze · 2025-12-06T15:29:03Z

i think you mean -66%. you can't 'cut' 300% - you'll end up BLE generating us power for Lora :D. And .. this just refers to the power of BLE advertising - which is a cut from 100uA down to 33uA. Those Airtags and 'Faketecs' (which are flashed nRF52820 with coin battery) do this BLE advertising 24/7 ... for a year+.
Anyway congratulations 🎉 for this cool discovery. Need to test it tomorrow :D

phaseloop · 2025-12-06T15:47:51Z

i think you mean -66%. you can't 'cut' 300% - you'll end up BLE generating us power

lmao, we don't need solar panels anymore! You're right - I should change it to "improve by" maybe.

Yeah I thought description was clear that this BT subsystem power usage only. Funny enough much bigger power saving can be at the phone side as timing influences battery drain too.

mdecourcy · 2025-12-06T18:14:30Z

Funny enough much bigger power saving can be at the phone side as timing influences battery drain too.

Can you expand on this and potentially create an issue in the app repos?

RichieFrame · 2025-12-07T10:34:21Z

Flashed to a t-echo and custom RAK4631 device, no noticeable changes in behavior yet

ndoo · 2025-12-08T03:31:39Z

Tested this on a T114v2, so far no regression, Android app works fine over BLE.

Forget device from Android settings -> Bluetooth
Scan from Meshtastic app
Pair and key in BLE PIN again

Above works well.

ndoo · 2025-12-08T03:40:23Z

Spoke too soon, I’m not able to change any settings from the Android app. Tried reset (rebooting) of the T114, clearing and re-pairing the BLE bonds.

Android app gets stuck at 0% when opening any settings pane, and the T114 spams this to serial log:

INFO  | 19:38:08 843 toRadioWriteCb data 0x2002abe2, len 162
DEBUG | 19:38:08 843 Drop dup ToRadio packet we just saw
INFO  | 19:38:08 843 toRadioWriteCb data 0x2002abe2, len 162
DEBUG | 19:38:08 843 Drop dup ToRadio packet we just saw
INFO  | 19:38:08 843 toRadioWriteCb data 0x2002abe2, len 162
DEBUG | 19:38:08 843 Drop dup ToRadio packet we just saw
INFO  | 19:38:08 843 toRadioWriteCb data 0x2002abe2, len 162
DEBUG | 19:38:08 843 Drop dup ToRadio packet we just saw
INFO  | 19:38:08 844 toRadioWriteCb data 0x2002abe2, len 162
DEBUG | 19:38:08 844 Drop dup ToRadio packet we just saw
INFO  | 19:38:08 844 toRadioWriteCb data 0x2002abe2, len 162
DEBUG | 19:38:08 844 Drop dup ToRadio packet we just saw
INFO  | 19:38:08 844 toRadioWriteCb data 0x2002abe2, len 162
DEBUG | 19:38:08 844 Drop dup ToRadio packet we just saw
INFO  | 19:38:08 844 toRadioWriteCb data 0x2002abe2, len 162
DEBUG | 19:38:08 844 Drop dup ToRadio packet we just saw
INFO  | 19:38:08 844 toRadioWriteCb data 0x2002abe2, len 162
DEBUG | 19:38:08 844 Drop dup ToRadio packet we just saw
INFO  | 19:38:08 844 toRadioWriteCb data 0x2002abe2, len 162
DEBUG | 19:38:08 844 Drop dup ToRadio packet we just saw
INFO  | 19:38:08 844 toRadioWriteCb data 0x2002abe2, len 162

ndoo · 2025-12-08T03:41:32Z

Spoke too soon, I’m not able to change any settings from the Android app. Tried reset (rebooting) of the T114, clearing and re-pairing the BLE bonds.

Android app gets stuck at 0% when opening any settings pane, and the T114 spams this to serial log:

INFO  | 19:38:08 843 toRadioWriteCb data 0x2002abe2, len 162
DEBUG | 19:38:08 843 Drop dup ToRadio packet we just saw
INFO  | 19:38:08 843 toRadioWriteCb data 0x2002abe2, len 162
DEBUG | 19:38:08 843 Drop dup ToRadio packet we just saw
INFO  | 19:38:08 843 toRadioWriteCb data 0x2002abe2, len 162
DEBUG | 19:38:08 843 Drop dup ToRadio packet we just saw
INFO  | 19:38:08 843 toRadioWriteCb data 0x2002abe2, len 162
DEBUG | 19:38:08 843 Drop dup ToRadio packet we just saw
INFO  | 19:38:08 844 toRadioWriteCb data 0x2002abe2, len 162
DEBUG | 19:38:08 844 Drop dup ToRadio packet we just saw
INFO  | 19:38:08 844 toRadioWriteCb data 0x2002abe2, len 162
DEBUG | 19:38:08 844 Drop dup ToRadio packet we just saw
INFO  | 19:38:08 844 toRadioWriteCb data 0x2002abe2, len 162
DEBUG | 19:38:08 844 Drop dup ToRadio packet we just saw
INFO  | 19:38:08 844 toRadioWriteCb data 0x2002abe2, len 162
DEBUG | 19:38:08 844 Drop dup ToRadio packet we just saw
INFO  | 19:38:08 844 toRadioWriteCb data 0x2002abe2, len 162
DEBUG | 19:38:08 844 Drop dup ToRadio packet we just saw
INFO  | 19:38:08 844 toRadioWriteCb data 0x2002abe2, len 162
DEBUG | 19:38:08 844 Drop dup ToRadio packet we just saw
INFO  | 19:38:08 844 toRadioWriteCb data 0x2002abe2, len 162

Posted this too soon… the page did eventually load, after about a minute of spamming the log. Going to flash without the change to confirm this PR caused the issue.

Would appreciate if anyone else can confirm this PR makes configuration panes take much longer to load and spam the log too.

ndoo · 2025-12-08T03:52:40Z

Downgraded back to 2.7.16 tag, settings panes load instantly on Android, so this PR does cause a regression for my setup.

RichieFrame · 2025-12-08T04:33:25Z

Would appreciate if anyone else can confirm this PR makes configuration panes take much longer to load and spam the log too.

While I did not check the log, the settings loaded instantly, and I was able to modify them without issue or delay

Android app 2.7.8, on both devices I flashed

phaseloop · 2025-12-08T07:22:49Z

@ndoo I have some suspicions what may be the issue.

What phone is it? Does this happen only when trying to save settings? Can you try disabling BT on phone, waiting 15s and reconnecting again?

@mdecourcy As for phone battery drain - there is BLE setting called connection interval which influences radio subsystem power usage and sleep modes (this is what is broken in esp32 ESP-IDF before v5.5, lmao). But when talking about that I forgot this is something I have in other PR not yet published as we need to sort out this one first.

…htastic-firmware into nrf52-power-saving-1

ndoo · 2025-12-08T09:49:07Z

I noticed the pushed commits involve the T114, do you still need me to make any changes to bisect the issue or do you wish me to just test the latest commit as-is?

ndoo · 2025-12-08T09:51:27Z

@ndoo I have some suspicions what may be the issue.

What phone is it?

Sonim XP8800, Android 10, Qualcomm SDM630.

Does this happen only when trying to save settings?

Yes, but not saving settings - just opening the settings pane where it tries to read settings.

Can you try disabling BT on phone, waiting 15s and reconnecting again?

Not tested yet.

phaseloop · 2025-12-08T09:52:41Z

@ndoo - yes, please test the latest commits. There are confirmed issues that damaged/off spec LF crystals may throw off bluetooth timings when using slave latency settings.

If this is XTAL issue - it may explain why it worked initially but stopped as the crystal heated a bit and deviated in freq

max-arnold · 2025-12-08T13:38:37Z

I can't connect from MacBook Pro 13" 2017 (Bluetooth 4.2) to T1000-E with 2.7.16 and this patch applied.

ndoo · 2025-12-08T14:50:19Z

Android app settings loading and reading back are are snappy for me again on the latest commit, T114v2, Android 10, Qualcomm SDM630.

Did not re-pair the node.

phaseloop · 2025-12-08T16:20:20Z

@max-arnold @ndoo - I pushed another change. I got a Mac to test but I'll check if the same issue can be replicated here.

Edit: works fine on Mac M3. I'll dig up some ancient Android.

max-arnold · 2025-12-08T23:19:06Z

@phaseloop The last commit fixed the issue on MB Pro 2017 (Bluetooth 4.2). Also tested on iPhone XR (Bluetooth 5.0).

phaseloop · 2025-12-08T23:44:15Z

@max-arnold awesome, thanks for testing!

It seems that some devices ignore GAT preferred settings and need to be forced to renegotiate it.

ponzano · 2025-12-09T13:57:41Z

Hi, just tested the power consumption difference with and without this commit using a lab bench multimeter and a MeshLink board.
On average, it consumes about 0.24mA less at 4.00v after the commit with app connected.
I found that bluetooth connection using iOS was very difficult but it connected successfully after about a minute of automatically retrying. Forgetting device did not help.

)" This reverts commit ae8d3fb.

phaseloop · 2025-12-09T14:04:38Z

@ponzano did you test the branch with the changes I implemented yesterday?

Do you know what is overall power cost of having bluetooth enabled on NRF52?

ponzano · 2025-12-09T14:50:57Z

@ponzano did you test the branch with the changes I implemented yesterday?

Do you know what is overall power cost of having bluetooth enabled on NRF52?

Uh no I didn’t notice it, I’ll have time to test again with this (and better) instrumentation on Friday morning so we’ll have to wait a couple of days. I’ll also compare power usage with and without Bluetooth enabled.
Just to be sure, is it this one with the latest updates? https://github.com/phaseloop/meshtastic-firmware/tree/nrf52-power-saving-1

phaseloop · 2025-12-09T15:09:38Z

Yeah, that patch fixed connectivity issues on MacOS so there is a big change it will fix your issue too :).

The branch you mentioned is the one. Thanks for testing!

@thebentern - is it possible to reopen this PR somehow?

max-arnold · 2025-12-10T07:05:23Z

I did more tests with an iPhone XR (bluetooth 5.0) and after a couple of successful connects/disconnects (and maybe some idle time) the phone refuses to connect again. Rebooting the T1000-E usually helps.

fifieldt · 2025-12-10T09:37:32Z

@phaseloop , need to make a new PR - but you can push to the same branch

phaseloop · 2025-12-10T10:36:03Z

@max-arnold I've pushed a patch that may help. Please see if there is anything in debug log when the phone can't connect. Thanks!

max-arnold · 2025-12-10T12:23:01Z

@phaseloop I do not see any new commits in your branch develop...phaseloop:meshtastic-firmware:nrf52-power-saving-1 (I did my last test using the "force BLE param negotiation" revision)

phaseloop · 2025-12-10T13:26:46Z

I commited to wrong branch, should be ok now

max-arnold · 2025-12-10T14:13:37Z

Here is the log when my phone fails to connect twice and then succeeds on the third attempt (all I did to reproduce the problem is just connecting and disconnecting multiple times):

INFO  | 14:02:51 553 BLE Connected to iPhone XR (Max)
DEBUG | 14:02:51 553 BluetoothStatus CONNECTED
INFO  | 14:02:51 553 BLE connection secured
INFO  | 14:02:52 555 BLE Disconnected, reason = 0x13
DEBUG | 14:02:52 555 PhoneAPI::close()
DEBUG | 14:02:52 555 BluetoothStatus DISCONNECTED
INFO  | 14:03:03 565 BLE Connected to iPhone XR (Max)
DEBUG | 14:03:03 565 BluetoothStatus CONNECTED
INFO  | 14:03:03 565 BLE connection secured
INFO  | 14:03:04 567 BLE Disconnected, reason = 0x13
DEBUG | 14:03:04 567 PhoneAPI::close()
DEBUG | 14:03:04 567 BluetoothStatus DISCONNECTED
INFO  | 14:03:09 572 BLE Connected to iPhone XR (Max)
DEBUG | 14:03:09 572 BluetoothStatus CONNECTED
INFO  | 14:03:09 572 BLE connection secured
INFO  | 14:03:11 573 CCCD Updated: 1
INFO  | 14:03:11 573 Notify/Indicate enabled
INFO  | 14:03:11 573 CCCD Updated: 1
INFO  | 14:03:11 573 Notify/Indicate enabled
INFO  | 14:03:11 573 toRadioWriteCb data 0x2001cf3a, len 8
DEBUG | 14:03:11 573 New ToRadio packet
DEBUG | 14:03:11 573 Got client heartbeat

I'm testing against 2.7.16 with your branch applied on top.

max-arnold · 2025-12-10T14:25:57Z

Another type of failure:

INFO  | 14:20:46 1629 BLE Connected to iPhone XR (Max)
DEBUG | 14:20:46 1629 BluetoothStatus CONNECTED
INFO  | 14:20:46 1629 BLE connection secured
INFO  | 14:20:48 1630 BLE Disconnected, reason = 0x13
DEBUG | 14:20:48 1630 PhoneAPI::close()
DEBUG | 14:20:48 1630 BluetoothStatus DISCONNECTED
INFO  | 14:20:55 1637 BLE Connected to iPhone XR (Max)
DEBUG | 14:20:55 1637 BluetoothStatus CONNECTED
INFO  | 14:20:55 1637 BLE connection secured
INFO  | 14:20:56 1639 BLE Disconnected, reason = 0x13
DEBUG | 14:20:56 1639 PhoneAPI::close()
DEBUG | 14:20:56 1639 BluetoothStatus DISCONNECTED
INFO  | 14:20:59 1642 BLE Connected to iPhone XR (Max)
DEBUG | 14:20:59 1642 BluetoothStatus CONNECTED
INFO  | 14:20:59 1642 BLE connection secured
INFO  | 14:21:01 1644 CCCD Updated: 1
INFO  | 14:21:01 1644 Notify/Indicate enabled
INFO  | 14:21:01 1644 CCCD Updated: 1
INFO  | 14:21:01 1644 Notify/Indicate enabled

... at this point the app says "Too Many Retries" (No device connected, and my T1000-E is not in the list of available radios)

However, the radio thinks it is connected and if I force close the app, radio prints the following lines:

INFO  | 14:25:10 1892 CCCD Updated: 0
INFO  | 14:25:10 1892 Notify/Indicate disabled
INFO  | 14:25:10 1893 BLE Disconnected, reason = 0x13
DEBUG | 14:25:10 1893 PhoneAPI::close()
DEBUG | 14:25:10 1893 BluetoothStatus DISCONNECTED

phaseloop · 2025-12-10T18:52:17Z

Thanks! That helped a lot. I pushed another fix. It seems some Apple products between iOS versions have conflicting BLE requirements. So we probably need to test few settings to check what makes it happy. I

max-arnold · 2025-12-11T05:11:46Z

Unfortunately the problem is still there. Also found another way to reproduce it (not 100% reliably, sometimes it works just fine):

Connect to the radio
Wait till the phone finishes fetching the node list
Disconnect
Wait 1-5 minutes
Try to connect - sometimes it fails to connect and the app shows "Too Many Retries" and needs to be restarted to be able to connect again

Without the patch the app always connects reliably. iOS version 18.7.2 (latest for an iPhone XR)

phaseloop · 2025-12-11T10:21:45Z

Thanks! I pushed another change - this time disabled Slave Latency at all. I increased the connection interval a bit so we can offset energy saves there.

Are you on discord? Maybe we can switch there. I hope disabling SL will work this time xD

ponzano · 2025-12-12T09:41:26Z

here are some tests:
1- Firmware without blt optimizations
-Bluetooth on and connected

-Bluetooth on but disconnected

-Bluetooth off

After updating to your version i can't connect anymore on iPhone 12 iOS 26.2

ponzano · 2025-12-12T09:57:39Z

Connected using an android phone
2-Your version of firmware:
-Bluetooth enabled and connected

-Bluetooth enabled but disconnected

-Bluetooth disabled

phaseloop · 2025-12-12T10:56:51Z

@ponzano thank you! That was helpful. Can you try the latest commit to check if iPhone issues were fixed?

max-arnold · 2025-12-13T10:58:41Z

@phaseloop With the latest version of your branch both my phone and laptop reliably connect to T1000-E

phaseloop · 2025-12-15T11:29:12Z

Perfect, thanks! If @ponzano confirms latest patch works for their iPhone as well, I'll reopen the PR and merge those changes.

Thank you all for testing and helping!

ponzano · 2025-12-15T12:08:15Z

Perfect, thanks! If @ponzano confirms latest patch works for their iPhone as well, I'll reopen the PR and merge those changes.

Thank you all for testing and helping!

Yes seems to work correctly with iPhone as well! Nice job 👍

…#8858) * Improve NRF52 bluetooth power efficiency * test T114 bad LFXO * T1000 test * force BLE param negotiation --------- Co-authored-by: Ben Meadors <benmmeadors@gmail.com>

…shtastic#8858)" This reverts commit ae8d3fb.

…#8858) * Improve NRF52 bluetooth power efficiency * test T114 bad LFXO * T1000 test * force BLE param negotiation --------- Co-authored-by: Ben Meadors <benmmeadors@gmail.com>

…shtastic#8858)" This reverts commit f0557db.

phaseloop and others added 2 commits December 4, 2025 11:15

Improve NRF52 bluetooth power efficiency

39362b0

Merge branch 'develop' into nrf52-power-saving-1

4b7d959

thebentern added the enhancement New feature or request label Dec 4, 2025

Merge branch 'develop' into nrf52-power-saving-1

9b70271

phaseloop added 2 commits December 8, 2025 09:45

test T114 bad LFXO

2faf55f

Merge branch 'nrf52-power-saving-1' of ssh://github.com/phaseloop/mes…

b21b7c4

…htastic-firmware into nrf52-power-saving-1

phaseloop added 2 commits December 8, 2025 15:03

T1000 test

640d29d

force BLE param negotiation

70330ce

thebentern approved these changes Dec 9, 2025

View reviewed changes

thebentern merged commit ae8d3fb into meshtastic:develop Dec 9, 2025
66 of 67 checks passed

thebentern added a commit that referenced this pull request Dec 9, 2025

Revert "Cut NRF52 bluetooth power usage by 300% - testers needed! (#8858

e691bd9

)" This reverts commit ae8d3fb.

thebentern mentioned this pull request Dec 9, 2025

Revert "Cut NRF52 bluetooth power usage by 300% - testers needed!" #8913

Merged

phaseloop mentioned this pull request Dec 13, 2025

NRF52 bluetooth code small cleanup #8912

Closed

phaseloop mentioned this pull request Dec 16, 2025

Cut NRF52 bluetooth power usage #8992

Merged

scobert969 pushed a commit to zeropt/meshtastic-firmware that referenced this pull request Dec 22, 2025

Revert "Cut NRF52 bluetooth power usage by 300% - testers needed! (me…

04a0984

…shtastic#8858)" This reverts commit ae8d3fb.

jeek pushed a commit to jeek/Meshtastic-Exploiteers-Hacker-Pager that referenced this pull request Jun 30, 2026

Revert "Cut NRF52 bluetooth power usage by 300% - testers needed! (me…

ac3d932

…shtastic#8858)" This reverts commit f0557db.

Uh oh!

Uh oh!

Conversation

phaseloop commented Dec 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🤝 Attestations

Uh oh!

thebentern commented Dec 4, 2025

Uh oh!

phaseloop commented Dec 4, 2025

Uh oh!

neopiccolorat commented Dec 4, 2025

Uh oh!

phaseloop commented Dec 4, 2025

Uh oh!

rbomze commented Dec 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

phaseloop commented Dec 6, 2025

Uh oh!

mdecourcy commented Dec 6, 2025

Uh oh!

RichieFrame commented Dec 7, 2025

Uh oh!

ndoo commented Dec 8, 2025

Uh oh!

ndoo commented Dec 8, 2025

Uh oh!

ndoo commented Dec 8, 2025

Uh oh!

ndoo commented Dec 8, 2025

Uh oh!

RichieFrame commented Dec 8, 2025

Uh oh!

phaseloop commented Dec 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ndoo commented Dec 8, 2025

Uh oh!

ndoo commented Dec 8, 2025

Uh oh!

phaseloop commented Dec 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

max-arnold commented Dec 8, 2025

Uh oh!

ndoo commented Dec 8, 2025

Uh oh!

phaseloop commented Dec 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

max-arnold commented Dec 8, 2025

Uh oh!

phaseloop commented Dec 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

ponzano commented Dec 9, 2025

Uh oh!

phaseloop commented Dec 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ponzano commented Dec 9, 2025

Uh oh!

phaseloop commented Dec 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

max-arnold commented Dec 10, 2025

Uh oh!

fifieldt commented Dec 10, 2025

Uh oh!

phaseloop commented Dec 10, 2025

Uh oh!

max-arnold commented Dec 10, 2025

Uh oh!

phaseloop commented Dec 10, 2025

Uh oh!

max-arnold commented Dec 10, 2025

Uh oh!

max-arnold commented Dec 10, 2025

phaseloop commented Dec 4, 2025 •

edited

Loading

rbomze commented Dec 6, 2025 •

edited

Loading

phaseloop commented Dec 8, 2025 •

edited

Loading

phaseloop commented Dec 8, 2025 •

edited

Loading

phaseloop commented Dec 8, 2025 •

edited

Loading

phaseloop commented Dec 8, 2025 •

edited

Loading

phaseloop commented Dec 9, 2025 •

edited

Loading

phaseloop commented Dec 9, 2025 •

edited

Loading