Cycling Power Profile

Revision: v1.1
Revision Date: 2016-05-03
Prepared By: Sports and Fitness Working Group
Feedback Email: sf-main@bluetooth.org

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

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

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.

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

2.2. Role/Service Relationships

The following diagram shows the relationships between service and profile roles.

Note

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

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 Section 7.1 and Section 8.1 for additional CP Sensor requirements for the LE transport and Section 7.3 and Section 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 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
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 Broadcast feature	4.5.1	C.1
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
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
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 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 Supported	Top Dead Spot Present and Bottom Dead Spot Present bits of the Cycling Power Measurement characteristic
Accumulated Energy Supported	Accumulated Energy Present bit of the Cycling Power Measurement characteristic
Offset Compensation Indicator Supported	Offset Compensation Indicator bit of the Cycling Power Measurement characteristic
Sensor Measurement Context set to 0 (Force based)	Extreme Torque Magnitudes Present bit of the Flags field of the 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 1 (Torque based)	Extreme Force Magnitudes Present bit of the Flags field of the Cycling Power Measurement characteristic and the Instantaneous Force Magnitudes Array Present bit of the Flags field of the Cycling Power Vector characteristic
Instantaneous Measurement Direction Supported	Instantaneous Measurement Direction bits of the Cycling 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 Characteristic Content Masking Supported	Mask Cycling Power Measurement Characteristic Content (see Section 4.7.2.13)
Multiple Sensor Locations Supported	Request Supported Sensor Location (see Section 4.7.2.3) and 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 Length (see Section 4.7.2.7)
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 Length (see Section 4.7.2.11)
Factory Calibration Date Supported	Request Factory Calibration Date (see Section 4.7.2.15)
Enhanced Offset Compensation Supported	Start Enhanced Offset Compensation (see Section 4.7.2.16)

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.

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

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 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 Collector does with the additional, unrecognized octets is left to the implementation.

4.7. Cycling Power Control Point

Before performing a Cycling Power Control Point procedure, the Collector shall configure the 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
Set Chain Weight	M
Request Chain Weight	O
Set Span Length	M
Request Span Length	O
Start Offset Compensation	M
Mask Cycling Power Measurement Characteristic Content	O
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 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).

The Collector shall wait for the Response Code Cycling Power Control Point Indication with the 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.

See Section 4.7.3 for general error handling procedures.

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.

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

Refer to Section 7.4 for multiple bike considerations and how a Collector should handle the Crank Length parameter since a Collector may be used with more than one CP Sensor (e.g., the user owns several bikes).

See Section 4.7.3 for general error handling procedures.

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 Crank Length parameter since a Collector may be used with more than one CP Sensor (e.g., when the user owns several bikes).

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

See Section 4.7.3 for general error handling procedures including information relating to the 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.

Refer to Section 7.4 for multiple bike considerations and how a Collector should handle the Chain Length parameter since a Collector may be used with more than one CP Sensor (e.g., the user owns several bikes).

See Section 4.7.3 for general error handling procedures.

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.

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 with a 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 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 including information relating to 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 Code with a UINT16 Parameter that represents the chain weight in grams with a resolution of 1 gram.

Refer to Section 7.4 for multiple bike considerations and how a Collector should handle the Chain Weight parameter since a Collector may be used with more than one CP Sensor (e.g., the user owns several bikes).

See Section 4.7.3 for general error handling procedures.

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.

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

See Section 4.7.3 for general error handling procedures including information relating to the 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.

Refer to Section 7.4 for multiple bike considerations and how a Collector should handle the Span Length parameter since a Collector may be used with more than one CP Sensor (e.g., the user owns several bikes).

See Section 4.7.3 for general error handling procedures.

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.

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 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 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 including information relating to 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.

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

See Section 4.7.3 for general error handling procedures.

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 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
9–15	Reserved for future use

Table 4.8. Mask Cycling Power Measurement Characteristic Content Procedure Parameter Requirements

See Section 4.7.3 for general error handling procedures.

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.

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

See Section 4.7.3 for general error handling procedures including information relating to the 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.

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

See Section 4.7.3 for general error handling procedures including information relating to the 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.

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

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.

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 Collector does with the additional, unrecognized octets is left to the implementation.

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

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.

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 in an undirected non-connectable advertisement	6.1	M

Table 6.1. Procedure Requirements for CP Observer

To enhance the user experience, the CP Observer should scan for undirected non-connectable advertisements from the CP Broadcaster(s) using fast scan parameters T_GAP(scan_fast_interval) and T_GAP(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

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 T_GAP(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 connectable undirected advertising events and it should be in the GAP Bondable mode.

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

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

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.

7.2.1. Link Loss Reconnection Procedure

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.

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 when commanded by the user).

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.

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. 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 Collectors when it is ready for a connection (e.g., when the CP Sensor detects some activity or when commanded by the user).

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.

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.2. Link Loss Reconnection Procedure

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

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

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
UUID	Universally Unique Identifier

Table 10.1. Abbreviations and Acronyms

11. References

Bibliography

[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

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 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
A magnitude vector, as described in Section 12.2 (e.g., without angle or crank revolution information).

The sampling rate referenced in Section 12.1 and Section 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

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:

Determining an average crank angular speed by using the latest received consecutive Crank Revolution Data which have different Cumulative Crank Revolutions values, and
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
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
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).

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

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.

Figure 12.3. Cycling Power Vector: Force versus Time.

Cycling Power Profile

Bluetooth® Profile Specification

Revision History

Contributors

Document Terminology

1. Introduction

1.1. Profile Dependencies

1.2. Conformance

1.3. Bluetooth Specification Release Compatibility

2. Configuration

2.1. Roles

2.2. Role/Service Relationships

Note

2.3. Concurrency Limitations and Restrictions

2.4. Topology Limitations and Restrictions

2.4.1. Topology Restrictions for Low Energy

2.4.2. Topology Limitations and Restrictions for BR/EDR

2.5. Transport Dependencies

3. CP Sensor Role Requirements

3.1. Incremental Cycling Power Service Requirements

3.1.1. Additional Requirements for Low Energy Transport

3.1.1.1. Service UUIDs AD Type

3.1.1.2. Local Name AD Type

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

4. Collector Role Requirements

4.1. GATT Sub-Procedure Requirements

4.2. Service Discovery

4.3. Characteristic Discovery

4.3.1. Cycling Power Service Characteristic Discovery

4.3.2. Device Information Service Characteristic Discovery

4.3.3. Battery Service Characteristic Discovery

4.4. Cycling Power Feature

4.5. Cycling Power Measurement

4.5.1. Cycling Power Measurement Broadcast Feature Configuration

4.6. Sensor Location

4.7. Cycling Power Control Point

4.7.1. Cycling Power Control Point Procedure Requirements

4.7.2. Cycling Power Control Point Behavioral Description

4.7.2.1. Set Cumulative Value Procedure

4.7.2.2. Update Sensor Location Procedure

4.7.2.3. Request Supported Sensor Locations Procedure

4.7.2.4. Set Crank Length Procedure

4.7.2.5. Request Crank Length Procedure

4.7.2.6. Set Chain Length Procedure

4.7.2.7. Request Chain Length Procedure

4.7.2.8. Set Chain Weight Procedure

4.7.2.9. Request Chain Weight Procedure

4.7.2.10. Set Span Length Procedure

4.7.2.11. Request Span Length Procedure

4.7.2.12. Start Offset Compensation Procedure

4.7.2.13. Mask Cycling Power Measurement Characteristic Content Procedure

4.7.2.14. Request Sampling Rate Procedure

4.7.2.15. Request Factory Calibration Date Procedure

4.7.2.16. Start Enhanced Offset Compensation Procedure

4.7.3. General Error Handling

4.7.4. Procedure Timeout

4.7.4.1. Cycling Power Control Point Procedure Timeout Handling

4.8. Cycling Power Vector

4.9. Device Information Service Characteristics

4.10. Battery Service Characteristics

5. CP Broadcaster Role Requirements

6. CP Observer Role Requirements

6.1. Broadcasting Cycling Power Measurement Characteristic

7. Connection Establishment Procedures

7.1. CP Sensor Connection Establishment for Low Energy Transport

7.1.1. Connection Procedure for Unbonded Devices

7.1.2. Connection Procedure for Bonded Devices

7.1.3. Link Loss Reconnection Procedure

7.2. Collector Connection Establishment for Low Energy Transport

7.2.1. Link Loss Reconnection Procedure

7.3. Connection Establishment for BR/EDR

7.3.1. Connection Procedure

7.3.1.1. Connection Procedure for Unbonded Devices

7.3.1.2. Connection Procedure for Bonded Devices

7.3.2. Link Loss Reconnection Procedure

7.4. Multiple Bike Considerations

Bluetooth^® Profile Specification