Comparison of BLE Connection Current Consumption Between Zephyr and Arduino Core

[msfujino]

I compared the current consumption during bidirectional BLE communication between Zephyr and Arduino Core. It appears there is still considerable room for improvement in Arduino Core.

I set the transmit power to 8 dBm and the connection interval to 50 ms.
In the test, I repeated a sequence where 16 bytes of data—including battery voltage and RSSI—were transmitted bidirectionally via Notify/Write every second, followed by a 1-second idle period. Using a PPK2, I supplied 3.8 V from the battery pad on the back of the board and measured the current consumption waveforms of Peripheral. The vertical and horizontal scales of the waveforms are aligned, allowing for direct comparison.
I also used the PPK2’s Digital channels to observe the relationship between the sequence and the waveforms.

The code used in the experiment is attached below. I used Arduino Core v0.7.14, but the sketch was written in the nRF52840-compatible Bluefruit style. I used nRF Connect v3.3.0 for Zephyr.
TEST_BROJECTS.zip
PPK2.zip

VBAT_READ-Tx-Rx

Tx section

Rx section

Idle section

[lolren]

Thanks for the detailed captures and the test projects. I made one more timing pass in the BLE connection scheduler and published it as 0.7.21.

The change keeps the wider first-event/resync windows, but tightens the steady-state default connection RX lead/listen margins so the peripheral should spend less time awake before each 50 ms connection event. I tested the attached Arduino central/peripheral sketches compile with the low-power/interoperability profile, plus the existing BLE connection examples. I also installed the public 0.7.21 Board Manager package and recompiled the peripheral sketch from that installed package.

Could you please retest with 0.7.21 when you have time, using the same PPK2 setup? I am especially interested in whether the peripheral idle section and the Tx/Rx sections are closer to your Zephyr captures now.

Edit: The reason why I cannot test it myself with PPK2 is that I am at work, and don't have the setup here.

[msfujino]

I checked version 0.7.21, but saw almost no improvement.
Connection_v0721.zip

[lolren]

You were right, the 0.7.21 timing change was too small to show up clearly in the PPK2 trace. I found the repeated cost was still mostly the steady-state connection HFXO prewarm, not just the RX listen margin.

I published 0.7.22 with a shorter connection prewarm and a little less steady-state RX margin, while keeping the wide first-event/resync window so the link has room to recover if it misses an event. I compiled your central/peripheral sketches from the installed Board Manager package and also flashed a two-board local check with the same low-power/interop settings.

Please retest the same PPK2 setup with 0.7.22 when you have time. This one should be visible in the connected-current trace; if it still is not, the next thing to check is whether the sketch path is holding the connection scheduler awake outside the radio event itself.

[msfujino]

I checked version 0.7.22, but saw almost no improvement.

[lolren]

I had another look at the traces and I do not think the remaining gap was just the HFXO lead time.

The Arduino trace showed a connected-idle floor, and the XIAO low-power delay path can collapse the board rails while the BLE connection is still alive. Connected BLE events now explicitly own/re-enable the RF path for the event, then release it again if BLE had to power it. I also changed the peripheral side to enter the background connected scheduler immediately after CONNECT_IND, and fixed the central scanner state so Scanner.resume() while already connected does not keep the scanner path looking active.

I pushed this as 0.7.24. I tested the two sketches from your zip on two XIAO boards: the link stayed up and the central showed 1M PHY, data length 251, MTU 23, and interval 40 units, so the 50 ms connection cadence is still there.

One thing worth noting: the Arduino and Zephyr sketches are still not exactly identical at the GATT level. Zephyr uses Write Without Response for the RX characteristic, while the Arduino sketch currently exposes/uses normal Write. That can change the shape and charge of the TX/RX exchange even when the connection interval is the same.

Could you please retest 0.7.24 with the same PPK2 setup? I would mainly look for whether the connected-idle floor drops and whether the event bursts look less stretched.

[msfujino]

I verified this in v0.7.25.
While there are improvements in the Tx/Rx section, the floor current has not decreased significantly from 1 mA. We really need to do something about that floor current!
Please refer to the attached PPK2 file.
v0725.zip

               Zephyr     v0.7.14   v0.7.25
Tx section      3.1uC      12.5uC     6.3uC
Rx section      3.1uC      11.7uC     5.1uC
Idle section   60.6uA      1020uA     978uA

[lolren]

This bug is very stubborn! Can you try again please?
We will get there eventually :)

[msfujino]

There has been a significant improvement in the floor current(1mA -> 100uA). Please take a look at the attached ppk2 file. I will post the detailed graph later.
v0751.zip

[msfujino]

I tested it in v0.7.51 and saw significant improvements.
Some issues include Peripheral being unable to read the battery voltage and the RSSI value dropping.

VBAT_READ-Tx-Rx

Tx section

Rx section

Idle section

VBAT_READ section

[lolren]

Can you retest please?

[lolren]

Try again please :D

[msfujino]

I verified this in version v0.7.54. The RSSI still appears to be low.
The idle current has increased to 150 µA.
v0754.zip

[msfujino]

I verified this in v0.7.55. The RSSI still appears to be low.
The idle current has returned to below 100 µA.

I’d like to revert to v0.6.95 to verify, but it no longer appears in the Board Manager. Is there a way to make v0.6.96 available?

[lolren]

Done. v0.6.95 should be available now. Also, test v0.7.56 when you can please.
How far are we from Zephyr total, about 40 uA more on idle? how about on total? Getting close?

[msfujino]

I verified this in v0.7.56. The RSSI still appears to be low, but
the current has returned to the actual values measured in v0.7.51.
Please refer to the graph for v0.7.51.

               Zephyr      v0.7.51
Tx section     3.1uC       6.3uC
Rx section     3.1uC       6.5uC
Idle section   60.7uA     93.8uA
VBAT-Tx-Rx     218uA      336uA

I’d like to evaluate the RSSI drop a bit more quantitatively.

[lolren]

Thanks for the detailed captures. The Tx/Rx pictures pointed at one concrete mismatch: the Arduino test sketch has delayMicroseconds(1000) around the packet markers, and in the low-power profile that was still a CPU spin. The Zephyr side is sleeping for that 1 ms, so Arduino was burning extra charge inside the selected Tx/Rx windows.

I pushed v0.7.57 with a narrow fix for that: connected BLE paths can now let long microsecond waits use the tickless idle delay path, while short microsecond waits stay busy/precise and non-BLE timing paths do not opt in.

One other thing to keep in mind for exact Zephyr comparison: the Zephyr sketch uses Write Without Response. If the Arduino sketch exposes a normal Write characteristic, that can still add an ATT response packet. The conncurrent_zephyr_equiv_central / conncurrent_zephyr_equiv_peripheral diagnostics in the examples use Write Without Response so they should be the cleaner comparison pair. Please retest with 0.7.57 when you have time.

[msfujino]

I eliminated unnecessary LEDs, test signals, and delays, set CHR_PROPS_WRITE_WO_RESP, standardized the conditions, and remeasured the Zephyr and v0.7.57. There were no significant changes in the numerical values or waveforms. I have summarized the preliminary results below. Please note that the units include both uA and uC.

Zephyr’s Idle current is dominated by the RF_SW’s current consumption and is 61 µA. Since the RF_SW is OFF in v0.7.57, it should consume almost no power, but it still measures 91 µA. What do you think is the cause of this?

              Zephyr      v0.7.57
VBAT-Tx-Rx     223uA       300uA
Idle section    61uA        91uA    <<<<<<<<

VBAT-Tx-Rx    17.6uC      33.2uC
Tx section     3.1uC       7.1uC
Rx section     2.7uC       5.5uC

[msfujino]

This is a comparison of RSSI values between v0.6.95 and v0.7.57.
In v0.7.57, the RSSI measured by Peripheral decreases by approximately 10 dBm.

v0.7.57 RSSI

v0.6.95 RSSI

[lolren]

Thanks, that RSSI comparison helped narrow it down.

I found one real bug: when the link does a PHY reconfiguration, the RADIO block gets soft-reset and the core was not restoring the TX power selected by the sketch. So setTxPower(8) could effectively be lost after requestPHY(), which matches the ~10 dB RSSI drop you measured.

I pushed v0.7.58 with that fixed. I also tightened the already-synced connected-event timing so the default profile should spend less time sitting in the receive window between 50 ms connection events, while still keeping the wider resync window after missed events.

I tested with your central/peripheral current sketches on two XIAO boards: the link stayed connected, PHY=1, Data length=251, MTU=23, and RSSI was back in the expected close-board range here. Please retest v0.7.58 when you can, especially the RSSI plot and the current captures.

[msfujino]

I verified this in v0.7.58. The RSSI issue has been resolved. Thank you.
The Idle current remains at 91 μA, and no improvement was observed.

[lolren]

this is a stubborn bug! :D I foresee it will take some time to be resolved :(

[msfujino]

Since we were able to successfully reduce the Idle current in Advertise Current, I’m sure it will work out this time too.
Let’s take our time and not rush!

[lolren]

You are right. We will get there. just slower :D

[lolren]

Thanks, that last check was the useful clue. The remaining idle gap was not the RF switch path. The core was still waking the CPU before the steady-state peripheral RX window and then sitting through part of the RX lead/listen time in firmware. Zephyr avoids that by using timer/DPPI hardware to start RADIO at the event time.

I pushed 0.7.59 with the same idea for the synced peripheral connection path: GRTC compare now triggers RADIO RXEN through DPPI/PPIB, and the CPU wakes close to the connection anchor instead of before RX start. There is still a fallback path if the hardware trigger is not armed or the link needs resync, so it should not make the normal connection path fragile.

I tested the current central/peripheral sketches on two XIAO boards before publishing: the link stayed up, interval was 40 units, PHY was 1M, data length was 251, MTU was 23, and packets kept moving once per second for the soak I ran. I cannot measure the PPK trace here, so please retest 0.7.59 with the same capture setup when you have time.

[msfujino]

Here are the test results for v0.7.59.
Compared to v0.7.57, the current consumption has increased. In particular, an extra 50 mS interval has been inserted in the VBAT-Tx-Rx section.
You can load the attached PPK2 file into PowerProfiler application on your PC to compare the results, so please check the waveforms.

v0757.zip
v0759.zip

              Zephyr      v0.7.57     v0.7.59
VBAT-Tx-Rx     223uA       300uA       445uA
Idle section    61uA        91uA        92uA 

VBAT-Tx-Rx    17.6uC      33.2uC      69.1uC
Tx section     3.1uC       7.1uC      13.9uC
Rx section     2.7uC       5.5uC      13.5uC

[lolren]

Thank you for your testing. I have found a big issue and working on it now. Testing on my PPK2 shows much better results. Will push it soon.

[msfujino]

I verified this in v0.7.66.
It has improved significantly and is now closer to Zephyr's current values.
What really concerns me is that the Idle current remains high even though RF_SW is set to OFF.

              Zephyr      v0.7.57     v0.7.59     v0.7.66
VBAT-Tx-Rx     223uA       300uA       445uA       204uA
Idle section    61uA        91uA        92uA        81uA     <<<<<<<<

VBAT-Tx-Rx    17.6uC      33.2uC      69.1uC      23.9uC
Tx section     3.1uC       7.1uC      13.9uC       5.5uC
Rx section     2.7uC       5.5uC      13.5uC       3.9uC

[lolren]

Yes. I am working hard on it. I am trying to copy Zephyr in how they achieve so low power consumption , but there are a lot of core mismatch at the moment.
Won't be a easy change, sadly :(

[lolren]

Please test latest version when you get a chance. I've tested the average current consumption and it's close to Zephyr.
Still room for improvement in some areas.

[lolren]

I will have to dig further into this. But good theory about the RF switch. I was expecting it to be it.
Somehow I think it is related to the buck converter. I had very bad experiences with buck converters when ultra low power consumption was involved.

[msfujino]

I think this is relevant information.
In my PPK2, I observe spikes in version 0.7.68, but I don't see them in earlier versions. I still suspect there’s some underlying cause for the sudden increase in load current.

[lolren]

This is relevant information, because I can diff it. Will have a search blindly in the code to see the issue. But sadly I cannot test until I get back home, as both my 2 Xiao and PPK2 are at home, and I am at work at the moment.

[msfujino]

I’ve been monitoring this for about an hour now, and the spikes have gradually decreased; I can no longer detect any spikes.
For your reference, the room temperature is 26°C.

[lolren]

Sorry for the delayed reply. I had some work to do at work.
I haven't had time to look into it yet. But i wonder if they have something to do with the spikes I'm getting all the time with both Zephyr and Arduino code on Xiao board. Somehow I have a feeling is can be a Xiao specific issue.

[lolren]

Plain board without rf switch and buck converter destroy the xiao numbers!
On 3.3v , on Holyiot 25008 board, i get much smaller numbers! and no spikes!
Peripheral connected HolyIoT 80uA - XIAO 200uA Central connected HolyIoT 72uA - XIAO 280uA Disconnect avg (spike+scan) HolyIoT 1.7mA - XIAO ~5mA

[lolren]

arduino.zip

[msfujino]

I suspect the spikes observed on my PPK2 are caused by a broken wire. I discovered a partial break near the base of the connector. I’m currently rebuilding it, so I’ll let you know the results as soon as I have them.

To determine whether the issue is related to the RF_SW being turned on or off, you can write a test Core that toggles Port D1 in sync with the RF_SW’s state. This way, you can monitor the current waveform and the Digital Channel simultaneously on the PPK2.

[msfujino]

I tried two new cables and connectors, but spikes still occur in v0.7.68.
When I bypass the buck converter and apply 3.35V directly to the 3V3 pin, no spikes occur.
I am still investigating this further.
Will the spikes disappear over time?
The relationship between temperature and spikes
Do spikes not occur in v0.7.57?

[msfujino]

Will the spikes disappear over time? No
The relationship between temperature and spikes There is no significant change whether it is heated or cooled.
Do spikes not occur in v0.7.57? Although the peak current is high 30mA, no 100 mA spikes are observed.

3.35V applied to the 3V3 pin
v0768_3v3_3350.zip
v0.7.57
v0757.zip
v0.7.678 2 hours later
v0768_bat_3800_2H.zip

[lolren]

I am looking again at the core, but cannot find any issues. I had one more look at the schematic of the Xiao, and the RF_Switch has only 100pF capacitor. That is not close to being enough to create a huge spike.
I'm still betting on a weird buck converter issue. Same like when you power the board on vbat pins with exactly 3.3V and current jumps! must be something when the current draw is too low. But, I dont understand why when you added a led didn't changed that. Very weird issue indeed

[msfujino]

Please take a look at the PPK2 file when 3.35 V is applied to the 3V3 pin to bypass the buck converter. No spikes are observed on the load side at all. It seems the buck converter is indeed the cause.

Although the datasheet does not provide details, it appears that the system automatically switches between PWM mode and PF mode in the low-current range, but I suspect some kind of discontinuity occurs at the moment of the switch.

Could you please write a test core that sets Port D1 to High/Low at the same time RF_SW is turned ON/OFF?

[lolren]

Yes. Will add it in the next release. I wont be able to test it as my stuff is at home , and I'm going to work now, so it will be remotely added blindly :D

[lolren]

nrf54l15clean-0.7.68-rfsw-d1-debug-arduino15-overlay.zip
Unzip it into the Arduino
data-dir root, not into packages directly:

• Linux: ~/.arduino15
• Windows: %LOCALAPPDATA%\Arduino15
• macOS: ~/Library/Arduino15
  Edit: in this core D1 now mirrors RF_SW power high/low,

[lolren]

Wow, good finding! I wonder why? It has to be the buck converter, my bet is on that!
A few years ago I've tried to create some ultra low power flashing things (for fun) with buck converter! I found out that a buck converter behaved weird at ultra low power, and dragging actually more power.

[msfujino]

I received a message from Seeed saying they’ll be sending me a sample of the nRF54LM20A as early as next week. It doesn’t appear to be the Sense version, but I plan to run it on ncs_Zephyr first to check the current consumption. Since it’s not the Sense version, I might not be able to determine the behavior of the onboard devices.

[lolren]

I'm happy they are sending one! You are the biggest contributor for this core! Not joking! Because of your persistence and meticulousness we have these great results!
If it would not have been for your testing, most of the stuff would have been broken in this core. And power consumption would have been huge! (I've never heard of PPK2 before you mentioned it!).
Once again kudos for all your work!

[msfujino]

Should I replace the ~/.arduino15/packages/nrf54l15clean/hardware/nrf54l15clean/0.7.68 folder with the 0.7.68 folder that was sent to me?

[lolren]

yes

[lolren]

I still think there is plenty of room of improvement on the central part at least at the moment, the average i am getting is about 700uA, but that is still way too high for what it does.
Edit: I've meant when disconnected!

[msfujino]

Since I had always assumed that Central was receiving a sufficient power supply, I had not evaluated the current values until now.

[lolren]

My optimisations were based on: Connected current on both peripheral and central) . I was getting about 200 ua and 250ua, ( and then tried to optimise it when disconnecting the other board while measuring the other one.
Central took the most, around 4 mA or so, but a bit more on zephyr. (around 5.5mA) This was because it was bursting Rx to attempt a connection.
Peripheral is advertising, so on Zephyr it is about 500 uA while Arduino core has a bit more, around 700uA. But i think I can get that to about 300ua or so. It was 1.7ma before this version.
So, optimisations are still on their way. Just when I get some time.

[msfujino]

I swapped out the v0.7.68 folder and tried running it, butPeripheral port D1 remains LOW.

[lolren]

I will check to see the issue when I get back home, this evening

[msfujino]

I was investigating the current spikes observed in PPK2. Since I only had three samples and could not maintain consistent boundary conditions, I was unable to perform a quantitative evaluation; however, I reached the following conclusions:

1. Spikes occur in both Zephyr and Arduino Core, and the peak current values and occurrence frequency vary depending on the XIAO board.
2. The phenomenon is unstable and varies depending on environmental factors such as temperature and elapsed time.
3. At the moment the spikes occur, the buck converter input voltage dips by approximately 300 mV.
4. Although a 4.7 uF input capacitor is connected to the buck converter, adding a 2 uF capacitor can almost completely prevent the spikes.

[lolren]

This comes back to one of my previous theory:
The ppk2 uses shunts resistors, and switches (mosftets) to commute them really fast.. When a high value shunt is auto selected by the ppk2, because power consumption is low, and then a small spike occurs in the power consumption, the ppk2 is not fast enough because the lack of capacitors on the XIAO input , so there is no buffer in-between. This would not occur with a battery, because of the low resistance of the battery.
And like I've said in my earlier comments, this buck regulator behaves bad when voltage is exactly 3.3v. Power consumption jumps trough the roof.
I would say we use capacitors for measuring or ignore it altogether.

[msfujino]

I made a cable with a 2uF capacitor attached so I can use it for evaluating XIAO. I’ll be using this cable for the time being.

Now that the spike issue has been resolved, is it safe to conclude that Peripheral’s current consumption is lower than that of Zephyr?
If that’s okay, I’d like to evaluate Central’s current consumption. I’ve never evaluated it before, so I’m looking forward to it.

[lolren]

Yes. I would agree :)
I was optimising that as well. From my measurements, It was lower as well.
The only higher current I was getting on Peripheral was when disconnecting central after the 2 connected.

[msfujino]

This thread has gotten too long, so I'll start a new thread to discuss Central's current consumption.

[msfujino]

I posted a summary on the Seeed Forum.
https://forum.seeedstudio.com/t/ble-current-consumption-of-the-xiao-nrf54l15-when-using-arduino-core/295457