Bluetooth Data Transfer Initial Progress

Bluetooth Data Transfer

The original Bluetooth LE service design proposed during Fall 2021 is shown in the Figure below.

We decided to modify this to account for the considerations below. The newly designed service will be referred to as GDS, or Gait Data Service.

The timestamp and each sensor reading are separate characteristics. This means that even if they are simultaneously made available to the BLE central device (the smartphone) via BLE notifications, the sender (the gait sensing device) cannot guarantee that the receiving application will process all the notifications simultaneously. This raises the possibility of sensor readings being associated with the wrong timestamp. The timestamp and all sensor readings associated therewith are instead compacted into a single integer representation so that the association is less likely to be lost. This value can then be notified over a single BLE characteristic (GDS Data Characteristic), simplifying the data processing required to obtain all data from the BLE transmission.

In the original design, the sensor device decides when to begin transfer of data (given that it holds the ability to notify a characteristic containing a sensor reading). However, once again there is no guarantee that the receiving device is ready to receive data. Even if the Bluetooth stack is functioning on the receiving smartphone, the smartphone application may not be ready to receive the data, so the sensor device choosing to notify a characteristic on the basis of an established BLE connection alone could lead to data loss. To remedy this, a writeable characteristic called the GDS Data Control Point characteristic is added that allows the smartphone application to signal to the sensor device to begin transmission. GDS Data Control Point also has a notify feature to notify the application of whether the command was successful. Additionally, a GDS Available Data Bytes characteristic is added that can be read by the smartphone application to determine whether it is necessary to initiate a data transfer based on the amount of available new data buffered on the sensor device. The design pattern used for GDS Data Control Point mirrors that of characteristics with similar functionality defined in official BLE services, for example the Media Control Point characteristic in BLE Media Control Service.

The final BLE service design is shown below.

Firmware

The decision was made to use the Arduino language wrapper made by Adafruit for the Nordic nRF5 SDK. This removes some of the lower level customizability of the SDK, as only certain functions are exposed in the wrapper. However, using the Arduino development environment significantly simplifies the development process, as most configuration steps, managing complex C-structs using for setting up modules, etc. are abstracted away. An initial assessment by the team determined that the customizability that has been lost will not significantly impact the implementation of our required functions.

To speed up development, the custom_hrm for BLE peripheral example project from Adafruit was used as the starting point. The example code provides a custom implementation of the BLE Heart Rate Service. It therefore had most of the code pieces necessary to start building GDS, including advertising, connecting, and example usage of APIs used for creating BLE services and characteristics.

Current progress on the firmware front includes a working implementation of GDS, the ability to advertise and connect over BLE, and the ability to pair with the smartphone device.

‍

Smartphone App

The BluetoothLeGatt example project was used as the starting point for the app, as it includes example usage of BLE-related APIs. Similar to the custom_hrm example used for firmware, the BluetoothLeGatt project implements the BLE Heart Rate Service, and provides code for scanning and connecting to a BLE peripheral. The plan is to build all of the underlying functionality of the app starting from this example, and eventually modify the existing UI as well to suit the project.

Current progress includes a working implementation of GDS, the ability to connect to and pair with a sensor device, and a basic demonstration of the smartphone app writing a command to GDS Data Control Point to start data transfer, and receiving dummy data over notifications.

The UI for the app is shown below, although this is currently just the UI from the original BluetoothLeGatt example from which this project is built.