Developing Cross-platform Qt Applications for BLE-based Systems

What makes BLE so popular?

Bluetooth Low Energy (BLE, Bluetooth LE, also known as Bluetooth Smart) is a form of wireless PAN technology that can be used to transfer data between devices using radio waves.

The explosive growth in connected consumer electronics and the release of LE Audio will see an increase in annual shipments of Bluetooth LE devices over the next five years.

According to the Bluetooth 2022 Market Update report, annual shipments of Bluetooth-enabled devices will reach 7 billion units by 2026.

Shipments of Bluetooth platforms and peripheral devices 2017-2026

Since many IoT devices use small processors and sensors, BLE has become the most commonly used communication protocol (compared to Bluetooth Classic) in IoT applications. BLE is best suited for applications with small transmission ranges and infrequently transmitted small amounts of data.

With all the variety, BLE devices have common characteristics:

• Lower power consumption when compared to Bluetooth devices;
• Communication is carried out over short distances;
• The priority is the operating time of the device without replacing the battery, rather than the data transfer rate;
• Small size;
• Ease of interaction with various mobile platforms.

Basic things you need to know about BLE when starting app development with Qt

There are several building blocks of a Bluetooth device.

• An application implements the logic of work that is useful to the end-user;
  
• The upper layers of the Bluetooth protocol stack are provided by the Host.
  
• The Bluetooth Controller deals with the lower layers of Bluetooth, including the radio.

The Bluetooth low energy protocol stack is built on several layers needed for the exchange of information.

BLE protocol stack architecture

PHY - or Physical Layer, which is in charge of the actual transmission and receipt of information over the air using radio waves.

BLE transmits data on the non-licensed 2.4 GHz band at a speed of 1 Mbps. The information is transmitted using Gaussian Frequency-Shift Keying (GFSK) through discrete changes in the frequency of the carrier signal. This form of modulation makes it possible to save battery power, as it involves the use of radio power amplifiers. GFSK also provides for the use of cheaper and less accurate transmission components since the circuit does not need to perform significant out-of-channel filtering.

The Link Layer (LL) is an interface for a physical layer. It deals with monitoring the RF (Radio Frequency) state of the device and is also in charge of the formation of anchor points, turning on the physical channel, and the length of the packets. The LL has two types of packets: advertising and data packets. The advertising packet is transmitted through 3 advertising channels, and the data packet is transmitted through 37 data channels.

HCI (Host Controller Interface) provides communication between the host and the controller. HCI is implemented through either a software API or a hardware interface (UART, SPI, or USB).

All profiles and applications run on top of the GAP and GATT layers.

GAP (Generic Access Profile) manages connections and advertising. 

Devices can communicate in two ways: advertisement mode (broadcasting) and connection mode.

In the BLE advertising mode, peripheral devices send a relatively small amount of information at regular intervals without being able to receive any information in return. So do beacons in retail outlets and public places. Any BLE-enabled device, such as smartphones or tablets, can receive information from nearby BLE beacons. Advertising messages from retail chains appear on the smartphone screen. The method is not secure because the data is passed to any application that knows the beacon’s UUID (Universal Unique Identifier). 

The features of this communication method can also be attributed to saving the energy of the peripheral device. The ability to connect to a device is not always enabled. The advertising package is sent at certain intervals. This way, the peripheral device is not always in standby mode, and significant battery savings are achieved.BLE beacons are used in many areas: for advertising purposes, as part of BLE positioning and location tracking systems, and as a transmission link between other devices and the server.

BLE broadcast mode

The use of GATT (Generic ATTribe Profile) services and characteristics is possible after a connection between two objects is established. The connected mode allows two devices to communicate and privately share much more data. Two objects can exchange information in both directions.

BLE connection mode

GAP defines the roles of devices in interaction as central (clients) or peripheral devices.

We use this method when we link a fitness tracker to a smartphone. Once the connection is made, data exchange begins. 

Peripherals are most often beacons, smart watches, sensors, heart rate monitors, fitness trackers, etc.

Central devices generally have more power and memory and can process and combine information from several devices to provide it to the user in a summarized form. Usually, these are tablets, smartphones, and computers.

GATT defines the procedures and formats for transmitting data over BLE.

All standard BLE profiles are based on GATT, with a unified structure that enables interoperability between devices from different vendors.

GATT is based on an attribute protocol, where data is organized into services. A service is a specific hardware feature of a Bluetooth device. For example, temperature-related sensor values ​​or battery indicators are grouped into separate services.

Hierarchy of GATT Profiles

A service has one or more characteristics. The number of services and characteristics is determined by the tasks of the device. The characteristic reflects the internal state of the BLE device. A characteristic can have one or several descriptors. Each service, feature, and descriptor is identified by a Universally Unique Identifier (UUID). Attributes store data related to services and characteristics.

Characteristics also provide various permissions that are used to determine the client's ability to interact with the characteristic: read, write, notify, or indicate. Permissions determine whether the attributes can be read or written; whether they can send notifications or indications; and what levels of access are required for each of these operations. These permissions are not defined by the Attribute Protocol (ATT) and cannot be read through it. They are defined at the top level (GATT or application layer).

The application developer primarily interacts with the API provided by the operating system or the chipset SDK, which abstracts away many questions related to BLE configuration.

Native and cross-platform BLE applications 

Applications designed to communicate with peripheral BLE devices can be

• mobile
• desktop
• or embedded.

Applications for BLE devices can be native and cross-platform by belonging to the operating system.

Major mobile and desktop platforms like iOS, Android, Linux, macOS, and Windows support BLE. Each platform has a BLE app development service - a set of native applications and associated SDKs for creating applications for interacting with BLE devices.

Even when writing a native Android BLE application, compatibility issues can arise. The Android operating system runs on devices from different manufacturers with different hardware configurations and BLE versions. It creates certain difficulties in BLE mobile app development because an application should work the same on all existing Android devices.

Using native tools is not so convenient and cost-effective if developers need to make the same application for several operating systems, for example, iOS and Android. Having made a native application, it will not be possible to quickly port it to another platform. A cross-platform approach allows you to write one application and build it on different platforms with minor modifications. Yet, desktop and mobile applications can significantly differ in interface design with the same logic of work.

BLE cross-platform development makes it possible to apply cross-platform solutions in this area.

Features of Qt BLE app development

C++ is an extremely convenient programming language for developing applications for embedded systems and smart devices. It offers high performance, control, and long-term operation, which is important for low-power devices.

The most popular C++ cross-platform framework for app development is Qt. The framework supports BLE either out of the box or via plugins. Qt has certain functions for interacting with BLE that can be used to create applications regardless of the platform. The Qt Bluetooth Low Energy API is provided for BLE application development with Qt. 

The framework is notable for combining all the benefits of C++ with a declarative QML language built on top of flexible JavaScript. Graphically rich user interface elements written in QML can be integrated with logic written in C++.

QML makes development fast and easy by saving code. Acting as a wrapper for building Qt BLE, the Bluetooth LE QML API allows you to quickly and easily build and integrate desktop, mobile, or embedded applications into any BLE-enabled device.

Qt Bluetooth supports the development of BLE-related software on the client/central device side.

Starting with Qt 5.7, an additional API for the server/peripheral part is provided as a technology preview.

We have developed a Qt application for iOS and Android to collect information from numerous detectors and sensors installed on agricultural machines and storage facilities via BLE. Internet data transmission was also possible, but not always feasible due to intermittent and slow Internet connections.

A special Qt class is necessary when developing an application that involves the use of several communication protocols. This class serves as a buffer for receiving data, while the internal implementation is created separately for each communication protocol. Creating a custom class is a complex and time-consuming application implementation option.

To fully implement the functionality of the cross-platform application, it was necessary to register additional services in the GATT protocol of BLE peripheral devices and assign a unique number to each of the objects for incoming data arrangement. The simple and intuitive interface of the application makes it possible to visualize data on temperature, humidity, and other quantitative indicators.

A cross-platform application for our BLE-related project.

On the client/central device side, the Qt BLE API is responsible for connecting to peripheral devices, discovering their services, as well as reading and writing characteristics and descriptors stored on the device. On the server/peripheral side, the API provides the ability to configure and advertise services, and receive notifications when a client writes a characteristic.

The toolkit provides a standard Qt BLE library, which contains the necessary tools for BLE interaction.

BLE peripherals, such as heart rate monitors and pressure or humidity sensors, have a standardized communication protocol provided by the built-in Qt BLE library. Working with user devices includes actions related to the communication protocol construction. In addition to specifying other points, the protocol describes how many bytes the header and the message body will have. The Qt BLE data comes into the QByteArray internal class, which manages buffer memory. The Qt tools allow us to work comfortably with this class without data conversion.

Communication protocols are created for specific devices. One of our projects involved building the BLE receiver that would serve as an intermediate link between a device, provided by the customer, and a smartphone with a client application. The protocol’s peculiarity was that more than a hundred parameters needed to be transmitted via BLE. Our Qt developers have built the cross-platform mobile application, the BLE receiver, and the protocol for communication between devices from scratch. The application acted as a client, initiating a connection and data exchange.

In another agriculture-related project, a small number of features will be broadcast by the peripheral, so the client application will receive data in advertising mode. The peripheral device serves as a BLE beacon in this case. There is no need to implement a protocol. Small pieces of data will be written by the peripheral one after another to the array and read by the application.BLE broadcast mode entails applying the Qt BLE library without creating a communication protocol.

BLE advertising mode in our agriculture-related project

The most time-consuming stages of Qt application development are protocol creation and internal logic implementation. The transport layer (i.e., BLE) does not affect the app's internal logic, adding the stages of searching for and determining the device and, possibly, the GUI part.

How to apply Qt BLE to create applications

Using the Qt Bluetooth Low Energy API implies a standard algorithm of actions.

Establishing a Connection

We use the QBluetoothDeviceDiscoveryAgent class to discover the peripheral device.

We need to select LE devices when filtering by device type in the receiving slot.

To get the QBluetoothAddress of the peripheral, we use the QLowEnergyController class. Now we set up regular slots and connect directly to the device.

The search session for a peripheral device does not last continuously but ends after a short period. The search can be restarted manually. The device search session usually lasts 20-30 seconds, and the object is not always found the first time.

Service Discovery

By performing service discovery, the GATT client learns about the server's attributes. Once the connection is established, the application uses the QLowEnergyController to initiate a service searching process.

Created after service discovery, the QLowEnergyService class provides access to information about Bluetooth Low Energy services. QLowEnergyService helps quickly discover and provide information about the service. It gives permission to read and write data and makes notifications of data changes. After completing this procedure, the client can read and write the attributes that are on the server. 

Interaction with the Peripheral Device

Depending on the specifics, the application may contain notifications about changes to some standardized characteristics. The QLowEnergyCharacteristic class gives information about the characteristics of the Bluetooth Low Energy service: name, UUID, value, properties, handle, and descriptors. To get such information, we should apply QLowEnergyService and QLowEnergyController to connect to the device. Furthermore, the characteristic value is processed according to Bluetooth Low Energy standards.

Advertising Services

When creating a GATT server application on a remote device, a list of services that will be offered and advertised to clients/central devices must be defined. The QLowEnergyAdvertisingData class passes a set of data that will be introduced to clients as either an advertising service package or a scan response package. After this step, peripheral devices are available for clients to connect to.

Creating a Service on the Peripheral Device

First, we need to define the service along with its characteristics and descriptors using the QLowEnergyServiceData, QLowEnergyCharacteristicData, and QLowEnergyDescriptorData classes. Essentially, these classes are containers for information that needs to be specified.

The QLowEnergyDescriptorData class is needed to get the GATT service data. A descriptor offered by the QLowEnergyDescriptorData should be added to the QLowEnergyCharacteristicData.

Both QLowEnergyServiceData and QLowEnergyAdvertisingData have somewhat similar information but serve different purposes. Advertising information displayed on devices is usually brief and limited in size. The QLowEnergyServiceData class gives the complete information available to the client after establishing a connection with service discovery.

The same algorithm for connecting BLE devices is used to update the characteristics and values ​​of descriptors on the remote device.

Challenges in Qt application development for Windows and Android

We should warn of the certain difficulties that may be ahead when creating a client BLE application for Windows using the Qt framework. The challenges that these tasks entail are associated with the huge diversity of devices from different manufacturers. Each device has unique drivers, which are not controlled by the OS manufacturer. This fact makes the process of describing the scope of tasks in Qt rather complicated. To develop a Bluetooth Low Energy application for Windows on Qt, you may need to purchase a licensed package of framework libraries. 

Developers face similar issues when building Android mobile BLE applications with Qt. Qt translates C++ code into Java and calls native methods for Android BLE application development. As mentioned earlier, the peculiarities of the OS and the fact that Android devices are manufactured by different companies sometimes create difficulties with communication between devices. Support for different versions of BLE protocols and OS versions is implemented inside the framework, but sometimes bugs happen. The developers of the framework do their best to fix such errors promptly and effectively.

Conclusion

Bluetooth Low Energy, as a short-range communication technology, has gained popularity and is widely used in portable smart devices. Bluetooth Smart can be used alone or in combination with other data transmission methods.

Bluetooth LE finds its use in healthcare, fitness, security, agriculture, and entertainment. The fact that all modern mobile devices have BLE modules opens up unlimited opportunities when creating software for BLE communication.

Applications can be created both using tools native to a specific OS and using cross-platform frameworks. Multi-platform toolkits allow you to create an application that can run on different platforms. Qt is a universal set of tools for creating cross-platform applications. It provides the Qt BLE library for fast implementation of the BLE-related parts of an application.

The process of using such a universal multi-platform toolkit as Qt can have minor irregularities and pitfalls, often depending more on the features of the operating system than on the framework itself.

Originally published here.