Bluetooth wearable module

The Bluetooth wearable module reads a Bluetooth Low Energy (BLE) heart rate monitor over Windows’ own Bluetooth stack and publishes heart rate, R-R interval and energy expended as one entity. It speaks the standard Bluetooth SIG Heart Rate Service, not a proprietary protocol, so any BLE device implementing that service works, not only a specific vendor’s strap. Package name in the module registry: HEAT.BluetoothWearableModule.

What you need

A Windows Bluetooth adapter, and a BLE heart rate monitor that advertises the standard Heart Rate Service (some straps require pairing before their Heart Rate Measurement characteristic is readable; the module logs when that is the case).
See Install a capture module for adding it to HEAT Capture.

Scanning, connecting, discovering GATT services and subscribing to notifications routinely takes longer than a typical module’s startup allowance; this module raises its own startup timeout to 30 seconds to cover that.

What it captures and how to configure it

One fixed entity, carrying a BiometricSensorComponent with three readings:

Reading name	Type	Notes
`HeartRate`	int, beats per minute	From the Heart Rate Measurement characteristic’s 8-bit or 16-bit value, whichever the device sends
`RR`	float, milliseconds	One R-R interval per notification, converted from the device’s native 1/1024 s units. If a notification carries more than one R-R value (some straps batch them when running behind), only the first is read
`kcal`	float, kilocalories	The characteristic’s cumulative energy-expended field, converted from kilojoules. Per the Bluetooth spec this accumulates since the device’s last reset, it is not a per-reading value

At this source revision, every polled frame includes RR and kcal, even before the device has provided either optional field. The initial cache values are RR=0 and kcal=0; the initial heart rate is 60 bpm. Treat all three values as valid only after the device has sent a Heart Rate Measurement notification. A device that omits the optional flags continues to produce zero-valued RR and kcal readings.

Two settings of its own, under HEAT.BluetoothWearableModule:

Setting	Type	Default	Effect
`DeviceID`	string (MAC address)	empty	The Bluetooth device to connect to, in `AA:BB:CC:DD:EE:FF` form. Populated by a scan dropdown in the settings UI; there is no “first available device” fallback, an empty value never matches a real device
`SendAtNativeRate`	boolean	`true`	See Native rate versus polled

Beyond those, it exposes only the generic settings every module has (Enabled, Interval, OverrideNodeId/NodeId, Timeout) - see Manage capture modules.

Native rate versus polled

SendAtNativeRate inverts which of the module’s two code paths is live, not only a speed knob:

true (default): every BLE notification from the device publishes immediately, at whatever interval the strap itself broadcasts on (typically about once per second). HEAT Capture’s own per-tick capture call returns nothing.
false: BLE notifications only update the module’s internal cache; HEAT Capture’s own per-tick capture call is what publishes, using the most recently cached values. Between two ticks with no new notification, the same reading publishes again unchanged.

Limits

One entity, one device. The module connects to exactly the configured DeviceID; it does not support more than one strap at a time.
Only the first R-R interval in a notification is read. A device that batches multiple R-R values per packet loses everything after the first.
No data at all until connected, and no explicit “device lost” event afterward: absence is the only signal.
This module has a live debug view (device name, connection status, and a heart-rate chart) in HEAT Capture’s own interface, not documented here since it is an operational feature of the host application, not part of the published data contract. Use it to confirm a connection is live before trusting an exercise’s data.

Interface Control Document

See Interface control document for Bluetooth discovery, GATT service and characteristic use, notification-field semantics, publication timing and disconnect behavior.