超小型可穿戴传感器平台hSensor：从硬件选型到低功耗链路全解析

做可穿戴硬件的人迟早会碰到一个让人头皮发麻的需求把三轴加速度计、光学心率传感器、低功耗蓝牙和电源管理电路全部塞进一块比硬币还小的板子里。我第一次看到需求文档的时候给的可用面积大概只有1.2cm × 1.2cm整机厚度压在8mm以内电池还不能牺牲太多容量。当时心里只有一个想法传统那种MCU一块板、蓝牙一个模块、传感器到处飞线的做法在这个体积约束下根本不成立。后来才有了Ultra-Small hSensor Platform for Wearable Apps这个项目。它不是一个单独的芯片也不是一块半成品的开发板而是一套面向可穿戴应用的超小型传感器平台从高集成度原理图、微型PCB布局、低功耗固件到手机端的数据协议整条链路统统打通。目标是让一个没有太多射频和传感器经验的团队拿到这套平台也能在三天内把数据从传感器送到App界面上。这篇文章会把整套平台从0到1的设计思路、关键选型逻辑、实际调试中踩过的坑以及最后测出来的真实数据一五一十写清楚。如果你正在做手环、贴片式健康监测器、运动传感器标签或者刚开始接触低功耗穿戴电子这篇应该能帮你少走不少弯路。1. 可穿戴设备的空间战争为什么够小是刚需先说说为什么一定要做这么小。很多从传统嵌入式转过来的人会觉得板子大一点怎么了性能还更好。但在可穿戴设备里尺寸不是审美问题是物理约束。消费级手环的电池通常在200mAh到300mAh之间厚度三到四毫米形状要贴着腕带弧度走。扣掉屏幕、振动马达、充电触点、按键这些部件之后留给PCB的区域经常只有15mm × 20mm甚至更小。对传感器板卡来说能分到的空间往往就是1cm见方左右。这不是个别产品的极端要求而是整个行业的普遍趋势——设备越做越小留给硬件的余地越少。厚度也一样。主板叠层能用的空间常常在1mm以内这要求所有器件高度都要控制在0.8mm左右屏蔽盖能不用就不用屏蔽罩反而可能让整机厚度超标。这种空间约束会直接影响方案选型你没法再指望用两颗独立芯片加一块蓝牙模块去凑数必须走高度集成路线。1.1 面积与厚度的真实账本拿一个实际手环产品来算账。假设产品定义了3轴加速度计、光学心率、BLE蓝牙、线性马达、220mAh电池。结构工程师给的可用主板区域是14mm × 18mm板厚要求1.0mm以内。如果按传统分立方案来做大概是这样蓝牙SoC加上外围晶振、电感、天线匹配网络至少需要5mm × 6mm的区域PPG模拟前端加上LED驱动和匹配电路大概要5mm × 5mmIMU虽然小但要留退耦电容、中断走线算下来也有2mm × 3mm充电IC、LDO、锂电池保护电路加起来又是2mm × 3mm剩下的就是密密麻麻的电容电阻、调试测试点、连接器焊盘。这么一摆板子很难低于20mm × 25mm。如果在14mm × 18mm的框里做几乎必然要双面贴片、高密度布线但这样做带来的射频干扰和调试难度会急剧上升。hSensor的做法是把核心功能浓缩成一块经过验证的最小系统传感器组合、BLE、电源管理做成一个整体参考设计而不是让使用方自己拼搭。最终核心区域可以压到12mm × 12mm以内。别小看省出来的这几十平方毫米它对产品定义是决定性的——省下的空间可以换成更大的电池、更薄的整机或者塞进额外的功能模块。1.2 分立方案与平台化方案的直观对比对比维度分立式方案hSensor 平台方案核心板面积约2cm × 2.5cm约1.2cm × 1.2cmBOM条目数80甚至更多40颗左右射频验证成本每版都要做天线匹配平台已验证只需微调固件工作量从零调驱动提供SDK和示例工程原型到联调时间2到4周3到5天这里说的平台化不是把方案锁死。它给使用方预留了必要的可配置空间——比如传感器可以通过I2C/SPI接口替换或扩展BLE的GPIO也可以按需分配。重点是平台帮你完成了占用大量调试时间的底层工作让你把精力放到应用层功能上。1.3 这个平台到底覆盖哪些可穿戴应用从实际见过的项目来看hSensor这类平台主要落在这些场景手环和智能手表常见的是心率、步数、睡眠监测医疗级贴片设备比如体温贴、心电贴、术后恢复监测贴运动传感器标签绑在鞋带、球拍、头盔上做动作分析睡眠监测仪放枕头边或贴在身上整晚记录体征儿童防丢挂件虽然核心是定位但也会用传感器判断佩戴状态和活动情况。这些场景的共同点是体积小、功耗敏感、必须通过蓝牙把数据送到手机App。这也正是hSensor Platform的主战场——不是跑复杂视频处理的设备而是以传感器数据为核心的可穿戴外围设备。2. 核心硬件选型与电路实现的取舍逻辑这一章我会把每个核心器件的选择理由讲清楚而不是只列一个BOM。选型在可穿戴设备里不是哪个参数高选哪个而是面积、功耗、性能和成本之间的四角平衡。2.1 主控SoC为什么优先把nRF52系列作为默认选项我在这套平台里默认用的是nRF52832选择逻辑可以拆成几条内核是Cortex-M4F主频64MHz跑BLE协议栈加上轻量级信号处理算法都够用512KB Flash和64KB RAM对可穿戴固件来说非常宽裕不会因为内存不足被迫砍功能内部RC时钟精度足够好可以省掉外部的32.768kHz RTC晶振这在寸土寸金的板子上是实打实的面积和成本节省射频性能稳定SoftDevice协议栈非常成熟DFU、Mesh这些功能都有现成库不需要自己从零写蓝牙栈。备选方案我也列一下方便你们做不同定位的产品时对比DA14531待机功耗极低但Flash和RAM都比较小适合功能简单、只需跑一个传感器的设备nRF52840带USB和更多GPIO适合需要与外部存储、LCD或复杂外设交互的产品Apollo4 Blue Plus如果未来想在设备端跑TinyML模型这颗SoC的计算能力会从容很多。选主控时要记住一点不要只看性能余量要看睡眠功耗和唤醒时间。可穿戴设备大部分时间都在睡觉真正干活的瞬间很短。一个睡眠电流2uA的芯片比一个睡眠电流10uA但主频高一倍的芯片在整机续航上的差异远远大于主频差异。2.2 传感器组合与各自的工作电流hSensor默认的传感器组合是这样配的6轴IMU选用LSM6DSO或同级别加速度计工作电流约0.55mA陀螺仪约0.55mA内置FIFO有4KB。关键价值就是FIFO够大MCU可以长时间睡眠由FIFO水位中断唤醒PPG光学心率传感器选用MAX30102或AFE4404。MAX30102集成红光和红外LED适合做心率、血氧工作电流主要由LED的占空比决定一般平均5到10mAAFE4404的优势是多波长分时驱动暗电流补偿做得更好温湿度传感器SHT40级别测量时电流6uA左右睡眠时0.4uA几乎可以忽略不计气压计可选BMP581工作电流在几微安到几十微安用于海拔和楼层检测。选传感器的核心原则是自带FIFO和中断引脚的型号优先。千万不要选那些必须靠MCU高频轮询才能读数据的旧型号否则MCU平均电流会被拉高好几个数量级。这一点在电池设备上是决定生死的。2.3 电源链路里容易被忽略的细节电池出来后的第一级是锂电池保护IC型号一般是DW01加8205的组合然后是线性充电IC比如BQ25185或TP4054充电电流靠外部电阻设定在100mA到500mA之间再往后就是系统LDO给数字域和模拟域分别供电。一个容易被忽略的问题PPG模块的LED驱动瞬间电流非常大单个脉冲能到几十毫安。如果LED和MCU数字电路共用同一个LDO输出会被瞬间拉低导致传感器AD采到的波形出现周期性纹波。正确的做法是把模拟传感器域的LDO独立出来数字域和射频域再用另一路。如果板子空间实在紧张至少要在PPG电源引脚附近加足够容量的电容并让LED驱动的地单独回流不要和MCU数字地混在一起。2.4 PCB布局的优先级排序空间小不代表可以随便布恰恰相反空间越小越要有严格的布局纪律。我在这套平台上定下的优先级是这样的先把天线和匹配电路的位置占好保证净空区至少6mm × 3mm正下方禁止走线铺铜再放PPG光路区域LED和光电二极管之间必须有隔光结构隔墙下方不能走数字信号线然后是晶振、射频参考地和电源去耦最后才放MCU、连接器、测试点这些对位置相对不敏感的器件。这个优先级顺序如果错了典型后果就是板子功能跑得通但天线辐射效率差PPG波形上毛刺多最后只能割线飞线去补既难看又不可靠。硬件开发里最贵的从来不是器件本身而是返工时间。3. 低功耗数据链路的工程实现硬件选型只是第一步真正决定设备续航的是固件里的电源管理策略和数据链路设计。这一章讲的是每毫安时都要花在刀刃上的具体做法。3.1 电源域划分与主循环的休眠模型System ON睡眠是整个功耗设计的核心。系统里要分三个电源域Always-on域只保留唤醒源包括RTC定时器、GPIO唤醒、复位逻辑Sensor域由MCU的GPIO控制传感器LDO开关需要采集时才打开BLE域由SoftDevice协议栈管理连接事件到来时自动唤醒射频收发。典型的主循环流程是进入System ON睡眠RTC定时100ms唤醒一次检查是否有传感器中断标志比如FIFO水位中断有中断就读FIFO做轻量算法处理拼装BLE数据包没有中断就继续睡。关键点在于主循环里不要有任何周期性的、无事件触发的任务。所有周期性检测都应该交给外设中断来完成否则MCU会在醒来发现没事做的状态里反复空转消耗的电流远比你想象的大。3.2 传感器FIFO与突发传输不要让MCU频繁醒来这是低功耗设计里最实惠的一项优化。拿LSM6DSO举例加速度计工作频率25Hz每个数据点12字节。如果MCU每25ms读一次每秒要唤醒40次每次唤醒从睡眠到SPI稳定需要几百微秒这部分开销累积起来平均电流比正常读取数据本身还高。正确的做法是把FIFO水印设到40个样本大概1.6秒的数据水位满了才触发一次中断。MCU被唤醒后一次性读出40个样本然后继续睡觉。这样MCU从每秒唤醒40次变成不到1次功耗直接下降一个数量级。MAX30102也是同理芯片内部有FIFO和数据就绪中断把采样率50Hz、LED脉宽、ADC位宽设置好让它攒几十个样本后一次性读出来。3.3 BLE连接参数怎么调连接间隔和从机延迟BLE的功耗由连接事件频率决定而连接事件频率由两个参数控制连接间隔两个连接事件之间的时间单位是1.25ms的倍数。间隔越短数据实时性越好但功耗越高从机延迟允许从机跳过N个连接事件不响应进一步降低功耗。hSensor默认的设置分两套工作模式连接间隔从机延迟适用场景后台日常模式45ms4低频数据同步比如计步和心率快照实时波形模式7.5ms0实时上传PPG波形或IMU原始数据应用层要做的就是动态切换参数用户打开App查看实时心率曲线时请求短连接间隔App退到后台后恢复长连接间隔。这个切换逻辑要写好否则会出现明明App都退出了设备还以高频连接事件耗电的情况。还有一个嵌入式开发者容易忽略的细节BLE默认的MTU只有23字节扣掉协议头后用户数据只有20字节。要把GATT的MTU协商到247字节iOS端用maximumWriteValueLengthAndroid端用requestMtu协商成功后单包最多能塞200多字节数据传输效率差十倍。3.4 本地缓存与掉电安全在运动场景里用户可能没带手机或者App被系统杀掉。数据在设备端做本地缓存非常重要。hSensor的做法是循环写SPI Flash比如W25Q16固定格式记录时间戳和传感器特征。每10分钟落盘一次Flash擦写寿命约10万次算下来能撑很久但还是建议做磨损均衡避免每次写同一个扇区。这里有一个必须避开的坑写Flash的擦除操作通常需要几十毫秒期间主控要保持活跃。如果BLE连接事件正好和Flash擦除撞在一起容易导致连接事件超时轻则丢包重则断连。解决方式是写Flash前先检查当前BLE连接状态或者把写操作放在两个连接事件之间在RTOS里用优先级机制保证Flash操作不阻塞BLE通信。4. 机械集成与射频调试中容易踩的坑硬件原型到量产之间最耽误进度的往往不是电路本身而是射频和结构件的集成问题。这套平台在打样和试产阶段我踩过不少让我记忆深刻的坑。4.1 天线净空区省空间的反面教材第一版hSensor为了多放两个测试点把PCB天线的净空区切掉了一部分。裸板功能测试看起来一切正常但一装进整机信号衰减特别严重——手机放在10米外数据就断断续续。用频谱仪一测才发现净空区不足导致天线效率降了6dB左右相当于蓝牙发射功率从4dBm掉到了-2dBm这个差距直接反映在连接距离和稳定性上。后来重新改板把测试点挪到不干扰的边角完整保留了净空区同样环境下20米外还能稳定连接。这个教训非常直接天线底下每一条走线、每一块铜皮都在以辐射效率为代价。天线问题不是软件能补出来的位置占错了整版废掉重做。4.2 电池与FPC连接线对天线匹配的影响可穿戴设备里电池往往就放在主板正下方电池本身是一个大金属块会显著改变天线附近的电磁环境。hSensor第一版调射频匹配的时候只在裸板状态下调的S11参数S11在2.4GHz到2.48GHz之间低于-15dB指标很漂亮。结果一装进外壳中心频率漂了十几MHzS11掉到-6dB左右整机灵敏度下降明显。从那以后所有射频调试都强制要求在整机状态做带电池、带外壳、带上FPC连接线。另外FPC本身也会参与辐射走线路径尽量沿着地平面边缘不要横跨天线的辐射区。4.3 PPG光学通道的隐形坑PPG传感器是这套平台上最挑剔的模块。裸露PCB在桌面测试时心率波形都很好脉动波形清晰一装进外壳波形的交流分量掉了一半很多脉冲几乎看不到。排查下来是三个原因叠加外壳开窗孔径太小LED和光电二极管的视场都被遮挡了LED和光电二极管之间的隔光结构没有完全贴紧PCB环境光从缝隙进入直接把微弱的光电容积信号淹没了透窗材料对绿光的透过率不够深色PC或高雾度材质会让有效光信号损失一半以上。解决思路是在PCB设计阶段就预留遮光泡棉和结构件的装配空间结构设计上明确开窗尺寸、透镜材质和透镜到皮肤的距离。最稳妥的方案是先做3D打印透明件实测几版光学通道的信号质量再投入模具。4.4 S11与杂散实测流程射频调试的具体步骤我一般是走这套流程将板子置于整机状态通过预留的SMA测试座连接矢量网络分析仪查看S11曲线目标是在2.4GHz到2.48GHz频段内低于-10dB如果有偏移调整π型匹配网络的串并联电容或电感再用频谱仪看带外杂散确认在2400MHz到2483.5MHz以外没有超过-30dBm的杂散成分最后做开阔场地传输距离测试固定数据包间隔100ms丢包率低于1%。每一版PCBLayout微调后天线匹配都会变。所以匹配网络一定要预留可调位置不能把元器件值焊死。这也是平台化设计的一个优势底层参考设计已经把这些东西验证过了使用方只需要做微调不用从零开始。5. 从原始数据到可穿戴App端到端打通硬件再小、功耗再低最终价值都体现在App能不能拿到干净可靠的数据。这一章讲设备端协议设计、双平台BLE适配以及算法怎么分工。5.1 设备端协议越简单越不容易错协议设计我坚持几个原则所有字段用固定长度小端字节序每个数据包带消息类型、序号、时间戳时间戳用开机以来的毫秒数32位够用约49天载荷里每个数据点固定字节数解析端不需要做变长字典解析用CRC16做校验BLE虽然可靠但链路层重传不代表应用层数据一定正确。一个心率数据帧的真实布局大概是这样0x01 | 0x00 0x34 | 0x00 0x00 0x00 0x3A 0x14 | 0x64 0x12 0x05 0x00 0x26 | 0x4E 0xA8解释一下每个字段0x01消息类型心率包0x00 0x34序列号标到52号包0x00 0x00 0x00 0x3A 0x14开机以来的时间戳毫秒数0x64心率100bpm0x12血氧饱和度97%0x05 0x00 0x26置信度和附加状态0x4E 0xA8CRC16校验。长度加起来不到12字节BLE一个包轻松装下解析端也只需要按固定偏移读取逻辑简单不容易出错。5.2 Android和iOS双端接BLE的差异iOS端的处理相对简单用CBCentralManager扫描连接就行但要在Info.plist里声明NSBluetoothAlwaysUsageDescription。真正的坑在后台模式App进后台后系统会自动拉长连接间隔如果你正在实时上传PPG波形很容易出现丢包。解决方式是App在前台时用短间隔传波形退到后台后只接收低频数据包需要原始数据就在后台发一个请求补传命令。Android端的坑更多Android 12以上的动态权限有BLUETOOTH_SCAN和BLUETOOTH_CONNECT要分别申请扫描回调在不同品牌机型上表现不稳定建议把扫描结果放进队列不要在回调里直接发起连接部分手机对连接参数协商不友好设备端要做好兜底逻辑对方不接受请求就按默认参数工作。无论哪一端App都必须处理连接断开和重连。可穿戴设备的连接稳定性和Android系统杀后台的机制往往冲突产品设计上要考虑通过前台服务或系统级API保持数据通路。5.3 算法放设备端还是App端我的分工原则很简单设备端做轻量级特征提取App端做重量级模型推理。设备端适合跑的算法计步器静止检测和佩戴状态判断简单的活动识别走路、跑步、骑行区分。这些算法在MCU上跑不需要占用BLE带宽只上传特征值就行。比如每小时上传一次步数、活动类型、平均心率而不是把所有原始数据都传上来。App端适合跑的算法心率变异性分析HRV睡眠分期运动轨迹和长期趋势预测需要机器学习模型的异常检测。一个折中的做法是设备端做环形缓冲保存最近1小时或一整天的原始PPG和IMU数据块。App有需要时按时间段拉取既能保留原始数据用于离线分析又不用长期占用BLE带宽。5.4 典型场景把hSensor做成贴片式心率监测器我做过一个具体的验证项目把hSensor平台做成一个贴片式心率监测器。工作模式是这样的PPG采样率25HzIMU采样率25Hz两路数据同步采集设备端实时计算瞬时心率App端每2秒刷新一次数显晚上入睡后设备端检测到3分钟无活动自动进入低频记录模式降低LED亮度和采样率第二天早上用户连接手机App一次性拉取前一天完整数据。实测下来App从连接蓝牙到拿到昨晚的全套心率曲线整个补传过程大约2秒。这个体验在原型验证阶段已经能说服合作方继续投入了。6. 实测性能与后续演进方向硬件项目只看原理会显得很虚实测数据才最有说服力。这一章把hSensor在不同工况下的实测结果列出来包括续航、数据精度和目前已知的短板。6.1 续航实测实验室里用一个模拟佩戴工况的设备做测试电池标称容量230mAh环境温度25度。使用场景平均电流估算续航深度待机无BLE连接2.1uA电池自放电主导日常佩戴IMU 25Hz加上后台BLE连接1.8mA约5天连续心率监测PPG 25Hz加BLE实时传输8.5mA约27小时运动模式IMU 100Hz加上Flash记录加BLE传输12.3mA约18小时实测中还发现一个有意思的现象保持长连接比频繁断开重连省电得多。每次重连过程里广播、扫描、连接参数协商的开销远高于周期性的连接事件。所以产品设计上尽量让用户连接一次、长期保持不要频繁让设备回到广播状态。6.2 数据精度心率与医疗级指夹式血氧仪在静坐场景对比误差在±3bpm以内中高强度运动状态下运动伪迹会把误差扩大到±7bpm左右这时需要IMU辅助做运动伪迹消除否则效果有限。计步日常步态下误差小于3%。但如果是推着购物车行走、手在裤兜里甩动这类特殊场景误差会明显增大需要在算法里单独处理。温度皮肤表面温度与实际核心体温的差一般在1到2度需要按佩戴位置做校准不能直接当核心体温使用。6.3 已知限制与下一步方向每个平台在完成基本目标之后总能看到明显的下一代改进方向。hSensor目前有三个我认为最值得关注的计算能力边界。当前MCU跑小型机器学习模型已经很吃力下一步考虑带NPU的低功耗SoC在设备端做更智能的佩戴状态判断和异常检测。PPG模块的适应范围。目前PPG在深肤色、低灌注条件下信号质量还不够稳定需要多波长LED和更先进的模拟前端才能覆盖更广的人群。结构验证周期。模具开模成本高、周期长建议团队在早期就做3D打印光学验证不要等到模具出来才发现光路设计有问题。如果让我重做一遍这个项目我会把更多时间花在整机状态下的射频和光学联合调试上而不是埋头调固件。软件功能可以慢慢迭代但天线效率和光学通道这种物理层面的东西一旦板子和模具冻结就几乎没有修正空间了。另一个建议是任何一个可穿戴原型从第一天起就坚持带电池、带外壳测试裸板数据再好看整机数据才有说服力。这套经验陪我走过了好几轮产品迭代希望也能帮你省下几周返工时间。