BLE (Bluetooth Low Energy), also called Bluetooth LE, is a short-range wireless protocol in the Bluetooth 4.0+ specification designed for low duty-cycle communication between devices, prioritizing energy efficiency over throughput. Unlike Classic Bluetooth, BLE is optimized for sending small packets infrequently, making it well-suited for battery-powered embedded sensors and peripherals.
In practice
BLE operates in the 2.4 GHz ISM band across 40 channels (three advertising channels and 37 data channels). Devices discover each other through advertising packets broadcast on the three advertising channels; a central device (e.g., a smartphone or gateway) scans for these packets and initiates a connection if needed. Communication can be connection-oriented or connectionless (the latter via broadcaster/observer roles present since BLE 4.0; Bluetooth 5.0 extended this model with extended advertising and periodic advertising for higher-capacity, more flexible connectionless operation).
The GATT (Generic Attribute Profile) layer defines how data is structured for connected operation. A peripheral exposes a hierarchy of Services and Characteristics, which the central reads, writes, or subscribes to for notifications. Most embedded BLE development at the application level is largely GATT profile design: choosing UUIDs, setting characteristic properties, and handling notify/indicate callbacks. Nordic Semiconductor's nRF5 SDK and nRF Connect SDK (Zephyr-based), Silicon Labs' Gecko SDK, and TI's SimpleLink SDK each wrap the underlying BLE stack with their own GATT APIs.
On the hardware side, BLE is available as a standalone radio module (e.g., u-blox NINA, Murata Type 1JP), as an integrated SoC with an onboard ARM Cortex-M core (e.g., Nordic nRF52832/nRF52840, Silicon Labs EFR32BG, Dialog DA14531, TI CC2640R2F), or as a hosted co-processor connected over UART or SPI (e.g., Nordic nRF52 series acting as a BLE co-processor controlled by a separate host MCU via the HCI or a vendor serial protocol). The SoC approach is most common in new embedded designs because it eliminates an external host MCU for simple applications.
Key pitfalls include: misunderstanding connection interval and supervision timeout tuning (too-short intervals drain the peripheral battery; too-long intervals increase latency); exceeding the MTU (default 23 bytes for ATT payload in BLE 4.x, negotiable up to 512 bytes with ATT MTU exchange); forgetting that the 2.4 GHz band is shared with Wi-Fi and 802.15.4 (Zigbee/Thread), which can cause coexistence interference; and underestimating the certification burden (Bluetooth SIG qualification is required for end products, though pre-certified modules shift much of that burden to the module vendor).
Frequently asked
What data rates does BLE actually achieve in practice?
BLE 4.x uses a 1 Mbps physical layer (LE 1M PHY). Bluetooth 5.0 added a 2 Mbps PHY (LE 2M) for higher throughput and a 125/500 kbps coded PHY (LE Coded) for extended range at the cost of throughput. Actual application throughput on the 1M PHY is typically 200-800 kbps depending on connection interval, MTU size, and
stack overhead. BLE is not designed for streaming large amounts of data; for that, Classic Bluetooth or Wi-Fi is usually more appropriate.
How does BLE compare to Classic Bluetooth for embedded designs?
Classic Bluetooth (BR/EDR) targets higher-throughput, lower-latency streaming applications such as audio. BLE targets low duty-cycle sensor and control applications where a coin cell battery may need to last months or years. The two share the same 2.4 GHz radio band and addressing scheme but use different air protocols. Many modern SoCs, such as the Nordic nRF52840 and Silicon Labs EFR32MG, support both modes (dual-mode), but many cost-optimized embedded parts support BLE only.
What is the typical range of a BLE link?
Range depends heavily on TX power, antenna design, the physical environment, and PHY selection. In open air with the 1M PHY, 10-30 meters is common for typical module-class hardware at 0 dBm TX power. Bluetooth 5.0 LE Coded PHY can extend this to several hundred meters in ideal conditions at the cost of throughput. Indoors with walls and interference, practical range is often under 10 meters for reliable connectivity.
Do I need a full RTOS to run a BLE stack on a microcontroller?
It depends on the
stack implementation. Nordic's SoftDevice (used with the nRF5 SDK) runs as a pre-compiled binary with its own
scheduler and reserves specific hardware resources; your application code runs cooperatively alongside it without necessarily requiring an RTOS, though
FreeRTOS and Zephyr are both supported. The nRF Connect SDK uses Zephyr, which does include an RTOS. Silicon Labs' Gecko SDK BLE stack is similarly designed to integrate with or without an RTOS. Simpler hosted co-processor setups (where the BLE stack runs on a separate chip) reduce the burden on the host
MCU considerably.
What is the difference between advertising and a connection in BLE?
In advertising mode, a peripheral broadcasts small packets (up to 31 bytes of payload in BLE 4.x, extended in BLE 5.0) periodically on the three advertising channels without any established link. Any scanner in range can receive these without the peripheral knowing. A connection is established when a central device sends a connection request to the advertising peripheral and both sides synchronize to a hopping schedule across the 37 data channels (in BLE 4.x this uses a CONNECT_IND packet on an advertising channel; BLE 5.0 extended advertising uses a different procedure). Connections allow bidirectional, acknowledged data exchange with GATT but also consume more power and require the peripheral to wake on a defined connection interval.
Differentiators vs similar concepts
BLE is frequently confused with Classic Bluetooth (BR/EDR). The two share the Bluetooth brand and the 2.4 GHz band but are distinct air protocols with different
stack architectures, power profiles, and use cases. Classic Bluetooth targets continuous streaming (audio,
serial port emulation via SPP) with higher throughput and lower
latency, at the cost of significantly higher power consumption. BLE targets intermittent sensor and control data with very low average current draw. A dual-mode device supports both; a BLE-only device cannot communicate with a Classic-only device. BLE is also sometimes confused with Bluetooth mesh, which is a higher-layer networking specification built on top of BLE advertising and connections, not a separate radio standard.
