Bluetooth & BLE Patterns on Embedded Systems Development

BLE Advertising & GAP

Mon, 01 Jan 0001 00:00:00 +0000

BLE Advertising & GAP#

BLE advertising is the mechanism by which devices announce their presence to the world. Unlike WiFi, where a station actively searches for access points, BLE reverses the model — the peripheral broadcasts short packets at regular intervals, and any nearby central or observer can receive them without establishing a connection. The Generic Access Profile (GAP) defines the roles, modes, and procedures that govern this discovery process. Understanding advertising at the packet level is essential because every byte matters: the legacy advertising payload is limited to 31 bytes, and the choices made in configuring advertising parameters directly determine power consumption, discovery latency, and connection speed.

GATT Services & Characteristics

Mon, 01 Jan 0001 00:00:00 +0000

GATT Services & Characteristics#

The Generic Attribute Profile (GATT) is the framework that organizes all data exchange over a BLE connection. Every piece of information — a temperature reading, a firmware version string, a configuration parameter — is exposed through a structured hierarchy of services, characteristics, and descriptors. GATT determines how a central discovers what a peripheral offers, how data is read and written, and how the peripheral pushes updates without being polled. Getting GATT design right is the difference between a device that pairs seamlessly with phone apps and one that requires custom protocol documentation and fragile byte-level parsing.

BLE Bonding & Security

Mon, 01 Jan 0001 00:00:00 +0000

BLE Bonding & Security#

BLE security is frequently misunderstood and frequently misconfigured. The protocol provides a layered security model — pairing establishes trust, encryption protects data in transit, and bonding stores keys for future reconnections without re-pairing. The challenge is that BLE’s default mode (Just Works pairing) provides encryption but no authentication, meaning a man-in-the-middle (MITM) attack is trivially possible during the pairing process. Understanding the security model at the protocol level is essential for choosing the right trade-off between usability, security, and firmware complexity.

BLE Connection Parameters & Throughput

Mon, 01 Jan 0001 00:00:00 +0000

BLE Connection Parameters & Throughput#

BLE connection parameters determine three fundamental trade-offs: power consumption, latency, and throughput. Unlike WiFi, where the radio stays on continuously, BLE operates in discrete connection events — short windows during which the central and peripheral exchange data, then both radios power down until the next event. The timing of these events, the amount of data exchanged per event, and the physical layer data rate collectively determine what is achievable. A misconfigured connection can waste 10x the power necessary or deliver 10x less throughput than the hardware supports.

BLE Power Optimization

Mon, 01 Jan 0001 00:00:00 +0000

BLE Power Optimization#

Power consumption is the defining advantage of BLE over other wireless protocols. A BLE peripheral can operate for years on a coin cell battery — but only if the firmware is designed around the protocol’s duty-cycling nature. The radio consumes 5–8 mA when transmitting and 5–7 mA when receiving on a typical nRF52 SoC, which means even brief radio activity dominates the total power budget. The difference between a well-optimized and a naively configured BLE device can be 10x in average current draw, translating directly to 10x battery life.

BLE Central Role & Scanning

Mon, 01 Jan 0001 00:00:00 +0000

BLE Central Role & Scanning#

Most BLE tutorials focus on the peripheral role — advertising a service and waiting for a phone to connect. But many embedded applications require the MCU to act as a central: scanning for peripherals, initiating connections, and managing ongoing data exchange with one or more remote devices. The gateway pattern — an MCU central aggregating data from a fleet of BLE sensor peripherals — is one of the most common architectures in commercial IoT deployments. Running a BLE central on an MCU introduces scheduling challenges, memory constraints, and scanning trade-offs that do not exist in phone-based central implementations.