How to Craft a Raspberry Pi 5 BLE Central Device

The new Raspberry Pi 5 has proven itself to be a force to be reckoned with in the world of embedded single-board computers. The Raspberry Pi 5’s Linux OS is the real deal and contains an instance of the BlueZ BLE stack just like it’s desktop cousins. The existence of an official Linux BLE stack on the Raspberry Pi 5 allows us to configure the Raspberry Pi 5 as a BLE peripheral device or a BLE central device. When a Raspberry Pi 5 is programmed to be a BLE central device, the Raspberry Pi 5 can send commands to and exchange data with a BLE peripheral device.

A BLE-enabled Raspberry Pi 5 can do more than just shuffle data from one point to another. As an indoor device, a BLE-equipped Raspberry Pi 5 acting as a positioning device is more accurate than an indoor GPS device. In addition, a Raspberry Pi 5 running BLE can act as a beacon and communicate with multiple BLE devices within its range. BLE provides the ability for a Raspberry Pi 5 and like devices to be used in smart home and health/fitness applications among others.

Using guidance contained within the Bluetooth for Linux Developer’s Study Guide, I have assembled a customized Python BLE central device script that you can use as a basis to create your own version of a Raspberry Pi 5 BLE central device. My Raspberry Pi 5 BLE central script was written within an Eclipse IDE embellished with PyDev and is loaded with debug print statements that allow you to monitor BLE command and data exchanges in real time via the Eclipse Console. 

Related:How to Control the Raspberry Pi 5's GPIO Using an Android Phone

During the BLE Central script coding process, I found D-Spy, a tool to explore D-Bus connections, to be an extremely useful debugging and verification tool. I have also written a BLE peripheral device application targeting the Nordic Semiconductor nRF52840. I have packaged my custom Raspberry Pi 5 BLE Central Python script and the nRF52840 application into a single zip file that can be downloaded using this link. You will need to get a copy of the BLE and nRF code to reference as we continue our BLE discussion.

What’s in the BLE Central Python Code?

The BLE Central Python code speaks for itself. However, to understand what the BLE Central Python statements are doing we must examine some fundamental BlueZ and D-Bus concepts.

D-Bus is simply a conduit used to deliver messages between clients (applications) attached to a common bus. Applications attached to the D-Bus mechanism contain objects. Objects expose interfaces, which are made up of methods. Methods are functions. Applications can call methods owned by other applications on the bus by using special messages. For instance, a BLE positioning application could call a function to extract position information from an application running on another BLE device.

Related:Developing Raspberry Pi 5 Apps Using Eclipse

Each object that is registered with the D-Bus daemon has a unique path identifier. The format of these paths is clearly shown in D-Spy captures. For instance, a typical BLE Peripheral device may have a path identifier of /org/bluez/hci0/dev_DE_88_83_B1_AB_15. The /org/bluez/hic0 portion of the BLE Peripheral path identifier is the path identifier for the Bluetooth adapter object. The /dev_DE_88_83_B1_AB_15 portion just happens to be the device address of our custom BLE Peripheral.

Object interfaces are capable of transmitting signals. A signal is akin to a message and can be sent at any time. Applications participating on the bus have the option of subscribing to particular signals of interest. However, some signals are broadcasts and are delivered to all of the registered applications. The BLE Central Python script discover_devices function includes registration of signal handlers that process InterfacesAdded, InterfacesRemoved, and PropertiesChanged signals. Object interfaces also expose properties whose values can be obtained and changed with get and set operations, respectively. Additional D-Bus operational information can also be obtained by invoking the dbus-monitor command line tool.

Related:Using Raspberry Pi Pico W For a Bluetooth Low-Energy Application

BLE could help support health/fitness devices. VIOLETASTOIMENOVA/ISTOCK/GETTY IMAGES PLUS VIA GETTY IMAGES

Functions of the BLE Central Device Script

Now that you understand that D-Bus operations play a significant role in the operation of BlueZ, let’s talk about the functions that make up the BLE central Python script. BLE Peripheral devices that want to contact BLE central devices that are within radio range “advertise” their resources. BLE central devices that are in radio range receive the BLE Peripheral advertisements. This is known as device discovery and is the responsibility of the discover_devices function. The fruit produced by the discover_devices function is a list of discovered BLE Peripheral devices. The discovered device list is then passed to the get_nrf52840_addr function, which will search for the BLE peripheral device name NRF52840_BRD. If the desired device name is found in the list, the device address associated with the device name can be determined. In our case, that device address, which is associated with the device name of NRF52840_BRD, is DE:88:83:B1:AB:15.

Now that we have the desired BLE peripheral’s device address, we can initiate a connect process by calling the connect function. The BLE central script was called with an argument matching the BLE peripheral device name (NRF52840_BRD) we wish to connect to. Before we call the connect function, we must establish a path to the adapter, which in this case is hci0. The adapter hci0 is usually always present. The hci in hci0 stands for host controller interface. The host controller interface is the communication path between the BlueZ Host software layers and the controller, which is normally embedded in some kind of hardware such as an integrated circuit or a USB Bluetooth dongle. In the BlueZ universe, the Bluetooth controller is referred to as the adapter. Once the adapter path is known, the peripheral device path can be plotted by combining the adapter path with the peripheral device address. Take a look at the bluetooth_constants.py file to get a better understanding of the BlueZ paths and addressing used in the BLE Central Python script. The goal is to define what is termed a device_interface, which we will pass to the connect function. 

Upon a successful connection, the BlueZ stack will automatically discover services that are defined within the connected BLE Peripheral device. In our case, the NRF52840_BRD supports a sensor service and an LED service and their associated characteristics. The service_discovery_completed function builds paths for the services and characteristics that were exposed in the service discovery process.

At this point, we can communicate intelligently with the BLE peripheral. A look at the contents of the service_discovery_completed function reveals that we can call the read_sensor function to get an analog-to-digital value from the nRF52840-based BLE Peripheral. We can also call the led_on and led_off functions to toggle the user LED that resides on the BLE Peripheral. You now have a fully functional template in which you can add your own services and characteristics to create a BLE central on your Raspberry Pi 5.