By Dave Drogowski
Published on July 8, 2026
Bluetooth LE has grown dramatically from a simple sensor protocol to a full data and audio solution. But for the highest data rates, it can struggle – and even 2M PHY is quickly eaten up by protocol overhead. Here’s some common questions about getting around these limitations with Nordic’s Enhanced Shockburst (ESB).
Q: Why does BLE feel too slow for high-data-rate applications?
A: BLE's 2 Mbps PHY sounds fast on paper, but connection intervals, L2CAP framing, and ATT headers cut practical throughput to around 1.4 Mbps — not enough for use cases like raw ADC streams in medical devices, high-resolution motion capture, or real-time industrial monitoring.
Q: Are there alternatives to increase BLE throughput using the same hardware?
A: Yes, but only currently on Nordic hardware. Using Nordic's Enhanced Shockburst (ESB) protocol with the proprietary 4 Mbps PHY on two Ezurio BL54L15 DVKs, Ezurio achieved ~3.3 Mbps sustained unidirectional throughput — more than double BLE's practical ceiling. There are caveats, but the throughput gains are very real.
Q: What is Enhanced Shockburst (ESB), and how is it different from BLE?
A: ESB is a lightweight, proprietary radio protocol built into the Nordic radio peripheral. It runs in the same 2.4 GHz band as Bluetooth but strips out GATT, L2CAP, frequency hopping, and connection management — the application just writes a packet and the radio sends it, which is what unlocks the higher throughput.
Q: What are the trade-offs when using ESB instead of BLE?
A: ESB only works between Nordic devices — no phone pairing, no app store integration, no cross-vendor ecosystem. It's suited to links where you control both embedded endpoints.
Q: What configuration changes were needed to hit 3.3 Mbps?
A: Starting from standard ESB PTX/PRX samples in nRF Connect SDK v3.2.4, the changes were: switching to the 4 Mbps PHY, increasing max payload to 252 bytes (from 32), disabling acknowledgement (noack = true) to remove TX/RX turnaround, enabling fast radio ramp-up (CONFIG_ESB_FAST_SWITCHING=y), and replacing k_sleep() with a tight k_yield() loop. All changes used the public configuration API — no modification to the ESB library itself. See the full report here.
Q: Does this approach guarantee reliable delivery?
A: No — acknowledgement was disabled for max throughput, resulting in about 1% packet loss. This is often acceptable for streaming use cases where a new sample simply replaces the last one; ACKs can be re-enabled for reliable transport, at the cost of lower throughput.
Q: Are there other trade-offs besides reliability?
A: Yes — ESB uses a single channel with no frequency hopping (more vulnerable to interference), has no built-in security (encryption is left to the application layer), and the 4 Mbps PHY trades receiver sensitivity for speed, meaning shorter range than 1 or 2 Mbps modes.
Q: What do I need to try this myself?
A: Two BL54L15 DVKs and a working nRF Connect SDK v3.2.4 setup. Flash esb_4mbps_ptx to one board and esb_4mbps_prx to the othe. The full project is on GitHub, and Ezurio has an Application Note - Enhanced Shockburst (ESB) with 4 Mbps PHY on the BL54L15 and Quick Start Guide for BL54Lxx Application Development with nRF Connect for VS Code for further detail.
/filters:background_color(white)/2024-01/BL54L15-Group.png)