CPP v1.1

Cycling Power Profile
Bluetooth® Profile Specification
Date 2016-May-03
Revision CPP_v1.1
Group Prepared By Sports and Fitness Working Group
Feedback Email [email protected]
Abstract:
This profile enables a Collector device to connect and interact with a Cycling Power Sensor for use in sports and
fitness applications.
Bluetooth SIG Proprietary

Bluetooth Profile Specification
Revision History
Revision Number Date Comments

v1.0 2013-04-30 Adopted by the Bluetooth SIG Board of Directors
v1.1 2016-05-03 Adopted by the Bluetooth SIG BoD
Contributors
Name Company
Robert Hughes Intel Corporation
Niclas Granqvist Polar
Jari Miettinen Polar
Guillaume Schatz Polar
Laurence Richardson CSR
Ed Watson Saris
Donny Warbritton Stages Cycling
CPP_v1.1
Bluetooth SIG Proprietary Page 2 of 47

DISCLAIMER AND COPYRIGHT NOTICE

This disclaimer applies to all draft specifications and final specifications adopted by the Bluetooth SIG Board of Directors (both of
which are hereinafter referred to herein as a Bluetooth “Specification”). Your use of this Specification in any way is subject to your
compliance with all conditions of such use, and your acceptance of all disclaimers and limitations as to such use, contained in this
Specification. Any user of this Specification is advised to seek appropriate legal, engineering or other professional advice regarding
the use, interpretation or effect of this Specification on any matters discussed in this Specification.
Use of Bluetooth Specifications and any related intellectual property is governed by the Promoters Membership Agreement among
the Promoter Members and Bluetooth SIG (the “Promoters Agreement”), certain membership agreements between Bluetooth SIG and
its Adopter and Associate Members, including, but not limited to, the Membership Application, the Bluetooth Patent/Copyright License
Agreement and the Bluetooth Trademark License Agreement (collectively, the “Membership Agreements”) and the Bluetooth
Specification Early Adopters Agreements (1.2 Early Adopters Agreements) among Early Adopter members of the unincorporated
Bluetooth SIG and the Promoter Members (the “Early Adopters Agreement”). Certain rights and obligations of the Promoter Members
under the Early Adopters Agreements have been assigned to Bluetooth SIG by the Promoter Members.
Use of the Specification by anyone who is not a member of Bluetooth SIG or a party to an Early Adopters Agreement (each such
person or party, a “Member”) is prohibited. The use of any portion of a Bluetooth Specification may involve the use of intellectual
property rights ("IPR"), including pending or issued patents, or copyrights or other rights. Bluetooth SIG has made no search or
investigation for such rights and disclaims any undertaking or duty to do so. The legal rights and obligations of each Member are
governed by the applicable Membership Agreements, Early Adopters Agreement or Promoters Agreement. No license, express or
implied, by estoppel or otherwise, to any intellectual property rights are granted herein.
Any use of the Specification not in compliance with the terms of the applicable Membership Agreements, Early Adopters Agreement
or Promoters Agreement is prohibited and any such prohibited use may result in (i) termination of the applicable Membership
Agreements or Early Adopters Agreement and (ii) liability claims by Bluetooth SIG or any of its Members for patent, copyright and/or
trademark infringement claims permitted by the applicable agreement or by applicable law.
THE SPECIFICATION IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF
CPP_v1.1
MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, SATISFACTORY QUALITY, OR

REASONABLE SKILL OR CARE, OR ANY WARRANTY ARISING OUT OF ANY COURSE OF DEALING, USAGE, TRADE
PRACTICE, PROPOSAL, SPECIFICATION OR SAMPLE.
Each Member hereby acknowledges that products equipped with the Bluetooth wireless technology ("Bluetooth Products") may be
subject to various regulatory controls under the laws and regulations applicable to products using wireless non licensed spectrum of
various governments worldwide. Such laws and regulatory controls may govern, among other things, the combination, operation, use,
implementation and distribution of Bluetooth Products. Examples of such laws and regulatory controls include, but are not limited to,
airline regulatory controls, telecommunications regulations, technology transfer controls and health and safety regulations. Each
Member is solely responsible for the compliance by their Bluetooth Products with any such laws and regulations and for obtaining any
and all required authorizations, permits, or licenses for their Bluetooth Products related to such regulations within the applicable
jurisdictions. Each Member acknowledges that nothing in the Specification provides any information or assistance in connection with
securing such compliance, authorizations or licenses. NOTHING IN THE SPECIFICATION CREATES ANY WARRANTIES, EITHER
EXPRESS OR IMPLIED, REGARDING SUCH LAWS OR REGULATIONS.
ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY INTELLECTUAL PROPERTY RIGHTS OR FOR
NONCOMPLIANCE WITH LAWS, RELATING TO USE OF THE SPECIFICATION IS EXPRESSLY DISCLAIMED. To the extent not
prohibited by law, in no event will Bluetooth SIG or its Members or their affiliates be liable for any damages, including without limitation,
lost revenue, profits, data or programs, or business interruption, or for special, indirect, consequential, incidental or punitive damages,
however caused and regardless of the theory of liability, arising out of or related to any furnishing, practicing, modifying, use or the
performance or implementation of the contents of this Specification, even if Bluetooth SIG or its Members or their affiliates have been
advised of the possibility of such damages. BY USE OF THE SPECIFICATION, EACH MEMBER EXPRESSLY WAIVES ANY CLAIM
AGAINST BLUETOOTH SIG AND ITS MEMBERS OR THEIR AFFILATES RELATED TO USE OF THE SPECIFICATION.
If this Specification is an intermediate draft, it is for comment only. No products should be designed based on it except solely to verify
the prototyping specification at SIG sponsored IOP events and it does not represent any commitment to release or implement any
portion of the intermediate draft, which may be withdrawn, modified, or replaced at any time in the adopted Specification.
Bluetooth SIG reserves the right to adopt any changes or alterations to the Specification it deems necessary or appropriate.
Copyright © 2013–2016. The Bluetooth word mark and logos are owned by Bluetooth SIG, Inc. All copyrights in the Bluetooth
Specifications themselves are owned by Ericsson AB, Lenovo (Singapore) Pte. Ltd., Intel Corporation, Microsoft
Corporation, Motorola Mobility, LLC, Nokia Corporation and Toshiba Corporation. Other third-party brands and names are
the property of their respective owners.

Document Terminology
The Bluetooth SIG has adopted portions of the IEEE Standards Style Manual, which dictates
use of the words “shall”, “should”, “may”, and “can” in the development of documentation, as
follows:
The word shall is used to indicate mandatory requirements strictly to be followed in order to
conform to the standard and from which no deviation is permitted (shall equals is required to).
The use of the word must is deprecated and shall not be used when stating mandatory
requirements; must is used only to describe unavoidable situations.
The use of the word will is deprecated and shall not be used when stating mandatory
requirements; will is only used in statements of fact.
The word should is used to indicate that among several possibilities one is recommended as
particularly suitable, without mentioning or excluding others; or that a certain course of action is
preferred but not necessarily required; or that (in the negative form) a certain course of action is
deprecated but not prohibited (should equals is recommended that).
CPP_v1.1
The word may is used to indicate a course of action permissible within the limits of the standard
(may equals is permitted).
The word can is used for statements of possibility and capability, whether material, physical, or
causal (can equals is able to).
The term Reserved for Future Use (RFU) is used to indicate Bluetooth SIG assigned values that
are reserved by the Bluetooth SIG and are not otherwise available for use by implementations.

Contents
1 Introduction .......................................................................................................................................... 7
1.1 Profile Dependencies...................................................................................................................... 7
1.2 Conformance .................................................................................................................................. 7
1.3 Bluetooth Specification Release Compatibility ............................................................................... 7
2 Configuration ....................................................................................................................................... 8
2.1 Roles ............................................................................................................................................... 8
2.2 Role/Service Relationships ............................................................................................................. 8
2.3 Concurrency Limitations and Restrictions ...................................................................................... 9
2.4 Topology Limitations and Restrictions ............................................................................................ 9
2.4.1 Topology Restrictions for Low Energy ....................................................................................... 9
2.4.2 Topology Limitations and Restrictions for BR/EDR ................................................................... 9
2.5 Transport Dependencies ................................................................................................................ 9
3 CP Sensor Role Requirements ......................................................................................................... 10
3.1 Incremental Cycling Power Service Requirements ...................................................................... 10
3.1.1 Additional Requirements for Low Energy Transport ............................................................... 10
3.2 Incremental Device Information Service Requirements ............................................................... 11
CPP_v1.1
4 Collector Role Requirements ........................................................................................................... 12

4.1 GATT Sub-Procedure Requirements ........................................................................................... 13
4.2 Service Discovery ......................................................................................................................... 13
4.3 Characteristic Discovery ............................................................................................................... 14
4.3.1 Cycling Power Service Characteristic Discovery..................................................................... 14
4.3.2 Device Information Service Characteristic Discovery.............................................................. 14
4.3.3 Battery Service Characteristic Discovery ................................................................................ 14
4.4 Cycling Power Feature ................................................................................................................. 15
4.5 Cycling Power Measurement ........................................................................................................ 17
4.5.1 Cycling Power Measurement Broadcast Feature Configuration ............................................. 19
4.6 Sensor Location ............................................................................................................................ 19
4.7 Cycling Power Control Point ......................................................................................................... 20
4.7.1 Cycling Power Control Point Procedure Requirements .......................................................... 20
4.7.2 Cycling Power Control Point Behavioral Description............................................................... 21
4.7.3 General Error Handling ............................................................................................................ 28
4.7.4 Procedure Timeout .................................................................................................................. 29
4.8 Cycling Power Vector ................................................................................................................... 29
4.9 Device Information Service Characteristics .................................................................................. 30
4.10 Battery Service Characteristics .................................................................................................... 31
5 CP Broadcaster Role Requirements ................................................................................................ 32
6 CP Observer Role Requirements ..................................................................................................... 33

6.1 Broadcasting Cycling Power Measurement Characteristic .......................................................... 33

7 Connection Establishment Procedures........................................................................................... 34
7.1 CP Sensor Connection Establishment for Low Energy Transport ............................................... 34
7.1.1 Connection Procedure for Unbonded Devices ........................................................................ 34
7.1.2 Connection Procedure for Bonded Devices ............................................................................ 35
7.1.3 Link Loss Reconnection Procedure ......................................................................................... 35
7.2 Collector Connection Establishment for Low Energy Transport ................................................... 36
7.3 Connection Establishment for BR/EDR ........................................................................................ 37
7.3.1 Connection Procedure ............................................................................................................. 37
7.4 Multiple Bike Considerations ........................................................................................................ 39
8 Security Considerations ................................................................................................................... 40
8.1 CP Sensor Security Considerations for Low Energy .................................................................... 40
8.2 Collector Security Considerations for Low Energy ....................................................................... 40
8.3 Security Considerations for BR/EDR ............................................................................................ 40
9 Generic Access Profile for BR/EDR ................................................................................................. 41
CPP_v1.1
9.1 Modes ........................................................................................................................................... 41

9.2 Idle Mode Procedures................................................................................................................... 41
10 Acronyms and Abbreviations ....................................................................................................... 42
11 References ...................................................................................................................................... 43
12 Appendix A – Cycling Power Vector Handling ............................................................................ 44
12.1 Magnitude vs. Crank Angle .......................................................................................................... 44
12.2 Magnitude vs. Time ...................................................................................................................... 46

1 Introduction
The Cycling Power Profile is used to enable a data collection device to obtain data from a
Cycling Power Sensor (CP Sensor) that exposes the Cycling Power Service [1].
1.1 Profile Dependencies

This profile requires the Generic Attribute Profile (GATT).
1.2 Conformance
If conformance to this profile is claimed, all capabilities indicated as mandatory for this profile
shall be supported in the specified manner (process-mandatory). This also applies for all
optional and conditional capabilities for which support is indicated. All mandatory capabilities,
and optional and conditional capabilities for which support is indicated, are subject to verification
as part of the Bluetooth qualification program.
1.3 Bluetooth Specification Release Compatibility

This specification is compatible with any of the following:
• Bluetooth Core Specification 4.0 with CSA2, CSA3, and CSA4 [2]
CPP_v1.1
• A Bluetooth Core Specification later than 4.0

2 Configuration
2.1 Roles
The profile defines four roles: CP Sensor, Collector, CP Broadcaster (LE Only) and CP
Observer (LE Only). The CP Sensor is the device that reports cycling data related to power,
force, speed and cadence to a Collector. The Collector is the device that receives the data from
a CP Sensor while connected to a CP Sensor. The CP Broadcaster is the device that reports
cycling data related to power, force, speed and cadence to a CP Observer using undirected
non-connectable advertisements (broadcast) and the CP Observer is the device that receives
the broadcasts from a CP Broadcaster.
• The CP Sensor shall be a GATT Server.
• If a CP Sensor uses LE transport, it may also implement the CP Broadcaster role.
• The Collector shall be a GATT Client.
• The CP Observer does not require any particular GATT Role; however it shall use the GAP
Observer role to be able to receive undirected non-connectable advertisements.
CPP_v1.1
2.2 Role/Service Relationships

The following diagram shows the relationships between service and profile roles.
Collector CP Sensor CP Broadcaster CP Observer

(LE Only) (LE Only)
Cycling Power Service
Device Information
Service
Battery Service
Notes: Profile roles (Collector, CP Sensor, CP Broadcaster and CP Observer) are represented by blue
boxes and services (Cycling Power Service, Device Information Service and Battery Service) are
represented by gray boxes.
Dashed box items are optional.
A CP Sensor instantiates the Cycling Power Service [1] and optionally the Device Information
Service [4], as well as the Battery Service [5].

2.3 Concurrency Limitations and Restrictions

There are no concurrency limitations or restrictions for the Collector and the CP Observer roles
imposed by this profile. However, the CP Broadcaster role is only permitted for LE CP Sensors.
Additionally, a LE CP Sensor which implements the CP Broadcaster role is permitted to send
broadcasts only when connected to a Collector.
2.4 Topology Limitations and Restrictions

2.4.1 Topology Restrictions for Low Energy
This section describes topology limitations and restrictions when the profile is used over Low
Energy transport.
The CP Sensor shall use the GAP Peripheral role (see Section 7). The CP Sensor may also
implement the CP Broadcaster role (see Section 5).
The Collector shall use the GAP Central role (see Section 7).
The CP Observer shall support the GAP Observer role and be able to receive undirected
non-connectable advertisements from a CP Broadcaster (see Section 6).
CPP_v1.1
2.4.2 Topology Limitations and Restrictions for BR/EDR

There are no topology limitations and restrictions when the profile is used over the BR/EDR
transport.
2.5 Transport Dependencies

The Cycling Power Measurement Broadcast feature is not supported when the BR/EDR
Transport is used. Hence the CP Observer and CP Broadcaster roles are not supported over
the BR/EDR Transport. Otherwise, there are no transport restrictions imposed by this profile
specification.
Where the term BR/EDR is used in this document, it also includes the optional use of AMP.

3 CP Sensor Role Requirements

The CP Sensor shall instantiate one and only one Cycling Power Service [1]. See specific
recommendations in Section 3.1.
The Cycling Power Service shall be instantiated as a «Primary Service».
The CP Sensor should instantiate the Device Information Service [4]. See specific
recommendations in Section 3.2.
The CP Sensor should instantiate the Battery Service [5].
Service CP Sensor
Cycling Power Service M
Device Information Service O
Battery Service O
Table 3.1: CP Sensor Service Requirements
Other than the CP Sensor, requirements in this section refer to Sections 7.1 and 8.1 for
CPP_v1.1
additional CP Sensor requirements for the LE transport and Sections 7.3 and 8.3 for the
BR/EDR transport.
Refer to Section 7 for connection establishment procedure considerations and refer to Section 7
for security considerations.
Refer to Section 5 for additional CP Broadcaster considerations for LE devices.
Refer to Section 6 for additional CP Observer considerations for LE devices.
3.1 Incremental Cycling Power Service Requirements

3.1.1 Additional Requirements for Low Energy Transport
This section describes additional CP Sensor requirements beyond those defined in the Cycling
Power Service when using this profile over Low Energy transport.
3.1.1.1 Service UUIDs AD Type

While in a GAP Discoverable Mode for initial connection to a Collector, the CP Sensor should
include the Cycling Power Service UUID defined in [3] in the Service UUIDs AD type field of the
advertising data. This enhances the user experience as a CP Sensor may be identified by the
Collector before initiating a connection.
3.1.1.2 Local Name AD Type

For enhanced user experience, a CP Sensor should include the Local Name (containing either
the complete or shortened value of the Device Name characteristic as defined in [2]) in its
Advertising Data or Scan Response Data. For privacy reasons, CP Sensors with the Privacy
Feature enabled should not include this field in the advertisement.
3.1.1.3 Writable GAP Device Name characteristic

The CP Sensor may support the write property for the Device Name characteristic in order to
allow a Collector to write a device name to the CP Sensor.
3.1.1.4 Appearance AD Type

For enhanced user experience, a CP Sensor should include the value of the Appearance
characteristic defined in [3] in its Advertising data or Scan Response data.
3.1.1.5 CP Broadcaster Role

If the CP Sensor supports the CP Broadcaster role, it shall support the Cycling Power
Measurement Broadcast feature defined in [1]. See Section 5 for additional requirements for CP
Broadcaster role.
3.1.1.6 Requirements for CP Sensors Used for a Distributed Power System

CP Sensors used as a part of a distributed power sensor system shall have different sensor
location values (e.g., Left Pedal and Right Pedal or Left Crank and Right Crank) to allow the
Collector to distinguish between the CP Sensors and to calculate values such as the pedal
CPP_v1.1
power balance or the total power. See Section 6 for additional requirements for CP Observer
role.
3.2 Incremental Device Information Service Requirements

In order to allow the user to log the type of equipment used in a training session, the CP Sensor
should instantiate the Manufacturer Name String and the Model Number String in the Device
Information Service [4].

4 Collector Role Requirements

The Collector shall use the Cycling Power Service [1].
The Collector may use the Device Information Service [4] as well as the Battery Service [5].
Service Collector
Cycling Power Service M
Device Information Service O
Battery Service O
Table 4.1: Collector Service Requirements
This section describes the profile requirements for a Collector.
Profile Requirement Section Support in Collector

Service Discovery 4.2 M
Cycling Power Service Discovery 4.2 M
Device Information Service Discovery 4.2 O
Battery Service Discovery 4.2 O
CPP_v1.1
Characteristic Discovery 4.3 M

Cycling Power Service Characteristic Discovery 4.3.1 M
Device Information Service Characteristic Discovery 4.3.2 O
Battery Service Characteristic Discovery 4.3.3 O
Cycling Power Feature 4.4 M
Cycling Power Measurement 4.5 M
Configuration of the Cycling Power Measurement 4.5.1 C.1
Broadcast feature
Sensor Location 4.6 M
Cycling Power Control Point 4.7 M
Cycling Power Vector 4.8 O
Table 4.2: Profile Requirements for Collector
C.1: Optional for an LE device, otherwise Excluded.
The Collector shall determine the features supported by the CP Sensor by reading the Cycling
Power Feature characteristic (see Section 4.4). If the Collector discovers the Server
Characteristic Configuration descriptor of the Cycling Power Measurement characteristic, it shall
assume that the CP Sensor supports the Cycling Power Measurement Broadcast feature.
Similarly, if the Collector discovers the Cycling Power Vector characteristic, it shall assume that
the CP Sensor supports the Cycling Power Vector feature.

Refer to Section 7 for connection establishment procedure consideration and refer to Section 8
for security considerations.
4.1 GATT Sub-Procedure Requirements

Requirements in this section represent a minimum set of requirements for a Collector. Other
GATT sub-procedures may be used if supported by both Client and Server.
The table below summarizes additional GATT sub-procedure requirements beyond those
required by all GATT Clients.
GATT Sub-Procedure Collector Requirements

Discover All Primary Services C.1
Discover Primary Services by Service UUID C.1
Discover All Characteristics of a Service C.2
Discover Characteristics by UUID C.2
Discover All Characteristic Descriptors M
Read Characteristic Value M
Write Characteristic Value C.3
CPP_v1.1
Notification M
Read Characteristic Descriptors M
Write Characteristic Descriptors M
Table 4.3: Additional GATT Sub-Procedure Requirements
C.1: Mandatory to support at least one of these Service Discovery sub-procedures when using the LE transport.
Excluded when using the BR/EDR transport since SDP must be used in this case.
C.2: Mandatory to support at least one of these Characteristic Discovery sub-procedures.
C.3: Mandatory if at least one Cycling Power Control Point procedure or the writable GAP Device Name is
supported (see Section 3.1.1.3).
4.2 Service Discovery

When using the Low Energy transport, the Collector shall perform primary service discovery
using either the GATT Discover All Primary Services sub-procedure or the GATT Discover
Primary Services by Service UUID sub-procedure.
When using the BR/EDR transport, the Collector shall perform service discovery by retrieving
the SDP record of the Cycling Power Service as defined in [1].
The Collector shall discover the Cycling Power Service and may discover the Device
Information Service and the Battery Service.

4.3 Characteristic Discovery

As required by GATT, the Collector must be tolerant of additional optional characteristics in the
service records of services used with this profile.
4.3.1 Cycling Power Service Characteristic Discovery

The Collector shall use either the GATT Discover All Characteristics of a Service sub-procedure
or the GATT Discover Characteristics by UUID sub-procedure to discover the characteristics of
the service.
The Collector shall use the GATT Discover All Characteristic Descriptors sub-procedure to
discover the characteristic descriptors.
The discovery requirements for the Collector are shown in Table 4.4 below:
Characteristic Discovery Requirements

for Collector
Cycling Power Feature M
Cycling Power Measurement M
Sensor Location M
CPP_v1.1
Cycling Power Vector O

Cycling Power Control Point O
Table 4.4: Discovery Requirements for Collector
Where a characteristic is discovered that can be notified or indicated, the Collector shall also
discover the associated Client Characteristic Configuration descriptor.
Where a characteristic is discovered that can be broadcasted, the Collector shall also discover
the associated Server Characteristic Configuration descriptor.
4.3.2 Device Information Service Characteristic Discovery

The Collector may discover the characteristics of the Device Information Service.
In order for the Collector to discover the characteristics of the Device Information Service, it
shall use either the GATT Discover All Characteristics of a Service sub-procedure or the GATT
Discover Characteristics by UUID sub-procedure to discover all characteristics of the service.
4.3.3 Battery Service Characteristic Discovery

The Collector may discover the characteristics of the Battery Service.
In order for the Collector to discover the characteristics of the Battery Service, it shall use either
the GATT Discover All Characteristics of a Service sub-procedure or the GATT Discover
Characteristics by UUID sub-procedure to discover all characteristics of the service.

4.4 Cycling Power Feature

The Collector shall read the Cycling Power Feature characteristic to determine the supported
features of the CP Sensor in order to understand its capabilities. In many cases, this will allow
the Collector to operate more efficiently. If one of the feature bits in Table 4.5 is set to 1
(meaning this feature is supported), the Collector shall assume that the related bits of the Flags
field are used by the CP Sensor. Otherwise, it is unnecessary for the Collector to check the
value of the related bits in the Flags field for the specified characteristic.
Cycling Power Feature Bit(s) Related Flag(s)

Pedal Power Balance Supported Pedal Power Balance Present bit and Pedal Power Balance
Source bit of the Cycling Power Measurement characteristic
Accumulated Torque Supported Accumulated Torque Present bit and Accumulated Torque
Source bit of the Cycling Power Measurement characteristic
Wheel Revolution Data Supported Wheel Revolution Data Present bit of the Cycling Power
Measurement characteristic
Crank Revolution Data Supported Crank Revolution Data Present bit of the Cycling Power
Measurement and the Cycling Power Vector characteristics
Extreme Magnitudes Supported Extreme Force Magnitudes Present bit and Extreme Torque
CPP_v1.1
Magnitudes Present bit of the Cycling Power Measurement

characteristic
Extreme Angles Supported Extreme Angles Present bit of the Cycling Power Measurement
characteristic and First Crank Measurement Angle bits of the
Cycling Power Vector characteristic
Top and Bottom Dead Spot Angles Top Dead Spot Present and Bottom Dead Spot Present bits of
Supported the Cycling Power Measurement characteristic
Accumulated Energy Supported Accumulated Energy Present bit of the Cycling Power
Measurement characteristic
Offset Compensation Indicator Offset Compensation Indicator bit of the Cycling Power
Supported Measurement characteristic
Sensor Measurement Context set to Extreme Torque Magnitudes Present bit of the Flags field of the
0 (Force based) Cycling Power Measurement characteristic and the
Instantaneous Torque Magnitudes Array Present bit of the
Flags field of the Cycling Power Vector characteristic
Sensor Measurement Context set to Extreme Force Magnitudes Present bit of the Flags field of the
1 (Torque based) Cycling Power Measurement characteristic and the
Instantaneous Force Magnitudes Array Present bit of the Flags
field of the Cycling Power Vector characteristic
Instantaneous Measurement Instantaneous Measurement Direction bits of the Cycling
Direction Supported Power Vector characteristic
Table 4.5: Cycling Power Feature Bit Requirement for Collector – Flags

Similarly, if one of the feature bits in Table 4.6 is set to 1, then the Collector shall assume that
the related procedure is supported by the CP Sensor. Otherwise, it is unnecessary for the
Collector to attempt to initiate the related procedure.
Cycling Power Feature Bit(s) Related Procedure(s)

Offset Compensation Supported Start Offset Compensation (see Section 4.7.2.12)
Cycling Power Measurement Mask Cycling Power Measurement Characteristic Content (see
Characteristic Content Masking Section 4.7.2.13)
Supported
Multiple Sensor Locations Request Supported Sensor Location (see Section 4.7.2.3) and
Supported Update Sensor Location (see Section 4.7.2.2)
Crank Length Adjustment Supported Set Crank Length (see Section 4.7.2.4) and Request Crank
Length (see Section 4.7.2.5)
Chain Length Adjustment Supported Set Chain Length (see Section 4.7.2.6) and Request Chain
Chain Weight Adjustment Supported Set Chain Weight (see Section 4.7.2.8) and Request Chain
Weight (see Section 4.7.2.9)
Span Length Adjustment Supported Set Span Length (see Section 4.7.2.10) and Request Span
CPP_v1.1

Factory Calibration Date Supported Request Factory Calibration Date (see Section 4.7.2.15)
Enhanced Offset Compensation Start Enhanced Offset Compensation (see Section 4.7.2.16)
Supported
Table 4.6: Cycling Power Feature Bit Requirements for Collector — Procedures
If the Distributed System Support bits of the Cycling Power Feature characteristic are set to 00
(Unspecified (legacy sensor)), the Collector shall make no adjustments to the power value
returned from a single CP Sensor. If the bits are set to 01 (Not for use in a distributed system),
the CP Sensor is not designed for use in a distributed system (i.e., the CP Sensor measures the
total amount of power generated by the user), and the Collector shall assume that the
Instantaneous Power value of the Cycling Power Measurement characteristic sent by the CP
Sensor represents the total amount of power generated by the user. If the bits are set to 10
(Can be used in a distributed system), the Collector shall assume that the Instantaneous Power
value of the Cycling Power Measurement characteristic sent by the CP Sensor represents only
a portion of the total amount of power generated by the user (e.g., the portion that the CP
Sensor measures). In this case, the Collector may double the value if there is no other CP
Sensor connected or calculate the total power as the sum of two connected CP Sensors. The
user should be alerted if the Collector senses only one CP Sensor in a distributed system and
also if the Collector doubles the value presented to the user.
If the Collector receives a Cycling Power Feature characteristic with Reserved for Future Use
(RFU) bits of the Cycling Power Feature field that are non-zero, it shall ignore those bits and

any additional data that may be present in the packet and continue to process the Cycling
Power Feature characteristic in the same way as if all the RFU bits had been zero.
If the Collector reads a Cycling Power Feature characteristic with additional, unrecognized
octets, the Collector behavior shall be identical to the Collector behavior when only recognized
octets are received. This is to enable compatibility with future Cycling Power Service updates for
the case where available octets in the characteristic are specified for optional use. What the
Collector does with the additional, unrecognized octets is left to the implementation.
4.5 Cycling Power Measurement

The Collector shall control the configuration of notifications (i.e., via the Client Characteristic
Configuration descriptor) of the Cycling Power Measurement characteristic.
The Collector shall be able to receive notifications of the Cycling Power Measurement
characteristic from the CP Sensor at intervals determined by the CP Sensor.
The Collector shall determine the contents of the Cycling Power Measurement characteristic
structure based on the contents of the Flags field. This allows the Collector to determine
whether or not the optional fields are present.
CPP_v1.1
If the CP Sensor supports the Pedal Power Balance feature (see Section 4.4), the Collector
shall consider the Pedal Power Balance Reference bit of the Flags field of the Cycling Power
Measurement characteristic to determine the reference of the pedal power balance.
If the CP Sensor supports the Accumulated Torque feature (see Section 4.4), the Collector
should refer to the Accumulated Torque Source bit of the Flags field of the Cycling Power
Measurement characteristic to determine the accumulated torque source (e.g., Wheel based or
Crank based).
If the CP Sensor supports the Wheel Revolution Data feature, the Collector can calculate the
instantaneous speed based on the Cumulative Wheel Revolution and the Last Wheel Event
Time fields of the Cycling Power Measurement characteristic. The Collector should support the
calculation of average speed.
Calculation of instantaneous speed at the Collector can be derived from the wheel
circumference and data in two successive measurements. The Collector calculation can be
performed as shown below:
Instantaneous Speed = (Difference in two successive Cumulative Wheel Revolution

values * Wheel Circumference) / (Difference in two successive Last Wheel Event Time
values)
If the CP Sensor supports the Crank Revolution Data feature, the Collector can calculate the
instantaneous cadence based on the Cumulative Crank Revolutions and the Last Crank Event

Time fields of the Cycling Power Measurement characteristic. The Collector should support the
calculation of average cadence.
Calculation of instantaneous cadence at the Collector can be derived from data in two
successive measurements. The Collector calculation can be performed as shown below:
Instantaneous Cadence = (Difference in two successive Cumulative Crank Revolutions

values) / (Difference in two successive Last Crank Event Time values)
The Cumulative Crank Revolutions value will occasionally roll over (i.e., as frequently as every
12 hours if ridden at 80 rpm). As such, the Collector shall take into account that the Cumulative
Crank Revolutions value can roll over during a ride.
While the Cumulative Wheel Revolution value cannot practically roll over during the life of the
Sensor, the Collector may set this value to a specific value (e.g., the value of the cumulative
wheel revolutions of an old CP Sensor to keep track of the total distance travelled). See Section
4.7.2.1 for information on how to set this value.
The Collector shall be tolerant of the fact that the Cumulative Wheel Revolutions value may
decrement for some implementations (e.g., if the bicycle is rolled in reverse).
CPP_v1.1
The Collector, when connected to a distributed power sensor system (e.g., left and right CP
Sensors), can:
• Display the distributed power values (e.g., left and right power values) and calculate and
display the pedal power balance (e.g., ratio of the consecutive left and right power values)
as described in Section 3.2.1.3 of [1], or
• Calculate and display the total power (e.g., sum of the distributed power values), or
• Estimate the total power based on only one distributed power value (e.g., double of the right
power value).
The Collector shall take into account that the following values can roll over during a ride:
• Accumulated Torque
• Last Wheel Event Time
• Cumulative Crank Revolutions
• Last Crank Event Time
• Accumulated Energy
If the Collector has a display, it can alert the user when data required for calculation of
instantaneous power, instantaneous speed, or instantaneous cadence is no longer being

received (e.g., due to link loss or sensor misalignment). This can be done by displaying “--” (i.e.,
two dashes) or by other means. Once the data is again received (e.g., the link is restored or
sensor position readjusted), the display can return to normal. In addition, if the user is coasting
(i.e., not rotating the crank), the instantaneous cadence can also be represented on the display
as “--” (i.e., two dashes).
If there is a link loss situation during a ride, the Collector should take that into account when
calculating the average.
If the CP Sensor supports the Offset Compensation Indicator feature, the Collector should
consider the Offset Compensation Indicator bit of the Flags field to determine whether or not an
action is required to recalibrate the CP Sensor.
If the Collector receives a Cycling Power Measurement characteristic with Reserved for Future
Use (RFU) bits of the Flags field that are non-zero, it shall ignore those bits and any additional
data that may be present in the packet and continue to process the Cycling Power
Measurement characteristic in the same way as if all the RFU bits had been zero.
If the Collector receives a Cycling Power Measurement characteristic with additional,

unrecognized octets, the Collector behavior shall be identical to the Collector behavior when
CPP_v1.1
only recognized octets are received. This is to enable compatibility with future Cycling Power
Service updates for the case where available octets in the characteristic are specified for
optional use. What the Collector does with the additional, unrecognized octets is left to the
implementation.
4.5.1 Cycling Power Measurement Broadcast Feature Configuration

If the Collector supports the configuration of the Cycling Power Measurement Broadcast feature,
it may control the configuration of broadcast (i.e., via the Server Characteristic Configuration
descriptor) of the Cycling Power Measurement characteristic typically only when directed
through user interaction via the Collector UI.
4.6 Sensor Location

The Sensor Location characteristic describes the location where the device is intended to be
installed. If the CP Sensor supports the Multiple Sensor Locations feature, the value of the
Sensor Location characteristic may change while in a connection; otherwise, the value of the
Sensor Location characteristic is static for the lifetime of the CP Sensor. The value of the
Sensor Location characteristic shall not be used to determine if the CP Sensor is part of a
distributed system.
If the CP Sensor supports the Multiple Sensor Locations Feature, the Collector may request the
supported sensor locations by using the procedure described in Section 4.7.2.3 and may also
update the value of the Sensor Location characteristic by using the procedure described in
Section 4.7.2.2.

If the CP Sensor supports the Multiple Sensor Locations Feature, the Collector should read the
value of the Sensor Location characteristic each time the connection is established to determine
if the CP Sensor is properly configured. This should be done in case the Sensor Location
characteristic value was altered by another Collector or in case the CP Sensor is unable to
cache the value. See Section 4.7.3 for information relating to the caching of the Sensor Location
characteristic.
If the Collector reads a Sensor Location value that is designated as Reserved for Future Use
(RFU), it shall ignore the value and may substitute it with the value for ‘Other’ (0x00) it shall also
ignore any additional data that may be present in the packet and continue to process the Sensor
Location characteristic in the same way as if all the RFU bits had been zero.
If the Collector receives a Sensor Location characteristic with additional, unrecognized octets,
the Collector behavior shall be identical to the Collector behavior when only recognized octets
are received. This is to enable compatibility with future Cycling Power Service updates for the
case where available octets in the characteristic are specified for optional use. What the
4.7 Cycling Power Control Point

Before performing a Cycling Power Control Point procedure, the Collector shall configure the
CPP_v1.1
Cycling Power Control Point characteristic for indications (i.e., via the Client Characteristic
Configuration descriptor).
The Collector may perform a write to the Cycling Power Control Point to request a desired
procedure. A procedure begins when the Collector writes a particular Op Code to the Cycling
Power Control Point to perform some desired action and ends when the Collector sends a
confirmation to acknowledge the Cycling Power Control Point indication sent by the CP Sensor
at the end of the procedure. This indication includes the Response Code, the Requested Op
Code, and the Response Value and may also include a Response Parameter as defined in [1].
4.7.1 Cycling Power Control Point Procedure Requirements

Table 4.7 shows the requirements for the Cycling Power Control Point procedures (Op Codes)
in the context of this profile:
Procedure (Op Code) Requirement

Set Cumulative Value O
Update Sensor Location M
Request Supported Sensor Locations M
Set Crank Length M
Request Crank Length O
Set Chain Length M
Request Chain Length O

Procedure (Op Code) Requirement

Set Chain Weight M
Request Chain Weight O
Set Span Length M
Request Span Length O
Start Offset Compensation M
Mask Cycling Power Measurement O
Characteristic Content
Request Sampling Rate C.1
Request Factory Calibration Date O
Start Enhanced Offset Compensation O
Table 4.7: Cycling Power Control Point Procedure Requirements
C.1: Mandatory if Cycling Power Vector feature is supported, otherwise Excluded.
4.7.2 Cycling Power Control Point Behavioral Description

The Collector shall write to the Cycling Power Control Point characteristic using one of the
supported Op Codes in Table 4.7 to request a CP Sensor to perform a procedure. This may
CPP_v1.1
include a Parameter that is valid within the context of that Op Code as defined in [1].
4.7.2.1 Set Cumulative Value Procedure

To request a specific setting of the Cumulative Wheel Revolutions value within the CP Sensor,
the Collector shall write the Set Cumulative Value Op Code followed by a UINT32 Parameter
Value that represents the desired cumulative wheel revolution. For example, writing a parameter
of 0x00000000 will set the Cumulative Wheel Revolutions value to 0 within the Sensor.
In some cases it may be desirable to use this feature to allow a user to transfer the distance
value (i.e., Cumulative Wheel Revolutions Value in the Sensor) from their old sensor onto their
new sensor (e.g., if they desire to keep track of the total distance they have travelled on their
bike).
In this scenario, a Collector that knows the Cumulative Wheel Revolutions value that was
reached with the old CP Sensor (or can calculate it from the total distance recorded) can use
the Set Cumulative Value Procedure to set the Cumulative Wheel Revolutions value within the
new CP Sensor to the same value.
In a second scenario, both the Collector and the CP Sensor are being replaced at the same
time. The user interface of the new Collector allows the user to set the wheel circumference for
the bike and the total distance value that he or she desires to transfer from the old CP Sensor.
The new Collector is able to calculate the Cumulative Wheel Revolutions value from these two
values and can use the Set Cumulative Value Procedure to set the Cumulative Wheel

Revolutions value within the new CP Sensor to the same value as it had reached in the old CP
Sensor.
The Collector shall wait for the Response Code Cycling Power Control Point Indication with the
Response Value set to Success indicating successful operation as per the request or an error
response value as described in Section 4.7.3 or for the procedure to time out according to the
procedure time-out operation described in Section 4.7.4.
See Section 4.7.3 for general error handling procedures.
4.7.2.2 Update Sensor Location Procedure

To update the sensor location within the CP Sensor, the Collector shall write the Update Sensor
Location Op Code followed by a UINT8 Parameter Value that represents a supported location.
A list of supported sensor locations, for a particular CP Sensor, is determined through the use of
the Request Supported Sensor Locations procedure described in Section 4.7.2.3. The possible
sensor location values are defined in the Sensor Location characteristic description in [3].
Refer to Section 7.4 for multiple bike considerations and how a Collector should handle the
Sensor Location parameter since a Collector may be used with more than one CP Sensor (e.g.,
the user owns several bikes).
CPP_v1.1
Response Value set to Success indicating success of the operation as per the request or an
error response value as described in Section 4.7.3 or for the procedure to time out according to
the procedure time out operation described in Section 4.7.4.
4.7.2.3 Request Supported Sensor Locations Procedure

To request the list of the sensor locations supported by the CP Sensor, the Collector shall use
the Request Supported Sensor Locations procedure.
Response Value set to Success indicating successful operation as per the request with the list
of supported locations in the Response Parameter value or an error response value as
described in Section 4.7.3 or for the procedure to time out according to the procedure time out
operation described in Section 4.7.4. The possible sensor location values are defined in the
Sensor Location characteristic description in [3].
Since the list of supported locations is static for the lifetime of the device as defined in the
Cycling Power Service, the Collector should cache the list of supported values.
See Section 4.7.3 for general error handling procedures including information relating to the
caching of the Sensor Location characteristic.

4.7.2.4 Set Crank Length Procedure

To set the crank length in the CP Sensor, the Collector shall write the Set Crank Length Op
Code with a UINT16 Parameter Value that represents the crank length in millimeters with a
resolution of 1/2 millimeter.
Crank Length parameter since a Collector may be used with more than one CP Sensor (e.g.,
4.7.2.5 Request Crank Length Procedure

To request the current value of the crank length set in the CP Sensor, the Collector shall use the
Request Crank Length procedure.
Refer to Section 7.4 for multiple bike consideration and how a Collector should handle the
CPP_v1.1
Crank Length parameter since a Collector may be used with more than one CP Sensor (e.g.,
when the user owns several bikes).
Response Value set to Success indicating successful operation as per the request with a
UINT16 Response Parameter value that represent the crank length in millimeters with a
resolution of 1/2 millimeter or an error response value as described in Section 4.7.3 or for the
procedure to time out according to the procedure time out operation described in Section 4.7.4.
caching of the crank length value.
4.7.2.6 Set Chain Length Procedure

To set the chain length in the CP Sensor, the Collector shall write the Set Chain Length Op
Code with a UINT16 Parameter that represents the chain length in millimeters with a resolution
of 1 millimeter.
Chain Length parameter since a Collector may be used with more than one CP Sensor (e.g.,
4.7.2.7 Request Chain Length Procedure

To request the current value of the chain length set in the CP Sensor, the Collector shall use the
Request Chain Length procedure.
Chain Length parameter since a Collector may be used with more than one CP Sensor (e.g.,
UINT16 Response Parameter value that represent the chain length in millimeters with a
resolution of 1 millimeter or an error response value as described in Section 4.7.3 or for the
caching of the chain length value.
4.7.2.8 Set Chain Weight Procedure

To set the chain weight in the CP Sensor, the Collector shall write the Set Chain Weight Op
CPP_v1.1
Code with a UINT16 Parameter that represents the chain weight in grams with a resolution of
1 gram.
Chain Weight parameter since a Collector may be used with more than one CP Sensor (e.g.,
4.7.2.9 Request Chain Weight Procedure

To request the current value of the chain weight set in the CP Sensor, the Collector shall use
the Request Chain Weight procedure.
Chain Weight parameter since a Collector may be used with more than one CP Sensor (e.g.,
UINT16 Response Parameter value that represent the chain weight in grams with a resolution of

1 gram or an error response value as described in Section 4.7.3 or for the procedure to time out
according to the procedure time out operation described in Section 4.7.4.
caching of the chain weight value.
4.7.2.10 Set Span Length Procedure

To set the span length in the CP Sensor, the Collector shall write the Set Span Length Op Code
with a UINT16 Parameter that represents the span length in millimeters with a resolution of
1 millimeter.
Span Length parameter since a Collector may be used with more than one CP Sensor (e.g., the
user owns several bikes).

CPP_v1.1
4.7.2.11 Request Span Length Procedure

To request the current value of the span length set in the CP Sensor, the Collector shall use the
Request Span Length procedure.
Span Length parameter since a Collector may be used with more than one CP Sensor (e.g., the
user owns several bikes).
Response Value set to Success indicating successful operation as per the request with the
UINT16 Response Parameter value that represents the span length in millimeters with a
resolution of 1 millimeter or an error response value as described in Section 4.7.3 or for the
caching of the span length value.
4.7.2.12 Start Offset Compensation Procedure

To start the offset compensation procedure within the Cycling Power Sensor, the Collector shall
write the Start Offset Compensation Procedure Op Code.
SINT16 Response Parameter value that represents, based on the Sensor Measurement

Context bit of the Cycling Power Feature characteristic, either the raw force in Newton with a
resolution of 1 Newton (Force-based) or the raw torque in Newton meter with a resolution of
1/32 Newton meter (Torque-based) before the offset is compensated or an error response value
as described in Section 4.7.3 or for the procedure to time out according to the procedure time
out operation described in Section 4.7.4.
4.7.2.13 Mask Cycling Power Measurement Characteristic Content Procedure

To set the contents of the Cycling Power Measurement characteristic within the Cycling Power
Sensor, the Collector shall write the Mask Cycling Power Measurement Characteristic Content
Op Code with a UINT16 Parameter that represents the content settings of the Cycling Power
Measurement characteristic (e.g., the optional fields that are requested to be turned off) as
defined in Table 4.8.
Bit Number Description

0 Pedal Power Balance
0: Leave as default
1: Turn off
1 Accumulated Torque
CPP_v1.1
0: Leave as default
1: Turn off
2 Wheel Revolution Data
0: Leave as default
1: Turn off
3 Crank Revolution Data
0: Leave as default
1: Turn off
4 Extreme Magnitudes
0: Leave as default
1: Turn off
5 Extreme Angles
0: Leave as default
1: Turn off
6 Top Dead Spot Angle
0: Leave as default
1: Turn off
7 Bottom Dead Spot Angle
0: Leave as default
1: Turn off
8 Accumulated Energy
0: Leave as default
1: Turn off

Bit Number Description

9–15 Reserved for future use
Table 4.8: Mask Cycling Power Measurement Characteristic Content Procedure Parameter
Requirements
4.7.2.14 Request Sampling Rate Procedure

To request the current value of the sampling rate used by the CP Sensor, the Collector shall use
the Request Sampling Rate procedure.
Response Value set to Success indicating successful operation as per the request with a UINT8
Response Parameter value that represents the sampling rate in Hertz with a resolution of
1 Hertz or an error response value as described in Section 4.7.3 or for the procedure to time out
CPP_v1.1
according to the procedure time out operation described in Section 4.7.4.
Since the sampling rate is static for the lifetime of the device as defined in the Cycling Power
Service, the Collector should cache this value.
caching of the sampling rate value.
4.7.2.15 Request Factory Calibration Date Procedure

To request the factory calibration date of the CP Sensor, the Collector shall use the Request
Factory Calibration Date procedure.
Response Parameter value that represents the factory calibration date or an error response
value as described in Section 4.7.3 or for the procedure to time out according to the procedure
time out operation described in Section 4.7.4. When the procedure is successful, the format of
the Response Parameter value, in the response to this Control Point, is defined to use the same
format as the Date Time characteristic defined in [3]. However, a value of 0 for the year, month,
or day fields shall not be used.
Since the factory calibration date is static for the lifetime of the device as defined in the Cycling
Power Service, the Collector should cache this value.

caching of the factory calibration date value.
4.7.2.16 Start Enhanced Offset Compensation Procedure

To start the enhanced offset compensation procedure within the Cycling Power Sensor, the
Collector shall write the Start Enhanced Offset Compensation Procedure Op Code.
SINT16 Response Parameter value that represents, based on the Sensor Measurement
Context bit of the Cycling Power Feature characteristic, either the raw force in Newton with a
resolution of 1 Newton (Force-based) or the raw torque in Newton meter with a resolution of
1/32 Newton meter (Torque-based) before the offset is compensated followed by a UINT16
value representing the manufacturer Company ID as given in the Bluetooth SIG assigned
numbers, a UINT8 representing the number of octets of manufacturer specific data (e.g., Analog
to Digital Conversion data), and the corresponding manufacturer specific data. A value of 0 for
the length of the manufacturer specific data is possible if the Cycling Power Sensor has no
additional data to send along with the response to this procedure.
If the operation results in an error condition received from the CP Sensor (e.g., the operation
CPP_v1.1
failed because the CP Sensor is in an inappropriate position for calibration, thus resulting in an
Operation Failed Response Value), the Collector can determine the cause of the error from the
received Response Parameter as described in [1].
The Collector shall handle an error response value as described in Section 4.7.3 and time out
according to the time out procedure described in Section 4.7.4.
4.7.3 General Error Handling

The Collector shall be tolerant and behave appropriately when receiving the following Control
Point Error codes defined in [3]:
• Op Code Not Supported
• Invalid Parameter
• Operation Failed
The Collector shall also be tolerant and behave appropriately when receiving the following ATT
Error Codes defined in CSS Part B, Section 1.2 [6]:
• Procedure Already In Progress
• Client Characteristic Configuration Descriptor Improperly Configured
If a Service Changed indication is received from the CP Sensor, this indicates not only that the
Collector shall re-perform Service and Characteristic discovery (as defined in GATT), but also

that the cached values for characteristics (e.g., the Sensor Location characteristic) may no
longer be valid and Collectors that use the Sensor Location feature are required to re-perform
the Request Supported Sensor Locations procedure to acquire a list of supported locations and
the CP Sensor parameters (e.g., chain length, chain weight, crank length, or span length) may
no longer be valid and Collectors should reconfigure those parameters.
4.7.4 Procedure Timeout

In the context of the Cycling Power Control Point characteristic, a procedure is started when the
Collector writes a particular Op Code to the Cycling Power Control Point to perform some
desired action and ends when the Collector sends a confirmation to acknowledge the Cycling
Power Control Point indication sent by the CP Sensor at the end of the procedure with the Op
Code set to Response Code.
In the context of the Cycling Power Control Point characteristic, a procedure is not considered
started and not queued in the CP Sensor when a write to the Cycling Power Control Point
results in an ATT Error Response defined in CSS Part B, Section 1.2 [6].
A procedure is considered to have timed out if a Cycling Power Control Point indication is not
received within the ATT transaction timeout, defined as 30 seconds in Volume 2, Part F, Section
3.3.3 of [2], from the start of the procedure.
CPP_v1.1
If the link is lost while a Cycling Power Control Point procedure is in progress, then the
procedure shall be considered to have timed out. See Section 4.7.4.1 for handling this condition.
Thus a Collector shall start a timer, with the value set to the ATT transaction timeout, after the
write response is received from the CP Sensor. The timer shall be stopped when a Cycling
Power Control Point indication is received and the Op Code is set to Response Code. If the
timer expires, then the procedure shall be considered to have failed.
4.7.4.1 Cycling Power Control Point Procedure Timeout Handling

If a Cycling Power Control Point procedure times out (see Section 4.7.4 for details of how this
may occur), then no new Cycling Power Control Point procedure shall be started by the
Collector until a new link is established with the CP Sensor. To ensure a good user experience,
if a Cycling Power Control Point procedure times out, the Collector should disconnect and then
reconnect.
4.8 Cycling Power Vector

The Collector shall control the configuration of notifications (i.e., via the Client Characteristic
Configuration descriptor) of the Cycling Power Vector characteristic.
If the Collector enables the notifications of the Cycling Power Vector characteristic, it shall be
able to receive the notifications from the CP Sensor at regular intervals. The notification interval
is defined by the CP Sensor.

The Collector should accept any valid GAP Connection Parameter Update procedure initiated
by the CP Sensor (e.g., L2CAP Connection Parameter Update Request) in order to allow the
CP Sensor to send the notification of the Cycling Power Vector at the desired interval.
The Collector shall determine the contents of the Cycling Power Vector characteristic structure
based on the contents of the Flags field. This allows the Collector to determine whether or not
the optional fields are present.
The Collector can support the calculation of instantaneous cadence.
Calculation of instantaneous cadence at the Collector can be derived from data in two
successive measurements. The Collector calculation can be performed as shown below:
Instantaneous Cadence = (Difference in two successive Cumulative Crank Revolution

values) / (Difference in two successive Last Crank Event Time values)
The Cumulative Crank Revolution value will occasionally roll over (i.e., as frequently as every 12
hours if ridden at 80 rpm). As such, the Collector shall take into account that the Cumulative
Crank Revolution value can roll over during a ride.
The Collector shall take into account that the Last Crank Event Time can roll over during a ride.
CPP_v1.1
If the Collector has a display, it can alert the user when data required for calculation of cycling
power data is no longer being received (e.g., due to link loss or sensor misalignment). This can
be done by displaying “--" (i.e., two dashes) or by other means. Once the data is again received
(e.g., the link is restored or sensor position readjusted), the display can return to normal. In
addition, if the user is coasting (i.e., not rotating the crank), the instantaneous cadence can also
be represented on the display as “--" (i.e., two dashes).
The Collector, to create a vector based on the data sent by the CP Sensor can follow the
procedure described in Section 12.
If the Collector receives a Cycling Power Vector characteristic with Reserved for Future Use
(RFU) bits of the Flags field that are non-zero, it shall ignore those bits and continue to process
the Cycling Power Vector characteristic in the same way as if all the RFU bits had been zero.
If the Collector receives a Cycling Power Vector characteristic with additional, unrecognized
octets, the Collector behavior shall be identical to the Collector behavior when only recognized
octets are received. This is to enable compatibility with future Cycling Power Service updates for
the case where available octets in the characteristic are specified for optional use. What the
4.9 Device Information Service Characteristics

The Collector may read the value of Device Information Service characteristics.

4.10 Battery Service Characteristics

The Collector may read the value of the Battery Level characteristic exposed in the Battery
Service. If the CP Sensor supports the notification of the Battery Level characteristic, the
Collector may also configure this characteristic for notification (e.g., via the Client Characteristic
Configuration descriptor).
CPP_v1.1

5 CP Broadcaster Role Requirements

This section describes the procedure requirements for a CP Broadcaster.
The CP Broadcaster shall start broadcasting the Cycling Power Measurement characteristic
when directed by the Collector (i.e., via the Server Characteristic Configuration descriptor). The
CP Broadcaster shall stop broadcasting the Cycling Power Measurement characteristic value
when directed by the Collector (i.e., via the Server Characteristic Configuration descriptor).
When the link with the Collector is terminated (e.g., terminated by the Collector, the CP Sensor
or when a link loss occurs), the CP Broadcaster shall stop broadcasting the Cycling Power
Measurement characteristic value.
The CP Broadcaster should set the advertisement interval with the same value as the
notification interval of the Cycling Power Measurement characteristic.
CPP_v1.1

6 CP Observer Role Requirements

This section describes the procedure requirements for a CP Observer.
A CP Observer that is expected to receive broadcasts of the Cycling Power Measurement

characteristic from one or more CP Broadcasters should know the address of the CP
Broadcaster(s) (e.g., the user sets the CP Broadcaster’s address in the CP Observer before the
training session starts). When the user of the CP Observer starts the procedure to receive
broadcast from a particular CP Broadcaster (e.g., GAP Observation procedure using passive
scanning), the CP Observer typically populates its White List with the preconfigured CP
Broadcaster’s address. This device is a CP Observer (GAP Observer or any other GAP Role
that allows receiving undirected non-connectable advertisements).
Profile Requirement Section Support in CP Observer

Cycling Power Measurement characteristic value included 6.1 M
in an undirected non-connectable advertisement
Table 6.1: Procedure Requirements for CP Observer
To enhance the user experience, the CP Observer should scan for undirected non-connectable
CPP_v1.1
advertisements from the CP Broadcaster(s) using fast scan parameters TGAP(scan_fast_interval)

and TGAP(scan_fast_window) (see [2] Volume 3, Part C, Section 9.3.11) until the first broadcast
is received. Then, the scan parameters should be defined based on the advertisement interval
set in the Advertisement Interval AD Type of the broadcast with consideration of the link layer
specific timing requirements (e.g., advDelay).
6.1 Broadcasting Cycling Power Measurement Characteristic

The CP Observer shall be able to receive multiple broadcasts of the Cycling Power
Measurement characteristic value from the CP Broadcaster at intervals determined by the CP
Broadcaster.
The requirements defined in Section 4.5 which define the contents of the Cycling Power
Measurement characteristic also apply to the CP Observer.

7 Connection Establishment Procedures

This section describes the connection establishment and connection termination procedures
used by a CP Sensor and Collector in certain scenarios.
The following scenario description is informative for Low Energy Transport:
Once configured by the Collector, a CP Sensor will typically remain powered off between
training sessions and will only advertise and allow a Collector to connect when it detects
user activity and has data to send. In this scenario, the CP Sensor will enter a GAP
Connectable Mode and start advertising when it has data to send to a Collector. The
Collector will typically execute a GAP connection establishment procedure such that it is
scanning for a CP Sensor. When a connection is established and the CP Sensor is
configured for notifications and indications by the Collector, the CP Sensor sends
notifications to the Collector at regular intervals. When the training session is ended on
the Collector, the Collector typically terminates the connection. When the CP Sensor is
inactive for a certain period of time, the CP Sensor typically terminates the connection.
7.1 CP Sensor Connection Establishment for Low Energy Transport

CPP_v1.1
This section describes connection procedures a CP Sensor should follow to initiate a connection
with a Collector using an LE transport.
• Section 7.1.1 describes the connection procedure when the CP Sensor does not support
bonding or if the CP Sensor supports bonding but is not bonded with any Collectors.
• Section 7.1.2 describes the connection procedure when the CP Sensor is bonded with one
or more Collectors.
• Section 7.1.3 is used when the established connection is broken after a link loss.
7.1.1 Connection Procedure for Unbonded Devices

This procedure is used for connection establishment when the CP Sensor is not bonded with
any Collectors and ready for connection (e.g., when the CP Sensor detects some activity or
when commanded by the user).
The CP Sensor should use the GAP General Discoverable Mode with connectable undirected
advertising events when establishing a connection.
If a connection is not established within TGAP(adv_fast_period), the CP Sensor may either

continue sending background advertising to reduce power consumption as long as it detects
user activity (e.g., user turns the cranks) or stop advertising.
The advertising interval and time to perform advertising should be configured with consideration
for user expectations of connection establishment time.

If a connection is not established within a time limit defined by the CP Sensor, the CP Sensor
may exit the GAP Connectable Mode.
The CP Sensor should be in the Bondable mode during this procedure to optimize the future
connections to the Collector.
If a bond is created, the CP Sensor should write the Bluetooth device address of the Collector in
the White List of its controller.
When the CP Sensor no longer detects user activity for several seconds (e.g., 10 to
20 seconds), the CP Sensor should perform the GAP Terminate Connection procedure.
7.1.2 Connection Procedure for Bonded Devices

This procedure is used after the CP Sensor is bonded with one or more Collectors.
When establishing a connection, the CP Sensor should use the GAP Non-Discoverable Mode
with connectable undirected advertising events for the first 10 seconds, with a White List
containing addresses of bonded devices, to allow only active bonded Collectors to establish a
connection. After the 10 second period has expired and in order to allow connection with
additional Collectors, the CP Sensor should use the GAP General Discoverable Mode with
CPP_v1.1
connectable undirected advertising events and it should be in the GAP Bondable mode.
If a connection is not established within TGAP(adv_fast_period), the CP Sensor may either

continue sending background advertising to reduce power consumption as long as it detects
user activity (e.g., user turns the cranks) or stop advertising.
The advertising interval and time to perform advertising should be configured with consideration
for user expectations of connection establishment time.
If a connection is not established within a time limit defined by the CP Sensor, the CP Sensor
may exit the GAP Connectable Mode.
If a bond is created, the CP Sensor should write the Bluetooth device address of the Collector in
the White List of its controller.
When the CP Sensor no longer detects user activity for several seconds (e.g., 10 to 20
seconds), the CP Sensor should perform the GAP Terminate Connection procedure.
When the CP Sensor is disconnected and the CP Sensor is ready for reconnection (e.g., when
the CP Sensor detects some activity or when commanded by the user), the CP Sensor should
reinitiate the connection procedure (e.g., start advertising).
7.1.3 Link Loss Reconnection Procedure

When a connection is terminated due to link loss, the CP Sensor should attempt to reconnect to
the Collector by entering a GAP Connectable Mode.

7.2 Collector Connection Establishment for Low Energy Transport

This section describes connection procedures a Collector should follow to initiate a connection
with a CP Sensor using an LE transport.
The Collector should use the GAP General Discovery procedure to discover a CP Sensor.
A Collector may use one of the GAP connection procedures based on its connectivity
requirements as described in Table 7.1:
GAP Connection Procedure Unbonded Collector Bonded Collector

General Connection Establishment Allowed Allowed
Direct Connection Establishment Allowed Allowed
Auto Connection Establishment Not Allowed Allowed
Selective Connection Establishment Not Allowed Allowed
Table 7.1: Allowed GAP Connection Procedure
If a connection is not established within TGAP(adv_fast_period) (see [2] Volume 3, Part C,

Section 9.3.11), the Collector may either continue background scanning to reduce power
consumption or stop scanning.
CPP_v1.1
The scan interval, scan window, and time to perform scanning should be configured with
consideration for user expectations of connection establishment time as defined in [2] Volume 3,
Part C, Section 9.3.11.
If a connection is not established within a time limit defined by the Collector, the Collector may
exit the connection establishment procedure.
When the connection is established, the Collector should bond with the CP Sensor to optimize
the future connections to the device.
If a bond is created, the Collector should write the Bluetooth device address of the CP Sensor in
the White List of its controller and set its initiator filter policy to ‘process connectable
advertisement packets.’
Once connected and if not already bonded to the CP Sensor, the Collector shall configure the
Cycling Power Measurement characteristic for notification and shall configure the Cycling Power
Control Point characteristic for indication. If the CP Sensor supports the Cycling Power
Measurement Broadcast feature, the Collector may enable the broadcast of the Cycling Power
Measurement characteristic as described in Section 4.5.1, typically when directed through the
user interaction via the Collector user interface (UI).
The Collector should terminate the connection when the measurement session is terminated at
the Collector by the user. In this case, the Collector should disable the notification of the Cycling
Power Vector characteristic prior to disconnect if this was previously enabled. The CP Sensor

will typically terminate the connection if the CP Sensor no longer detects user activity for several
seconds (e.g., 10 to 20 seconds).
When the Collector is disconnected, the Collector may initiate the new Connection Procedure.
For Collectors that may be used with one or more bikes, refer to Section 7.4.

When a connection is terminated due to link loss, the Collector should attempt to reconnect to
the CP Sensor using any of the GAP connection procedures using the connection establishment
timing parameters defined in [2] Vol. 3, Part C (GAP) section 9.3.11 and the connection interval
timing parameters defined in [2] Vol. 3, Part C (GAP) section 9.3.12.
7.3 Connection Establishment for BR/EDR

This section describes the connection establishment and connection termination procedures
used by a CP Sensor and Collector using a BR/EDR transport. Unlike the LE Connection
procedures, which describe specific connection parameters, BR/EDR connection establishment
does not state requirements beyond those described in GAP based on potential interactions
with other BR/EDR profiles operating concurrently on the CP Sensor and/or Collector.
CPP_v1.1
When using BR/EDR, devices can utilize sniff mode and sniff subrating to reduce power
consumption; however, no particular parameters are recommended and the requirements of
other profiles may need to be considered.
7.3.1 Connection Procedure

The procedures for establishing a connection between a CP Sensor and Collector that do not
have an existing bond and for re-establishing a connection between bonded devices use the
inquiry, discovery, paging, pairing, and security procedures described in Generic Access Profile
of the Core Specification [2] and any additional GAP requirements enumerated in Sections 7
and 9.
7.3.1.1 Connection Procedure for Unbonded Devices

The CP Sensor shall use the GAP General Discoverable Mode when it is not bonded with any
Collectors and is ready for a connection (e.g., when the CP Sensor detects some activity or
The Collector should use the GAP General Discovery procedure to discover a CP Sensor to
establish a connection to a CP Sensor to which it is not bonded.
Either the CP Sensor or the Collector can establish a BR/EDR link to a remote peer device.
Once a link is established, the Collector shall discover the Cycling Power Service using SDP
procedures prior to establishing a GATT connection.

Once the Cycling Power Service is discovered and a GATT connection is established, the
Collector shall discover the Cycling Power Service characteristics exposed by this service using
GATT Discovery procedures.
Once connected, the Collector shall configure the Cycling Power Measurement characteristic for
notification. If the CP Sensor exposes the Cycling Power Control Point characteristic, the
Collector should configure the Cycling Power Control Point for indication.
Power Vector characteristic prior to disconnect if this was previously enabled. When the CP
Sensor no longer detects user activity for several seconds (e.g., 10 to 20 seconds), the CP
Sensor may disconnect the link, depending on the use cases of the devices and other profiles
connected on either device.
For Collectors that may be used with one or more bikes each with its own independent set of
sensors, refer to Section 7.4.
7.3.1.2 Connection Procedure for Bonded Devices

The CP Sensor shall use the GAP Link Establishment Procedure to connect to any bonded
CPP_v1.1
Collectors when it is ready for a connection (e.g., when the CP Sensor detects some activity or
The Collector shall be Connectable to accept a connection from a CP Sensor to which it is

bonded.
Either the CP Sensor or the Collector can establish a BR/EDR link to a remote peer device.
If a higher layer determines the bond no longer exists on the remote device, the local device
must reconfigure the remote device after:
• user interaction confirms that the user wants to re-pair with the remote device,
• re-bonding has been performed, and
• service discovery has been performed.
If the local device had previously determined that the remote device did not have the «Service
Changed» characteristic then service discovery may be skipped.
Power Vector characteristic prior to disconnect if this was previously enabled. When the CP
Sensor no longer detects user activity for several seconds (e.g., 10 to 20 seconds), the CP
Sensor may disconnect the link, depending on the use cases of the devices and other profiles
connected on either device. When the CP Sensor is disconnected and it is ready for

reconnection (e.g., when the CP Sensor detects some activity or when commanded by the
user), the CP Sensor should initiate a connection with the Collector.
For Collectors that may be used with one or more bikes, each with its own independent set of
sensors, refer to Section 7.4.

When a connection is terminated due to link loss, a CP Sensor should reconnect to the
Collector by attempting, for an implementation-specific time, to reestablish an ACL link between
the two devices. The Collector should remain Connectable for an implementation-specific time
so that a CP Sensor can reestablish an ACL link.
7.4 Multiple Bike Considerations

In the context of this Profile, a Collector may be used with more than one bike, but not
simultaneously. To enhance the user experience and because each bike may be equipped with
its own set of Sensors (e.g., a Cycling Power Sensor, a Cycling Speed Sensor and a Cycling
Cadence Sensor or even a Sensor that supports both speed and cadence), it is recommended
that the user interface on the Collector allows the user of the Collector to select the bike to be
used among a list of the user’s bikes. The list of Sensors associated to one specific bike may be
CPP_v1.1
used to populate the White List to avoid connection to a Sensor installed on another of the
user’s nearby bikes.
The user interface on the Collector can also provide a mechanism to remove Sensors and to
add new Sensors to a bike definition to enhance the user experience. The Collector should
store the parameters (e.g., crank length, chain length, chain weight, and span length) of a CP
Sensor and provide a mechanism to set and/or retrieve those parameters from a CP Sensor,
typically upon user interaction.

8 Security Considerations
This section describes the security considerations for a CP Sensor and Collector.
8.1 CP Sensor Security Considerations for Low Energy

This section describes the security requirements for the CP Sensor for an LE transport.
All supported characteristics specified by the Cycling Power Service shall be set to LE Security
Mode 1 and either Security Level 1, 2, or 3.
The CP Sensor should bond with the Collector.
The CP Sensor should use the SM Slave Security Request procedure.
If used, all characteristics exposed by the Device Information Service for use by this profile
should be set to the same security mode and level as the characteristics in the Cycling Power
Service.
8.2 Collector Security Considerations for Low Energy

This section describes the security requirements for the Collector for an LE transport.
CPP_v1.1
The Collector should bond with the CP Sensor.
The Collector shall accept any request by the CP Sensor for LE Security Mode 1 and either
Security Level 1, 2, or 3.
8.3 Security Considerations for BR/EDR

As required by GAP, Security Mode 4 shall be used for connections by CP Sensor and
Collector.
• The Collector and CP Sensor should bond.
• Acceptance of Bonding should be supported by all CP Sensors and Collectors.
• Initiation of Bonding should be supported by Collectors.

9 Generic Access Profile for BR/EDR

This section defines the support requirements for the capabilities as defined in the Generic
Access Profile of the Core Specification [2] when BR/EDR is used.
9.1 Modes
The Mode Procedures as defined in GAP describe requirements for both CP Sensor and
Collector involved. This profile further refines the requirements.
• General Discoverable mode or Limited Discovery mode shall be supported by CP Sensors

supporting BR/EDR.
• Bondable mode should be supported by CP Sensors and Collectors
Table 9.1 shows the support status for GAP Modes in this profile.
Procedure Support in CP Sensor Support in Collector

General Discoverable Mode M X
Table 9.1: Modes
CPP_v1.1
9.2 Idle Mode Procedures

The Idle Mode Procedures as defined in GAP describe requirements for both CP Sensor and
Collector involved. This profile further refines the requirements.
• General inquiry shall be supported by all Collectors.
• General bonding should be supported by all CP Sensors and Collectors.
Table 9.2 shows the support status for Idle Mode procedures within this profile.
Procedure Support in CP Sensor Support in Collector

General Inquiry X M
Table 9.2: Idle mode procedures

10 Acronyms and Abbreviations

Any abbreviation or acronym used in the document, but not defined in the common specification
sections (e.g., Volume 1, Part B), is defined here. The list is alphabetized.
Abbreviation or Acronym Meaning

ACL Asynchronous Connection-oriented [logical transport]
AD Advertising Data
AMP Alternate MAC/PHY
BR/EDR Basic Rate / Enhanced Data Rate
CP Cycling Power
GAP Generic Access Profile
GATT Generic Attribute Profile
LE Low Energy
RFU Reserved for Future Use
SDP Service Discovery Protocol
SM Security Manager
CPP_v1.1
UUID Universally Unique Identifier

Table 10.1: Abbreviations and Acronyms

11 References
[1] Cycling Power Service v1.1 or later
[2] Bluetooth Core Specification v4.0 with CSA2, CSA3, and CSA4 or later version of the Core
Specification.
[3] Characteristic and Descriptor descriptions are accessible via the Bluetooth SIG Assigned
Numbers.
[4] Device Information Service v1.1 or later
[5] Battery Service v1.0 or later
[6] Supplement to the Bluetooth Core Specification, Version 3 or later
CPP_v1.1

12 Appendix A – Cycling Power Vector Handling

This section is informative and describes the different methods a Collector can use to handle
the Cycling Power Vector characteristic in order to build a vector of raw force or torque.
Depending on the CP Sensor capabilities, the Collector can build either:
a) A magnitude-angle vector if the CP Sensor supports the Crank Revolution Data feature
and the Extreme Angles feature, as described in Section 12.1 or
b) A magnitude vector, as described in Section 12.2 (e.g., without angle or crank revolution
information).
The sampling rate referenced in Sections 12.1 and 12.2 is not necessarily the sampling rate at
which the CP Sensor samples the raw signal, but it represents the sampling rate at which the
Instantaneous Magnitude values present in the Cycling Power Vector characteristic are sampled
since those data are typically down-sampled from the raw signal. Typically, the data are down-
sampled to a sampling rate of 25 Hertz to 50 Hertz. This sampling rate value can be accessed
using the Request Sampling Rate procedure defined in Section 4.7.2.14.
12.1 Magnitude vs. Crank Angle

CPP_v1.1
If the CP Sensor supports the Crank Revolution Data feature and the Extreme Angles feature,
and when the Collector receives a Cycling Power Vector characteristic notification with the First
Crank Measurement Angle value present, representing the angle value of the first
Instantaneous Magnitude value in the Instantaneous Force Magnitude Array field (or
Instantaneous Torque Magnitude Array field), the Collector is able to recompose the first angle-
magnitude pair. In a typical case where there are more than one Instantaneous Magnitude
values present, the Collector would calculate angle-magnitude pairs for the rest of the
Instantaneous Magnitude values by:
a) Determining an average crank angular speed by using the latest received consecutive
Crank Revolution Data which have different Cumulative Crank Revolutions values, and
b) Dividing the angular crank speed by the Sample Rate value (see Section 4.7.2.14),
yielding the angle that the crank turned between consecutive samples, and
c) In some cases where the Instantaneous Magnitude values for a single crank rotation
(360 degrees) do not fit within a single packet, the next packet will be a continuation of
the array and will not contain the First Crank Measurement Angle field. Calculating the
cumulative angle for each value in the Instantaneous Force Magnitude Array (or
Instantaneous Torque Magnitude Array) data, yielding a complete set of angle-
magnitude pairs of a crank rotation, and
d) Repeating steps a), b), and c) as long as Cycling Power Vector data measurement is
active.

See Figure 12.1 for an example of the force (or torque) measurement during a crank revolution,
and see Figure 12.2 for a representation of the force measurement vs. crank angle.
When observed with the front wheel to the right of the pedals, a value of 0 degrees represents
the angle when the crank is in the 12 o'clock position and a value of 90 degrees represents the
angle, measured clockwise, when the crank points towards the front wheel in the 3 o'clock
position. The left crank sensor (if fitted) detects a value of 0 degrees when the crank it is
attached to is in the 12 o'clock position, and the right sensor (if fitted) detects a value of 0
degrees when the crank it is attached to is in its 12 o'clock position. Therefore, there is a
constant difference of 180 degrees between the right crank and the left crank position signals
(i.e., when the right crank is at 12 o'clock position, the left crank is at 6 o'clock position).
0°
270° 90°
CPP_v1.1
180°
Figure 12.1: Force measurement during one crank revolution.
The Instantaneous Magnitude values transmitted are represented with the sample points on top
of the Force curve in Newton.

Figure 12.2: Cycling Power Vector: Force versus Time.
12.2 Magnitude vs. Time

CPP_v1.1
If the CP Sensor does not support the Extreme Angles feature, then the Collector can still
display the force/torque vs. time (see Figure 12.3: for an example of raw force data from a
distributed cycling power system). Refer to Section 4.7.2.14 for more information on the
Sampling Rate at which the CP Sensor samples the transmitted the data. The Instantaneous
Magnitude values transmitted by each CP Sensor are represented with the sample points on top
of the Force curves in Newton.


CPP_v1.1
Figure 12.3: Cycling Power Vector: Force versus Time.

CPP v1.1

Uploaded by

Copyright:

Available Formats

CPP v1.1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CPP v1.1

Uploaded by

Copyright:

Available Formats

Cycling Power Profile

Bluetooth® Profile Specification

Group Prepared By Sports and Fitness Working Group

Feedback Email [email protected]

Bluetooth SIG Proprietary

Bluetooth Profile Specification

Revision Number Date Comments

Bluetooth SIG Proprietary Page 2 of 47

Bluetooth Profile Specification

DISCLAIMER AND COPYRIGHT NOTICE

MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, SATISFACTORY QUALITY, OR

Bluetooth SIG Proprietary Page 3 of 47

Bluetooth Profile Specification

Bluetooth SIG Proprietary Page 4 of 47

Bluetooth Profile Specification

4 Collector Role Requirements ........................................................................................................... 12

Bluetooth SIG Proprietary Page 5 of 47

Bluetooth Profile Specification

6.1 Broadcasting Cycling Power Measurement Characteristic .......................................................... 33

9.1 Modes ........................................................................................................................................... 41

Bluetooth SIG Proprietary Page 6 of 47

Bluetooth Profile Specification

1.1 Profile Dependencies

1.3 Bluetooth Specification Release Compatibility

• A Bluetooth Core Specification later than 4.0

Bluetooth SIG Proprietary Page 7 of 47

Bluetooth Profile Specification

• The CP Sensor shall be a GATT Server.

• If a CP Sensor uses LE transport, it may also implement the CP Broadcaster role.

• The Collector shall be a GATT Client.

2.2 Role/Service Relationships

Collector CP Sensor CP Broadcaster CP Observer

Dashed box items are optional.

Bluetooth SIG Proprietary Page 8 of 47

Bluetooth Profile Specification

2.3 Concurrency Limitations and Restrictions

2.4 Topology Limitations and Restrictions

2.4.2 Topology Limitations and Restrictions for BR/EDR

2.5 Transport Dependencies

Bluetooth SIG Proprietary Page 9 of 47

Bluetooth Profile Specification

3 CP Sensor Role Requirements

The Cycling Power Service shall be instantiated as a «Primary Service».

The CP Sensor should instantiate the Battery Service [5].

Refer to Section 5 for additional CP Broadcaster considerations for LE devices.

Refer to Section 6 for additional CP Observer considerations for LE devices.

3.1 Incremental Cycling Power Service Requirements

3.1.1.1 Service UUIDs AD Type

3.1.1.2 Local Name AD Type

Bluetooth Profile Specification

3.1.1.3 Writable GAP Device Name characteristic

3.1.1.4 Appearance AD Type

3.1.1.5 CP Broadcaster Role

3.1.1.6 Requirements for CP Sensors Used for a Distributed Power System

3.2 Incremental Device Information Service Requirements

Bluetooth SIG Proprietary Page 11 of 47

Bluetooth Profile Specification

4 Collector Role Requirements

This section describes the profile requirements for a Collector.