Problem solve Get help with specific problems with your technologies, process and projects.

Optimizing BLE for high-volume data

Bluetooth has been around for decades. And while its everyday applications in cellphones, media players and other communication devices might come to mind at first, there are some unique and complex applications of the technology. Bluetooth, and perhaps its lesser known sibling, Bluetooth Low Energy (BLE), have seen some success when applied to transportation, healthcare and security systems. At Exadel, we’ve been working with Bluetooth on mobile devices for many years, and have completed many successful projects, both with standard Bluetooth and with BLE. We’re currently working on developing an app for a major Fortune 500 high-tech company that pairs a mobile app with wearable hardware for biometrics and health awareness, and wanted to share some best practices and challenges of developing a BLE app based on this experience.

One of the significant challenges of this project has been to use BLE to transfer data that is:

  1. Constant
  2. Near-real time
  3. High volume

We are also working with hardware and firmware that is new, which means we’re co-developing with other teams and defining the protocol for data on top of Bluetooth.

Because of the data requirements listed above, optimization counts. Waste and overhead of data packets must be eliminated or reduced to the smallest amount possible, while still operating reliably. While all overhead is waste in some sense, having some overhead allows for maintainability, adaptability and testability.

So, the key has been to balance the client’s need for adaptability (i.e., the development team needs to be able to make changes and have the expense of that be reasonable in both time and money) and the client’s needs for data throughput to handle high volumes.

Establishing the initial protocol was relatively straightforward; it needed to be flexible enough to handle the current batch of sensor data, handle changes on this project and handle future needs — possibly sensor types not on the horizon today.

As part of our collaboration with the client, we decided to move from BLE 4.2 to BLE 5 in order to take advantage of some new features to BLE 5. The main driving factors were to take advantage of the 2 Mbps speed advantage and extended data length capability.

Once the basics of the protocol were established, we needed to make further optimizations to handle all the requirements.

Working side-by-side with client firmware developers, the fine-tuning of the BLE interaction could begin. Together, the two teams worked on optimizing the interaction to handle the data. Optimizations to the interaction included fine-tuning:

  • Connection intervals — the length of time between data interactions. This needs to be large enough to transfer all the data and not overlap with the next connection, but not so frequent that the radio is woken up when not necessary (causing undue battery drain).
  • Maximum transmission unit (MTU) size. The team needed to collaborate to find an MTU that supported passing all the data that we needed while maximizing the ratio of overhead to payload. If the MTU is too small, you consume too much bandwidth with overhead and slow your transmission of real data. If your MTU is too large, you will have to consume more bandwidth on resends, which can also cause transmission slowdowns.

In order to ensure that we have as high a volume of overhead/payload as possible, the team has been using BLE 5’s 2 Mbps connection for maximum throughput. The team has worked closely together, iterating through changes to all these settings, as well as debugging the normal challenges that come along with Bluetooth development, such as adding new sensor types, revising features, creative updates, debugging, evaluating data and hardware updates.

It will be exciting to see this app in production and see how Bluetooth and BLE technologies can continue to expand their significance in a range of industries.

This article was co-written by Travis Bolinger, a senior software engineer at Exadel, based in Boulder, Colo. In his role, Bolinger helps Fortune 500 clients solve some of their toughest digital transformation initiatives with mobile, Bluetooth and other leading-edge technologies. Bolinger has a master’s degree in computer science from the University of Wyoming, bringing a strong technical focus in mobile and research and development.

All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.

Data Center
Data Management