Heart Rate Monitor example for the BLE API using nRF51822 native mode drivers

Dependencies:   BLE_API mbed nRF51822 X_NUCLEO_IDB0XA1

BLE_HeartRate implements the Heart Rate Service which enables a collector device (such as a smart phone) to connect and interact with a Heart Rate Sensor.

For the sake of simplicity and portability, the sensor in this case has been abstracted using a counter which counts up to a threshold and then recycles. The code can be easily extended to use the real heart rate sensor.

Apps on the collector device may expect auxiliary services to supplement the HRService. We've therefore also included the Device Information Service and the Battery Service.

BLE_API offers the building blocks to compose the needed GATT services out of Characteristics and Attributes, but that can be cumbersome. As a shortcut, it is possible to simply instantiate reference services offered by BLE_API, and we'll be taking that easier route. The user is encouraged to peek under the hood of these 'services' and be aware of the underlying mechanics. It is not necessary to use these ready-made services.

Like most non-trivial services, the heart-rate service is connection oriented. In the default state, the application configures the Bluetooth stack to advertise its presence and indicate connectability. A Central/Master device is expected to scan for advertisements from peripherals in the vicinity and then initiate a connection. Once connected, the peripheral stops advertising, and communicates periodically as a server using the Attribute Protocol.

Walkthrough of the code

Let's see how this magic is achieved. We'll be pulling out excerpts from main.cpp where most of the code resides.

You'll find that the entire system is event driven, with a single main thread idling most of its time in a while loop and being interrupted by events. An important startup activity for the application is to setup the event callback handlers appropriately.

The first thing to notice is the BLEDevice class, which encapsulates the Bluetooth low energy protocol stack.

BLEDevice

#include "BLEDevice.h"

BLEDevice  ble;

void disconnectionCallback(Gap::Handle_t handle, Gap::DisconnectionReason_t reason)
{
    ble.startAdvertising(); // restart advertising
}

int main(void)
{
    ble.init();
    ble.onDisconnection(disconnectionCallback);
 ...
    ble.startAdvertising();

    while (true) {
...
            ble.waitForEvent();
...
    }
}

There is an init() method that must be called before using the BLEDevice object. The startAdvertising() method is called to advertise the device's presence allowing other devices to connect to it.

onDisconnect() is a typical example of setting up of an event handler. With onDisconnect(), a callback function is setup to restart advertising when the connection is terminated.

The waitForEvent() method should be called whenever the main thread is 'done' doing any work; it hands the control over to the protocol and lets you save power. So when will waitForEvent() return? Basically whenever you have an application interrupt, and most typically that results in some event callback being invoked. In this example there is a Ticker object that is setup to call a function every second. Whenever the ticker 'ticks' the periodicCallback() is invoked, and then waitForEvent() returns, resuming the execution in main.

Interrupt to trigger periodic actions

void periodicCallback(void)
{
    led1 = !led1; /* Do blinky on LED1 while we're waiting for BLE events */

    /* Note that the periodicCallback() executes in interrupt context, so it is safer to do
     * heavy-weight sensor polling from the main thread. */
    triggerSensorPolling = true;
}

int main(void)
{
    led1 = 1;
    Ticker ticker;
    ticker.attach(periodicCallback, 1);
...

It is worth emphasizing that the periodicCallback() (or any other event handler) is called in interrupt context; and should not engage in any heavy-weight tasks to avoid the system from becoming unresponsive. A typical workaround is to mark some activity as pending to be handled in the main thread; as done through 'triggerSensorPolling'.

BLEDevice offers APIs to setup GAP (for connectability) and GATT (for services). As has been mentioned already, GATT services may be composed by defining Characteristics and Attributes separately (which is cumbersome), or in some cases by simply instantiating reference services offered by BLE_API. The following illustrates how straightforward this can be. You are encouraged to peek under the hood of these implementations and study the mechanics.

Service setup

    /* Setup primary service. */
    uint8_t hrmCounter = 100;
    HeartRateService hrService(ble, hrmCounter, HeartRateService::LOCATION_FINGER);

    /* Setup auxiliary services. */
    BatteryService           battery(ble);
    DeviceInformationService deviceInfo(ble, "ARM", "Model1", "SN1", "hw-rev1", "fw-rev1", "soft-rev1");

Setting up GAP mostly has to do with configuring connectability and the payload contained in the advertisement packets.

Advertiser setup

    ble.accumulateAdvertisingPayload(GapAdvertisingData::BREDR_NOT_SUPPORTED | GapAdvertisingData::LE_GENERAL_DISCOVERABLE);
    ble.accumulateAdvertisingPayload(GapAdvertisingData::COMPLETE_LIST_16BIT_SERVICE_IDS, (uint8_t *)uuid16_list, sizeof(uuid16_list));
    ble.accumulateAdvertisingPayload(GapAdvertisingData::GENERIC_HEART_RATE_SENSOR);
    ble.accumulateAdvertisingPayload(GapAdvertisingData::COMPLETE_LOCAL_NAME, (uint8_t *)DEVICE_NAME, sizeof(DEVICE_NAME));
    ble.setAdvertisingType(GapAdvertisingParams::ADV_CONNECTABLE_UNDIRECTED);
    ble.setAdvertisingInterval(1600); /* 1000ms; in multiples of 0.625ms. */

The first line (above) is mandatory for Bluetooth Smart, and says that this device only supports Bluetooth low energy. The 'general discoverable' is the typical value to set when you want your device to be seen by other devices on order to connect. Next comes the ID for the heart rate sensor service and the name of the device.

After the payload is set the code sets the advertising type and the advertising interval. In Bluetooth Smart timing values are typically multiples of 625 us.

If you are new to Bluetooth Smart there are probably a lot of terms that are new to you. There is a lot of information about this on the Internet.

Revisions of mbed.bld

Revision Date Message Actions
:8b7c8c240540 13 months agoUpdate libraries. File  Diff  Annotate
:6f16dab7a60c 14 months agoUpdate mbed lib to the latest revision.; This fix the build of this example which was somehow broken even if the example was not touched. File  Diff  Annotate
:a2ab41a7f067 18 months agoUpdate libraries to the latest revision. File  Diff  Annotate
:99c283dfe28d 24 months agoupdate to v2.0.0 of BLE_API. Add bleInitComplete() to main.c File  Diff  Annotate
:469dbde1a238 2015-09-29updating call to onDisconnection() due to updates to underlying libraries. File  Diff  Annotate
:0a19690e8d23 2015-08-11updating the underlying libraries. File  Diff  Annotate
:cb76569f74f6 2015-06-20make use of the gap() accessor for ble File  Diff  Annotate
:749d180e6a3d 2015-06-08updating to the latest of the mbed sdk File  Diff  Annotate
:371d78b94ca8 2015-05-13updating to S130 softdevice and the latest of BLE_API and nRF51822. File  Diff  Annotate
:b32d42836762 2015-04-30updating underlying libraries for v8 of the Nordic SDK. File  Diff  Annotate
:d80d8dbaf86b 2015-04-15updating to the latest from mbed SDK. includes update to Nordic SDKv7.1 File  Diff  Annotate
:83623419d5e4 2015-03-24updating underlying libraries File  Diff  Annotate
:3a7d497a3e03 2015-02-09removed unncessary Battery Service from HearRate demo code File  Diff  Annotate
:54a3de277e6b 2014-12-09updating underlying libraries. File  Diff  Annotate
:8bca6365f8b0 2014-11-05updating the underlying libraries. File  Diff  Annotate
:06ebef2e0e44 2014-09-22updating to 0.2.0 of the BLE_API File  Diff  Annotate
:6390604f904c 2014-08-22Extract HeartRateService as a template to simplify the main application. File  Diff  Annotate
:7761a83ba06d 2014-07-25updating the underlying libraries. File  Diff  Annotate
:380687727e63 2014-07-04updating underlying libraries. File  Diff  Annotate
:4dab884e2235 2014-06-13updating underlying libraries. File  Diff  Annotate
:87a7fc231fae 2014-03-31First commit of HRM example for the BLE API (using nRF51822 native mode drivers) File  Diff  Annotate