Bluetooth & BLE

Bluetooth Low Energy (BLE) is the default wireless interface for products that pair with a smartphone: wearables, medical sensors, environmental monitors, and asset trackers. Getting the GATT profile, connection parameters, and pairing model right early avoids expensive firmware rework once an app or certification process depends on them.

What Is Bluetooth & BLE?

This subtopic covers BLE at the implementation level: how to structure a GATT profile, how connection parameters trade off power against latency, how pairing and bonding secure a link, and how the protocol has evolved from Bluetooth 4.0 through 6.0. It sits below the protocol-selection layer. For the decision between BLE, Wi-Fi, LoRa, and Zigbee, see the parent Wireless topic.

This subtopic is part of the Wireless topic.

Why Bluetooth & BLE Design Matters

• Battery life is set by firmware decisions, not just hardware — the same BLE radio can draw 50 µA or 5 mA average current depending on advertising interval, connection interval, and slave latency choices made in firmware.
• A poorly designed GATT profile is expensive to change — once a companion app ships against a characteristic UUID and data layout, revising the profile means versioning both the firmware and the app, or supporting both indefinitely.
• Security decisions made at pairing time are hard to retrofit — Just Works pairing accepted in early development has no protection against eavesdropping; adding LE Secure Connections and per-characteristic security levels later means re-testing the entire bonding and reconnection flow.
• Debugging BLE without the right tools wastes days — connection and pairing failures are frequently invisible from application-level logs alone and require a packet sniffer to diagnose correctly.

Key Concepts

• GAP (Generic Access Profile) — governs how BLE devices become discoverable and form connections: advertising, scanning, and connection establishment roles (peripheral, central, broadcaster, observer).
• GATT (Generic Attribute Profile) — the data model used once connected: services group related characteristics, each characteristic holds a value and properties (Read, Write, Notify, Indicate).
• Connection interval, slave latency, supervision timeout — the three parameters that determine a connected BLE link's power and latency behaviour; see BLE connection parameters and power optimisation.
• Pairing and bonding — pairing establishes a shared key for a session; bonding stores that key (the LTK) so future reconnections skip the pairing exchange. See BLE pairing and security in embedded products.
• CCCD (Client Characteristic Configuration Descriptor) — the descriptor a GATT client writes to enable or disable notifications/indications on a characteristic; a very common source of "notifications never arrive" bugs.
• PHY (LE 1M, LE 2M, LE Coded) — the physical layer mode negotiated per connection, trading data rate for range since BLE 5.0.

Common Tools and Software

• nRF Sniffer for Bluetooth LE — Nordic's free packet sniffer (with a compatible nRF52 dev board) that captures over-the-air BLE traffic into Wireshark, including the advertising and connection-establishment exchange.
• Wireshark — the standard tool for inspecting captured BLE packets: GATT operations, pairing exchanges, and connection parameter negotiation, once a capture exists from the nRF Sniffer or a platform log.
• nRF Connect for Mobile — Nordic's Android/iOS app for manually browsing GATT services and characteristics, writing values, and toggling notifications during bring-up without a custom companion app.
• Android btsnoop_hci.log — a host-side capture of all BLE HCI traffic on an Android test device, useful when the sniffer's radio can't keep up with a fast-hopping connection.

Common Questions

Does a commercial BLE product need Bluetooth SIG qualification?

Yes, in most cases. Any product using the Bluetooth wordmark or logo, or using a Bluetooth stack, must complete Bluetooth SIG qualification (Declaration ID and listing) under the Bluetooth SIG's membership and qualification program, separate from radio (ACMA/RCM) certification. Pre-certified modules (Nordic nRF52 modules, ESP32 WROOM, etc.) typically carry an "end product listing" path that references the module's existing qualification, which is simpler than qualifying a custom BLE stack from scratch. See the Compliance topic for the radio certification side of the requirement.

What is BLE Mesh, and is it the same as a normal GATT connection?

No. BLE Mesh is a separate specification built on top of the BLE advertising and scanning mechanism (not GATT connections) that allows many-to-many communication across a network of nodes, with messages relayed hop-to-hop. It is used for large-scale lighting and building-automation deployments where a single-connection GATT model doesn't scale. A standard BLE peripheral with a GATT server (the model covered throughout this topic) is the right choice for point-to-point sensor-to-phone or sensor-to-hub products; BLE Mesh is a distinct architecture worth evaluating only when the deployment genuinely needs many interconnected nodes. See What Is Bluetooth Mesh? for the managed-flooding architecture, provisioning process, and node roles in full.

Can two BLE peripherals talk to each other directly, without a phone in the middle?

Yes. Any BLE device can implement both central and peripheral roles (subject to the stack's supported role combinations), allowing one embedded device to connect directly to another as its GATT client. This is less common than phone-to-device communication because embedded GATT client implementations are more work than using a phone's existing BLE stack, but it is a standard pattern for sensor-to-gateway products where the gateway is itself an MCU (e.g. an ESP32 acting as a BLE-to-Wi-Fi bridge for several BLE sensor peripherals).

How much does moving from Bluetooth 4.x to 5.x actually help?

It depends on which BLE 5.x feature the application uses. LE 2M PHY roughly doubles data throughput at similar range; LE Coded PHY extends range at the cost of throughput; Extended Advertising raises the advertising payload limit from 31 to 255 bytes, useful for beacons carrying more data without a connection. None of these are "on" by default: the application and stack must explicitly negotiate them, and the peer (typically a phone) must also support the feature. See Bluetooth versions 3.0 through 6.0 compared for the full feature-by-version breakdown. Zeus Design develops BLE firmware and GATT profiles for connected hardware products.

Knowledge Base

BLE Fundamentals

• What Is Bluetooth Low Energy (BLE)? — GAP/GATT architecture, advertising and scanning, connection parameters, and BLE 5.x features
• What Are the Differences Between Bluetooth Versions 3.0 Through 6.0? — BR/EDR vs BLE split, and a version-by-version feature table through LE Audio and Channel Sounding
• How Do You Implement Bluetooth LE Audio and the LC3 Codec? — the LC3 codec, CIS/BIS Isochronous Channels, the BAP/CAP profile stack, Auracast broadcast audio, and SoC/stack requirements
• What Is Bluetooth Mesh and How Does It Work? — managed flooding vs routed mesh, provisioning (PB-ADV/PB-GATT), Relay/Friend/Low Power Node roles, and NetKey/AppKey security
• How Do You Implement BLE Direction Finding (AoA and AoD)? — the Constant Tone Extension, IQ sampling, AoA vs AoD antenna-array placement, and which nRF52 chips support the required radio hardware
• How Do You Implement a BLE Beacon: iBeacon vs Eddystone? — iBeacon's UUID/Major/Minor format, Eddystone-UID/URL/TLM frame types, Tx power calibration, and choosing between them

GATT Profile Design

• How Do You Design a Custom BLE GATT Profile? — service/characteristic data modelling, standard vs custom 128-bit UUIDs, characteristic properties, and the Notify vs Indicate decision

Connection Parameters and Power

• How Do BLE Connection Parameters Affect Power Consumption? — connection interval and slave latency tuning, supervision timeout, a worked nRF52840 power example, and per-application-type guidance

Security

• How Does BLE Pairing and Security Work in Embedded Products? — SMP pairing methods, Legacy Pairing vs LE Secure Connections, bonding and LTK storage, and security levels per characteristic

Debugging

• How Do You Debug BLE with a Packet Sniffer? — nRF Sniffer + Wireshark capture workflow, the channel-hopping problem, Android's btsnoop_hci.log, and when to sniff versus read SDK logs

Platform Implementation

For platform-specific BLE implementation guides, see BLE on the ESP32 (NimBLE) and BLE peripheral with Zephyr GATT on nRF52 in the ESP32 and nRF topics.

Forum Discussions

• BLE GATT notifications stop after reconnect — the CCCD not being re-written by the client after a reconnect, and Zephyr/ESP-IDF subscription management patterns