我去年做的一个可穿戴项目，前前后后迭代了三版硬件，踩了不少坑，这篇把完整的技术路径和心得写出来。项目本身是围绕STM32搭建的多生理参数实时监测与预警系统，能同时采集心率、体温、运动状态等数据，在本地完成异常判断并发起预警。适合正在做嵌入式毕业设计、准备电子设计竞赛，或者想从零开始做一款完整可穿戴设备的开发者参考，整篇会覆盖硬件选型、信号链路、低功耗设计、预警策略和实际测试这几个核心环节。
1. 硬件选型与信号链设计的核心取舍
1.1 为什么是STM32，而不是ESP32或其它方案
说起可穿戴设备的主控，很多人第一时间会想到ESP32，毕竟自带Wi-Fi和蓝牙，开发资料也丰富。但这个项目我最终选了STM32L4系列，原因有三点。
第一是功耗。可穿戴设备长时间贴身佩戴，电池不可能做得很大，一颗100mAh左右的锂电池要撑住至少24小时，对主控的待机功耗和运行功耗要求非常苛刻。STM32L4系列在运行模式下电流可以压到100μA/MHz以内，停止模式更是能到微安级别，这是ESP32做不到的。ESP32的Wi-Fi模块虽然平时可以关掉，但它的射频前端和协议栈功耗还是偏大，做低功耗手表这类产品不太合适。
第二是模拟外设。多生理参数采集最核心的环节是把传感器输出的微小模拟信号转换成数字量。STM32L4内置了16位ADC和多个运放、比较器，配合DMA可以直接把采集到的数据搬进内存，CPU几乎不参与。这类高精度模拟采集能力，是很多通用MCU不具备的。
第三是生态。STM32的CubeMX加HAL库开发效率很高，芯片型号切换也方便。而且这个项目涉及多路传感器、无线模块、OLED显示，各种外设资源要同时跑，STM32的中断优先级管理和定时器资源足够丰富，后期扩展功能时心里有底。
1.2 传感器选型：每一路信号的来源
这套系统一共采集三路生理参数：心率、体温、运动状态。每一路传感器都经历过对比和替换，我把最终方案和备选方案一并列出来。
| 参数 | 最终选型 | 备选方案 | 选择理由 |
|---|---|---|---|
| 心率/血氧 | MAX30102 | 反射式PPG传感器、胸带式ECG | 模块体积小，I2C接口，绿光+红外双波长，抗运动干扰能力比单波长强 |
| 体温 | NTC热敏电阻(100kΩ) | DS18B20、红外热电堆 | NTC响应速度快，线性度可通过查表修正，功耗极低，成本几毛钱 |
| 运动姿态 | LSM6DS3 | MPU6050、ADXL345 | 六轴一体，内置DMP可输出步数等算法结果，功耗比MPU6050低15%左右 |
这里多说一句心率传感器的坑。MAX30102在国内很容易买到，但市面上水货很多，部分芯片的寄存器地址和读出的数据跟正品有差异。我后来直接在立创商城买带编带的原装货，虽然贵一点，但省去了排查异常数据的痛苦。如果是做毕业设计，建议优先在正规渠道购买，某宝上散装芯片十片有八片数据不太对劲。
体温测量我放弃了DS18B20，原因是它温度分辨率虽然高，但不适合做皮肤接触式测温。DS18B20是不锈钢封装的话热容太大，测量皮肤表面温度时响应很慢，而且贴紧程度不同读数差异很大。最后用了贴片NTC，直接压在PCB的铜箔焊盘上，再通过导热硅胶垫接触皮肤，实测响应时间能控制在两秒以内。
1.3 整体硬件架构和各模块的连接关系
整个系统的硬件拓扑是一个典型的嵌入式数据采集链路：传感器作为信号源，STM32作为数据汇聚和处理中心，OLED做本地显示，蓝牙模块负责与手机通信，蜂鸣器加LED做本地预警。
MCU用的是STM32L431RCT6，256KB Flash、64KB SRAM，对这套系统来说绰绰有余。传感器I2C总线上挂了MAX30102和LSM6DS3，体温NTC通过电压采样电路接到ADC引脚。电源部分用了TP4056充电芯片加XC6206 LDO，把锂电池电压稳定到3.3V。
有一个设计细节我觉得做得比较满意：把传感器的模拟地和数字地做了单点连接，避免数字信号噪声串进模拟采集链路。可穿戴设备PCB面积小，地平面往往只有一整块，但心率信号峰值只有几微安级别的光电流转换而来，对噪声非常敏感。我在这上面吃过亏，第一版PCB信号噪声大得离谱，示波器一看波形全是锯齿，后来把传感器底部做了开槽隔离才好转。
2. 三路生理参数的数据采集实现细节
2.1 心率采集：从PPG原始波形到BPM计算
PPG信号（光电容积脉搏波描记法）的原理不复杂：LED发出的光穿透皮肤组织，被血液部分吸收后，光电二极管接收到反射光强信号。心脏搏动时血管容积变化，导致接收光强产生周期性波动，这个波动的频率就是心率。
MAX30102内置了红光（660nm）和红外光（940nm）两个LED，我的做法是用红外光作为主信号源。红外光对皮肤色素不敏感，穿透深度更深，在肤色较深的人身上表现更稳定。红光通道留着做血氧计算，这个项目没有对血氧精度做临床级要求，所以暂时只用了红外通道。
采集逻辑上用定时器触发DMA连续读取FIFO，每50ms读取一次，积累到256个采样点做一轮处理。数据处理流程分四步：滑动平均去高频噪声、去除基线漂移、峰值检测、计算瞬时心率。
峰值检测我用的是自适应阈值法。具体来说就是维护一个滑动窗口，取窗口内的最大值和最小值的中间值作为动态阈值，信号上升沿跨过阈值时记一次心跳。这个办法比固定阈值鲁棒很多，因为PPG信号的幅值会随着佩戴松紧、运动状态剧烈变化，固定阈值要么漏检要么误检。
一个实际的例子：静坐时红外PPG信号的峰值电压大约在200mV左右，但稍微走动一下，运动伪迹产生的基线漂移就能达到500mV以上。如果不做基线漂移去除，峰值检测算法会把这些漂移误认为心跳信号，算出来的心率直接飙到150以上。
2.2 体温采集：NTC查表法和滤波处理
NTC热敏电阻的阻值随温度非线性变化，我用的100kΩ规格在25℃时阻值是100kΩ，温度系数大约是-4.4%/℃。为了把电阻变化转成电压信号，我搭了一个简单的分压电路：3.3V电源串联一个100kΩ精密电阻，再串NTC到地，从两个电阻的连接点取电压。
ADC采到的电压值经过下面公式换算成电阻值：
R_ntc = R_ref × (V_ref - V_out) / V_out
拿到电阻值之后通过查表法换算成温度。我在代码里建了一张-20℃到60℃、精度0.1℃的NTC分度表，总共801个点，占用不到1KB的Flash。查表时用二分查找，找到相邻两个温度点的区间，再线性插值出精确温度。
实际测试下来这个方案的测量误差能做到±0.2℃以内，跟水银体温计对比过，满足日常体温监测需求。
滤波方面我用了滑动平均加一阶低通滤波双保险。NTC本身热质量小，容易受到环境温度波动的影响，一段30秒的采样数据如果不做滤波，可以看到明显的随机抖动。滑动平均窗口取16个点，一阶低通的系数取0.8，实测滤波后数据平滑很多，响应速度也不会有明显延迟。
2.3 运动姿态采集：加速度计数器的低功耗处理
LSM6DS3的配置上，我把加速度量程设成±4g，采样率设成52Hz。这个采样率是经过计算的：人体日常运动的频率主要集中在0.5Hz到20Hz之间，52Hz的采样率足以覆盖有效频段，同时功耗只有0.4mA左右。
运动状态判断用了一个非常简单的算法：每秒钟计算一次加速度向量的模长平方，公式是a² = x² + y² + z²。静止状态下模长平方约等于1g²（因为只有重力加速度），一旦人开始走动或者跑动，模长会明显偏离这个值。
设定两个阈值来判断状态：A² < 1.1时判定为静止，1.1 ≤ A² < 1.8时判定为轻微活动，A² ≥ 1.8时判定为剧烈运动。这套判断在普通行走、上楼、慢跑等场景下实测准确率大概在八成左右，作为状态判断已经够用。
更精细的计步算法其实可以依赖LSM6DS3内置的计步功能，它内部有个步数计数器，走一步加一。但实测下来这个内置计步器在慢走时偶尔会漏步，所以我最后还是在MCU端自己实现了步数检测，做法是对加速度波形做峰值检测加零交叉计数，每检测到一个完整的波峰波谷且幅值超过阈值才算一步。
3. 预警系统的算法设计：阈值、判定与去误报
3.1 多参数联合判定：单一参数容易误报，组合起来才靠谱
预警系统最核心的难点不是"阈值设多少"，而是"怎样减少误报"。只盯着心率一个指标，血压偏高的人稍微走两步心率就上100，如果100次/分钟就报警，那系统几乎每分钟都在响。
我的做法是采用多参数联合判定逻辑。只有当心率、体温、运动状态三个维度同时满足异常条件时，系统才触发预警。判定规则用了一张状态表来表达。
| 运动状态 | 心率异常阈值 | 体温异常阈值 | 预警等级 |
|---|---|---|---|
| 静止 | 静息心率超过100或低于50 | 体温超过37.5℃或低于35.5℃ | 中级预警 |
| 轻微活动 | 心率超过140 | 体温超过38.5℃ | 中级预警 |
| 剧烈运动 | 心率超过180 | 无 | 低级别提醒 |
这个表的设计思路是：静息状态下心率阈值设得比较严格，因为正常情况下静息心率在一个窄范围内波动；运动状态下心率本来就该升高，所以阈值放宽到对应运动强度下的预期心率区间。
实现上，运动状态判定模块的输出会传到一个状态机，预警判定逻辑每秒钟执行一次。只有当异常情况持续超过30秒才真正触发预警，短于30秒的偶发抖动一律忽略掉。这个30秒的延迟窗口对减少误报帮助极大，实测下来误报率至少下降了七成。
3.2 心率变异性特征作为预警的辅助维度
除了绝对阈值，我还加了一个心率变异性（HRV）的分析维度。HRV是指相邻两次心跳之间时间间隔的波动情况，医学上认为HRV降低往往意味着身体处于应激状态或者过度疲劳。
具体实现是记录最近60次心跳的RR间期（相邻R波之间的时间间隔），计算标准差和均方根差值。当标准差连续两分钟低于某个阈值，同时心率又超过正常范围，系统会给出"疑似疲劳状态"的提示。
这个功能实现起来不复杂，但非常加分。比如一个用户静坐时心率80，不算异常，但HRV指标明显下降，说明他的自主神经调节状态可能有问题。这种"看图说话"式的联合分析，比单纯看心率高低有价值得多。
3.3 预警响应的分级设计与防抖机制
预警不是一触即发，我设计了三级响应机制：
- 提醒级别：OLED屏幕闪烁显示异常参数，蜂鸣器短鸣一次，信息通过蓝牙推送到手机App。
- 中级预警：OLED持续显示异常提示，蜂鸣器每5秒响一次，手机App持续推送通知。
- 高级预警：蜂鸣器连续鸣响，系统自动通过蓝牙向预设联系人发送紧急通知消息。
防抖机制除了前面提到的30秒确认窗口，还有一个"冷却时间"设计。同一种类型的预警触发后，5分钟内不会再次触发同级别预警，防止设备在异常状态持续存在时反复报警导致用户麻木。这个设计在真实使用中很实用，我戴着手环做测试的那段时间，如果没有冷却时间设计，光是心率偶尔波动就会让手机响个不停。
4. 低功耗设计：续航才是可穿戴设备的第一竞争力
4.1 功耗预算表：每一毫安电流都要精打细算
可穿戴设备能不能被用户接受，续航能力是决定性的。我给自己定的目标是：100mAh电池，持续工作24小时以上。为了实现这个目标，我首先做了一张完整的功耗预算表。
| 硬件模块 | 工作电流 | 占空比 | 平均电流 |
|---|---|---|---|
| STM32L431运行模式 | 4.8mA @ 16MHz | 50% | 2.4mA |
| MAX30102心率传感器 | 0.6mA | 20% | 0.12mA |
| LSM6DS3加速度计 | 0.4mA | 100% | 0.4mA |
| NTC分压电路 | 33μA | 100% | 0.033mA |
| OLED显示屏 | 18mA | 10% | 1.8mA |
| BLE蓝牙模块 | 8mA | 5% | 0.4mA |
| LDO静态电流 | 1μA | 100% | 0.001mA |
| 系统总平均电流 | - | - | 约5.15mA |
注意OLED显示屏是整个系统最大的耗电来源，虽然它只在显示时工作18mA，但10%的占空比就占了平均电流的1.8mA。为了进一步压低这块功耗，我把屏幕刷新率降到1Hz，同时只刷新变化的区域。正常显示状态下，一块屏幕每秒钟需要的电流大约只有静态全亮刷新时的三分之一。
按照5.15mA的平均电流计算，100mAh电池的理论续航是19.4小时，不够24小时的目标。所以还需要做进一步优化。
4.2 动态电源管理：让MCU在99%的时间里睡觉
进一步优化核心思路是让STM32进入低功耗模式。具体做法是把系统改成事件驱动模式：正常情况下MCU进入STOP2模式，电流只有1μA左右，然后通过RTC闹钟每500ms唤醒一次，处理完数据又睡回去。
RTC唤醒周期内的工作流程是这样的：唤醒后先读取加速度计数据判断是否发生运动，如果有运动就进入全速模式采集心率；如果静止，则把心率采集的间隔拉长到5秒一次，体温每10秒采一次。
这个策略的依据是：人在静坐或者睡眠时生理参数变化缓慢，没必要以100Hz的频率连续采集，中等频率采样完全够用。而在运动状态下，心率变化快，需要连续监测，所以动态调整采样率。
优化后系统功耗模型变为：配置模式下CPU使用率不足1%，系统绝大多数时间处于低功耗睡眠状态。实测下来，100mAh电池的续航从19.4小时提升到了30小时以上，最初设定的24小时目标顺利达成。
4.3 传感器和蓝牙模块的供电开关设计
传感器和BLE蓝牙模块是除了MCU之外的另外两个耗电大头。MAX30102内部LED的驱动电流是可以配置的，我把它从默认的50mA降到了20mA，配合合适的透光率，在手腕上依然能采到有效信号。这样MAX30102在工作模式下的电流从0.6mA降到了0.25mA。
蓝牙模块我用了BLE 4.2协议的透传模块，工作电流8mA左右。BLE协议本身支持广播间隔和连接间隔的动态调整，在静止状态下我把广播间隔拉长到1000ms，连接间隔拉到100ms，这样平均电流可以压到0.1mA左右。一进入预警状态，再把广播间隔调到100ms，确保手机能第一时间收到消息。
还有一个细节：NTC分压电路虽然静态电流只有33μA，但它是常开的。我加了一个MOS管做电源控制，在MCU深度睡眠期间把分压电路的电源也断掉，又省了一部分电流。这类"看起来很小但积累起来很可观"的电流开销，在可穿戴设备里比比皆是，每省下一毫安，续航就多一份保障。
5. 数据链路与上位机：本地显示、手机推送与云端存储
5.1 蓝牙通信协议设计与数据帧格式
可穿戴设备和手机之间要交换的数据类型很杂，有心率、体温、运动状态、预警事件、设备状态等。如果只是简单地把所有数据拼在一起发送，解析端会很痛苦。所以我在数据链路层设计了一套轻量级的帧格式。
帧格式如下：
| 字段 | 长度 | 说明 |
|---|---|---|
| 帧头 | 1字节 | 固定为0xAA |
| 数据类型 | 1字节 | 0x01心跳数据，0x02状态数据，0x03预警事件 |
| 数据长度 | 1字节 | 数据域字节数 |
| 数据域 | N字节 | 具体数据 |
| 校验和 | 1字节 | 数据域累加和的低8位 |
校验和用于检测数据传输过程中的错误。BLE传输偶尔会出现丢包，加了校验之后接收端可以识别出坏帧并请求重传。
预警事件帧的数据域我定义成这样：第一个字节是预警等级，第二个字节是预警类型（1心率异常、2体温异常、3运动状态异常），后面跟着具体数值和时间戳。这样手机端收到预警事件后，可以直接根据类型弹出对应的通知文案。
5.2 手机端数据展示与本地日志存储
手机端我用的是Android平台的简单App，通过系统的BLE API与设备通信。App的功能分成三块：实时数据展示、历史数据曲线、预警消息管理。
实时数据展示部分用一个自定义View画折线图，每收到一帧数据就更新曲线并显示最新数值。历史数据先缓存在手机本地SQLite数据库里，这样即使不联网也能查看过去七天的心率变化趋势。预警消息管理会单独放一个列表，标记每次预警的时间、类型和当时的三项参数值。
BLE通信这块有个容易踩的坑：Android的BLE API在连续收发小数据包时偶尔会出现"Gatt status 133"连接断开的问题。这个错误通常是因为底层在短时间内收到了太多数据，超过了协议栈的处理能力。我在代码里把发送间隔限制到50ms以上，每次只发20字节以内的数据，问题就消失了。
5.3 数据上云：可选的进阶功能
本地存储的问题在于数据不能远程查看。我给系统预留了Wi-Fi模块的接口，通过ESP-01S模块和MQTT协议将采集到的数据上传到公共MQTT服务器。这样手表周围5公里内通过手机App可以远程看到家里老人的实时体征数据。
MQTT的主题设计成按设备ID和设备类型分层的结构，比如"device/{id}/heartrate"和"device/{id}/alert"。服务器端用Node-RED做一个简单的订阅程序，实时转发到网页仪表盘上。
这部分的功耗会比只开蓝牙高出不少，所以做成可配置项，默认关闭。只有需要远程监控时才在手机App里手动打开。
6. 整机测试与问题排查：实测数据、典型故障与解决思路
6.1 正常佩戴场景下的实测数据
设备完成之后，我戴在手腕上进行了48小时的不间断测试，记录了三组典型的实测数据。
静坐状态下，心率稳定在68-75次/分钟之间，运动状态切换时心率从70左右逐渐上升到100左右。体温数据在36.3-36.8℃之间波动，符合正常人体体温范围。运动状态下心率从120回到静息值约需要2-3分钟，这个恢复速度说明心率监测模块的响应比较及时。
我特意测试了一个"异常预警"的场景：连续做高抬腿运动两分钟，让心率冲到150以上，系统在心率超过140并持续30秒后触发中级预警，OLED弹出红色警告图标，手机端同步收到推送。整个过程从心率越线到预警响应，延迟大约35秒（包含30秒确认窗口和传输延迟），符合设计预期。
6.2 信号质量问题的完整排查链路
第一版样机在验证阶段出现了一个典型的信号质量故障：心率数据时有时无，静止状态下也无法稳定采到有效波峰。排查过程花了整整两天，我把完整链路写出来，供大家参考。
第一步怀疑传感器本身。用示波器监控I2C引脚，发现传感器能正常应答，数据能够读取，但FIFO里读出的原始光强数据幅值极低，几乎只有正常值的三分之一。这说明问题出在光路环节。
第二步检查透光结构。排查发现，我用的手环外壳是深色半透明硅胶，对红外光有较大的吸收。把外壳拆掉之后，原始信号幅值立刻恢复到了正常水平。
第三步验证后发现还有一个隐藏问题。传感器与皮肤贴合面留了0.5mm的缝隙，环境光直接射进了传感器，导致基线漂移严重。解决方案是在传感器周围加一圈遮光泡棉，让传感器紧贴皮肤，同时排除环境光干扰。
这个排查过程告诉我一个道理：PPG模块的光路设计和电路设计同样重要，甚至更重要。传感器周围哪怕只有一条细小的漏光缝隙，都会对信号质量产生毁灭性影响。可穿戴设备的外壳设计阶段就要把光学窗口和贴合结构纳入考虑，不能等硬件做完了再补救。
6.3 系统级联调时的线程优先级问题
软件联调阶段遇到一个隐蔽的Bug：心率采集偶尔会丢数据，排查后定位到是SPI和I2C的中断优先级配置问题。LSM6DS3的SPI中断优先级高于MAX30102的I2C中断，在高数据速率下，SPI中断频繁抢占I2C中断的时序，导致I2C通信偶尔失败。
处理方式是把I2C中断优先级提到最高，SPI中断降一级，同时在两个外设的DMA中断服务函数里加入互斥判断，避免同一时间两个DMA同时访问内存缓冲区。
这类问题很难通过查阅数据手册发现，只有在真实系统里跑高频数据流时才会暴露。调试时推荐用逻辑分析仪同时抓取两路总线的波形，对比看看是否存在总线冲突，定位效率会高很多。
7. 项目可扩展方向与个人经验总结
这套系统基本功能已经跑通，但距离"产品"还有不少距离。如果大家想在这个基础上继续深入，我列出几个我认为最有价值的扩展方向。
第一个方向是提升算法的临床价值。目前的心率算法、HRV分析都还只是"能跑"的程度，距离医疗级的准确度和可靠性还有差距。接入更复杂的信号处理算法，比如基于小波变换的伪迹去除、基于机器学习的运动状态识别，可以让预警系统的准确率提升一个台阶。
第二个方向是引入更多传感器。血氧饱和度（SpO2）、血压趋势、皮肤电导率（GSR）都是很容易集成进去的生理参数。MAX30102本身就支持红光和红外光双波长，只需在算法上增加一个光密度比计算，就能输出血氧值。
第三个方向是结构设计的优化。我用的是3D打印的外壳加上弹性表带，体积和重量控制得不算好。如果做到接近主流手环的尺寸，需要在PCB堆叠、电池形态、传感器布局上做更精细的规划。
最后说一个我在整个项目中感受最深的地方：可穿戴设备和普通嵌入式项目最大的区别在于，它的每一个子系统都要同时满足功能、功耗、体积三个维度上的约束。采集到信号不难，难的是在微安级电流预算内持续稳定地采集信号；做一个功能模块不难，难的是把它塞进一小块PCB上；实现一个算法不难，难的是让它在低功耗处理器上实时运行。做这个项目的过程中，我在这三个约束之间反复权衡、反复妥协，最终找到一套还算平衡的方案。这种"戴着镣铐跳舞"的训练，对理解嵌入式系统设计的本质帮助非常大。
