The Wheels on the Bikeare Bluetooth Smart, Part 2

October 12, 2015
Martin Woolley
Bluetooth Low Energy, Connected Device, Data Transfer

In part 1, I explored the Bluetooth^® Smart technology available to cyclists to help them improve their performance. In this article I will examine Bluetooth cycling technology from a developer’s perspective.

Adopted Profiles

The key adopted profiles related to cycling are the Heart Rate Profile, the Cycling Speed and Cadence Profile and the Cycling Power Profile.

The Heart Rate Profile uses notifications to transmit heart rate measurements to a connected GATT client. There’s more in these notifications than just heart rate data and we’ll look more closely at the profile shortly.

The Cycling Speed and Cadence Profile also uses notifications and each notification can contain either wheel revolution data, crank revolution data or both.

And you’ll never guess how the Cycling Power Profile works. Yes, it too uses those super-useful Attribute Protocol messages, “notifications,” to transmit data. The Cycling Power Profile has lots to offer as you’ll see.

Bluetooth Developer Studio

If you are eager to dive in and get hands on, download and install Bluetooth Developer Studio. This new developer tool from the Bluetooth SIG is a good place to start. Its repository of adopted profiles, services, characteristics and descriptors includes those I just mentioned and more. The tool is a great way to explore the profiles, and it allows you to generate code via plugins to get your implementation work off to a flying start.

Smartphone Applications You Can Download

There’s a good selection of mobile applications available for these profiles which you can download and use. Here are a few for Android:

– Polar Beat

– Wahoo Fitness

– Nordic Semiconductor nRF Toolbox for BLE

Develop Your Own Smartphone Application

If you’re a mobile developer, there’s always the option to develop your own Bluetooth Smart application and this is especially appealing when a device’s profile has been published, either by the Bluetooth SIG or by the equipment manufacturer. And don’t forget, it’s perfectly valid to create your own custom profile which combines adopted services and your own custom services in any combination you like.

What kind of code you write depends on the platform for which you’re developing and whether you’re developing the GATT client or GATT server. If you’re writing a GATT-client application to work with one or more of the types of sensor that might be found on a bike or cyclist, you’ll need to subscribe to notifications from the characteristics that contain the sensor values you want and then handle those notifications in your code as they arrive over Bluetooth Smart.

Let’s take a closer look at our three profiles and I’ll throw in some code fragments as we proceed.

The Heart Rate Profile (HRM)

This profile has one mandatory service, the Heart Rate Service and one optional service, the Device Information Service. The Heart Rate Service defines the following three characteristics:

Characteristic	Requirement	Comments
Heart Rate Measurement	Mandatory	Heart rate and other data communicated to a GATT client in notification messages.
Body Sensor Location	Optional	Read-only characteristic which indicates the intended location of the sensor such as chest, wrist, finger etc.
Heart Rate Control Point	Conditional	Only required if the sensor supports the energy expended feature. Allows accumulated energy expended value to be reset.

The Heart Rate Measurement characteristic has a value which breaks down into a number of distinct fields so the first thing an application receiving a notification for this characteristic needs to do is to separate the value data into its constituent parts. The first byte is the Flags field and bits 0 – 4 tell us more about the capabilities of the heart rate sensor and about the format of the data in the remainder of the characteristic value. For example, the heart rate value in beats per minute may either be an 8-bit field or a 16-bit field and the Flags field will tell us which we’re dealing with in a particular notification.

An 8-bit field, capable of holding values in the range 0-255 is fine for use with humans (though presumably a heart rate of zero would be slightly worrying!). One guide for calculating someone’s theoretical maximum heart rate is to subtract the person’s age from 220, so for a 40 year old that would give them a theoretical maximum heart rate of 180. On the other hand, if you really must attach a heart rate monitor to a hummingbird, you’ll find its heart rate may vary from 50 – 1260 beats per minute and so you’ll definitely need 16-bit values!

Figure 2 - Handling a heart rate notification in Android — Figure 2 – Handling a heart rate notification in Android

Heart Rate Profile References

– Profile

– Heart Rate Service

The Cycling Speed and Cadence Profile (CSC)

This profile also has one mandatory service, the Cycling Speed and Cadence Service and one optional service, the Device Information Service. The CSC Service defines the following four characteristics:

Characteristic	Requirement	Comments
CSC Measurement	Mandatory	Either wheel revolution data, crank revolution data or both. May be sent to a client application in notification messages.
CSC Feature	Mandatory	Read-only characteristic which indicates which of wheel revolution data, crank revolution data or both are supported and whether or not multiple sensor locations are supported.
Sensor Location	Conditional	Indicates the location of the sensor (e.g. front wheel, left crank) and is required if multiple sensor locations are supported.
SC Control Point	Conditional	Allows the initiation of various procedures such as the starting of sensor calibration.

The CSC Measurement characteristic is of primary interest to application developers and once again its value breaks down into a number of fields. The first byte contains a Flags field and the first two bits indicate whether the value contains wheel revolution data, crank revolution data or both. Wheel revolution data, if present, consists of a 32-bit cumulative count of revolutions of the wheel plus a 16-bit value which represents the time the last wheel event was measured in units of 1/1024 of a second. Crank data, if present consists of a 16-bit cumulative count of revolutions of the crank plus a similar, 16-bit last event time field. Using this data, the client can calculate the average speed of wheel rotation or pedaling (cadence) since the last event, even if the Bluetooth link was lost in between. If the client knows the circumference of the wheel, distance travelled since last event and average speed of travel can also be calculated.

Figure 3 - Handling CSC notifications in Android — Figure 3 – Handling CSC notifications in Android

CSC Profile References

Profile
Cycling Speed and Cadence Service

The Cycling Power Profile (CPP)This profile defines four roles and allows a cycling power sensor to be used in two quite different ways. A “Collector” may connect to a “CP Sensor” and discover and interact with its GATT services and characteristics in the usual ways. But a cycling power sensor may instead be configured to take on the role of “CP Broadcaster,” with one or more clients acting as “CP Observers” and receiving cycling power data within undirected, non-connectable GAP advertisements. In the latter case, Bluetooth Smart (Low Energy) must be used as the transport whereas the CP Sensor and Collector roles may also be used over Bluetooth BR/EDR. Note that it’s common for multiple cycling power sensors to be used at the same time and be installed in different locations such as on the left crank and right crank of the bike. The Cycling Power Service accommodates this by including a Sensor Location characteristic. The profile defines one mandatory service, the Cycling Power Service, and two optional services, the Device Information Service and the Battery Service. The Cycling Power Service defines 5 characteristics. The Cycling Power Measurement is the characteristic which most applications will make use of. Using GATT, notifications are used to transmit data from the CP Sensor to the connected Collector. Using GAP advertising packets, the characteristic is broadcast in the Service Data field if the Server Characteristic Configuration Descriptor attached to the characteristic has been set to 0x01.Cycling Power Profile References

Profile
Cycling Power Service

Testing Client Applications Testing Bluetooth^® client applications that work with sensor-equipped devices can be made easier by using a Bluetooth developer board to generate simulated sensor readings. It’s certainly more convenient than jumping on your bike to do some testing every time you change, build and install your smartphone application. Not as much fun perhaps, but it’s certainly more convenient. I have a collection of developer boards from various manufacturers including CSC (now Qualcomm), Nordic Semiconductor and Bluegiga (now Silicon Labs) and they all include implementations of the heart rate profile which can generate simulated heart rate data. The Nordic Semiconductor SDK includes the CSC profile too. Creating simulations of any of the profiles we’ve been looking at, using the heart rate profile as a template should be straightforward and will save you lots of time.

Figure 4 – Heart Rate Profile project for Nordic Semiconductor nRF51DK

Alternatively, there’s an application for iOS and Mac called LightBlue which lets you set up “virtual peripherals” on your Mac, iPhone or iPad and it supports lots of profiles including CSC, HRM and Cycling Power. Bluetooth Developer Studio — Bluetooth Developer Studio allows you to quickly jump right in and start using and designing services and characteristics for your own solutions. This tool is an invaluable resource for creating your own services as well as figuring out how adopted servers work. Nordic Semiconductor has an excellent application for Android which supports both the Heart Rate Profile and Cycling Speed and Cadence and various others. They’ve published the source code on Github too:The first two Bluetooth^® Smart applications I ever wrote were for the Heart Rate Profile and the Cycling Speed and Cadence Profile for BlackBerry 10. The code for both applications is available as open source.

Summary: That’s it! Cyclists are really well catered to with some great Bluetooth Smart devices to help them cycle further and faster, and with Bluetooth, developers can get creative and produce applications for cyclists that will have them wondering how they ever lived without them!

Characteristic	Requirement	Comments
Cycling Power Measurement	Mandatory	Contains the Instantaneous Power field and depending on the Flags field which occupies the first byte of the value, may contain a wide variety of other fields.
Cycling Power Feature	Mandatory	Bits indicate which of a series of 19 possible features the sensor supports. Examples include Pedal Power Balance, Accumulated Torque and Chain Weight Adjustment. See the specification for the full list.
Sensor Location	Mandatory	Indicates the location of the sensor. In contrast to this characteristic in the CSC Service, it is mandatory for the Cycling Power Service.
Cycling Power Vector	Optional	Contains raw force or torque data.
Cycling Power Control Point	Optional	Allows various operations to be initiated or configuration settings made on the sensor.