Bluetooth heart-rate lab: see every byte your strap sends

The structure it decodes against

The decoder has no packet layout of its own. It reads the Bluetooth SIG’s GATT Specification Supplement file for Heart Rate Measurement, gss/org.bluetooth.characteristic.heart_rate_measurement.yaml at commit 408f4a0 of the SIG’s public repository (read 2026-10-17), from this site’s generated copy, and builds the decoder from it. Every field after Flags is conditional:

The Flags bits, as the SIG lists them: bit 0, Heart Rate Value Format:; bit 1, Sensor Contact detected; bit 2, Sensor Contact Supported; bit 3, Energy Expended present; bit 4, RR-Interval present; bit 5–7, Reserved for Future Use. Bits 2 and 1 carry no field of their own: the lab reads them as “contact not supported” when bit 2 is clear, and otherwise as detected or not detected. The full page for the characteristic, with the SIG’s notice, is Heart Rate Measurement (0x2A37); Body Sensor Location (0x2A38), which the lab reads once after connecting, is on the Bluetooth GATT reference.

Why RR intervals decide HRV

The SIG defines the field plainly: The RR-Interval value represents the time between two R-Wave detections. and Each RR-Interval value is represented by a uint16 with 1/1024 second as the unit. HRV is a statistic over exactly those beat-to-beat times. A heart-rate value is one number in beats per minute per notification; the timing of the individual beats is not in it, and no amount of processing on the app side puts it back. That is why the verdict above is a yes or a no: a device that never sets bit 4 gives you heart rate, and only heart rate.

A notification can carry several RR values or none. The SIG: The number of RR-Interval sub-fields present is determined by a combination of the overall length of the characteristic and whether or not the characteristic contains the Energy Expended field. The lab therefore counts the octets left after the fields the flags announce, two per value, and reports an odd one left over instead of guessing at it.

The RMSSD the lab shows is the root mean square of successive differences between RR intervals, computed only within runs of notifications that all carried RR values. It is there so you can see the arithmetic work on your own data, labeled a demo, and it is not a medical or training measurement: there is no artifact or ectopic-beat correction, no minimum recording length and no baseline. What HRV is, and how the platforms store it, is covered in what is HRV, how to get HRV data from an API and Health Connect’s HeartRateVariabilityRmssdRecord.

Where the decoder reads past the SIG’s file

• Byte order. The structure gives sizes, not byte order. The lab reads multi-octet fields little-endian, as the Web Bluetooth specification’s heart-rate example does (result.heartRate = data.getUint16(index, /*littleEndian=*/true);, read 2026-10-31). The default value in the paste box, 1E 46 EE 02 7A 03 66 03, decodes to that example’s published result: 70 bpm, contact detected, Energy Expended 750, RR values 890 and 870.
• Energy Expended’s unit. The SIG’s file gives org.bluetooth.unit.energy.joule (energy (joule)), and the lab shows that. The same Web Bluetooth example comments the value as energyExpended: 750, // Meaning 750kJ.. The two sources disagree by a factor of a thousand; we report the disagreement rather than pick one.
• Battery Level (0x2A19). Outside this site’s Bluetooth dataset, so it was read on 2026-10-31 from the SIG’s own gss/org.bluetooth.characteristic.battery_level.yaml at the same commit: one uint8, Allowed range is 0 to 100. The lab asks for the Battery service (0x180F) as an optional service and says so when a device does not expose it.

What the lab cannot tell you

• Whether the RR values are measured. The bytes say a device sent values in the RR field, not how it got them; the lab shows how many distinct values arrived so a suspiciously uniform stream is visible, and leaves the judgment to you.
• Accuracy. Nothing here compares a device with a reference; we publish no accuracy figure for any strap or watch.
• Anything in a browser without Web Bluetooth. The page detects the API and, where it is missing, offers the synthetic replay and the paste box. Which browsers ship it is set out in Web Bluetooth for fitness devices. Real Bluetooth cannot be exercised in an automated test either, which is why the decoder is tested on synthetic packets built from the SIG structure (all 32 combinations of the five defined Flags bits).

Building this into an app is the subject of connecting a Bluetooth heart rate monitor, with the radio choice in ANT+ vs Bluetooth, the watch case in Apple Watch live heart rate, and CI without a strap in testing BLE fitness devices. Every characteristic the SIG defines for fitness devices is in the Bluetooth GATT reference.

Next step

Turning this into a choice of API:

• The Best Wearable Fitness & Health-Data APIs (2026) →
• The Best Wearable Health-Data Aggregator APIs (2026) →