📚 课程目录第4章健康数据常见类型

4、健康数据常见类型：心率、血氧、体温、步数、睡眠、ECG等数据的特征与传输要求

可穿戴设备（智能手表、手环、戒指、贴片等）采集的健康数据在物理特征、采样频率、数据量、实时性要求和容错机制上差异极大。心率数据需要连续监测但单点数据量小，ECG（心电图）数据采样率高且数据量大，血氧和体温数据更新频率低但对精度和抗干扰要求高，步数数据稀疏但需要长时间累积统计，睡眠数据则依赖多传感器融合和分段标注。理解这些差异，是设计蓝牙传输策略（连接间隔、MTU大小、通知频率、缓存策略）的前提。本章将系统梳理六类核心健康数据的信号特征、量化参数、传输需求及典型工程实现路径。

4.1 心率数据：从PPG波形到BLE实时流

4.1.1 核心原理与信号特征

心率数据在可穿戴设备中通常通过两种方式获取：光电容积脉搏波（PPG）和心电信号（ECG）。PPG利用绿光或红光照射皮肤，通过光电二极管检测血液容积变化，其信号频率范围约为0.5~4Hz（对应30~240bpm），采样率通常设为25~100Hz。ECG方式则直接测量心脏电活动，信号幅度为0.5~4mV，频率范围0.05~100Hz，采样率需达到250~512Hz才能保留QRS波群的细节。

从蓝牙传输角度看，心率数据具有“高频采样、低信息密度”的特点。原始PPG波形每秒产生25~100个采样点，每个采样点16bit，即每秒50~200字节。但实际传输时，通常不直接传原始波形，而是由设备端算法提取出瞬时心率值（每搏一次更新一次），再以1Hz的频率通过BLE通知发送。这种“边缘计算+低频传输”的模式，将有效数据量压缩了数十倍。

4.1.2 传输要求与GATT设计

蓝牙心率服务（Heart Rate Service, HRS）是BLE标准服务之一，UUID为0x180D。其核心特征包括：

心率测量特征（0x2A37）：包含心率值（8bit或16bit）、传感器接触状态、能量消耗等字段，支持通知（Notify）属性。
身体传感器位置特征（0x2A38）：描述传感器佩戴位置，只读。
心率控制点特征（0x2A39）：用于重置能量消耗累计值，写入属性。

实际工程中，若需要传输PPG原始波形（用于房颤筛查、HRV分析等），则需自定义服务。此时需注意：连接间隔（Connection Interval）应设置为7.5~15ms以支持高吞吐，MTU扩展至247字节，每个连接事件可发送4~6个通知包。以100Hz采样、16bit精度计算，每秒数据量为200字节，在MTU=247、连接间隔=7.5ms的条件下，理论吞吐率可达约32KB/s，完全满足需求。

  工程经验：心率数据的BLE传输应区分“实时流模式”和“批量同步模式”。实时流模式用于运动时手机端实时显示，采用Notify + 高频率连接间隔；批量同步模式用于全天数据补传，采用Indication + 低频率连接间隔（如100ms），可显著降低功耗。两种模式通过GATT的CCCD（客户端特征配置描述符）动态切换。

4.1.3 案例拆解：运动手环心率实时传输优化

背景与约束：某品牌运动手环需在跑步模式下将心率实时传输至手机APP，要求端到端延迟小于2秒，同时手环电池容量仅90mAh，蓝牙功耗预算为总功耗的30%。

初始现象：采用默认连接间隔50ms、MTU=23字节时，心率数据延迟达到3.5秒，且手环发热明显，续航从7天降至2天。

分析过程：通过BLE抓包工具（如nRF Connect）发现，MTU=23时每个通知包仅能携带1个心率值（2字节），每秒需发送1个包，但连接间隔50ms导致每个包平均等待25ms，加上系统调度开销，实际延迟约200ms。但延迟3.5秒的根因在于：手环端算法每5秒才批量发送一次数据，而非实时推送。

操作步骤：

将MTU扩展至247字节，每个通知包可携带20个心率值（40字节），减少包数量。
连接间隔调整为7.5ms，并启用DLE（数据长度扩展），单包有效载荷提升至244字节。
修改固件逻辑：心率算法每搏更新后立即写入GATT特征并触发通知，而非攒批发送。
增加“低功耗模式”开关：当手机APP退到后台时，自动切换至100ms连接间隔 + 批量同步模式。

结果对比：优化后延迟降至1.2秒，蓝牙功耗占比从45%降至22%，手环续航恢复至5.5天（牺牲部分待机时间换取实时性）。

复盘经验：实时心率传输的瓶颈往往不在BLE物理层，而在应用层的数据攒批策略。设计时应优先保证“每搏必达”，而非“每秒必达”。

4.2 血氧与体温数据：低采样率下的精度保障

4.2.1 血氧饱和度（SpO₂）的信号特征

血氧监测基于双波长PPG原理：红光（660nm）和红外光（940nm）交替照射皮肤，通过两种波长下光吸收率的比值（R值）计算血氧饱和度。由于需要检测微弱的交流分量（AC）叠加在直流分量（DC）上，信号极易受运动伪影和环境光干扰。采样率通常为25~50Hz，但实际输出的SpO₂值更新频率仅为0.5~1Hz。

传输要求方面，SpO₂数据具有“低频率、高可靠性”特征。单次测量值仅需1字节（85%~100%对应0~100），但医疗级应用要求误差小于±2%。因此，BLE传输时建议采用Indication（确认通知）而非Notify，确保数据可靠到达。同时，应附加信号质量标志位（如信噪比等级），供接收端判断数据可信度。

4.2.2 体温数据的采集与传输

可穿戴体温监测分为接触式（NTC热敏电阻）和非接触式（红外热电堆）两种。NTC方案响应慢（时间常数5~30秒），但精度可达±0.1°C；红外方案响应快（<1秒），但易受环境温度影响。体温数据更新频率极低（0.1~0.2Hz），单点数据量仅2字节（16bit，分辨率0.01°C）。

蓝牙传输体温数据时，需注意“连续监测”与“单次测量”的差异。连续监测场景（如发热预警）下，设备每10秒发送一次体温值，采用Notify即可；单次测量场景（如体温计）下，应使用Indication并等待手机端确认，再进入休眠。此外，体温数据通常与心率、活动状态联合分析，建议在GATT服务中设计复合特征，将体温、皮肤导热系数、环境温度打包在一个通知中。

数据维度	血氧 SpO₂	体温 Temp
采样率	25~50Hz（原始PPG）	0.1~1Hz
输出频率	0.5~1Hz	0.1~0.2Hz
单点数据量	1~2字节	2字节
精度要求	±2%	±0.1°C
BLE传输模式	Indication（推荐）	Notify / Indication
关键附加字段	信号质量、接触状态	环境温度、导热系数

风险提示：血氧和体温数据在医疗场景中属于“关键决策数据”，BLE传输层必须启用数据完整性校验（如CRC32）。若使用Notify模式，建议在应用层增加序列号字段，接收端检测到跳号时主动请求重传。切勿为了省电而牺牲这两类数据的可靠性。

4.3 步数与睡眠数据：批量同步与分段标注

4.3.1 步数数据的稀疏事件特征

步数数据由加速度计（通常为3轴，采样率25~50Hz）经过计步算法产生。原始加速度数据量较大（每秒150字节），但经过算法处理后，输出的是“步数事件”——每走一步产生一个计数，或每10秒输出一个累计值。这种事件驱动型数据具有极强的稀疏性：静止时数据量为0，步行时峰值也仅每秒1~2字节。

传输策略上，步数数据适合“批量同步”模式。设备端将步数按分钟或小时粒度累计，存储在本地Flash中，每15分钟或30分钟通过BLE同步一次。同步时，将时间戳+步数值打包为数组，一次通知可携带30~60个数据点。这种方式将蓝牙唤醒次数从每分钟1次降低至每小时2~4次，大幅节省功耗。

4.3.2 睡眠数据的多阶段传输架构

睡眠监测是多传感器融合的典型场景：加速度计检测体动、PPG检测心率和呼吸、可能还有麦克风检测鼾声。睡眠数据分为三个层级：

原始信号层：整晚的加速度波形（25Hz）和PPG波形（25Hz），数据量约50~100MB，仅在需要深度分析时通过Wi-Fi或USB传输。
特征层：每30秒一个epoch的体动强度、心率均值、呼吸率，数据量约2~5MB，适合通过BLE在早晨一次性同步。
结论层：睡眠分期结果（清醒/浅睡/深睡/REM）、睡眠评分、起夜次数，数据量小于10KB，可在用户查看APP时实时拉取。

BLE传输睡眠数据时，建议采用“分段同步 + 断点续传”机制。由于睡眠数据通常在早晨集中同步，此时手机可能不在身边，设备需支持多次连接、分批传输。具体实现时，GATT服务中增加“数据偏移量”特征，手机端每次读取指定偏移后的数据，设备端记录已确认的偏移位置，实现断点续传。

设计建议：步数和睡眠数据共用一个“历史数据服务”（Historical Data Service），通过数据类型字段区分。该服务使用Read + Indication组合：手机端先Read获取数据总长度，再通过Indication逐块读取。这种设计比Notify更可靠，且天然支持断点续传。

4.4 ECG心电数据：高吞吐连续传输的挑战

4.4.1 ECG数据的采样与量化

ECG是健康数据中数据量最大、实时性要求最高的类型。标准12导联ECG采样率为500Hz，每导联16bit，总数据率达8KB/s。可穿戴设备通常只采集单导联或双导联，采样率降至125~250Hz，数据率约0.5~1KB/s。即便如此，连续传输1小时ECG数据仍需1.8~3.6MB，远超心率或血氧的数据量。

ECG数据的BLE传输面临两个核心矛盾：吞吐率限制和功耗约束。BLE 4.2的理论吞吐率为~1.6Mbps（实际约800kbps），BLE 5.0可达2Mbps PHY。但可穿戴设备受限于天线尺寸和电池容量，实际有效吞吐率通常只有理论值的40~60%。

4.4.2 传输架构与压缩策略

针对ECG连续传输，业界普遍采用“分段缓存 + 突发传输”架构：

设备端以125~250Hz采样ECG数据，暂存于内部环形缓冲区（如256KB）。
每5~10秒将缓冲区数据打包为一批（约5~10KB），通过BLE以最大吞吐率突发发送。
发送完成后立即进入低功耗状态，等待下一批数据积累。

这种架构将蓝牙射频的占空比从100%降至20~30%，显著降低平均功耗。同时，可配合无损压缩（如LZ4或自定义差分编码）将数据量再压缩30~50%。差分编码利用ECG信号的相邻采样点高度相关性，仅存储差值（通常只需8bit），大幅减少传输字节数。

// ECG差分编码示例（伪代码）
int16_t prev_sample = 0;
for (int i = 0; i < sample_count; i++) {
    int16_t curr = ecg_buffer[i];
    int8_t diff = (int8_t)(curr - prev_sample);  // 差值范围 -128~127
    tx_packet[i] = diff;
    prev_sample = curr;
}
// 解码端：curr = prev + diff，误差为0（无损）

4.4.3 案例拆解：24小时动态心电记录仪的BLE同步方案

背景与约束：某医疗级单导联心电贴片需连续记录24小时ECG，采样率250Hz，16bit精度。设备内置Flash 128MB，电池容量200mAh，要求BLE同步时间不超过10分钟（用户每天同步一次）。

关键参数：24小时数据量 = 250Hz × 2字节 × 86400秒 ≈ 43.2MB。BLE 5.0 2M PHY理论吞吐率2Mbps，实际有效吞吐率约800kbps（考虑协议开销和重传），即100KB/s。理论同步时间 = 43.2MB / 100KB/s ≈ 432秒 ≈ 7.2分钟，满足要求。

实施过程：

采用BLE 5.0 2M PHY，MTU=247，连接间隔7.5ms，每个连接事件发送6个包。
启用数据长度扩展（DLE），单包有效载荷244字节。
使用差分编码压缩，数据量降至约25MB，同步时间缩短至4.2分钟。
增加断点续传：记录已确认的Flash偏移量，连接中断后从断点继续。

结果与代价：实际同步时间4.8分钟（含重传开销），蓝牙峰值电流15mA，平均电流0.8mA（同步期间），24小时总耗电约19.2mAh，占总电量9.6%。代价是固件复杂度增加，需实现Flash磨损均衡和差分编码/解码。

复盘经验：ECG同步的核心是“压缩率”与“CPU功耗”的平衡。差分编码的CPU开销极低（每样本仅需一次减法和一次移位），但压缩率受信号质量影响——运动伪影严重时差值可能超出int8范围，需设计溢出标志位。

4.5 多数据类型混合传输的GATT服务设计

4.5.1 服务架构原则

实际可穿戴设备通常同时采集多种健康数据，GATT服务设计需遵循以下原则：

按数据特性分组：实时性要求高的（ECG、运动心率）放在一个服务，准实时的（血氧、体温）放一个服务，批量同步的（步数、睡眠）放一个服务。
统一时间戳格式：所有数据特征均携带UTC时间戳（4字节），避免接收端时区换算错误。
优先级管理：当BLE带宽不足时，优先保证ECG和实时心率的传输，血氧和体温可降级为批量同步。

4.5.2 典型服务定义示例

服务名称	UUID	特征	属性	数据格式
实时健康服务	0xFFE0	ECG波形	Notify	差分编码数组，每包20个样本
实时健康服务	0xFFE0	瞬时心率	Notify	uint16 bpm + 信号质量
体征监测服务	0xFFE1	血氧	Indicate	uint8 SpO₂ + uint8 置信度
体征监测服务	0xFFE1	体温	Indicate	int16 温度（0.01°C）+ 环境温度
历史数据服务	0xFFE2	步数历史	Read/Indicate	时间戳+步数数组
历史数据服务	0xFFE2	睡眠分期	Read/Indicate	epoch时间戳+分期标签

4.5.3 常见误区与总结

误区一：所有数据都用Notify实时推送。这会导致BLE信道拥塞、功耗飙升。正确做法是区分实时流和批量同步，按需切换。

误区二：忽略MTU协商。默认MTU=23字节时，单包最多携带20字节有效数据，ECG传输效率极低。必须主动协商MTU至247字节。

误区三：不处理丢包重传。心率数据丢1包影响不大，但ECG丢1包可能导致QRS波群误判。应针对高价值数据启用应用层重传机制。

总结而言，可穿戴健康数据的蓝牙传输设计必须“因数据而异”：心率重实时、血氧体温重可靠、步数睡眠重功耗、ECG重吞吐。工程师应在理解每种数据物理特征的基础上，灵活配置BLE参数（连接间隔、MTU、PHY、通知模式），并善用边缘计算和压缩算法，在有限的无线带宽和电池容量内实现最优的数据同步体验。