做可穿戴硬件的人基本都经历过同一个夜晚板子调通了数据也能读出来但看着示波器上的纹波和App里抖得不成样子的波形你会怀疑自己到底在做什么。这个项目叫Ultra-Small hSensor Platform简单说就是我把原本要三块板子才能装下的传感器采集、信号预处理、无线传输整套链路压到了一块指甲盖大小的PCB上并且配套做了一套能从固件一直管到App的数据协议。这篇文章就把这个平台的完整设计思路、硬件选型、固件实现、App对接以及我在调试过程中踩过的坑全部摊开来讲适合正在做或者打算做小型化可穿戴设备的工程师做参考也适合刚入行、想搞明白一套可穿戴传感系统到底怎么从零落地的朋友。先说结论这个平台最终做到的核心指标大概在12mm x 12mm的双层板面积上集成了PPG心率/血氧、六轴IMU、高精度体温和BLE 5.0传输整板待机功耗在微安级别连续采样工作时平均电流能控制在10mA以内用一块100mAh的软包电池可以跑接近一天半。指标不算夸张但体积和功耗的平衡是实打实调出来的下面每一部分我都会讲清楚当时为什么这么选、实际踩了什么坑。1. 平台整体设计与思路拆解1.1 这个平台到底要解决什么问题我最初接到这个需求时客户给的描述很模糊只说“做一个极小的心率体温运动手环要能连手机App最好开发周期短”。这种需求在嵌入式领域天天都有但真正动起手来就会发现难点根本不在“能不能做出来”而在“这么小的体积里怎么保证信号质量同时把功耗压到能戴”。hSensor Platform的设计目标说白了就两个第一把传感端到App端的链路做完整让上层应用开发不用关心底层寄存器怎么配、数据怎么解第二用极端的小尺寸换取可穿戴产品在工业设计上的自由度。这两点决定了所有技术选型整机设计全部围绕它们展开。很多团队做类似产品喜欢拿现成的开发板叠起来验证但开发板那一堆排针和调试接口在小尺寸产品里没有参考意义。所以这平台从一开始就按最终产品的形态来做PCB叠层、天线净空、电池接口全部按量产标准设计开发板和最终产品之间几乎零转换成本。1.2 为什么选BLE而不是其他无线方案无线方案我对比过Wi-Fi、BLE、私有2.4G和NFC这几种。可穿戴设备选通信方案核心矛盾永远是功耗、带宽、连接便利性三者之间的取舍。Wi-Fi峰值功耗动辄一两百毫安而且需要路由器和网络配置流程在运动手环场景里完全用不上私有2.4G虽然功耗可控但需要额外加密狗或者专用网关才能和手机通信对C端用户太不友好NFC功耗极低但带宽和通信距离决定了它只能做碰一碰的数据同步不适合实时波形传输。BLE在这几个维度里算是综合最优解。BLE 5.0理论速率能到2Mbps实际跑人常心率波形毫无压力广播功耗控制得当的话发射峰值电流在10mA级别再加上所有主流手机系统都对BLE有完善的API支持App端开发成本最低。最终我选了Nordic的nRF52系列作为主控原因就是它把BLE射频、协议栈和作为传感器采集主控的ARM Cortex-M4核整合在一颗芯片里省掉一颗独立蓝牙芯片的空间和成本。1.3 尺寸、功耗、性能三者怎么平衡这是整个项目里最核心的设计哲学问题。小尺寸意味着PCB面积受限走线间距必须压缩器件封装得尽量小但封装越小寄存器和供电引脚间距越密生产焊接和调试难度越高。功耗和性能更是一对老冤家传感器采样率越高、无线广播越频繁功耗就越高但这又是保证数据质量的前提。我的平衡策略是分层处理。硬件层面把功耗大头拆成“传感器采样功耗、主控工作功耗、无线发射功耗”三段分别计算再逐项优化数据层面既然目标是给App用就干脆在板端就把滤波和特征提取做掉一大部分App拿到的不是原始几十上百Hz的裸数据而是已经标记好的波形片段和特征值这样无线传输的数据量能下降好几倍。这套策略实践下来效果很明显单纯传原始数据时一口气开100Hz的PPG和50Hz的IMUBLE几乎一直处于忙碌发送状态整板功耗轻松破20mA姿态特征在板端提取后再发发送间隔可以拉到几十毫秒一次平均功耗砍掉一半还多。所以真正的低功耗不是靠某一颗芯片省电而是靠整个数据链路的合理裁剪。2. 核心硬件选型与细节解析2.1 传感器选型逻辑PPG、IMU、体温怎么挑传感器是这套平台的感知前端选型直接决定数据质量和功耗底数。PPG传感器用来测心率和血氧市面上主流方案分为分立LED加光电二极管组合和集成式模块两类。集成式模块像MAX30102、MAX30101这类内部把LED驱动、PD接收、ADC、环境光消除都做好了软件配置相对简单但体积偏大而且因为光学结构是固定的在某些佩戴角度下反而容易受环境光干扰。分立方案体积控制更极限光学结构可以自己定但相应地把模拟电路、恒流源、跨阻放大器的设计风险都揽到了自己身上。考虑到“Ultra-Small”这个核心诉求我选择了将分立光学前端和模拟信号调理链路自行设计的方式。这里多说一句为什么敢这么干分立PPG的核心链路就三部分——LED恒流驱动、光电二极管电流转电压、以及带低通滤波的ADC采样。前两部分在微安级电流下对噪声极其敏感所以PCB布局的时候光敏器件的走线越短越好并且要用地铜皮包住ADC部分直接用主控内部集成的12位ADC加一个外部一阶低通滤波省掉一颗独立ADC芯片。IMU选了六轴方案也就是三轴加速度计加三轴陀螺仪用来做运动识别、姿态解算和睡眠翻身检测。关键是功耗要低、噪声要低、封装要小。同级别对比下来LSM6DS3系列在这个尺寸和功耗区间表现比较均衡片内还自带FIFO可以在主控睡眠时自己缓存数据这个特性对省电帮助很大。体温传感器用的是高精度数字温度芯片比如TMP117这类分辨率能做到0.0078摄氏度I2C接口直接读到寄存器值不需要校准。但它测的是芯片自身温度要测人体皮肤温度还得考虑热传导路径所以实际产品里我在传感器周围设计了一圈铜导热盘再在结构上和皮肤接触面保持尽量短的导热距离。2.2 主控选型与封装选择主控是整个平台的大脑。选主控我看重的顺序大概是BLE协议栈成熟度、处理能力、外设资源、功耗、封装尺寸、供货稳定性。nRF52832和nRF52840我都评估过最终选了nRF52832的QFN-48封装版本。为什么不用nRF52840它确实资源更丰富但体积更大几乎多出4平方毫米的面积在12mm见方的板子上是很可观的占用。而52832对这套系统来说是够用的64MHz的主频、512KB Flash和64KB RAM它跑BLE协议栈加数据采集加实时滤波绰绰有余多出来的主频和Flash对我这个场景没有意义。省下的面积给电池和传感器设计余量更大。封装封装我这里其实踩了一个小坑。一开始采用晶圆级封装WLCSP版本确实很小但一来对PCB工艺要求高焊接良率不稳定二来这颗料的引脚定义非常密集后期测试如果要飞线调试几乎无从下手。后来换到QFN封装尺寸大了一圈但焊盘间距大了普通PCB制程就能处理而且手工焊接和返修都容易得多。做小尺寸硬件不能只盯着最终面积生产可制造性一定要提前考虑进去。2.3 PCB堆叠与天线布局的几个关键点PCB布局这块我花的时间比画原理图还多。传感器信号是模拟量无线天线是射频信号两者放在同一块12mm板上干扰问题躲不开。布局的核心原则就三条模拟区域远离天线、电源地平面尽量完整、关键信号线包地。天线净空区是必须保证的BLE芯片的天线引脚出来后走线要控制阻抗在50欧姆左右天线周围一圈铜皮全部掏空不能有任何走线和元件。如果这个区域被电池或者金属结构件遮挡天线效率会急剧下降实测通信距离能从20米掉到5米以内。堆叠上我把天线放在板子一角远离PPG光学窗口并且用接地的铜皮把天线区域和传感器区域隔开。PPG光学窗口的布局也很有讲究。LED和光电二极管的物理距离决定了血液脉搏信号的路径深度太近了是表面反射噪声太远了信号又太弱。我实测下来在2到4毫米之间是比较合适的间距具体要配合导光结构和外壳开孔做微调。玻纤板基材对绿光的透过率会影响光学效率所以光学窗口正下方要尽量挖空铜皮我甚至试过直接上透明FPC做转接来降低光损耗。电源和地处理方面这种小板上没有多余空间做分割地我采用整块地平面加局部星型供电的折中方案模拟部分、数字部分、射频部分的电源从主电源节点分别取电中间加磁珠和小电容隔离。这比割地更稳妥能有效防止数字开关噪声窜到模拟链路里去。3. 固件与数据链路的实操实现3.1 底层驱动与传感器寄存器配置固件这一层我的习惯是先用一颗开发板把所有传感器驱动调通验证时序和中断行为然后再往目标板移植。传感器驱动看起来只是读寄存器但每颗芯片都有自己脾气尤其是时序上的细节比如PPG传感器上电后需要等待LED和光电二极管前端的稳定时间IMU上电后需要一段内部自校准时间。以PPG驱动为例关键的寄存器配置大概是这样// PPG传感器初始化示例伪代码寄存器地址需对应具体芯片手册 ppg_init() { write_reg(0x01, 0x00); // 关断复位 delay_ms(10); write_reg(0x02, 0x6C); // LED1 峰值电流设为中等 write_reg(0x03, 0x00); // LED2 电流 write_reg(0x05, 0x03); // 采样率100Hz write_reg(0x07, 0x02); // ADC量程和分辨率 write_reg(0x06, 0x00); // 动态环境光消除使能 write_reg(0x0C, 0x07); // 开启连续采样模式 write_reg(0x01, 0x01); // 退出关断启动采样 }这里想提一个很多人容易忽略的点PPG传感器在不同电流和量程配置下的噪声底完全不同。如果你的应用场景以静止心率为主采样率50Hz就够LED电流可以压低一点但如果是运动场景采样率必须拉高LED电流也要加大否则信号会在运动伪迹里完全淹没。这个没有公式可套我的做法是把驱动层做成参数可配置然后跑一组不同配置的对比测试用实际数据来确定最优档位。3.2 数据滤波与特征提取拿到传感器原始数据并不意味着能用PPG信号里混着基线漂移、工频干扰和运动伪迹。这部分在平台里做了两级处理第一级在MCU内部对原始采样做实时滤波第二级在App端做自适应滤波和特征识别。MCU内部滤波我用了很轻量的方案一个去直流分量的一阶高通滤波器再加一个滑动窗口平均的低通滤波器。为什么不在MCU里上更复杂的小波变换或者自适应滤波因为MCU的算力摆在那里而且复杂滤波算法会显著增加功耗。滑动窗口平均的处理方式在代码里很直接#define PPG_SAMPLE_RATE 100 #define PPG_WINDOW_SIZE 10 static int32_t ppg_raw[PPG_WINDOW_SIZE]; static uint8_t ppg_index 0; static int32_t ppg_sum 0; int16_t ppg_filter(int16_t new_sample) { ppg_sum - ppg_raw[ppg_index]; ppg_raw[ppg_index] new_sample; ppg_sum new_sample; ppg_index (ppg_index 1) % PPG_WINDOW_SIZE; int32_t avg ppg_sum / PPG_WINDOW_SIZE; return (int16_t)(new_sample - avg); }高通滤波处理的事是去掉因为呼吸和身体微动引起的基线漂移保留频率在0.5到5Hz之间的心跳脉动分量。IMU的数据同样做了均值滤波和运动强度计算然后在板端算出一个三轴的合成加速度幅值用来判断当前是在运动还是静止。这个运动状态标志会和PPG数据绑定在一起打包发送App端收到后可以据此决定是用强滤波算法还是轻滤波算法。3.3 BLE服务定义与App数据对接BLE这一层我定义了一个自定义服务里面分了三个特征一个用于传感器实时数据流一个用于设备状态和电量上报一个用于App下发配置命令。数据流用Notify方式推送也就是设备主动往App发数据App不需要轮询这样省电也实时。协议格式是自定义的但设计原则是自描述加可扩展。每个数据包固定8字节头加N字节负载头里包含包序号、数据类别、数据长度、时间戳和CRC校验。包序号特别重要BLE虽然是可靠传输但在断连重连或者缓存溢出的场景下也会丢包App端靠包序号能及时察觉数据空洞。App端我用原生Bluetooth API做连接和接收。iOS用CoreBluetoothAndroid用BluetoothGatt两者在扫描和回调模型上有差异但逻辑框架是一样的。连接流程上我加了一个扫描回调的过滤条件只认我们自定义的Service UUID避免用户旁边一堆蓝牙设备时App扫到一堆乱七八糟的外设。数据解析这层放在一个独立的数据解析模块里和UI完全解耦这样不管是iOS还是Android甚至将来要接入健康管理平台时都可以复用同一套协议解析逻辑。4. 移动端App接入与算法落地4.1 App端架构怎么设计App端最容易犯的错就是一上来就画界面结果连数据都没打通。我的建议是先把数据链路走通再回头打磨UI。整个App的架构按数据流分成三层底层是BLE连接管理模块负责扫描、连接、断开、重连中间是传感器数据解析模块负责接收原始协议包校验、拆包、还原成结构化的心率、血氧、IMU数据上层是算法和UI拿解析好的数据做波形展示、心率计算、活动状态识别。iOS端我写了一个单例的BLEManager负责所有和硬件的交互。Android端使用了Service加回调的方式原因是Android系统对后台蓝牙连接限制比较多用Service保活以及处理系统级广播会更稳定。举一个实际的小例子Android上如果你在Activity里直接建BluetoothGatt回调一旦Activity因为旋转屏幕被销毁重建蓝牙连接就容易跟着丢。所以我用了一个在应用Application全局持有的连接管理器绕开了这个生命周期问题实测可靠性提升非常明显。4.2 心率与HRV算法在端侧的裁剪思路心率算法算是最核心的算法了。可穿戴设备上计算心率大体可以分成时域峰值检测和频域分析两条路。时域法直接对滤波后的PPG波形做峰值检测找相邻两个波峰的平均间隔再换算成每分钟心跳数频域法则是通过FFT把PPG信号变换到频率域找主频峰来估算心率。考虑到移动端性能和实时性我选了时域法做主干再叠一个简单的频域校验。因为纯时域法在运动状态下容易把运动伪迹的峰值误判成心跳峰值频域就可以提供一个参考值当两个结果差异超过阈值时App就判定当前状态运动干扰较大提示用户静止一下或者自动切换到更高强度的滤波策略。HRV也就是心率变异性可以通过提取连续心跳间隔的RMSSD指标来算这要求PPG波形质量足够高所以HRV计算只在静止且信号质量好的时候启用否则算出来的数没有任何临床意义。4.3 数据协议与应用案例这里放出我实际用的数据包结构给后面要做类似系统的朋友一个参考字段长度说明帧头1字节固定为0xA5包序号2字节递增检测丢包数据类型1字节0x01心率0x02血氧0x03IMU数据长度1字节负载长度负载数据N字节采集到的传感器值/特征值时间戳2字节相对上电时间单位10msCRC162字节校验这个包设计看似简单但它解决了三个实际问题包序号让App能识别丢包和乱序数据类型让同一套连接可以复用心率、血氧、IMU多路数据流CRC16则保证了无线传输的偶发错误不会污染算法。搭好了这套协议接下来做App的波形绘制、数据存储和云端上传都非常顺。举个例子我在一个睡眠监测场景里App端就是靠这个协议同时拿到心率、翻身动作、体温三路数据再用睡眠分期算法对阶段做判断。因为是板端已经把信号做了预处理App的CPU占用非常低整个夜间采集下来手机耗电量几乎可以忽略不计。5. 调试、痛点与功耗优化实录5.1 信号质量调试的踩坑记录说到调试这是整个项目里最有血泪感的部分。PPG信号质量受佩戴松紧度、肤色、环境光和运动状态的综合影响在实验室桌上测的好好地一到手腕上就开始给你看脸色。第一个大坑是环镜光干扰。一开始用了普通透明白光LED做PPG光源发现阳光直射或者室内射灯照射的时候波形上会出现一个很大的直流偏置叠加周期性噪声比值式心率算法直接崩掉。解决方案是在PPG传感器周围加遮光边框同时在电路上优化环境光消除寄存器配置让ADC在LED灭掉时采样一次底噪再做差分效果立竿见影。第二个大坑是机械耦合振动。佩戴时传感器和皮肤之间有微小相对运动这种运动产生的伪迹频率和心率频率重叠度极高靠传统滤波器根本滤不掉。我的做法是把IMU加速度信号和PPG信号结合起来做运动伪迹消除当检测到明显加速度波动时暂时降低PPG数据在心率计算中的权重并在App端提示“运动干扰请保持静止”。这套策略并不能彻底做好但在绝大多数日常使用场景下已经够用。5.2 功耗逐项优化的实测过程功耗优化是一个需要拿电流表一遍一遍抠的活。我把整板功耗分成了四个档位全速采样模式、数据发送模式、睡眠监听模式和完全关机模式分别在不同场景下测量。最初测出来的数据很难看全速采样加BLE连续发送的时候整板跑到20mA往上这在可穿戴领域是灾难级的。逐项排查后发现问题出在几个地方一是PPG传感器的LED恒流电流设置得过高在高环境光下确实需要大电流但在普通室内环境下完全用不上这个档位二是主控在高频时钟下一直满负荷跑滤波算法没有充分发挥睡眠模式三是BLE的广播间隔设得太短实际场景下一秒钟广播几十次根本没必要。最终我做了三项针对性修改LED电流改成两档可调App可以动态切换MCU在无数据时快速进入睡眠由IMU的FIFO中断或者定时器唤醒BLE的连接间隔从7.5ms拉到30ms数据发送合并成批量传输。三轮优化跑下来待机电流降到微安级连续工作平均电流压到10mA以内配100mAh电池能用10到12小时。具体参数对比我整理成了表项目优化前优化后待机电流30mA异常8uA连续采样平均电流20mA9.6mA一次蓝牙发送数据量每包4字节每包20字节发送间隔7.5ms40ms100mAh电池续航约5小时约10.5小时5.3 常见问题速查表根据我在调试过程中遇到的问题整理了一份速查表方便你后面排查时快速定位现象可能原因排查与解决BLE扫描不到设备天线净空区被铜皮覆盖检查天线区域走线和铺地确认净空扫描到但连接不上GATT服务UUID初始化失败确认蓝牙协议栈启动完全后再设置服务心率波形杂乱环境光干扰或LED电流不足调大LED电流追加遮光结构运动时心率值跳动剧烈运动伪迹未被抑制结合IMU判断并切换强滤波策略App收包乱序BLE缓存未清或时序错误增加包序号检测调整发送间隔设备续航明显缩短传感器未完全睡眠检查传感器初始化时是否正确配置睡眠模式这个表不能覆盖所有问题但至少可以帮你把最常踩的坑先排掉。做硬件就是这样问题不会凭空消失只能一个坑一个坑地填每填一个后面的路就顺一分。5.4 再说几个实际工程里的心得最后聊几个不是教程里会写、但实际工程里特别重要的点。第一原理图阶段就要把测试点留足。12mm见方的板子上根本没有空间放排针但每一路关键电源、每个传感器的I2C总线上预留一个0欧电阻的焊盘位置关键时刻能让你用飞线勾出来调试。第二从第一天就建立功耗预算表。每一个模块的电流占用、使能时序都写清楚后期优化功耗时能少走大量弯路。第三交互体验要提前定义清楚LED灯怎么闪、震动什么时候来、App提示怎么给这类看似外围的设计其实直接决定产品成败。再补充一个我个人的小习惯每次拿到新一批板子先跑一遍全功能的烟尘测试把所有功能全部打开连续跑12小时记录电流曲线和数据日志。这能很快暴露很多间歇性问题比如某个传感器偶发I2C卡死、BLE偶发断连重连这些问题如果不是跑长时间压力测试光靠桌面验证根本发现不了。这套Ultra-Small hSensor Platform目前已经在两个实际项目中落地了一个是健康手环一个是医疗级的体温连续监测贴。前者更重功耗和体积后者更重数据稳定性和App端算法。回头看真正让这套平台能复用到不同项目里的不是哪一块具体的硬件而是从一开始就把固件、协议、App算法分层设计清楚让它们各自独立又彼此协作。做小尺寸可穿戴设备的核心壁垒也正在这里怎样在指甲盖大小的世界里把硬件、算法、体验这三件事拧成一股绳。