Electronics News Updates

Using the Ble Functionality of the Esp32

One of the most beautiful features which the ESP32 has over the ESP-12e is the fact that, asides the WiFi, it has two other communication modules onboard. The ESP32 comes with an onboard Classic Bluetooth and Bluetooth Low Energy modules. For today’s tutorial, we will explore how the Bluetooth Low Energy Module onboard the ESP-32 can be used in projects.

INTRODUCTION TO BLUETOOTH LOW ENERGY – BLE

The Bluetooth protocol can be divided into two types; Classic Bluetooth, and the newer Bluetooth Low Energy protocol which is also referred to as Bluetooth 4.0. These two protocols operate within the 2.4ghz ISM band but they both have different data rate, different power consumption rate, and are optimized for different kind of applications. The Bluetooth Low Energy (BLE) was created to overcome the setbacks of classic Bluetooth which makes it a little bit unfit for use in IoT and battery powered smart devices which only need to send short burst of data at specific intervals. The BLE was designed to consume only a fraction of the power which classic Bluetooth devices consume when transmitting data and stay in sleep mode when not transmitting data unlike the Classic Bluetooth’s continuous data streaming. This makes BLE devices more power efficient and suitable for IoT products and other battery-powered smart devices which are usually desired to last for as long as possible on a single battery charge.

A detailed comparison between the two Bluetooth types is shown in the Image below.

One of the downsides of the operation dynamics of BLE devices is the Complexity or Robustness (depending on how you look at it) of the messaging system. In classic Bluetooth, the serial port protocol (SPP) is usually used to send data between the devices as the communication occurs without much overhead, but for BLE, data during communication is organized using a profile referred to as GATT (Generic Attributes).

There are essentially two protocols that are important in communication between two BLE devices; GAP and GATT. Understanding how these two work is extremely important to programming devices to communicate via the BLE protocol.

GAP Protocol

GAP is an acronym for the Generic Access Profile, and it controls connections and advertising (Making a device visible and open for connection) in Bluetooth. It defines the roles which devices play in communication and also determines how the advertising (or scanning, depending on device role) payload is broadcasted.

There are essentially two roles which BLE devices can play based on GAP; Central Device and Peripheral Device. These two devices are the BLE’s representation for the more popular words; “Client” and “Server” respectively. The peripheral devices are usually small battery powered devices who broadcast the advertising data, waiting for a connection from a central device ready to receive the data payload. In IoT based solutions, the peripheral devices are usually sensors, etc., while the Central devices are usually gateway, smartphones, etc. Prior to connection, the Generic Access profile will keep broadcasting the advertising payload until there is a matching scanning response. Once a connection between a peripheral and a central device is established, the advertising process will stop and you will typically no longer be able to send advertising packets out anymore, at this point, GATT services and characteristics kick in to facilitate communication in both directions.

GATT Protocol

GATT is an acronym for the Generic Attribute Profile, and it defines how two Bluetooth Low Energy devices, transfer data back and forth between each other, using concepts called Services and Characteristics. It makes use of a generic data protocol called the Attribute Protocol (ATT), to store Services, Characteristics, and related data in a simple lookup table using 16-bit IDs for each entry in the table. The GATT hierarchical data structure comprises of three main elements; Profiles, Services, and Characteristics.

Using the Ble Functionality of the Esp32

A Profile is a pre-defined collection of Services that has been compiled by either the Bluetooth SIG or by the peripheral designers. For example, in a heart rate monitor, a Heart Rate Profile could include the Heart Rate Service, the Battery Life Service, and the Device Information Service. A list of officially adopted GATT is available here.

Services are used to group data into logic entities and contain specific chunks of data called characteristics. A service can have one or more characteristics, and each service distinguishes itself from other services by means of a unique numeric ID called a UUID, which can be either 16-bit (for officially adopted BLE Services) or 128-bit (for custom services). A full list of officially adopted BLE services can be seen on the Services page of the Bluetooth Developer Portal. To better understand how services work,  Consider the Heart Rate Example again, it could contain up to 3 characteristics which in the officially adopted service, for instance, includes; Heart Rate Measurement, Body Sensor Location, and Heart Rate Control Point. Thus a service essentially to group related data.

Characteristics represent the lowest level concept in GATT structure. It encapsulates a single data point and just like services, it distinguished from other characteristics using a Unique numeric ID; the UUID. Characteristics are the major containers that carry data between two devices.

With these said, today’s tutorial will show how to set up the ESP32 as a Client (Central Device) and as Server (peripheral device). For proper demonstration, we will use two ESP32 boards. One of the boards will be programmed to act as the server, with characteristics to send random data,  while the other ESP32 board will be programmed to act as a BLE scanner to find the server.

For More Details: Using the Ble Functionality of the Esp32

Tags

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button
Close
Close