nRF54L15 BLE: Connection Interval and DCDC

Your BLE sensor dies in 3 months instead of 3 years. Nine times out of ten, it is not the battery. It is three settings: connection interval too short, DCDC off, and sleep done wrong.

The nRF54L15 is now our default for small BLE sensors, and for good reason. It is a 128 MHz Arm Cortex-M33 with FPU, 1.5 MB NVM (1524 KB RRAM) and 256 KB RAM, plus a 128 MHz RISC-V coprocessor for time-critical peripherals. Nordic supports it in nRF Connect SDK v2.9.1+ / v3.x, which is Zephyr plus Nordic stacks. The board you want is the nRF54L15 DK (PCA10156).

TL;DR: Start at 100 ms interval + slave latency 4, enable DCDC, TX at 0 dBm indoors, sleep in System OFF with GRTC. Measure with PPK2. Everything below is how to get there without guessing.

nRF54L15 at a glance vs nRF52840

Item	nRF54L15	nRF52840 (older)
Core	128 MHz Cortex-M33, 503 CoreMark	64 MHz Cortex-M4
Memory	1.5 MB NVM + 256 KB RAM	1 MB Flash + 256 KB RAM
Coprocessor	128 MHz RISC-V FLPR for peripherals	None
BLE	LE with Channel Sounding, 2M / 1M / 125k / 500k	BLE 5, 2M / 1M / Coded
802.15.4	Yes, Thread / Matter / Zigbee	Yes, Thread / Zigbee
TX power	-8 to +8 dBm, 1 dB steps	-20 to +8 dBm
RX / TX 0 dBm	3.4 mA / 4.8 mA @ 3V	~4.6 mA / 4.8 mA
System OFF	0.7 uA, 0.8-0.9 uA with GRTC	0.7 uA, 1.5 uA with RTC
Supply	1.7-3.6 V, -40 to +105 C	1.7-5.5 V

The headline is not the MHz. It is the sleep current. Nordic specs System OFF at 0.7 uA, System OFF + GRTC + LFXO at 0.9 uA, and System ON idle + GRTC + 256 KB RAM at 2.9 uA @ 3V with DCDC. That GRTC-in-OFF detail matters — you keep a shared system timer running without an external chip.

Full details are in the nRF54L15 product page and datasheet.

1. Connection interval first, code second

A sensor that advertises for 30 seconds then connects and sends 20 bytes does not need a 7.5 ms interval. That setting is for commissioning or OTA only.

We start production sensors here on Zephyr:

struct bt_le_conn_param param = {
  .interval_min = 80,   /* 100 ms: units of 1.25 ms */
  .interval_max = 80,
  .latency = 4,         /* skip 4 events */
  .timeout = 400,       /* 4 s supervision */
};
bt_conn_le_param_update(conn, &param);

Why this works: average radio current scales almost linearly with how often you wake to hear the central. Going from 7.5 ms to 100 ms with latency 4 cuts average radio current by an order of magnitude. Downside is latency — a phone write to the sensor can wait up to interval * (latency+1) = 500 ms here. For temperature, door, meter data that is fine. For interactive commissioning, switch to short interval temporarily, then switch back.

Practical rules we use:

Advertising: 100-500 ms interval during setup, 1 s+ in field if connectable. Non-connectable beacons can go slower.
Connected sensor: 100 ms + latency 4 as baseline. Battery beacons: 200-400 ms.
Always set a sane supervision timeout (4 s here) so a lost link does not drain spinning.
Negotiate with bt_conn_le_param_update, do not assume the central accepts your first ask. iOS / Android have their own min/max rules.

If you are coming from STM32 low-power work, the mindset is identical to our STM32U3 Stop modes guide — pick the sleep depth by wakeup source, then shrink retained RAM.

2. DCDC and TX power: free battery life

Two lines in devicetree save more than a week of code tuning.

Enable the DCDC regulator in devicetree and set TX power to what the link needs. 0 dBm is enough inside a room. +8 dBm doubles range on paper and drains the cell for no reason in a home panel.

Radio numbers @ 3V with DCDC: RX 3.4 mA, TX 4.8 mA at 0 dBm, 6.6 mA at +4 dBm, 9.8 mA at +8 dBm. So jumping from 0 dBm to +8 dBm doubles TX current for ~2x range in free space — rarely worth it indoors.

Checklist:

Enable DCDC in your board DTS (not LDO). LDO burns (Vbat - Vcore) * I as heat.
Start at 0 dBm. Walk-test with RSSI logging. Only raise if packet loss >1% at edge.
Keep supply clean. Datasheet radio numbers assume a clean supply. A noisy LDO adds more than the radio saves. We measure with the PPK2 in source-meter mode, never from the datasheet alone.
Watch GPIO leakage. Two floating pins cost more than the whole sleep current — same lesson as on STM32.

See Developing with nRF54L for DK targets (nrf54l15dk/nrf54l15/cpuapp) and production SDK notes: use v2.9.1+ for L15, v3.0.0+ for L10/L05.

3. System OFF with GRTC, done right

Between readings the chip sits in System OFF. The nRF54L keeps a global RTC (GRTC) running there, so wakeup needs no external timer.

Zephyr pattern:

/* Zephyr: suspend, GRTC wakes us */
pm_state_force(0u, &(struct pm_state_info){
  .state = PM_STATE_SUSPEND_TO_RAM });

What actually happens: I_OFF0 0.7 uA with wake-on-GPIO, I_OFF1 0.9 uA with GRTC + LFXO. Compare to System ON idle with full RAM + GRTC at 2.9 uA. If you wake every 10 minutes to sample, OFF wins by a mile.

GPIOs are latched before sleep. Set every unused pin to a defined pull, latch, then sleep. A floating analog pin with input buffer on can add 10-50 uA — 20x your sleep budget.

Wake sources in OFF: GPIO DETECT, LPCOMP, NFCT SENSE, and GRTC SYSCOUNTER compare. That covers button, threshold, NFC field, and timed wake — 95% of sensors.

The RISC-V FLPR coprocessor (VPR docs) can offload polling while the app core sleeps, but treat it as experimental in NCS for now. Get OFF + GRTC solid first.

4. How we measure (so you do not fool yourself)

We use the Power Profiler Kit II in source mode (0.8-5.0 V, 500 nA-1 A, 100 ksps). Ampere-meter mode works too with external supply. The Power Profiler app in nRF Connect for Desktop shows average + high-res in one window. Eight digital inputs double as logic analyzer so you can correlate firmware markers with current spikes.

Procedure:

Power DK measurement pins from PPK2 VIN/VOUT/GND.
Capture 60 s: advertise -> connect -> 100 ms interval -> System OFF.
Export, integrate mAh, divide by battery capacity with 15% derate for self-discharge + cold.
No hardware yet? Use Nordic's Online Power Profiler for estimates.

Common trap: measuring with debugger attached and DBG power left on. Same as STM32 — debug power hides real sleep. Measure on a release build with debug cut.

5. Firmware skeleton that ships

nRF Connect SDK v3.x is Zephyr + bt, pm, nrf_ drivers. Minimal loop:

Boot: init sensors, set TX 0 dBm, DCDC on, conn params as above.
Advertise 30 s fast, then slow or stop.
On connect: send MTU-sized batches, update params, go idle.
On idle timeout: latch GPIO, enter System OFF, GRTC wakes for next sample.
OTA mode: short interval + DCDC + full RAM retained, then revert.

If you need Thread or Matter on the same silicon later, the radio already does 802.15.4 — see our ESP32-C6 Thread and Zigbee notes for border-router patterns that translate.

FAQ

nRF54L15 or nRF52840 for a new sensor? New: L15. Better sleep with GRTC, faster core for crypto, longer support in NCS v3.x. Stay on 52840 only if you have certified stock and firmware you cannot port.

What SDK version? Production L15 needs NCS v2.9.1+, L10/L05 need v3.0.0+. Do not ship on v2.8 experimental builds. See NCS 2.9.0 release notes.

How long will a CR2450 last? 620 mAh cell, 10-min sample + 100 ms / latency 4 connection for 5 s per hour: average ~15-25 uA including self-discharge -> 2.5-4 years. Short interval 7.5 ms continuous: weeks. Measure yours with PPK2.

Do I need the RISC-V coprocessor? No for V1. Ship OFF + GRTC first. Use FLPR later for sensor polling or custom protocols.

References

Nordic nRF54L15 product — https://www.nordicsemi.com/products/nrf54l15
nRF54L15 datasheet — https://docs.nordicsemi.com/r/bundle/ps_nrf54l15
VPR RISC-V coprocessor — https://docs.nordicsemi.com/r/bundle/ps_nrf54l15/page/vpr.html
Developing with nRF54L, DK targets — https://nrfconnectdocs.nordicsemi.com/ncs/3.0.2/nrf/app_dev/device_guides/nrf54l/index.html
NCS release notes — https://nrfconnectdocs.nordicsemi.com/ncs/latest/nrf/releases_and_maturity/releases/release-notes-2.9.0.html
PPK2 — https://www.nordicsemi.com/Products/Development-hardware/Power-Profiler-Kit-2
nRF54L15 DK — https://www.nordicsemi.com/Products/Development-hardware/nrf54l15-dk

Bring us your advertising interval and battery size. We reply with a current budget and a firmware plan.