咱们平时用的智能手表、运动手环这些穿戴设备，测心率是核心功能之一，但不少人都遇到过：跑步的时候，明明自己心跳跳得快，设备显示的心率却忽高忽低，甚至好几秒没数据——这就是心率数据断了，本质是从传感器拿到数据到蓝牙发给手机的过程中，耽搁得太久，中间的数据没传过来。
一、为什么穿戴设备的心率数据会断
1.1 采样端的“攒数据”坑
很多穿戴设备为了省电，会在采样环节故意攒数据，比如每采10次再打包发送，这样一来中间9次的心率波动就全丢了。还有采样频率设得太低，比如1Hz的频率，每秒才取1个值，根本跟不上最高200次/分的心率变化，自然会断档。
1.2 蓝牙上报的“等时机”坑
蓝牙给手机发心率数据时，要遵循一套叫GATT的传输规则，不少设备会设成“攒够一定数据再发”，或者等蓝牙和手机的下一次通信机会再传，这一耽搁就是几百毫秒，中间的心跳数据就丢了。还有蓝牙和手机的同步间隔（专业叫连接间隔）设得太松，比如每100毫秒才同步一次，数据要等100毫秒才能发出去，时延直接拉满。
二、怎么把采样到上报的时延压下来
2.1 采样端：不攒数据，固定频率采
这里用新手友好的Arduino平台搭配智能手表常用的MAX30102光学心率传感器，核心优化是不缓存数据，固定频率采样，代码示例如下：
// 技术栈：Arduino Uno + MAX30102光学心率传感器
#include "MAX30105.h"
#include "heartRate.h"
MAX30105 hrSensor;
const int SAMPLE_RATE = 10; // 采样频率10Hz，每100ms采1次，刚好覆盖心率变化精度
unsigned long lastSampleTime = 0; // 记录上一次采样时间，确保不超频率
void setup() {
Serial.begin(115200);
// 初始化传感器，找不到就停在这，避免后续报错
if (!hrSensor.begin(Wire, I2C_SPEED_STANDARD)) {
Serial.println("没找到心率传感器，请检查接线！");
while(1);
}
// 调整传感器参数：绿光亮度平衡功耗和采样质量，不用调太亮（费电）
hrSensor.setPulseAmplitudeGreen(0x18); // 绿光为核心采样光源，占比高
hrSensor.setPulseAmplitudeRed(0x10); // 红光辅助，亮度稍低
}
void loop() {
// 严格按10Hz采样，不攒数据，采完直接用，不存数组缓存
unsigned long currentTime = millis();
if (currentTime - lastSampleTime >= (1000 / SAMPLE_RATE)) {
lastSampleTime = currentTime;
// 读取当前的原始PPG数据，不保存，直接用于心率计算
long irData = hrSensor.getIR();
// 检测到脉搏就触发上报准备，跳过缓存环节，减少时延
if (checkForBeat(irData) == 1) {
// 这里是上报触发的钩子，后续会对接蓝牙发送逻辑
}
}
}
这段代码的核心逻辑是：采样后不攒数据，每次仅用当前值，既保证10Hz的精度，又不会因为缓存增加时延——要是改成攒10次再发，时延直接拉到1秒，肯定断档。
2.2 蓝牙上报端：不攒数据，调整连接参数
这里用穿戴设备常用的nRF52832低功耗芯片优化GATT上报逻辑，核心是每次有数据就发，缩短蓝牙同步间隔，代码示例如下：
// 技术栈：nRF SDK v15.3 + BLE心率服务（GATT标准实现）
#include "ble_hrs.h"
ble_hrs_t heartRateSvc; // 心率服务实例，符合蓝牙GATT规范
uint16_t connHandle = BLE_CONN_HANDLE_INVALID; // 蓝牙与手机的连接句柄
const uint16_t TARGET_CONN_INTERVAL = MSEC_TO_UNITS(20, UNIT_1_25_MS); // 目标连接间隔20ms
// 直接上报当前心率，不缓存批量数据
static void sendLatestHeartRate(uint8_t bpm) {
if (connHandle != BLE_CONN_HANDLE_INVALID) {
ret_code_t err;
ble_hrs_meas_t measData;
// 填充心率数据：仅当前值，无多余缓存
measData.heartRateBPM = bpm;
measData.flags = BLE_HRS_MEAS_FLAG_HEART_RATE_VALUE;
measData.energyExpended = 0;
// 触发GATT通知，直接发送，不延迟
err = ble_hrs_heart_rate_measurement_send(&heartRateSvc, &measData);
if (err != NRF_SUCCESS && err != NRF_ERROR_INVALID_STATE) {
// 处理连接断开或错误，后续重连即可
}
}
}
// 调整蓝牙连接参数，缩短同步时延
static void updateConnParams() {
ble_gap_conn_params_t connParams;
memset(&connParams, 0, sizeof(connParams));
connParams.min_conn_interval = TARGET_CONN_INTERVAL; // 最小连接间隔20ms
connParams.max_conn_interval = TARGET_CONN_INTERVAL + MSEC_TO_UNITS(20, UNIT_1_25_MS);
connParams.slave_latency = 0; // 关闭从机延迟，确保每次同步都响应
connParams.sup_timeout = MSEC_TO_UNITS(200, UNIT_10_MS); // 超时时间，避免断连
sd_ble_gap_conn_param_update(connHandle, &connParams);
}
这段代码把蓝牙连接间隔从默认的100ms降到20ms，手机每20ms就能收到一次数据，时延直接从100ms降到20ms左右，基本不会出现数据断档。
三、实际用的时候要注意的坑
3.1 技术优缺点
优点：优化后心率数据连续性提升，时延从几百ms降到几十ms，跑步、高强度运动时的数据不会断，监测结果更准确；缺点：10Hz采样和20ms连接间隔会比默认设置多耗一点电，比如原本能用10天的设备，现在大概用7-8天，不过可以通过其他优化（比如传感器非采样时段休眠）补回功耗，普通用户完全能接受。
3.2 避坑要点
第一：采样频率不要设太低，低于5Hz会错过心率波动的细节，也不要设太高（比如50Hz），会白白增加功耗；第二：绝对不要攒数据再发，哪怕是攒2个数据，也会把时延拉到几十ms，容易断档；第三：蓝牙连接间隔不要超过50ms，超过的话时延会明显上升，20-30ms是最合适的平衡点；第四：GATT传输的最大数据量（MTU）不要设太大，设128字节就够，心率数据很小，大了反而要分包，增加不必要的时延。
四、总结
要保障穿戴设备心率数据的连续性，核心就是从采样和蓝牙上报两个环节压缩时延：采样端不攒数据，设10Hz左右的固定频率；蓝牙上报端每次有数据就发，把连接间隔设成20ms左右，平衡功耗和数据连续性。普通用户的智能手表、专业运动手环都可以这么优化，彻底解决心率数据断档的问题，让健康监测和运动分析的结果更准确。
评论
围绕“低功耗蓝牙在穿戴设备上心率数据连续性保障：从采样到GATT上报的时延控制”参与讨论