Cycling power and cadence lab: from revolution counts to rpm

The structures it decodes against

Compiled from the Bluetooth SIG’s GATT Specification Supplement files at commit 408f4a0 of the SIG’s public repository (read 2026-10-17), through this site’s generated copy. The two measurements, then the characteristics the lab reads once after connecting:

The arithmetic, step by step

1. Find the struct. In CSC Measurement, Wheel Revolution Data is present when bit 0 of Flags is 1 and Crank Revolution Data when bit 1 is 1. In Cycling Power Measurement they hang on bits 4 and 5 of a two-octet Flags field, after Instantaneous Power, which is always there.
2. Difference two readings, with the wrap. Cumulative Crank Revolutions is a uint16 and every event time a uint16, so they roll over: a later reading smaller than the earlier one means the counter wrapped, and the step is the difference modulo 2¹⁶. At 1/1024 s the event time wraps every 64 s; the Cycling Power wheel’s, at 1/2048 s, every 32 s. The synthetic ride wraps both.
3. Scale the time. CSC’s wheel event time: Represented values: M = 1, d = 0, b = -10, beside Unit is 1/1024th of a second. Cycling Power’s: Represented values: M = 1, d = 0, b = -11, beside Unit is 1/2048 second. The lab multiplies by M × 10^d × 2^b; a parser that assumes one tick for both reads Cycling Power wheel speed at half or double its value.
4. Divide. Cadence in rpm is Δcrank revolutions ÷ Δt × 60. Wheel speed is Δwheel revolutions × circumference ÷ Δt; the lab shows km/h (× 3.6 from m/s). The circumference is not in either characteristic, which is why the lab asks for it.
5. Treat an unchanged event time as no new event. Two notifications with the same event time mean no revolution finished between them (coasting, or a notification interval shorter than one revolution). The lab reports “no new event” and keeps the last cadence on screen labeled as such, rather than dividing by zero or showing 0 rpm.

Where the decoder reads past the SIG’s file

• Byte order. Little-endian, as the Web Bluetooth specification’s heart-rate example reads every multi-octet field (result.heartRate = data.getUint16(index, /*littleEndian=*/true);, read 2026-10-31); the YAML gives sizes only.
• Extreme Angles. Two 12-bit members packed into three octets. The SIG’s file gives the example itself (Maximum Angle 0xABC and Minimum Angle 0x123 make 0x123ABC), and the test suite decodes exactly that example.
• Control points. Cycling Power Control Point and SC Control Point have no member layout for their Parameter in the files this site reads, so the lab neither decodes nor writes them. It writes nothing to a sensor.

Which browsers can connect

Web Bluetooth is a Chromium feature. MDN's compatibility data lists it in Chrome (requestDevice since version 56), Edge, Opera and Samsung Internet, with the note that Chrome's Linux support is not enabled by default, and marks the API experimental. It lists no support in Firefox, in Safari on macOS or iOS, or in Android's WebView.

Source: MDN browser-compat-data, api/Bluetooth.json, read 2026-11-05. Elsewhere the paste boxes and the replay still work.

What the lab cannot tell you

• Accuracy. Nothing here compares a power meter or sensor with a reference.
• Which source to trust when a trainer, a power meter and a cadence sensor all report the same pedal stroke. The lab shows each characteristic separately and never merges them; picking one source per metric is covered in reading cycling power, cadence and speed sensors.
• Smart-trainer data that arrives as FTMS Indoor Bike Data instead: that has its own FTMS lab, and the trainer side is in indoor bike trainer integration.

The radio choice is in ANT+ vs Bluetooth, CI without a sensor in testing BLE fitness devices, and any other characteristic in the BLE GATT explorer.