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.

Cycling

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

Profile

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.

Robust Indoor Distance Estimation Algorithms for Bluetooth® Channel Sounding

Bluetooth Channel Sounding is a powerful feature setting a clear and solid foundation for…

What’s New with Bluetooth® Technology: Channel Sounding, Upcoming Features, and Key Technology Trends

With over 5 billion devices shipping each year, Bluetooth technology is the most widely…

Bluetooth 6: What's New In The Latest Bluetooth Release?

Bluetooth technology is constantly growing, not only enhancing existing applications but also enabling entirely…

Bluetooth PAwR in a Large-Scale Test Network

In the ever-evolving, dynamic landscape of Bluetooth-connected smart devices, efficient interconnection and reliable communication…

Bluetooth Channel Sounding: How It Works and What It MeansBluetoothチャネルサウンディング:その仕組みと意義

Bluetooth® Channel Sounding is a new secure, fine-ranging capability that promises to enhance the…

Receiver Blocking Resilience Test Suite

This Test Suite tests the receiver blocking resilience of a Bluetooth implementation. It is…

Now Available: New Version of the Bluetooth Core SpecificationBluetoothコア仕様の新バージョンがリリース

Thanks to the dedication and hard work of the Bluetooth community, Bluetooth® technology is…

Channel Sounding: Technical Overview (Pt 2)

In Part 1 we introduced the new Bluetooth distance measurement innovation known as Channel…

Unlocking Healthcare Potential: SPP and Bluetooth® LE for Medical Devices

The Serial Port Profile (SPP) has long been a well-known standard for wireless serial…

The Bluetooth Roadmap: Bluetooth Specifications in ProgressBluetoothのロードマップ:策定中のBluetooth仕様

Though not commonly known among many consumers, Bluetooth® technology is constantly and consistently advancing to…

Bluetooth® Channel Sounding: A Technical Overview

This paper provides a detailed technical overview of Bluetooth® Channel Sounding, a secure fine ranging…

The Bluetooth® Mesh Primer

An introduction and explanation of important Bluetooth® Mesh concepts.

Enabling the Digital Transformation of Industrial IoT with Bluetooth®

The Industrial IoT is a digital transformation process for enterprises offering them compelling abilities…

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...

The Bluetooth LE Security Study Guide

Learn about fundamental security concepts, the security features of Bluetooth Low Energy, and gain some hands-on experience using those features in device code.

 Get Help