做可穿戴设备开发这几年，有个场景我碰到过很多次：方案选型会上，一提到 Python、MicroPython，就有同事下意识摇头，觉得这东西是“玩具语言”，写写网页脚本还行，碰硬件不靠谱。但这个项目，我偏要用 Python 生态把一套可穿戴设备实时心率监测系统从零做出来，而且最终跑在了 MicroPython 的单片机上，整机续航也达到了预期。

这篇复盘会从项目定位开始聊，把硬件选型、软件架构、信号处理算法、实时性优化和最后踩过的坑一条条说清楚。适合谁看？如果你正准备做智能手环、心率胸带，或者只是想在常见的联网开发板上体验一把“用 Python 写医疗级算法”的滋味，这篇能帮你少走不少弯路。文章不会有过度包装的设计图，只讲实测过的东西，附带的代码也是能直接抄作业的简化实现。

1. 项目定位与总体设计思路

1.1 为什么敢用 Python 和 MicroPython 做心率监测

先回答一个最现实的问题：为什么不老老实实用 C 写。

C 当然是嵌入式的主战场，功耗、实时性、底层寄存器访问它都能做到极致。但心率监测这个场景有个特点——它的信号频率不高，原始采样率通常只有几十到几百赫兹，真正吃性能的不是“采”，而是“算”：滤波、峰值检测、心率区间估计，这些算法大部分时间花在开发调试和参数调整上。智能硬件更新换代越来越快，项目迭代周期被压得越来越短，谁能快速验证算法、快速改参数，谁就能在有限的时间里多做几轮优化。

MicroPython 在带无线功能的联网开发板上，I2C 读取、定时器中断、GPIO 操作都能直接通过模块调用，开发效率比 C 高一个量级。我在项目里把绝大部分算法先用桌面版 Python 跑通，验证了逻辑，再用 MicroPython 在板子上复现，两边的语法几乎一致，迁移成本极低。再加上 MicroPython 的 REPL 交互环境，现场调参、临时打印波形，比反复编译烧录痛快太多。

这套方案不是没有代价。MicroPython 的浮点运算比 C 慢，解释执行的实时性也差一些。但只要把任务拆开：低速的显示刷新放主循环，中速的传感器读取用定时器回调，真正的高频采样交给传感器内部的 FIFO 硬件完成，性能短板就能绕过去。这也是这个项目里最值得聊的思路之一。

1.2 设计目标先行：先定性能边界再动手

动手之前，我先给系统定了几条硬指标，免得做一半变成“能用但说不清能用到什么程度”的东西。

第一，心率测量范围覆盖 30 到 220 BPM。这个范围不是拍脑袋定的，它基本覆盖了从睡眠状态到高强度运动的大部分人群场景。换算成信号特征，意味着算法要能在相邻两次心跳间隔从 0.27 秒到 2 秒之间都稳定工作。

第二，显示刷新延迟不超过 2 秒。实时心率监测如果屏幕上跳一个数字要等好几秒，体验就完全塌了。这里的心率刷新不需要做到毫秒级，因为心率本来就是一个动态变化的生理指标，带有一定惯性反而更像真实手环的体验。

第三，设备能够用 400mAh 锂电池在连续监测模式下坚持至少 8 个小时。这个目标直接决定了后面传感器 LED 电流、采样率和屏幕刷新策略怎么选，也决定了系统不能无脑跑满功耗。

这三条目标都是可以验证的：第一条用模拟波形和真实佩戴交叉验证，第二条用秒表实测，第三条用功耗仪记录。有了边界，设计时才不会什么都想要却什么都没做好。

1.3 三个关键取舍

项目里最核心的取舍有三处，先放在前面说。

选型上放弃专用心率芯片，选择通用 PPG 传感器。市面上很多心率模组把算法也固化了，开发省事，但可定制性差。我想自己控制算法，所以选的是能输出原始光电容积脉搏波数据的传感器。这正是整个项目“发散创新”的核心点：算法自主，才能不断迭代。用 Python 生态做数据分析和算法验证，再落到 MicroPython 里执行，整条链路都掌握在自己手中。

显示上不追求大屏，选择 128 像素宽的小 OLED。心率监测的核心信息量其实很小，一个数字加一点状态提示就够。小屏省电、省空间，也减少了 UI 复杂度。

系统架构上采用“传感器 FIFO + 应用层算法”而非“全程软件采样”。PPG 传感器内部自带 32 深度 FIFO，可以缓存一段时间的数据，主控不必每个采样点都切断当前任务去响应。这个取舍直接缓解了 MicroPython 实时性不足这个天然短板，是本项目中最关键的架构决策。

2. 硬件选型与接线规划

2.1 主控：选一颗能跑 MicroPython 又省电的芯

主控我选了一颗基于 RISC-V 内核的低功耗 Wi-Fi 蓝牙芯片。为什么不是经典的双核型号？因为可穿戴设备对尺寸和功耗更敏感，这颗芯片体积小、射频待机功耗低，而且 MicroPython 社区对它的支持已经很成熟，I2C、定时器、RTC、深度睡眠这些外设都有现成模块。开发板自带充电电路，调试时直接用 USB 供电，做成成品后可以拆掉充电部分，换成电源管理小板。

选主控还有一条容易被忽略的标准：GPIO 数量别太少。表面上心率监测只需要 I2C 两条线加一个中断脚，但实际做原型时还会接屏幕、蜂鸣器、按键、LED 指示，留出富余引脚能让布线从容很多。做硬件的人都有过这种体验：所有功能都在验证阶段跑得通，一到整合阶段才发现引脚不够用，只能推倒重来。

2.2 传感器：心率监测能否成功的第一道坎

传感器是整个系统的“眼睛”，我选的是 MAX30102。这是一颗红光加红外光的 PPG 传感器，内部集成了 LED 驱动、光电二极管、ADC 和 FIFO，通过 I2C 接口输出原始信号。它的工作原理可以这样理解：LED 发出的光射进皮肤，一部分被血液中的血红蛋白吸收，一部分反射回来被光电二极管接收。心脏泵血时血管容积随脉搏变化，反射光强度也跟着周期性变化，这个光强变化曲线就是 PPG 波形，心率就是从这个波形的峰间隔算出来的。

选型时我在几颗常用心率传感器之间犹豫过。和早期方案相比，MAX30102 封装更小，功耗控制更好；和带绿光的方案相比，红红外组合在血氧测量上有扩展空间，而绿光在手腕这种组织较厚的部位抗运动干扰更强。如果做的是静态心率监测，红红外方案完全够用；如果目标是运动手环，绿光方案会更好。这个细节我在后面问题章节还会提到，先记住一个结论：传感器不是越贵越好，匹配场景才是关键。

2.3 显示、电池与引脚分配

显示部分我用了一款 0.96 寸、128x64 的 OLED，SSD1306 驱动，I2C 接口。为什么要 I2C 版本而不用 SPI 版本？省引脚。虽然 SPI 刷新快，但心率显示刷新率根本用不到，I2C 在 400kHz 下足够应付几位数字的刷新。

电池方面，原型阶段我用一块 400mAh 的聚合物锂电池，通过板载充放电电路供电。系统电压 3.7V 左右，芯片工作电压 3.3V，中间有 LDO 做转换。传感器 LED 供电比较敏感，MAX30102 对电源纹波有一定要求，建议在电源输出端并一个 10uF 陶瓷电容。这个电容对波形质量的影响很明显，我后面补充了很多测试才确定它是关键因素。

引脚分配我做成了一张表，直接照抄即可。I2C 用的是默认的硬件外设，中断脚需要选一个支持电平触发的输入引脚。

这里有个经验：OLED 和传感器共用 I2C 总线时，两者默认地址不冲突，OLED 通常是 0x3C，MAX30102 是 0x57，直接共用没问题。但上拉电阻要特别注意，如果开发板已经把 SDA/SCL 上拉，外部再加 4.7k 上拉会造成并联后阻值偏低，拉低信号上升沿，导致通信不稳定。这个问题我在第一次调试时吃了不少苦头，后面会细说。

3. 软件架构与数据工作流

3.1 四层架构划分

软件上我把系统分成四层：物理传感器层、驱动层、算法层、应用层。传感器层就是 MAX30102 本身，它负责光电转换和内部 ADC 采样；驱动层用 MicroPython 的 machine.I2C 封装出 read_fifo、set_led_current、configure 这类函数，屏蔽寄存器细节；算法层处理 PPG 原始数据，输出瞬时心率和信号质量；应用层负责状态机、OLED 显示和电池电量提示。

分层的最大好处是调试的时候能精准定位问题。比如心率值不对，我只需要先看算法层的输入波形是否正常，再决定是调驱动还是调算法，不用每次从头到尾把所有代码翻一遍。这个习惯在写 C 项目时也有，但 Python 的模块化写起来更舒服，函数的边界也更清晰。

3.2 传感器数据采集：FIFO、中断与轮询

MAX30102 内部有 32 深度的 FIFO。固件可以配置采样率，比如 200 sps，传感器自己按节奏把 ADC 结果写进 FIFO，主控只需定期把 FIFO 里的数据批量读出来。这里有两种读取策略：轮询和中断。轮询就是主循环里反复检查 FIFO 写指针，发现新数据就读取；中断则是让 INT 引脚在 FIFO 写入一定数量后触发回调。

我在项目里用了“中断 + 批量读取”的方案。中断服务函数里不做任何算法处理，只置一个标志位，让主循环知道“该收数据了”。这样做的原因是 MicroPython 的中断回调有严格限制，耗时操作放里面会导致崩溃或数据丢失。数据读取和后续计算全部放在主循环，虽然看起来不够“实时”，但配合 FIFO 缓冲，实际表现比想象中稳。

3.3 状态机设计：从待机到测量的状态流转

纯业务代码如果全用 if/else 嵌套，后面加功能会非常痛苦。我设计了四个状态：待机态、佩戴检测态、测量态、低功耗态。

开机默认进入待机态，屏幕显示时间或电量，系统定时检查传感器是否检测到人体。检测到佩戴后，进入测量态，这个状态算法开始工作，屏幕刷新心率。如果传感器长时间没有检测到信号，或者用户按下按键切换，系统回到待机态。低功耗态其实是从待机态演化出来的，当电量低于阈值，系统自动关闭屏幕、降低采样率，只保留按键唤醒。

状态机的好处是后续加功能非常自然，比如添加血氧测量，只需新增一个状态，不影响原有的心率逻辑。代码里我用一个简单的枚举变量加分发函数实现，没有引入复杂框架，麻雀虽小五脏俱全。这种设计方式非常实用，尤其适合可穿戴这种功能还会不断扩展的产品。

4. 核心代码实现：从原始PPG到心率数值

4.1 传感器初始化与 I2C 配置

先看最底层的初始化代码。在 MicroPython 中，I2C 硬件外设初始化和寄存器写操作都非常直接。这份代码我尽量保持精简，重点是还原关键配置步骤。

from machine import Pin, I2C import time MAX30102_I2C_ADDR = 0x57 # 关键寄存器地址 REG_FIFO_CONFIG = 0x08 REG_MODE_CONFIG = 0x09 REG_SPO2_CONFIG = 0x0A REG_LED1_PA = 0x0C REG_LED2_PA = 0x0D REG_FIFO_DATA = 0x07 i2c = I2C(0, scl=Pin(9), sda=Pin(8), freq=400_000) def write_reg(reg, value): i2c.writeto_mem(MAX30102_I2C_ADDR, reg, bytes([value])) def read_reg(reg, length=1): return i2c.readfrom_mem(MAX30102_I2C_ADDR, reg, length) def max30102_init(): # 复位传感器 write_reg(REG_MODE_CONFIG, 0x40) time.sleep_ms(100) # FIFO配置：平均值4、FIFO回卷使能 write_reg(REG_FIFO_CONFIG, 0x4F) # 模式配置：红红外同时使能 write_reg(REG_MODE_CONFIG, 0x03) # 采样率200sps，ADC满量程8192nA，LED脉宽69us write_reg(REG_SPO2_CONFIG, 0x27) # LED电流：红光 6.4mA，红外 6.4mA write_reg(REG_LED1_PA, 0x24) write_reg(REG_LED2_PA, 0x24)

采样率配置为 200 sps，对应 5ms 一个数据点，这个速率能保证脉搏波形的细节完整。LED 电流先用 6.4mA，是因为这个值在实际佩戴中信号幅度适中，不会轻易饱和也不会太小。需要说明的是，寄存器值在不同固件版本下可能有些细节差异，拿到模块后先读一下芯片版本寄存器，确认型号再配置，避免初始化失败。

4.2 批量读取 FIFO 与环形缓存

MAX30102 的 FIFO 数据寄存器每次读一个字节，红红外数据是 18 位，存在三个字节里。读取时需要连续读 6 个字节，组合出红值和红外值。我在代码里封装了一个 read_fifo 函数，每次把当前 FIFO 里的数据取一个样本出来。

FIFO_SIZE = 32 data_buffer = [] # 每个元素是 (red, ir) 元组 def read_fifo_sample(): global data_buffer # 连续读 6 个字节，组成 red 和 ir 两个 18 位数值 raw = i2c.readfrom_mem(MAX30102_I2C_ADDR, REG_FIFO_DATA, 6) red = (raw[0] << 16) | (raw[1] << 8) | raw[2] ir = (raw[3] << 16) | (raw[4] << 8) | raw[5] red >>= 2 # 18位有效数据 ir >>= 2 data_buffer.append((red, ir)) # 缓存超过 300 个点后丢弃最旧的数据，防止内存膨胀 if len(data_buffer) > 300: data_buffer = data_buffer[-250:] def read_fifo_batch(count): for _ in range(count): read_fifo_sample()

这段代码里有个细节值得注意：FIFO 深度只有 32，如果主循环响应不及时，数据会被覆盖。为避免这个问题，我在应用层保证主循环轮询间隔不超过 100ms，按 200 sps 计算，100ms 内产生约 20 个点，小于 FIFO 深度，所以不会丢数据。OLED 刷屏停顿 20ms 时，最多只产生 4 个新点，同样不会造成覆盖。这就是前面提到的“实时性预算”思路，简单算一下，心里就有底了。

4.3 信号预处理：去基线漂移与平滑

原始 PPG 信号有几个特点：有直流偏置，数值可能从几万到几十万不等；有基线漂移，呼吸和肢体微动会让整体幅度缓慢变化；有高频噪声，主要是环境光和电子噪声。直接用原始信号做峰值检测很难稳定。

我用了两步预处理，第一步是去除基线漂移。比较简单的做法是用一个“滑动均值”作为基线估计，再用原始值减掉它。这里我用一个窗口长度为 15 的滑动均值来估计基线。

def moving_average(data, window=15): if len(data) < window: return 0 return sum(data[-window:]) / window base_ir = moving_average(ir_values, 15) ir_ac = ir_values[-1] - base_ir # 交流分量

第二步是平滑去噪。我选了一个简单的 5 点滑动平均，也可以加一个轻量级低通滤波。不要一上来就叠高频滤波器，那样会延迟大、计算量大，还会把真实的脉搏波削平。对于静态监测场景，5 点平均已经足够把大部分高频毛刺压下去。

这里要提醒一句：基线的窗口长度和滑动平均的窗口长度不是越大越好。窗口太大会导致基线跟随变慢，心率信号里的低频成分也被当成基线减掉；窗口太小又去不掉呼吸漂移。我这个参数是根据真实佩戴数据反复调出来的，先看波形再定参数，是很重要的经验。

4.4 峰值检测与 BPM 计算

预处理之后，PPG 波形呈现周期性脉搏波，下一步就是找波峰。峰值检测我用的是“动态阈值 + 最小间隔”的组合。动态阈值的思路是:维护一个波峰阈值的估计值，波形上升超过当前最大值的某个比例时就记录为候选波峰，然后计算相邻波峰的时间差，也就是 IBI（心跳间隔）。

BPM_MIN = 30 BPM_MAX = 220 min_interval_ms = int(60000 / BPM_MAX) # 最小间隔约273ms max_interval_ms = int(60000 / BPM_MIN) # 最大间隔2000ms peak_threshold = 0 last_peak_time_ms = 0 signal_max = 0 ibi_ms = 0 bpm = 0 def detect_peak(ir_ac_value, timestamp_ms): global peak_threshold, last_peak_time_ms, signal_max, ibi_ms, bpm # 不断跟踪当前波形的最大值 if ir_ac_value > signal_max: signal_max = ir_ac_value # 当波形从高位回落后，下一次再超过最大值的50%记为候选峰 if ir_ac_value < signal_max * 0.3: peak_threshold = signal_max * 0.5 if signal_max > 1000 and ir_ac_value > peak_threshold \ and (timestamp_ms - last_peak_time_ms) > min_interval_ms: ibi_ms = timestamp_ms - last_peak_time_ms last_peak_time_ms = timestamp_ms if min_interval_ms <= ibi_ms <= max_interval_ms: bpm = int(60000 / ibi_ms) signal_max = 0

上面的示例做了化简，真正的峰值检测还要处理“双峰”和“平台区”。我的经验是：先通过差分找到波形由负转正的上升沿位置，再去该位置附近搜索局部最大值，这样抗干扰能力更强。不过核心思路就是动态阈值，它比固定阈值靠谱得多，因为不同人体的信号幅度差别非常大，固定阈值根本没法通用。

4.5 心率数值平滑与异常剔除

每次心跳算出一个 BPM，但直接显示这个瞬时值会非常跳，因为相邻两次心跳间隔本身就有生理波动，还有测量误差。我对 BPM 输出做了一层“三值中值 + 加权平均”的后处理。

bpm_history = [0, 0, 0] final_bpm = 0 def update_bpm(new_bpm): global bpm_history, final_bpm bpm_history.pop(0) bpm_history.append(new_bpm) # 中值滤波，去掉异常大和异常小的值 sorted_bpm = sorted(bpm_history) median_bpm = sorted_bpm[1] if len(sorted_bpm) == 3 else new_bpm # 加权平均：历史值占 70%，新值占 30% final_bpm = int(final_bpm * 0.7 + median_bpm * 0.3) return final_bpm

这个后处理代码虽然短，但实际效果非常明显。它相当于把瞬时心率变成了一个带惯性的显示值，用户看起来更舒服，也不会因为一两个异常波峰而疯狂跳数字。需要提醒的是，惯性不能太大，否则真正的心率变化也会被抹平，运动场景下会显得“反应迟钝”。0.7/0.3 这个系数是我在静态和轻度运动两种场景实测后取的折中值。

至此，从传感器原始光信号到屏幕上的心率数字，整个数据链路就通了。下一步要解决的是让这条链路跑得更稳、更省电。

5. 实时性与功耗优化的实操经验

5.1 任务调度的坑：别让刷新线程卡住采样

项目做到一半，我遇到过一个很典型的问题：屏幕刷新的时候，心率数据会断流。查了很久才发现，OLED 通过 I2C 刷新一帧数据要传 1024 个字节，在 400kHz 下虽然只需要 20ms 左右，但如果刷屏代码放在主循环里和采样代码混在一起，一个完整的刷屏操作期间，传感器 FIFO 就可能被撑满，数据开始覆盖。

解决办法是“先收数据，再刷屏幕”。主循环每次迭代，第一件事就是读 FIFO，把新数据放进缓存，然后再去处理 OLED 刷新和按键扫描。换句话说，把数据采集的优先级放在所有 UI 操作的前面。这个顺序调整看似微不足道，实际效果却是质的提升：心率刷新不仅稳定了，整个系统的响应也感觉更顺。

如果你用多线程方案，建议采集线程保持实时，显示线程用队列接收数据。但在 MicroPython 中线程调度并不总是可信，我最后还是选择了单线程模型，靠严格的顺序和 FIFO 缓冲来保证。这个原则可以推广到任何嵌入式项目：别把时间敏感的操作和耗时操作混在同一个循环里，顺序就是优先级。

5.2 功耗测量与优化手段

功耗是这个项目的另一个硬骨头。整机功耗主要来自三块：主控、传感器、屏幕。我按模块测了一遍，顺带把优化手段也列了出来。

实测中我把 MAX30102 的 LED 电流从 6.4mA 降到 4mA，静态场景下信号幅度依然足够，功耗却少了将近一半。OLED 刷新策略也从“每秒刷 10 次”降为“心率变化时或最多每秒刷 4 次”，因为心率数字不是高频动画，刷新频率完全可以牺牲。这个优化看起来简单，但对续航的影响却非常直观。

更狠的一招是深度睡眠策略：当设备戴在桌上超过 30 秒，传感器信号持续低于阈值，系统自动进入低功耗睡眠，此时整机电流可以降到 1mA 以下。这个状态与待机态不同，深度睡眠会关掉大部分外设，只有 RTC 和按键唤醒在工作。它是让可穿戴设备真正“可穿戴”的关键一环，因为用户不可能一直处于测量状态。

5.3 实测数据一览

整套优化做完之后，我拿 400mAh 电池做了连续佩戴实测，结果是这样的：静态坐姿模式下，整机平均电流约 40mA，理论续航 10 小时左右；轻度步行模式下，平均电流约 55mA，续航约 7 小时。考虑到传感器 LED 电流因人而异的自动调节，实际续航还有进一步优化的空间。这些数据也验证了设计目标阶段定的“8 小时以上”没有落空。

值得注意的是，电池电压降到 3.5V 以下时，MAX30102 信号质量会明显下降，所以我在固件里加了电池电量检测：低于 30% 时提示充电，低于 15% 时自动进入低功耗模式。这个逻辑虽然简单，但对佩戴体验来说非常重要，谁也不希望设备在关键时刻突然没电而毫无预警。电源管理这部分如果偷懒不做，前面所有功耗优化的努力都会被最后一公里的体验问题抹掉。

6. 疑难问题与排查技巧实录

6.1 心率数值总是乱跳，怎么办

这是我最常被问到的问题，也是做 PPG 心率监测绕不开的坑。第一步不是改算法，而是先看原始波形。我在系统里留了一个调试口，可以把 data_buffer 里的原始值通过串口发到上位机，画成曲线。这一步能立刻定位问题：如果原始波形本身就乱，那就是光路或佩戴问题，算法再强大也无济于事；如果原始波形干净但心率值乱跳，那问题就在峰值检测或后处理。

波形乱通常有三个原因：传感器没有贴紧皮肤，环境光干扰太强，以及运动伪影。静态场景下，前两个因素居多。贴紧皮肤这一点我吃过亏，腕带稍微松动一点，波形幅度就会掉一个数量级，峰值检测也跟着失效。环境光方面，MAX30102 对可见光有一定抑制能力，但强光环境下还是会引入干扰，我后来在传感器窗口外面加了一圈遮光结构，效果立竿见影。如果你复现时发现波形毛刺多，先从物理接触和环境光入手，这是最容易被忽略的环节。

6.2 传感器输出恒为0，或者一直饱和

输出恒为 0，大概率是 I2C 初始化没成功，或者 LED 电流设置太小。先用简单脚本读取芯片 ID 寄存器，看看能不能读到正常的值。如果读不到，检查供电和 I2C 地址；如果读到了但数据全是 0，调大 LED 电流，再看 FIFO 配置是否正确。

输出一直饱和，也就是数值被顶在最大值，通常是 LED 电流过大或者传感器距离皮肤太近，光直接被反射回来没有进入组织。这时候要减小 LED 电流，同时检查传感器窗口是否有遮挡物。我遇到过一种很隐蔽的情况：传感器窗口上的保护膜没有撕干净，导致读数全部偏高，看起来像饱和。如果你拿到新模块排查这个问题，先撕膜，别急着改寄存器。

6.3 I2C 总线卡死，设备频繁死机

I2C 总线卡死多半是上拉电阻和信号线冲突引起的。MicroPython 的 I2C 驱动在总线异常时不会自动恢复，如果外设地址错误，或者从设备没有正常应答，整个总线就会卡住。我的处理方式是：初始化时加一次总线复位，把 SCL 手动翻转几个周期释放总线；同时在每次读取失败时做异常捕获，不让单次错误拖垮整个系统。

之前提到的上拉电阻问题也是这里的高发原因。如果总线挂载了多个 I2C 设备，要注意总线上拉电阻的总等效阻值。一般来说，总线上拉电阻在 2.2k 到 4.7k 之间比较合适，开发板自带上拉时不要再并联外部上拉，除非你确认阻值偏大导致信号上升沿太慢。这个坑我花了整整一个晚上才定位，现在记忆犹新。

6.4 设备发热，续航大打折扣

发热问题的根源通常是 LED 电流和主控功耗叠加。LED 长时间大电流工作，传感器窗口附近温度会明显上升，不仅影响舒适度，还会让 PPG 信号产生热漂移。我的调整思路是：把 LED 电流改成动态调节，根据信号幅度自动降低，信号太弱时才提高。同时建议主控在非采样期间进入短睡眠，把空闲功耗压下来。

这里有个细节：动态调节 LED 电流的反馈不能太激进，否则会出现“信号弱就加大电流，加大电流信号反而饱和”的振荡。我最后用的是缓慢调整策略，每 2 秒根据最近 5 秒的信号统计值微调一次，步进为 0.4mA。做完这步之后，整机温度不再明显上升，续航也回到了预期范围。很多时候，硬件问题不能光从硬件角度解决，软件调度上的调整往往能起到四两拨千斤的作用。

6.5 常见问题与排查速查表

把这些经验整理成一张表格，方便以后复现时快速对照。

这套排查表格是我三个月迭代下来的精华，每次遇到问题我都会先查表，再决定要不要动算法。多花几分钟定位原始波形，往往比瞎调参数更高效。如果你也准备做类似项目，建议直接把这张表打印出来贴在工位上。

7. 写在最后：迭代三个月后的实操体会

做这个项目前后花了三个月，我最大的体会是：在智能硬件开发这条路上，工具链的选择比想象中更重要。Python 和 MicroPython 让我省去了大量底层的苦力活，把精力真正集中到了信号处理和用户体验上；而底层硬件的配合，比如 MAX30102 的 FIFO 和中断机制，又弥补了解释型语言的实时性短板。两者结合得好，哪怕是非典型的选型组合，也能做出稳定可靠的产品原型。

如果你也想复现这个项目，我建议不要一上来就追求完整功能，先让屏幕能稳定显示原始波形的形状，再去填心率和状态机的代码。等原始波形这条链路稳定了，你会发现剩下的部分就是按部就班的拼接。我个人在实践中还发现另一个值得做的扩展方向：把原始 PPG 数据通过蓝牙同步到手机端，用 Python 桌面脚本离线分析信号质量，再反哺固件里的参数。这个闭环一旦打通，后续调算法参数就不需要反复擦写板子了，效率提升非常明显。后面我还计划往这个系统里加血氧测量和运动伪影抑制，方向已经验证，剩下的只是时间问题。