从一个真实的烦恼开始

我买 Polar H10 胸带,是因为它是目前消费级市场上 RR 间期精度最高的设备之一。但用了没多久,我发现自己陷入了一个奇怪的困境:

每天晚上睡前,要打开 Polar Flow 点"开始记录";早上醒来,再点"结束",然后跳去另一个 App 看 HRV 数据,再手动对比时间线。几天后,我就放弃了。

问题不是 H10 不好,而是整套流程需要人配合设备,而不是设备配合人。睡眠监测这件事,天然要求零干预——你不可能半睡半醒地去点"开始睡觉"。

于是我决定自己做一套。

手表的 HRV 为什么不够准

在开始之前,有个问题值得认真回答:为什么不直接用智能手表?现在几乎所有手表都有睡眠监测和 HRV 功能。

答案在于传感器原理的根本差异。

设备类型 测量原理 RR 间期精度 运动干扰
智能手表 / 手环 PPG 光学血流 ± 10 ~ 30 ms 严重
Polar H10 胸带 直接测量皮肤电位(ECG) ± 1 ~ 2 ms 极小

这个精度差距对 HRV 分析是决定性的。以最常用的 RMSSD 指标为例,它统计的是相邻 RR 间期差值的均方根,典型值在 20 ~ 50 ms 之间。如果传感器本身有 ±15 ms 的噪声,分析结果几乎失去意义。

学术界的共识:消费级 PPG 手表的 HRV 数据不适合做严肃的自主神经分析。Polar H10 是运动科学研究中的参考级设备,精度与医院级心电图接近。

ECG、RR 间期与 HRV 的关系

很多人以为 H10 的优势在于它能采集 ECG(心电图原始波形)。这是个常见误解,值得澄清。

ECG 原始波形每秒 130 个采样点,一晚 6 小时理论数据量约 5.6 MB,含文件封装实测在 30~40 MB 左右。临床医生需要这个波形来判断 ST 段抬高(心肌缺血)、QRS 形态(心律失常类型)等。但对于 HRV 睡眠分析,我们需要的只是 R 峰的时间序列,也就是 RR 间期。

ECG 原始波形: ___/\___/\___/\___ ↑ ↑ ↑ ↑ ← R 峰(QRS 波顶点) RR 间期: |←→| |←→| |←→| ← 相邻 R 峰时间差 H10 固件在芯片内部完成 R 峰检测,直接输出 RR 间期。 6 小时 RR 数据总量:约 86 KB(精华已提取,原始波形非必需)

H10 的真正优势是:它用 ECG 级别的精度来定位 R 峰,然后输出 RR 间期。你拿到的是精华,而不是 30~40 MB 的原始波形。

零操作:系统配合人,而不是人配合系统

明确了数据来源之后,核心设计原则只有一条:佩戴即采集,脱下即结束,中间不需要任何操作。

实现这个目标,需要处理几个细节问题:

自动识别佩戴状态。H10 通过 BLE 广播心率数据,当胸带离开皮肤,心率信号会消失。系统监听 BLE 连接状态 + 心率数据流,组合判断是否真正处于佩戴状态,避免 BLE 抖动产生虚假的穿脱事件。

睡眠会话自动识别。连续佩戴超过 3 小时,且平均心率低于日间基线,系统自动标记为睡眠会话,触发 HRV 深度分析。

晨间报告自动发送。早上 10 点,邮件送达:昨晚睡眠 HRV 摘要、最优 5 分钟窗口(通常对应深睡眠阶段)、恢复状态评估。不需要打开任何 App。

为什么选择树莓派,而不是云服务器

这个问题在商业化设计上值得认真对待。

云服务器方案的问题不只是成本,更在于数据主权。健康数据,尤其是连续的心率变异数据,是高度私密的生物特征信息。用户有理由不希望这些数据离开自己的家。

另一个问题是网络延迟。BLE 采集是实时的,如果把数据通过网络发送到远端处理再返回,增加了不必要的故障点,也牺牲了离线可用性。

最终选择的架构: ┌─────────────────────────────────┐ │ 卧室 树莓派 5 │ │ │ │ BLE ←────── Polar H10 │ │ ↓ │ │ 采集 + 存储 + HRV 分析 │ │ ↓ │ │ 本地 Web 仪表板(局域网访问) │ │ ↓ │ │ 邮件晨报(唯一的外网依赖) │ └─────────────────────────────────┘ 原始数据永远在本地。 用户可自选:是否将数据导出给 AI 做进一步分析。

树莓派 5 的性能远超这个任务的需求,体积约一张信用卡大小,放在床头柜完全不突兀。BLE 天线就在卧室里,信号稳定性最优。

多卧室场景的自然扩展

如果一个家庭有多个卧室——夫妻分房,或者需要监测老人睡眠——树莓派一体机方案就显得笨重了。这时候,分体设计更合理:

卧室 A 卧室 B ┌──────────┐ ┌──────────┐ │ BLE 网关│ │ BLE 网关│ │ (ESP32) │ │ (ESP32) │ └────┬─────┘ └────┬─────┘ │ 局域网 │ 局域网 └──────────┬─────────────┘ ↓ ┌──────────────┐ │ 中央服务器 │ │ (书房/机房) │ └──────────────┘

ESP32-S3 作为 BLE 网关,成本约 50 ~ 80 元/台,每个卧室放一个,负责采集和转发 RR 数据。中央服务器(可以是用户已有的 NAS 或小主机)负责分析和存储。这套架构特别适合养老场景——一台服务器,监测全家老人的睡眠状态。

数据说明

以下是实际采集的数据样本,供参考:

指标 睡眠期均值 日间均值
平均 RR 间期 1063 ms(≈ 56 bpm) 921 ms(≈ 65 bpm)
RMSSD 42 ms 49 ms
SDNN 87 ms 72 ms
pNN50 15 % 22 %
RR 异常跳变率(> 30%) 0.20 %(数据质量良好)

几点设计原则的总结

回头看,这个项目的核心不是技术有多复杂,而是几个设计选择的坚持:

精度优先于功能数量。H10 的 RR 间期精度是整套系统的根基,如果换成光学手表,其他所有分析都失去意义。

用户零操作是硬性约束。任何需要用户主动触发的流程,在睡眠场景下都会失败。系统必须自己判断何时开始、何时结束。

数据主权不能妥协。原始生物特征数据留在本地,是对用户隐私最起码的尊重。云端只接收用户主动选择发送的摘要。

架构跟随场景扩展。单卧室用一体机,多卧室用分体设计,同一套核心逻辑,两种部署形态,互不冲突。

这套系统目前仍在持续迭代。如果你对本地化健康数据分析、智能家居系统集成,或者类似的项目有想法,欢迎通过咨询页面交流。