Hello everyone, welcome to <span>Lixin Embedded</span>.
The term “Internet of Things” has probably become quite familiar to you. In simple terms, the Internet of Things connects various devices to the network, allowing them to communicate with each other. Wireless technology is a star player in the Internet of Things, especially Low Energy Bluetooth (BLE), which is known for its energy efficiency. Today, we will discuss all things BLE, from basic principles to the protocol stack, and provide a practical case of using the nRF52 to create a BLE peripheral, taking you from zero to one in fully understanding BLE!
What is BLE
Bluetooth Low Energy (BLE) is a wireless communication technology designed specifically for low-power scenarios, operating in the 2.4GHz ISM band. Its goal is clear: to enable devices to perform the most tasks with the least amount of power, making it particularly suitable for applications that need to run on batteries for months or even years, such as smart wristbands and temperature sensors.
The origin of BLE can be traced back to the early days of Bluetooth technology. The name “Bluetooth” comes from King Harald Bluetooth of Denmark in the 10th century, symbolizing connection and unity. In 1994, Ericsson launched the first version of Bluetooth, primarily to replace wired connections, such as those for mice and keyboards. By 2010, Bluetooth 4.0 was introduced, bringing forth this new species called BLE. Note that BLE is not an upgraded version of traditional Bluetooth; rather, it is a completely new design optimized for IoT scenarios, characterized by small data volumes and low rates, but with exceptional energy efficiency.
The Relationship Between Traditional Bluetooth and BLE
Although traditional Bluetooth and BLE share the same name, they are technically two different entities, incompatible with each other and serving very different purposes. Traditional Bluetooth is suitable for high-bandwidth scenarios such as audio streaming and file transfers, while BLE is the preferred choice for low-bandwidth applications like sensor data and device control.
Here’s a direct comparison:
- Traditional Bluetooth: Excels in streaming, such as listening to music through headphones or sharing files, with a maximum speed of 3Mbps and higher power consumption, operating on 79 RF channels.
- BLE: Designed for low power consumption, suitable for intermittent transmission of small data packets, with a maximum speed of 2Mbps (after Bluetooth 5), using 40 channels, three of which are specifically for broadcasting, allowing for faster connection speeds.
Since its introduction in 2010, BLE has evolved rapidly. Bluetooth 5, released in 2016, brought a doubling of speed, a fourfold increase in range, and an eightfold increase in broadcast data capacity. In 2019, Bluetooth 5.1 introduced Angle of Arrival (AoA) and Angle of Departure (AoD) direction-finding technologies, enhancing positioning accuracy.
Advantages and Limitations of BLE
Every technology has its pros and cons, and BLE is no exception. Understanding its advantages and limitations is crucial for determining its suitability for your project.
Advantages:
- Ultra-low Power Consumption: BLE saves power by keeping the RF in sleep mode and transmitting small data packets.
- Free Specifications: Bluetooth SIG documentation is freely accessible, unlike some protocols that require membership fees.
- Affordable Chips: BLE modules and chips are cost-effective, offering high value for money.
Limitations:
- Limited Throughput: The physical layer speed of BLE is constrained, making it unsuitable for large data transfers.
- Short Range: BLE is designed for short-range communication, and the 2.4GHz band is easily interfered with by walls, metal, and human bodies, often limiting actual range.
- Requires a Gateway: BLE devices must connect through another IP-supporting device, such as a smartphone or gateway, to access the internet.
Complete Analysis of the BLE Protocol Stack
The BLE protocol stack may seem complex, but it is straightforward when broken down. Below is a hierarchical diagram of the BLE protocol stack (in actual development, you will mainly focus on the upper layers):
- Physical Layer (PHY): Responsible for RF communication, operating in the 2.4GHz ISM band, modulating and demodulating data.
- Link Layer: Interacts with the physical layer, managing RF states and timing, strictly adhering to BLE specifications.
- Direct Test Mode: Used to test RF performance, such as transmission power and reception sensitivity.
- Host Controller Interface (HCI): The bridge for communication between the host and the controller, which may be implemented on the same chip or on separate chips.
- Logical Link Control and Adaptation Protocol (L2CAP): Responsible for protocol multiplexing, packaging upper-layer data into standard BLE packets.
- Security Manager: Defines security mechanisms such as pairing, bonding, authentication, and encryption.
- Attribute Protocol (ATT): Specifies how servers expose data to clients, divided into server (exposing data) and client (reading or controlling) roles.
As a developer, you should focus on the layers above ATT, especially GAP and GATT, which will be detailed below.
GAP, Broadcasting, Scanning, and Connection
GAP, the Generic Access Profile, defines how BLE devices discover, connect, and communicate with each other. The core includes device roles, broadcasting, connection establishment, and security.
Device Roles:
- Broadcaster: Only sends broadcast packets and does not accept connections, such as Beacons.
- Observer: Only listens for broadcast packets and does not initiate connections.
- Central Device: Actively scans and initiates connections, such as smartphones.
- Peripheral: Sends broadcasts and accepts connections, such as smart wristbands.
A device can serve multiple roles; for example, a smartphone can act as a central device connecting to a wristband while also being a peripheral connecting to a computer.
Broadcasting and Scanning: BLE has 40 RF channels, each spaced 2MHz apart, with three main broadcast channels (37, 38, 39) specifically for sending broadcast packets. Peripherals send broadcast packets at fixed intervals (broadcast intervals), and central devices discover peripherals by scanning these three channels. Broadcast packets can contain device names, UUIDs, and other information. To improve discovery efficiency, broadcasting and scanning parameters should be optimized, such as shortening the broadcast interval or extending the scanning window.
Connection: Establishing a connection is a precise dance:
- The peripheral sends a connectable broadcast packet.
- The central device scans, and upon receiving the broadcast packet, sends a connection request.
- The peripheral listens on the same channel for a short time after broadcasting, and upon receiving the request, both parties begin the connection process.
- Once the connection is created, the central device becomes the master, and the peripheral becomes the slave.
- Establishing a connection requires both parties to exchange data packets for confirmation.
Connection Events: After connecting, both parties exchange data through connection events. The master device sends the first packet, and the slave must respond; otherwise, the master will close the event. The connection interval determines the event frequency, typically ranging from 7.5ms to 4s. Additionally, the slave device can skip certain events through slave latency to save power.
GATT, Services, and Characteristics
GATT, the Generic Attribute Profile, defines how BLE devices organize and transmit data. GATT has two roles:
- Server: The device that exposes data, such as a wristband providing heart rate data.
- Client: The device that reads or controls the server, such as a smartphone reading heart rate.
A device can simultaneously be both a server and a client; for example, a wristband can provide heart rate data while also reading notifications from a smartphone.
Services and Characteristics:
- Attribute: The data unit exposed by the server, with services and characteristics being subsets of attributes.
- Service: A collection of related attributes representing a specific function. For example, the battery service includes the battery level characteristic.
- Characteristic: A specific data point within a service, such as the battery level characteristic indicating the remaining battery percentage.
The structure of services and characteristics resembles a tree: a service can have multiple characteristics, each representing a specific data or control point. GATT operations include:
- Command: Sent from the client to the server without requiring a response, such as a write command.
- Request: Requires a response from the server, such as read or write requests.
- Response: The server’s reply to a request.
- Notification: The server actively pushes data to the client without requiring a response.
- Indication: Similar to a notification but requires confirmation from the client.
- Confirmation: The client’s confirmation of an indication.
Notifications and indications are controlled through the Client Characteristic Configuration Descriptor (CCCD), where writing 1 enables notifications, writing 2 enables indications, and writing 0 disables them.
Conclusion
From the protocol stack to practical development, while BLE has many details, its core logic is not complex: broadcasting, connecting, and data exchange. I hope this article provides you with a comprehensive understanding of BLE. If you have any insights or questions about BLE development, feel free to leave a comment.
