What Is Bluetooth Low Energy (BLE)?

Detailed Explanation

BLE was introduced in Bluetooth 4.0 (2010) to address the power consumption of classic Bluetooth — a BLE device can realistically operate for years on a coin cell battery by transmitting brief bursts of data infrequently and sleeping in between. It has become the standard wireless interface for wearables, medical sensors, environmental monitors, and any embedded product that pairs with a smartphone.

Radio and channel structure

BLE operates in the 2.4 GHz ISM band (2400–2483.5 MHz), which is shared with Wi-Fi 2.4 GHz, classic Bluetooth, and Zigbee. BLE divides this band into 40 RF channels of 2 MHz width:

• 37 data channels (channels 0–36) for connected data exchange
• 3 advertising channels (37, 38, 39 at 2402, 2426, and 2480 MHz) chosen to avoid the Wi-Fi channels 1, 6, and 11 centres

Adaptive frequency hopping is used during connected mode: the master and peripheral hop through the 37 data channels using a pseudo-random sequence, avoiding persistent interference from Wi-Fi or other sources.

Advertising and scanning

A BLE peripheral (the embedded device) broadcasts advertising packets on the three advertising channels at a configured interval (typically 100 ms to 2 seconds). Each advertising packet is up to 31 bytes (or 255 bytes with extended advertising in BLE 5.0) and contains device identification, capabilities, and optionally sensor readings.

A central (typically a smartphone or hub) scans for advertising packets and may initiate a connection. Some devices operate in advertisement-only mode (no connection accepted), broadcasting sensor data directly in the advertising payload — this is used by Bluetooth beacons (iBeacon, Eddystone) and some BLE sensor tags where a connection is unnecessary.

GATT: services and characteristics

Once connected, BLE uses the GATT (Generic Attribute Profile) to structure data exchange. The embedded peripheral acts as a GATT server, exposing a set of services — each a UUID-identified collection of characteristics. The smartphone app acts as a GATT client, discovering and accessing these characteristics.

A characteristic has:

• A UUID identifying the data type
• A value (the data itself — up to 512 bytes per characteristic with long write/read procedures)
• Properties (Read, Write, Notify, Indicate)
• Descriptors (metadata about the characteristic — the CCCD enables/disables notifications)

Notify is the standard mechanism for pushing data from device to phone: the peripheral sends a notification whenever the characteristic value changes, without the phone needing to poll. Indicate is like Notify but requires an application-layer acknowledgement.

Connection parameters

Connected BLE communication is highly scheduled. The master sets:

• Connection interval: time between successive connection events (minimum 7.5 ms, maximum 4 seconds). Longer intervals = lower power, higher latency.
• Slave latency: number of connection events the peripheral is allowed to skip without timing out (reduces peripheral average current at the cost of command latency).
• Supervision timeout: maximum time without a successful connection event before the link is declared lost.

Typical IoT sensor parameters: 100–500 ms connection interval, slave latency 0–4, supervision timeout 4–10 seconds.

BLE 5.x features

BLE 5.0 (2016) and later introduced:

• 2× speed PHY (LE 2M): 2 Mbit/s data rate for higher throughput at the cost of slightly shorter range
• Long range PHY (LE Coded, S=2/S=8): error correction for extended range at reduced throughput
• Extended advertising: advertising packets up to 255 bytes, periodic advertising for connectionless broadcast
• Channel sounding (BLE 5.4): centimetre-accurate ranging using phase-based distance measurement

Practical Examples

A heart rate monitor uses BLE to connect to a smartphone fitness app. The monitor implements the standardised Bluetooth Heart Rate Service (UUID 0x180D) with a Heart Rate Measurement characteristic (UUID 0x2A37). The characteristic value is a 2-byte structure: the first byte indicates measurement format; the second is the heart rate in BPM. The monitor sends a Notify event every second; the app reads and displays it. Because the Heart Rate Service is standardised, any BLE heart rate monitor works with any compliant smartphone app without vendor-specific configuration.

For custom embedded BLE devices, the nRF52 series (using Zephyr RTOS) and ESP32 (using the NimBLE stack) are the most common platforms. See nRF52 BLE peripheral with Zephyr GATT for a Zephyr implementation, ESP32 BLE fundamentals for the ESP-IDF NimBLE approach, and how to minimise current draw on nRF52 for connection interval and advertising interval optimisation strategies.

Design Considerations

• BLE vs Wi-Fi power budget: for a device that publishes small sensor readings to a nearby smartphone, BLE draws far less power than Wi-Fi — BLE in connected mode at 100 ms connection interval draws approximately 50–200 µA average, while Wi-Fi in modem sleep draws 10–20 mA. Reserve Wi-Fi for devices that need internet access or high throughput.
• Connection vs advertising: for devices that broadcast public data (beacons, asset tags), advertisement-only mode consumes less power than establishing a connection. For devices that exchange private data bidirectionally (configuration, firmware updates, sensor readings with authentication), connections with CCCD notifications are appropriate.
• Security and pairing: BLE 4.2+ supports LE Secure Connections (LESC) using Elliptic Curve Diffie-Hellman for key exchange — use this for any product that transmits sensitive data or allows device configuration. Legacy pairing (Just Works) provides no protection against eavesdropping or man-in-the-middle attacks.
• 2.4 GHz coexistence with Wi-Fi: if the device uses both BLE and 2.4 GHz Wi-Fi, plan for radio coexistence. On modules with a single antenna shared between BLE and Wi-Fi (like the ESP32), both radios are time-multiplexed — simultaneous high-throughput Wi-Fi reduces BLE connection reliability.
• Zeus Design develops mobile apps and companion firmware for BLE-connected hardware products, covering GATT profile design, BLE pairing, and iOS/Android BLE integration.

Common Mistakes

• Advertising interval too fast: advertising every 20 ms consumes significant power and is rarely necessary. Use 100–500 ms advertising intervals for most applications; 1–2 seconds for low-power beacons.
• Forgetting to enable CCCD: notifications are only sent after the GATT client writes 0x0001 to the CCCD (Client Characteristic Configuration Descriptor) of the notifiable characteristic. Many developers are surprised when notifications are not received — check that the app enables the CCCD after discovering the service.
• Characteristic value too large for a single packet: BLE data packets carry a maximum ATT payload of 23 bytes by default (MTU = 23). Exchanging larger values requires MTU negotiation (up to 512 bytes) or fragmented read/write procedures. Negotiate MTU after connection establishment for any characteristic exceeding 20 bytes.
• Not handling connection parameter updates: the peripheral may request updated connection parameters (e.g. longer interval after initial setup) via the L2CAP connection parameter update request. iOS and Android handle this automatically for standardised profiles; custom implementations must handle the update request and response in both central and peripheral firmware.