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.

Figure 1 - Bluetooth Developer Studio
Figure 1 – Bluetooth Developer Studio

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)

Heart Rate Profile








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


Heart Rate Service

The Cycling Speed and Cadence Profile (CSC)

The Cycling Speed and Cadence Profile

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

The Cycling Power Profile (CPP)The Cycling Power ProfileThis 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

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

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:nRF ToolboxThe 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.

Low Energy Audio – Basic One-Way Unicast Audio

This document gives an introduction to Bluetooth LE Audio by explaining the basics of…

Low Energy Audio – Using UCIs, URIs, and URI Schemes

This document describes how implementers can use the UCIs, URIs, and URI schemes in…

Using a Bluetooth LE Wireless Module to Accelerate Time-to-market

Wireless connectivity makes dumb products intelligent. Smart devices can transmit information about their surroundings…

Now Available: Auracast™ Developer Best Practice Guides公開中:Auracast™開発者向けベストプラクティスガイド

When Bluetooth® LE Audio was released, it introduced broadcast audio to Bluetooth technology. This…

Automated Emergency Light Testing Through Bluetooth Mesh

During a summer internship at Nordic, I took on a project that focused on…

Coded PHYs + Advertising Coding Selection = Superior Bluetooth® Range

Bluetooth® v5.0 introduced LE Coded PHYs to extend the original range of the 1M…

Channel Sounding: Technical Overview (Pt 1)

Channel Sounding is an innovative new feature coming to Bluetooth technology, enabling distance estimation…

Bluetooth Low Energy Fundamentals

The Bluetooth Low Energy (LE) Fundamentals Course is designed to give you the knowledge…

How to Build an Auracast Assistant

This document covers the basic design principles for building an Auracast™ assistant, explaining the…

The Latest in HADM with Bluetooth LE

HADM, or high accuracy distance measurement using Bluetooth does exactly what it says –…

The Bluetooth® Low Energy Primer

Are you new to Bluetooth Low Energy? Learn about its constituent parts, features, and how it works.

Bluetooth® Technology for Linux Developers

Learn how to use the interprocess communication system D-Bus and the BlueZ APIs to create Bluetooth applications for Linux computers.

Designing and Developing Bluetooth® Internet Gateways

Learn about Bluetooth® internet gateways, how to make them secure and scalable, and design and implement your own...

NOTICE: The Bluetooth SIG updated its Privacy Policy on 6 June 2024Learn more
 Get Help