Indoor Environmental Monitoring with Bluetooth Low Energy (BLE) Part-1/4: Fundamental Concepts of BLE
The connected appliances in buildings have been gaining popularity for a while but monitoring the indoor environment has never been drawn public attention as in the pandemic. There is a bunch of parameters to assess the healthiness and comfort in buildings. Conventionally, the temperature is the fundamental one where its measurement and monitoring is technically and economically feasible for most of the modern building projects. However, with the emergence of Internet of Things (IoT), monitoring more parameters become accessible and feasible. Some of the other important parameters are humidity, lux and irradiance levels, acoustic power as well as the concentrations of volatile organic compounds (like formaldehyde, toluene and benzene), CO2, CO and pollens. Available products and services for multi-parameter indoor monitoring increases in the market day-to-day.
As the number of end points (sensing units) increase in the built environment, cabling each of them is neither a practical nor an economically preferable option. Thanks to the advancements in wireless communication and battery technologies, most of these parameters can be monitored without (or with minimum) wiring. At this point, Bluetooth Low Energy (BLE) shines out as a promising communication technology to transfer small data packages (just like sensor readings) with a slight amount of power. Hence, this four-parts-tutorial aims to present basic concepts, technologies and tools for a DIY BLE-enabled environmental monitoring system. Parts are organized as follows:
- Part-1 introduces fundamentals of BLE,
- Part-2 demonstrates a BLE application with ESP32 (microcontroller+BLE radio) and BME680 (multi-parameter sensing unit)
- Part-3 describes how to store and visualize data -transferred with BLE- in a local device (using Raspberry Pi and Node-Red)
- Part-4 shows how to store and visualize data in cloud (using AWS IoT Core and Elasticsearch)
Note that, the first part is limited to discuss only point-to-point (1:1) communication with BLE despite it is capable to establish broadcasting (one-to-many connection) and mesh networking (many-to-many connection) as well [1].
Definition and Main Properties of the BLE
BLE is a wireless personal area network (WPAN) technology that is designed and used for transferring small data packages [2]. It is developed by Bluetooth Special Interest Group (SIG) and commonly used in sports gear, personal health devices, IoT sensor telemetry in the field, smart toys, mobile phones and audio systems to transfer different types of data. Despite of highly depending on the device specifications and application conditions, some of the main data transfer properties of the BLE can be sum up as [3]:
- the data transfer rates are between 125 Kb/s and 2 Mb/s (which is between 54–1300 Mb/s for Wi-Fi)
- the range would be up to 15m for Class-1 transmitter, 90m for Class-2 transmitter and 450m for long range transmitter (as the range increase, power consumption increases as well)
- consumes low power (for short range communication)
- requires minimum cost per module compared to many other wireless technologies
BLE enabled devices are categorized as “peripheral” and “central” in accordance with their role in the data transfer [1]. In most cases, the peripheral is the device that has the data to deliver. It announces (“advertises”) its presence to audiences (central devices) within its range. On the other hand, the central device is generally the one that searches for data sources (peripherals) to interact and connects whenever recognized. The connection is governed by the central node. A peripheral can only connect to a central device but a central device can connect to several peripherals. Just after the connection, peripheral stops advertising itself to other centrals.
In a sports gear case, the heart rate monitor is the peripheral and advertises (makes visible) its existence to surrounding. Typically, the smart phone is the central device that establishes connection, enable security and exploit the data of the peripheral. As a common practice, central node can even upgrade the firmware of the peripheral. In a daily operation, heart monitor can only connect to a single central device (mobile phone) but can transfer several data types (such as battery level together with the heart rate). On the other hand, the central device can connect to some other peripherals such as cycling speed and cadence sensors or headphones at the same time.
Generic Access Profile (GAP) and Generic Attributes (GATT)
The GAP and the GATT are two fundamental concepts of BLE protocol and have to be understood clearly even for introductory level applications. The GAP is a standard framework to define a general topology of the network stack that controls a BLE device. It enables connectivity between devices by controlling the parameters that govern the connection (such as Connection Interval and Slave Latency). Not surprisingly, the device role of being a peripheral or a central node is defined by the GAP. It also enables the security policy desired for the connection. Once the GAP establishes pairing among devices, the GATT guides them “how to talk each other”.
Based on a low-level communication structure (called Attribute Protocol), GATT is the mechanism of the data transfer with BLE protocol. It defines two fundamental roles for devices: server and client (similar the central and the peripheral definitions of the GAP). Generally, the server is the device where data is generated and the client is the one that needs to reach this data to perform desired functionality. Client requests; server responses. Thanks to the IDs defined by Bluetooth-SIG, request-response streams are realized effectively. A device can act one or both of these roles. GATT is composed of interbedded layers that are depicted in the figure below and explained in the next section.
The Content of the GATT
The GATT related concepts and their role in the BLE protocol are briefly defined below.
A profile refers to the functionality of a BLE device for the given use case. For instance, Cycling Speed and Cadence Profile “enables a Collector device to connect and interact with a Cycling Speed and Cadence Sensor for use in sports and fitness applications” (official definition by BLE-SIG [4]). A profile hosts a set of services and characteristics (defined below) that are needed for meeting the requirements given by the device design. The Cycling Speed and Cadence Profile, for example, involves Cycling Speed and Cadence Service and Device Information Service as well as necessary GAP and GATT services. Some examples of profiles defined by BLE-SIG examples are [4]:
- Device Time Profile
- Environmental Sensing Profile
- Glucose Profile
- Location and navigation profile, among others.
A service defines a functionality for the BLE devices. There are pre-defined roles systematically listed in BLE standards with the dedicated identification numbers, called universally unique identifiers (UUID). Based on these, services enable standard connections and functionalities which are crucial for interoperability and cross-functionality among devices offered by different companies. Typical service examples are [4]:
- Device Time Service
- Environmental Sensing Service
- Fitness Machine Service,
- Heart Rate Service, among others.
As mentioned above, a device profile can host more than a single service.
A characteristic define a specific feature for the service. Again, each has to have an UUID and there are pre-defined ones for common characteristics. A service may involve several characteristics. For instance, some of the characteristics included in Fitness Machine Service are:
- Treadmill Data,
- Step Climber Data,
- Indoor Bike Data,
- Supported Speed Range,
- Fitness Machine Status, among others.
The most “valuable” content of a characteristic for the user is the Value. It is the information that we want to transfer, such as temperature, speed, concentration, heart rate, etc. The other components of the characteristic are needed for ruling the usage and transfer of the value. More specifically, the characteristic defines properties and permissions for the operations related to a certain value. Common ones are:
- Read permission: Lets client to read value for the given characteristics.
- Write permission: Lets client to write a value (with the pre-determined format) to the given characteristics.
- Notify property: Lets server to send data at anytime without expecting any response from the client
- Indicate: Lets server to send data at anytime by expecting a response from the client
Beside these transfer related ones, optional information about the value can be defined as Descriptors. It would be related to what the value means (like “Ambient temperature in Celcius”), how the value is represented (like time format), etc.
Above, the Bluetooth-SIG is referred frequently for providing examples but the GATT makes it also possible to define custom services, characteristics and descriptors for developers. In such a case, one need to carefully deal with the UUIDs. For the cases defined in Bluetooth-SIG standards , one can adopt UUIDs referring to corresponding documentation. On the other hand, for custom ones, it is needed to investigate API or SDK of the product for assigned UUIDs. In case one need to have a custom UUID for a brand-new service or characteristic, free online random generators are avalibale.
We have just covered the key concepts of BLE. In the following article, this basic knowledge will be transferred to the code with an environmental monitoring application.
References:
