尧图网页设计 
2014年前后我第一次拿到Hexoskin智能衬衫的拆解报告时最让我意外的是整件衣服的“大脑”居然是一颗来自Cypress赛普拉斯的EZ-BLE PRoC系列模块。那会儿绝大多数可穿戴设备还在用经典蓝牙传数据手机配对慢、功耗高而Hexoskin已经把实时ECG、心率、呼吸率这些医疗级生物特征数据全部压进了一颗基于ARM Cortex-M0核心的BLE SoC里。这正是今天这篇文章想拆开讲的东西——一件织物电极遍布全身的智能衬衫是如何通过Cypress EZ-BLE PRoC模块把生理信号稳定地送到手机App的。这篇内容适合三类人一是正在做智能服装、医疗可穿戴硬件选型的工程师想搞清楚BLE模块在织物环境里会遇到哪些坑二是做嵌入式BLE开发、想了解GATT服务如何承载多路生理数据流的朋友三是对Hexoskin这类产品好奇、想知道“一件衣服为什么能测心电图”的产品经理或爱好者。我会从硬件选型、信号链路、固件协议、实测坑点四个层面展开全程按实际项目推进的逻辑来讲能直接抄作业的地方尽量直接给参数和代码。1. 从一件智能衬衫说起Hexoskin到底在解决什么问题1.1 医疗级生物特征监测的硬件门槛Hexoskin的定位不是普通的运动手环而是医疗级别的贴身穿戴设备。它同时采集单导联ECG心电图、心率、心率变异性HRV、呼吸率、呼吸量、步数、睡眠分期等多项参数。注意ECG和光学心率是完全不同的东西——手环上的绿光PPG传感器测的是血液容积变化而Hexoskin用的是真正贴在胸口的织物电极放大心电信号这就意味着模拟前端的噪声要求、增益设计、抗干扰能力完全不是一个量级。医疗级ECG放大链路的输入噪声通常要在微伏级别才能看清P波和QRS波群。织物电极和皮肤之间的接触阻抗远高于传统凝胶电极动不动就是几十千欧到几百千欧而且还会随着身体动作大幅波动。这样一来放大器的输入阻抗必须做到GΩ级别偏置电流要足够小否则肌电噪声和运动伪影会把心电图彻底淹没。更麻烦的是衬衫是要水洗的织物电极经过几十次洗涤之后电极和导线之间的连接可靠性也会下降。这些物理层面的约束决定了Hexoskin的硬件团队从一开始就必须把“模拟前端性能”和“数字处理能力”放在同一个很小的PCB面积里考虑。我当时在国内跟做智能服装的团队聊天时很多人第一版方案都会用“MCU独立BLE射频芯片外置运放”的组合结果做出来的原型体积大、功耗高放在贴身衣物里既不舒适又容易掉线。这里面的核心问题不在于单个芯片选得好不好而在于系统级的集成度——如果你有多个传感器通道的数据要同步采集、压缩、无线传输那么主控和无线之间如果隔着一层SPI/UART接口无论是同步时序还是功耗优化都很难做到极致。Hexoskin直接选择带BLE收发器的PRoC模块让ECG前端和蓝牙协议栈跑在同一个芯片里本质上就是为了解决这个系统集成度的问题。1.2 为什么要用BLE而不是Wi-Fi或传统蓝牙对可穿戴设备来说无线协议的选择几乎决定了产品的功耗天花板。经典蓝牙BR/EDR建立连接后的射频功耗通常维持在几十毫瓦级别而且连接建立时间长达数秒Wi-Fi的功耗更高还要考虑天线面积和协议栈复杂度在一块只有拇指盖大小的模块上根本不现实Zigbee虽然低功耗但手机生态不支持用户不可能为了穿一件衬衫再买一个专用网关。BLE能成为唯一合理选项核心原因是它把“连接”变成了“按需唤醒”平时射频完全关闭只有设定的连接间隔窗口才打开一瞬间做数据收发其余时间系统可以继续睡。给Hexoskin这样的设备做功耗预算时你会发现连续ECG采样本身并不是大头。一个16位ADC、250Hz采样率、三通道同时采集满打满算也就是几千比特每秒的数据量功耗大概在几百微安到几毫安之间。真正吃掉电池的是无线传输的射频开销以及为了维持连接而必须周期性唤醒的协议栈。BLE的连接间隔connection interval可以从7.5毫秒到4秒之间配置每次连接事件只会开启一小段时间的收发窗口因此可以把平均射频电流压到几十微安甚至更低。这也是为什么Hexoskin能靠一颗容量不大的聚合物锂电池坚持数天——不是因为它省电省在传感器上而是省在了无线链路的调度策略上。另外BLE在手机端的生态成熟度也是一个决定因素。iOS从iPhone 4S开始就原生支持BLE 4.0Android从4.3API 18开始提供标准BLE API这意味着用户不需要任何额外适配器直接用手机App就能连上衬衫里的模块。相比Classic Bluetooth需要配对弹窗、配对后还要处理SPP之类的串口抽象BLE的GATT模型天然适合传感器数据流这种“多通道、低速率、结构化”的场景。EZ-BLE协议栈里封装好了完整的GATT服务负责产品的人只需要关注业务数据流不用去纠结底层射频和链路层怎么组织这大大缩短了产品从原型到交付的周期。2. Cypress EZ-BLE PRoC模块选它而不是nRF52832的理由2.1 EZ-BLE PRoC的硬件规格和BLE协议栈EZ-BLE PRoC是Cypress把自家PRoC BLEProgrammable Radio-on-Chip系列的SoC封装成模块的产品线典型代表是CYBLE-214009和CYBLE-013025这样的型号。模块内部通常已经集成了32-bit ARM Cortex-M0内核工作频率48MHz、BLE 4.2射频收发器、32.768kHz的RTC晶振、32MHz的系统晶振、天线、以及保证天线阻抗匹配的balun电路。换句话说一颗模块就是一颗完整的BLE节点外部只需要提供供电和传感器接口不用再去设计射频匹配网络也就绕开了整个硬件设计里最难验证的射频部分。协议栈方面Cypress现在属于英飞凌提供了一套完整且经过认证的BLE协议栈支持GAP通用访问协议、GATT通用属性协议、L2CAP、SM安全管理等所有标准层次。对Hexoskin而言最实用的是它支持自定义GATT服务并且允许开发者在Cypress的BLE组件里通过工具配置特征值、通知属性、安全模式和连接参数。这套开发环境虽然谈不上漂亮但在当时算是很稳定的。我记得Cypress的BLE协议栈有一个特点它把GATT数据库以“表”的形式维护用特征值句柄作为“索引”来定位读写操作。听起来有点绕但在实际调试时你是可以通过这个表索引快速找到某个特征值对应的处理函数入口的——这比一些其他厂商黑盒的协议栈要透明得多。这里顺便提一下我在项目中去翻数据手册时经常用到的“索引表”思维当一个GATT服务里有好几个特征值比如ECG数据、呼吸数据、设备状态、电池电量时固件里最忌讳的就是写一串if-else分支来逐个判断UUID。更稳妥的做法是维护一张服务定义表table把UUID、句柄、数据处理函数指针、通知开关状态全部做成结构体数组再用UUID或者句柄做索引index直接查表调用。这种“proc过程处理通过索引查表”的写法不仅代码量小而且后续要新增特征值只需要往表里加一行不容易漏。2.2 与主流BLE方案的对比我在选型时把当时的几条主流BLE路线放在一起比过简单列个表方案内核协议栈成熟度模块化支持备注Cypress EZ-BLE PRoCCYBLE系列Cortex-M0高Cypress官方好自带天线集成度高低功耗均衡Nordic nRF52832Cortex-M4F极高SoftDevice一般需自研射频性能强资料多当年很多高端产品用TI CC254x8051高有Module版经典但生态相对老旧Dialog DA14580Cortex-M0中有Module版功耗极低但Flash小Hexoskin选择Cypress而不是当年呼声更高的Nordic我猜测有几层原因。首先是模块化程度EZ-BLE PRoC直接以模块形式供货天线、晶振、匹配网络全集成通过了FCC/IC/CE等射频认证这对一个服装公司来说是非常重要的——毕竟团队的核心能力在纺织和生理信号处理不在天线调试上。其次是低功耗表现PRoC BLE在深度睡眠模式下电流可以到1微安级别而实际ECG连续传输场景下的平均电流也能控制在几毫安以内足够支撑数天的贴身佩戴。第三是供货和品控作为老牌半导体厂商Cypress的生命周期管理和可靠性测试做得比较扎实对医疗穿戴这种长周期产品来说这一点比纸面性能更重要。如果你今天重新做这个项目我当然会建议你把nRF52832甚至nRF52840也放进待选清单——它们的处理能力、Flash大小、社区生态在近几年已经追上来了。但如果你的团队缺乏射频经验产品的核心价值在传感器算法而非复杂的本地计算那么“带完整天线的认证模块”依然是我给你的首选推荐。与其花三个月调天线不如把时间花在呼吸算法和ECG滤波上这才是Hexoskin这类产品的护城河。2.3 天线设计与射频布线的实际考量聊完选型就得落地画板。EZ-BLE PRoC的模块封装设计得比较好把天线做成了PCB板载天线周围有一圈必须留空的禁布区keep-out area。这个禁布区在高频下是大事因为天线近场区域的金属、地平面、甚至高介电常数的材质都会改变天线的谐振频率和辐射效率。我第一次画板的时候偷懒把电池的金属外壳贴着天线放结果同一块板子在桌上测试RSSI是-45dBm贴到胸口直接变成-75dBm连接时不时就断。智能服装的挑战比普通手环更特殊天线周围是织物、人体和金属纽扣没有一个固定的环境。同样一块模块塞进棉质T恤和尼龙运动服里面介电常数不一样天线失谐程度也不一样。我当时看到Hexoskin的拆解图他们把天线区域刻意安排在了胸口偏上的位置周围尽量避开导电纱线和金属件而且模块底下的地平面做了比较完整的铺铜最大程度上减少了人体对天线的吸收。你可以理解为天线在人体附近本质上是在一个高损耗介质旁边工作能做的不是消除损耗而是让失谐后的驻波比尽可能平缓保证在几种典型穿着状态下都能保持可用灵敏度。3. 织物电极与BLE模块的硬件集成从传感器到天线的信号链路3.1 ECG/呼吸传感器的信号调理Hexoskin的信号采集链路可以拆成三段织物电极和呼吸传感器——模拟前端——数字处理与BLE模块。ECG部分通常使用三电极或者多电极布局信号进入芯片后先经过仪表放大器做第一级差分放大再接一个高通的二阶滤波去除基线漂移然后经过主放大和低通滤波最后进入ADC采样。这里面仪表放大器的共模抑制比CMRR至少要做到90dB以上否则工频干扰会从织物电极的不平衡阻抗里漏进来直接把心电信号盖掉。呼吸信号的采集是Hexoskin区别于大多数手环的地方。它用的不是简单的加速度计推算呼吸而是测量胸廓的膨胀变化常见方案有压阻式传感器带或者电感式体积描记RIP。RIP的原理是往织物里的线圈通一个高频小电流胸廓变化会改变线圈的电感进而改变振荡频率通过频率检测就能还原呼吸波形。这条链路的信号频率很低0.1-0.5Hz但幅度会受到运动伪影的调制所以模拟前端里要针对呼吸频段做一个窄带通滤波把高频肌电和运动冲击滤掉。值得强调的是这些模拟前端电路在PCB上的布局很讲究。心率和呼吸信号都是毫伏甚至微伏级别的弱信号如果数字部分的高频开关信号比如BLE射频在2.4GHz的突发发送通过地平面耦合进来哪怕只有几微伏也足以让ECG波形出现肉眼可见的毛刺。所以我通常建议把模拟前端和数字部分用星型接地或单点接地隔开ADC采样时序也尽量避开BLE的射频发送窗口——实际做的时候可以给射频发送加一个中断标志在发送期间暂停ADC采样或者丢弃该窗口的样本这个细节能大幅减少数据里的周期性噪声。3.2 模块供电与电池管理Hexoskin这件衬衫的电池不可能做得太大贴身穿的东西如果胸口鼓出一块电池别说用户了连我都不会愿意长期戴。所以整个系统的功耗预算是“挤”出来的。PRoC模块的宽电压输入通常是1.71V-5.5V具体要看型号让供电设计简洁了不少可以直接用一颗锂聚合物电池加低压差稳压器LDO供给模拟前端、数字部分和BLE射频部分。电池管理上有个容易被忽略的点ECG模拟前端和BLE射频的瞬态电流需求完全不同。BLE在发送数据的瞬间会从电源吸取十几毫安的脉冲电流如果LDO的动态响应不够快电源电压会瞬间跌落反映到ECG信号上就是一个低频的毛刺。我在项目里通常会给模拟前端的电源加一个低噪声LDO并用LC滤波器把数字电源和模拟电源隔离同时在BLE模块的电源引脚附近放一颗大容量的储能电容10μF级别专门负责给射频突发供电这样就能把电源跌落控制在一个可以接受的范围。另一个细节是电池电压监测。BLE的GATT服务里通常会放一个电池电量特征值但如果没有进行过校准这个值的实际意义很有限。我的做法是在固件里用ADC周期性采样电池电压然后根据锂聚合物电池的放电曲线做成一个分段线性的映射表又是查表把电压映射到百分比。这里的“表”要经过实际充放电曲线测量才能填好不能直接抄参考设计——不同容量、不同内阻的电池空载和负载下的电压差异很大。3.3 屏蔽和抗运动伪影处理智能服装最难搞的不是硬件性能而是动态场景下的可靠性。人在走路、跑步、翻身时织物和皮肤的接触状态会不断改变电极与皮肤的接触阻抗会出现低频大幅波动这个波动经过放大器之后就是所谓的运动伪影。处理运动伪影有几个层次第一是结构上保证电极始终贴合Hexoskin采用的是把电极编织进贴身面料里利用衣服的弹性提供持续的接触压力第二是模拟前端设计上加入自适应基线恢复电路通过积分反馈把直流偏置拉回到放大器的线性范围第三是在数字域做自适应滤波用加速度计信号作为参考来消除运动相关的噪声。射频链路上的屏蔽同样重要。织物本身对2.4GHz信号有一定的吸收如果导线走线离天线太近信号会被带着走导致辐射方向图畸变。我在同类项目里的经验是所有传感器导线尽量做成差分对并且在天线禁布区之外另走一路如果结构允许用一片金属化织物做一个局部屏蔽罩把模拟前端和数字部分隔开。Hexoskin的链路正是在这几个层面做了大量隐性优化才保证了用户从静坐到冲刺跑都能有连续可读的波形。4. 固件与数据链路如何用EZ-BLE把生理数据可靠地送到手机4.1 GATT服务设计与自定义Profile硬件链路搞定了接下来就是固件。Hexoskin集成了多个传感器通道如果用默认的Generic Attribute服务去传数据肯定不行。你需要自定义一个或多个GATT Service每个Service下面挂若干Characteristic分别承载ECG波形、呼吸波形、HRV指标、设备状态、控制命令和电池信息。设计自定义Profile时我强烈建议把数据结构做成查表驱动。具体来说在固件里定义一个特征值描述符数组每项包含UUID、值长度、读/写/通知权限、回调函数指针。当BLE协议栈收到来自手机的读取或写入请求时它首先根据句柄算出一个索引值然后拿这个索引去查找这个数组直接调用对应的处理函数。这种“index for table proc”的设计在有多路数据流的设备上可以避免在协议栈回调里写一大坨switch-case也让后续新增功能变得非常清晰。一个典型的自定义GATT服务结构大概是这样的CharacteristicUUID属性数据格式ECG波形自定义UUID-1通知16-bit采样值250Hz呼吸波形自定义UUID-2通知16-bit采样值100HzHRV/心率自定义UUID-3通知HR、RR间隔等控制命令自定义UUID-4写开始/停止/采样率配置电池状态自定义UUID-5读/通知电量百分比和电压每个通知型特征值在BLE协议栈里其实是一个环形缓冲区的“消费者”。数据采集线程比如ADC中断里往缓冲区写入样本而BLE协议栈在每次连接事件到来时从缓冲区里取一部分数据组成ATT通知包发给手机。如果你开启多个通知特征值要注意同一连接间隔内多个特征值的通知包不能超过链路层允许的最大包数量否则后面的包会被推迟到下一个连接事件带来额外的延迟。4.2 数据打包与传输策略生理数据是连续流式的你不能像传文件那样一帧一帧地丢。ECG 250Hz、每样本16位意味着每秒要传500字节呼吸波形100Hz、16位每秒200字节再加上HRV和状态信息总数据量大概在每秒1KB上下。这个速率对BLE来说并不高BLE 4.2的单连接最大可用吞吐量在几十KB/s瓶颈通常在Packet间隔和MTU大小上。如果用默认的MTU23字节一个数据包最多只能带20字节的应用数据每秒1KB需要拆成50多个包连接间隔稍微调大一点就会导致队列积压。更合理的做法是在连接完成后协商更大的MTU比如把MTU提升到247字节一次通知就能携带200多字节的样本数据大幅降低包的数量和中断频率。协商MTU的代码很简单就是发起一个MTU Exchange请求但很多开发者容易忘记在手机端也要把MTU配置上调导致协商失败后一直用默认值跑吞吐和功耗都不理想。数据帧格式方面我给每个传感器通道设计了统一的帧头帧起始标记、通道ID、序列号、数据长度、数据体、CRC16校验。序列号除了用来检测丢包还能让手机端把多路信号在时间轴上对齐——ECG和呼吸波形的采样时间戳不同如果不带序列号后期做HRV等分析时就很难对齐采样点。CRC16在BLE里面看起来有点多余因为链路层本身有重传机制但实测下来当手机处理不及时或后台被系统挂起时BLE的链路层重传并不能保证应用层数据的顺序完整性多一层CRC做最终校验还是值得的。4.3 功耗调优连接间隔与吞吐量的平衡接下来是BLE开发里最需要耐心调的一步连接参数。连接间隔connection interval决定了设备多久醒来一次和手机交换数据从机和主机的每次连接事件中又可以配置每个事件的包数量slave latency和超时时间。原理上很简单连接间隔越小数据延迟越低但收发窗口越频繁平均功耗越高连接间隔越大功耗越低但Buffer要做得更大否则数据会溢出。对Hexoskin这种连续数据流我的起始配置是连接间隔30-40毫秒从机延迟0超时3秒——这个组合能在功耗和延迟之间取得相对均衡实测ECG数据端到端延迟在100毫秒以内平均射频电流在2-3mA左右。如果只是想传心率这类低频数据可以把连接间隔拉到100毫秒以上再用Notification批量发送功耗还能降一个量级。计算吞吐量时我一般用这个简单公式有效吞吐 (连接间隔内可用的包数 × 每个包的负载字节数) / 连接间隔。假设MTU协商到247连接事件里最多能发6个包每个包有效负载244字节247-3的ATT头连接间隔40毫秒那理论吞吐大概是 6 × 244 / 0.04 36.6KB/s远高于我们的实际需求。这也是为什么我不建议为了速度盲目把连接间隔调到7.5毫秒——那会把功耗推高好几倍而你的数据量根本不需要那么高的速率。5. 实测中踩过的坑射频干扰、掉线和数据完整性问题5.1 天线净空区被织物覆盖导致的信号衰减我前面提过一次天线禁布区的问题但这里还是想单独拿出来讲因为这是智能服装项目里回报率最高的一次踩坑。原型阶段用的模块是直接焊在PCB上的天线朝外测试时拿在手里信号挺好但把整个PCBA塞进衬衫内侧的收纳袋后RSSI直线下降手机离开1米就开始断连。排查了几天最后发现不是软件问题而是收纳袋的面料正好覆盖在天线区域而且那片面料为了屏蔽静电还织入了导电纱线——天线等于被一个损耗很大的罩子罩住了。解决办法有两个方向一是调整PCBA在衣服里的摆放方向让天线尽可能贴近外层衣物且远离导电纱线二是选用外置天线版本的模块通过一根短的同轴线把天线引导到领口或袖口的位置。Hexoskin的实际产品里模块并没有放在正胸口而是放在了左侧肋下靠近腋下偏后一点的位置这个位置皮肤接触好、但离手机口袋通常在前侧或裤兜不算远同时避开了正面导电区域。如果你的产品结构允许尽量在天线附近不要放置任何金属纽扣、拉链头或者RFID标签这些都是隐形的信号黑洞。5.2 连接不稳定与重连机制老实说BLE在贴身穿着场景下的稳定性比实验室里差很多。实测中最常见的问题是手机锁屏进入后台后系统可能暂停BLE回调或者触发链路层超时断开衣服在洗涤、折叠后天线参数变化早期掉线率明显上升。一款智能衬衫要成为可靠产品重连机制比首次连接体验更关键。我在固件里做的处理是把连接状态机设计成“长连接优先、快速重连兜底”的双模式。正常情况下保持长连接但App端加入一个后台保活机制定期发一个空包检测链路。一旦检测到断连模块立即进入低功耗广播模式广播间隔设为100-200毫秒同时缩短广播超时时间避免浪费电App端则做后台扫描和自动重连最大重连次数和时间窗口都做了限制。这套机制让实际掉线后的恢复时间控制在几秒内用户体验上基本可以接受。另外要注意的是BLE协议栈里的“断开连接”有主动和被动之分。模块长时间没有收到主机的数据包会触发超时断开supervision timeout。这个超时值的配置不能太短我见过有人把超时设成500毫秒结果手机锁屏稍微卡一下模块就断连了。一般建议超时在3-6秒给系统留足缓冲。5.3 数据校验与断点续传数据完整性是医疗级产品绕不开的话题。BLE链路层的重传能保证单个包的可靠性但无法保证应用层的连续性和顺序性。我在多轮测试中发现当手机App被切到后台或者系统在做OTA时BLE通知包的到达间隔会出现几十毫秒到几百毫秒的抖动有的包还会被系统丢弃ECG波形上出现肉眼可见的断点。为了把丢数据的影响降到最低我做了两层设计。第一层是业务层校验每个数据帧都带序列号手机端检测到序列号跳变时通过一个控制特征值向模块发起补传请求模块从本地环形缓冲区重新发送缺失的一段数据。这个缓冲区的容量不需要太大以ECG的数据率算缓存10秒钟的数据大约只要5KB用模块内置的Flash或者一个外部SPI Flash很容易实现。第二层是业务层兜底当缓冲区溢出时优先保证ECG数据不丢呼吸和步数等低频数据允许降级。这套优先级策略在很多医疗可穿戴项目里都适用你不可能在所有异常场景下都保持全通道零丢失那就必须明确哪一路数据是“生命线”。6. 复盘与量产实话选型原则、洗水测试和产线筛查6.1 智能服装硬件选型的通用原则做了几个类似的贴身穿戴项目后我总结了一套选型原则不一定全面但足够避开大部分坑。选型时先问自己三个问题团队的射频经验有多少产品的核心竞争力在算法还是硬件传感器的数据量和实时性要求有多高如果射频经验不足直接选带认证的模块比如EZ-BLE PRoC这类如果核心竞争力在算法那么主控的Flash和算力要给够而不是一味追求最低功耗如果是多通道高频数据流BLE协议栈对多连接多个Central设备的支持也要在选型阶段就确认清楚。第二个原则是“模块先行SoC后移”。原型阶段用模块快速验证产品定型后再评估是否需要换成裸SoC以降低成本。Cypress的EZ-BLE PRoC从模块到SoC的迁移路径是相对平滑的固件接口基本一致这让我在项目后期有比较大的调整空间。如果你一开始就焊了一颗裸片等到天线不达标、认证卡壳再改结构的成本就高得多了。第三个原则是要把功耗预算表和RF链路预算表做在前面。不是文档刷墙而是真正把所有状态广播、连接、深度睡眠、传感器采样、事件处理的电流和时间占比列成表格算出平均电流再反推电池容量。我见过太多项目是在原型做完之后才发现电池续航只有6小时那时候再优化功耗牵一发而动全身。先做估算后做验证这是硬件项目里最省钱的工作方式。6.2 从原型到小批量生产的关键差异原型能跑通不代表能批量生产。智能服装有几个在量产阶段才会暴露的问题提前心里有数会少交很多学费。第一个是织物洗涤的可靠性。原型机测试时不会有人真的把衬衫洗50次但量产后的用户一定会洗。织物电极、导线和PCBA之间的连接点在反复洗涤后会出现接触电阻增大甚至断路所以所有这些节点都要做机械加固比如超声波焊接 Hexoskin智能衬衫的BLE设计解析：从织物电极到Cypress模块
2014年前后我第一次拿到Hexoskin智能衬衫的拆解报告时最让我意外的是整件衣服的“大脑”居然是一颗来自Cypress赛普拉斯的EZ-BLE PRoC系列模块。那会儿绝大多数可穿戴设备还在用经典蓝牙传数据手机配对慢、功耗高而Hexoskin已经把实时ECG、心率、呼吸率这些医疗级生物特征数据全部压进了一颗基于ARM Cortex-M0核心的BLE SoC里。这正是今天这篇文章想拆开讲的东西——一件织物电极遍布全身的智能衬衫是如何通过Cypress EZ-BLE PRoC模块把生理信号稳定地送到手机App的。这篇内容适合三类人一是正在做智能服装、医疗可穿戴硬件选型的工程师想搞清楚BLE模块在织物环境里会遇到哪些坑二是做嵌入式BLE开发、想了解GATT服务如何承载多路生理数据流的朋友三是对Hexoskin这类产品好奇、想知道“一件衣服为什么能测心电图”的产品经理或爱好者。我会从硬件选型、信号链路、固件协议、实测坑点四个层面展开全程按实际项目推进的逻辑来讲能直接抄作业的地方尽量直接给参数和代码。1. 从一件智能衬衫说起Hexoskin到底在解决什么问题1.1 医疗级生物特征监测的硬件门槛Hexoskin的定位不是普通的运动手环而是医疗级别的贴身穿戴设备。它同时采集单导联ECG心电图、心率、心率变异性HRV、呼吸率、呼吸量、步数、睡眠分期等多项参数。注意ECG和光学心率是完全不同的东西——手环上的绿光PPG传感器测的是血液容积变化而Hexoskin用的是真正贴在胸口的织物电极放大心电信号这就意味着模拟前端的噪声要求、增益设计、抗干扰能力完全不是一个量级。医疗级ECG放大链路的输入噪声通常要在微伏级别才能看清P波和QRS波群。织物电极和皮肤之间的接触阻抗远高于传统凝胶电极动不动就是几十千欧到几百千欧而且还会随着身体动作大幅波动。这样一来放大器的输入阻抗必须做到GΩ级别偏置电流要足够小否则肌电噪声和运动伪影会把心电图彻底淹没。更麻烦的是衬衫是要水洗的织物电极经过几十次洗涤之后电极和导线之间的连接可靠性也会下降。这些物理层面的约束决定了Hexoskin的硬件团队从一开始就必须把“模拟前端性能”和“数字处理能力”放在同一个很小的PCB面积里考虑。我当时在国内跟做智能服装的团队聊天时很多人第一版方案都会用“MCU独立BLE射频芯片外置运放”的组合结果做出来的原型体积大、功耗高放在贴身衣物里既不舒适又容易掉线。这里面的核心问题不在于单个芯片选得好不好而在于系统级的集成度——如果你有多个传感器通道的数据要同步采集、压缩、无线传输那么主控和无线之间如果隔着一层SPI/UART接口无论是同步时序还是功耗优化都很难做到极致。Hexoskin直接选择带BLE收发器的PRoC模块让ECG前端和蓝牙协议栈跑在同一个芯片里本质上就是为了解决这个系统集成度的问题。1.2 为什么要用BLE而不是Wi-Fi或传统蓝牙对可穿戴设备来说无线协议的选择几乎决定了产品的功耗天花板。经典蓝牙BR/EDR建立连接后的射频功耗通常维持在几十毫瓦级别而且连接建立时间长达数秒Wi-Fi的功耗更高还要考虑天线面积和协议栈复杂度在一块只有拇指盖大小的模块上根本不现实Zigbee虽然低功耗但手机生态不支持用户不可能为了穿一件衬衫再买一个专用网关。BLE能成为唯一合理选项核心原因是它把“连接”变成了“按需唤醒”平时射频完全关闭只有设定的连接间隔窗口才打开一瞬间做数据收发其余时间系统可以继续睡。给Hexoskin这样的设备做功耗预算时你会发现连续ECG采样本身并不是大头。一个16位ADC、250Hz采样率、三通道同时采集满打满算也就是几千比特每秒的数据量功耗大概在几百微安到几毫安之间。真正吃掉电池的是无线传输的射频开销以及为了维持连接而必须周期性唤醒的协议栈。BLE的连接间隔connection interval可以从7.5毫秒到4秒之间配置每次连接事件只会开启一小段时间的收发窗口因此可以把平均射频电流压到几十微安甚至更低。这也是为什么Hexoskin能靠一颗容量不大的聚合物锂电池坚持数天——不是因为它省电省在传感器上而是省在了无线链路的调度策略上。另外BLE在手机端的生态成熟度也是一个决定因素。iOS从iPhone 4S开始就原生支持BLE 4.0Android从4.3API 18开始提供标准BLE API这意味着用户不需要任何额外适配器直接用手机App就能连上衬衫里的模块。相比Classic Bluetooth需要配对弹窗、配对后还要处理SPP之类的串口抽象BLE的GATT模型天然适合传感器数据流这种“多通道、低速率、结构化”的场景。EZ-BLE协议栈里封装好了完整的GATT服务负责产品的人只需要关注业务数据流不用去纠结底层射频和链路层怎么组织这大大缩短了产品从原型到交付的周期。2. Cypress EZ-BLE PRoC模块选它而不是nRF52832的理由2.1 EZ-BLE PRoC的硬件规格和BLE协议栈EZ-BLE PRoC是Cypress把自家PRoC BLEProgrammable Radio-on-Chip系列的SoC封装成模块的产品线典型代表是CYBLE-214009和CYBLE-013025这样的型号。模块内部通常已经集成了32-bit ARM Cortex-M0内核工作频率48MHz、BLE 4.2射频收发器、32.768kHz的RTC晶振、32MHz的系统晶振、天线、以及保证天线阻抗匹配的balun电路。换句话说一颗模块就是一颗完整的BLE节点外部只需要提供供电和传感器接口不用再去设计射频匹配网络也就绕开了整个硬件设计里最难验证的射频部分。协议栈方面Cypress现在属于英飞凌提供了一套完整且经过认证的BLE协议栈支持GAP通用访问协议、GATT通用属性协议、L2CAP、SM安全管理等所有标准层次。对Hexoskin而言最实用的是它支持自定义GATT服务并且允许开发者在Cypress的BLE组件里通过工具配置特征值、通知属性、安全模式和连接参数。这套开发环境虽然谈不上漂亮但在当时算是很稳定的。我记得Cypress的BLE协议栈有一个特点它把GATT数据库以“表”的形式维护用特征值句柄作为“索引”来定位读写操作。听起来有点绕但在实际调试时你是可以通过这个表索引快速找到某个特征值对应的处理函数入口的——这比一些其他厂商黑盒的协议栈要透明得多。这里顺便提一下我在项目中去翻数据手册时经常用到的“索引表”思维当一个GATT服务里有好几个特征值比如ECG数据、呼吸数据、设备状态、电池电量时固件里最忌讳的就是写一串if-else分支来逐个判断UUID。更稳妥的做法是维护一张服务定义表table把UUID、句柄、数据处理函数指针、通知开关状态全部做成结构体数组再用UUID或者句柄做索引index直接查表调用。这种“proc过程处理通过索引查表”的写法不仅代码量小而且后续要新增特征值只需要往表里加一行不容易漏。2.2 与主流BLE方案的对比我在选型时把当时的几条主流BLE路线放在一起比过简单列个表方案内核协议栈成熟度模块化支持备注Cypress EZ-BLE PRoCCYBLE系列Cortex-M0高Cypress官方好自带天线集成度高低功耗均衡Nordic nRF52832Cortex-M4F极高SoftDevice一般需自研射频性能强资料多当年很多高端产品用TI CC254x8051高有Module版经典但生态相对老旧Dialog DA14580Cortex-M0中有Module版功耗极低但Flash小Hexoskin选择Cypress而不是当年呼声更高的Nordic我猜测有几层原因。首先是模块化程度EZ-BLE PRoC直接以模块形式供货天线、晶振、匹配网络全集成通过了FCC/IC/CE等射频认证这对一个服装公司来说是非常重要的——毕竟团队的核心能力在纺织和生理信号处理不在天线调试上。其次是低功耗表现PRoC BLE在深度睡眠模式下电流可以到1微安级别而实际ECG连续传输场景下的平均电流也能控制在几毫安以内足够支撑数天的贴身佩戴。第三是供货和品控作为老牌半导体厂商Cypress的生命周期管理和可靠性测试做得比较扎实对医疗穿戴这种长周期产品来说这一点比纸面性能更重要。如果你今天重新做这个项目我当然会建议你把nRF52832甚至nRF52840也放进待选清单——它们的处理能力、Flash大小、社区生态在近几年已经追上来了。但如果你的团队缺乏射频经验产品的核心价值在传感器算法而非复杂的本地计算那么“带完整天线的认证模块”依然是我给你的首选推荐。与其花三个月调天线不如把时间花在呼吸算法和ECG滤波上这才是Hexoskin这类产品的护城河。2.3 天线设计与射频布线的实际考量聊完选型就得落地画板。EZ-BLE PRoC的模块封装设计得比较好把天线做成了PCB板载天线周围有一圈必须留空的禁布区keep-out area。这个禁布区在高频下是大事因为天线近场区域的金属、地平面、甚至高介电常数的材质都会改变天线的谐振频率和辐射效率。我第一次画板的时候偷懒把电池的金属外壳贴着天线放结果同一块板子在桌上测试RSSI是-45dBm贴到胸口直接变成-75dBm连接时不时就断。智能服装的挑战比普通手环更特殊天线周围是织物、人体和金属纽扣没有一个固定的环境。同样一块模块塞进棉质T恤和尼龙运动服里面介电常数不一样天线失谐程度也不一样。我当时看到Hexoskin的拆解图他们把天线区域刻意安排在了胸口偏上的位置周围尽量避开导电纱线和金属件而且模块底下的地平面做了比较完整的铺铜最大程度上减少了人体对天线的吸收。你可以理解为天线在人体附近本质上是在一个高损耗介质旁边工作能做的不是消除损耗而是让失谐后的驻波比尽可能平缓保证在几种典型穿着状态下都能保持可用灵敏度。3. 织物电极与BLE模块的硬件集成从传感器到天线的信号链路3.1 ECG/呼吸传感器的信号调理Hexoskin的信号采集链路可以拆成三段织物电极和呼吸传感器——模拟前端——数字处理与BLE模块。ECG部分通常使用三电极或者多电极布局信号进入芯片后先经过仪表放大器做第一级差分放大再接一个高通的二阶滤波去除基线漂移然后经过主放大和低通滤波最后进入ADC采样。这里面仪表放大器的共模抑制比CMRR至少要做到90dB以上否则工频干扰会从织物电极的不平衡阻抗里漏进来直接把心电信号盖掉。呼吸信号的采集是Hexoskin区别于大多数手环的地方。它用的不是简单的加速度计推算呼吸而是测量胸廓的膨胀变化常见方案有压阻式传感器带或者电感式体积描记RIP。RIP的原理是往织物里的线圈通一个高频小电流胸廓变化会改变线圈的电感进而改变振荡频率通过频率检测就能还原呼吸波形。这条链路的信号频率很低0.1-0.5Hz但幅度会受到运动伪影的调制所以模拟前端里要针对呼吸频段做一个窄带通滤波把高频肌电和运动冲击滤掉。值得强调的是这些模拟前端电路在PCB上的布局很讲究。心率和呼吸信号都是毫伏甚至微伏级别的弱信号如果数字部分的高频开关信号比如BLE射频在2.4GHz的突发发送通过地平面耦合进来哪怕只有几微伏也足以让ECG波形出现肉眼可见的毛刺。所以我通常建议把模拟前端和数字部分用星型接地或单点接地隔开ADC采样时序也尽量避开BLE的射频发送窗口——实际做的时候可以给射频发送加一个中断标志在发送期间暂停ADC采样或者丢弃该窗口的样本这个细节能大幅减少数据里的周期性噪声。3.2 模块供电与电池管理Hexoskin这件衬衫的电池不可能做得太大贴身穿的东西如果胸口鼓出一块电池别说用户了连我都不会愿意长期戴。所以整个系统的功耗预算是“挤”出来的。PRoC模块的宽电压输入通常是1.71V-5.5V具体要看型号让供电设计简洁了不少可以直接用一颗锂聚合物电池加低压差稳压器LDO供给模拟前端、数字部分和BLE射频部分。电池管理上有个容易被忽略的点ECG模拟前端和BLE射频的瞬态电流需求完全不同。BLE在发送数据的瞬间会从电源吸取十几毫安的脉冲电流如果LDO的动态响应不够快电源电压会瞬间跌落反映到ECG信号上就是一个低频的毛刺。我在项目里通常会给模拟前端的电源加一个低噪声LDO并用LC滤波器把数字电源和模拟电源隔离同时在BLE模块的电源引脚附近放一颗大容量的储能电容10μF级别专门负责给射频突发供电这样就能把电源跌落控制在一个可以接受的范围。另一个细节是电池电压监测。BLE的GATT服务里通常会放一个电池电量特征值但如果没有进行过校准这个值的实际意义很有限。我的做法是在固件里用ADC周期性采样电池电压然后根据锂聚合物电池的放电曲线做成一个分段线性的映射表又是查表把电压映射到百分比。这里的“表”要经过实际充放电曲线测量才能填好不能直接抄参考设计——不同容量、不同内阻的电池空载和负载下的电压差异很大。3.3 屏蔽和抗运动伪影处理智能服装最难搞的不是硬件性能而是动态场景下的可靠性。人在走路、跑步、翻身时织物和皮肤的接触状态会不断改变电极与皮肤的接触阻抗会出现低频大幅波动这个波动经过放大器之后就是所谓的运动伪影。处理运动伪影有几个层次第一是结构上保证电极始终贴合Hexoskin采用的是把电极编织进贴身面料里利用衣服的弹性提供持续的接触压力第二是模拟前端设计上加入自适应基线恢复电路通过积分反馈把直流偏置拉回到放大器的线性范围第三是在数字域做自适应滤波用加速度计信号作为参考来消除运动相关的噪声。射频链路上的屏蔽同样重要。织物本身对2.4GHz信号有一定的吸收如果导线走线离天线太近信号会被带着走导致辐射方向图畸变。我在同类项目里的经验是所有传感器导线尽量做成差分对并且在天线禁布区之外另走一路如果结构允许用一片金属化织物做一个局部屏蔽罩把模拟前端和数字部分隔开。Hexoskin的链路正是在这几个层面做了大量隐性优化才保证了用户从静坐到冲刺跑都能有连续可读的波形。4. 固件与数据链路如何用EZ-BLE把生理数据可靠地送到手机4.1 GATT服务设计与自定义Profile硬件链路搞定了接下来就是固件。Hexoskin集成了多个传感器通道如果用默认的Generic Attribute服务去传数据肯定不行。你需要自定义一个或多个GATT Service每个Service下面挂若干Characteristic分别承载ECG波形、呼吸波形、HRV指标、设备状态、控制命令和电池信息。设计自定义Profile时我强烈建议把数据结构做成查表驱动。具体来说在固件里定义一个特征值描述符数组每项包含UUID、值长度、读/写/通知权限、回调函数指针。当BLE协议栈收到来自手机的读取或写入请求时它首先根据句柄算出一个索引值然后拿这个索引去查找这个数组直接调用对应的处理函数。这种“index for table proc”的设计在有多路数据流的设备上可以避免在协议栈回调里写一大坨switch-case也让后续新增功能变得非常清晰。一个典型的自定义GATT服务结构大概是这样的CharacteristicUUID属性数据格式ECG波形自定义UUID-1通知16-bit采样值250Hz呼吸波形自定义UUID-2通知16-bit采样值100HzHRV/心率自定义UUID-3通知HR、RR间隔等控制命令自定义UUID-4写开始/停止/采样率配置电池状态自定义UUID-5读/通知电量百分比和电压每个通知型特征值在BLE协议栈里其实是一个环形缓冲区的“消费者”。数据采集线程比如ADC中断里往缓冲区写入样本而BLE协议栈在每次连接事件到来时从缓冲区里取一部分数据组成ATT通知包发给手机。如果你开启多个通知特征值要注意同一连接间隔内多个特征值的通知包不能超过链路层允许的最大包数量否则后面的包会被推迟到下一个连接事件带来额外的延迟。4.2 数据打包与传输策略生理数据是连续流式的你不能像传文件那样一帧一帧地丢。ECG 250Hz、每样本16位意味着每秒要传500字节呼吸波形100Hz、16位每秒200字节再加上HRV和状态信息总数据量大概在每秒1KB上下。这个速率对BLE来说并不高BLE 4.2的单连接最大可用吞吐量在几十KB/s瓶颈通常在Packet间隔和MTU大小上。如果用默认的MTU23字节一个数据包最多只能带20字节的应用数据每秒1KB需要拆成50多个包连接间隔稍微调大一点就会导致队列积压。更合理的做法是在连接完成后协商更大的MTU比如把MTU提升到247字节一次通知就能携带200多字节的样本数据大幅降低包的数量和中断频率。协商MTU的代码很简单就是发起一个MTU Exchange请求但很多开发者容易忘记在手机端也要把MTU配置上调导致协商失败后一直用默认值跑吞吐和功耗都不理想。数据帧格式方面我给每个传感器通道设计了统一的帧头帧起始标记、通道ID、序列号、数据长度、数据体、CRC16校验。序列号除了用来检测丢包还能让手机端把多路信号在时间轴上对齐——ECG和呼吸波形的采样时间戳不同如果不带序列号后期做HRV等分析时就很难对齐采样点。CRC16在BLE里面看起来有点多余因为链路层本身有重传机制但实测下来当手机处理不及时或后台被系统挂起时BLE的链路层重传并不能保证应用层数据的顺序完整性多一层CRC做最终校验还是值得的。4.3 功耗调优连接间隔与吞吐量的平衡接下来是BLE开发里最需要耐心调的一步连接参数。连接间隔connection interval决定了设备多久醒来一次和手机交换数据从机和主机的每次连接事件中又可以配置每个事件的包数量slave latency和超时时间。原理上很简单连接间隔越小数据延迟越低但收发窗口越频繁平均功耗越高连接间隔越大功耗越低但Buffer要做得更大否则数据会溢出。对Hexoskin这种连续数据流我的起始配置是连接间隔30-40毫秒从机延迟0超时3秒——这个组合能在功耗和延迟之间取得相对均衡实测ECG数据端到端延迟在100毫秒以内平均射频电流在2-3mA左右。如果只是想传心率这类低频数据可以把连接间隔拉到100毫秒以上再用Notification批量发送功耗还能降一个量级。计算吞吐量时我一般用这个简单公式有效吞吐 (连接间隔内可用的包数 × 每个包的负载字节数) / 连接间隔。假设MTU协商到247连接事件里最多能发6个包每个包有效负载244字节247-3的ATT头连接间隔40毫秒那理论吞吐大概是 6 × 244 / 0.04 36.6KB/s远高于我们的实际需求。这也是为什么我不建议为了速度盲目把连接间隔调到7.5毫秒——那会把功耗推高好几倍而你的数据量根本不需要那么高的速率。5. 实测中踩过的坑射频干扰、掉线和数据完整性问题5.1 天线净空区被织物覆盖导致的信号衰减我前面提过一次天线禁布区的问题但这里还是想单独拿出来讲因为这是智能服装项目里回报率最高的一次踩坑。原型阶段用的模块是直接焊在PCB上的天线朝外测试时拿在手里信号挺好但把整个PCBA塞进衬衫内侧的收纳袋后RSSI直线下降手机离开1米就开始断连。排查了几天最后发现不是软件问题而是收纳袋的面料正好覆盖在天线区域而且那片面料为了屏蔽静电还织入了导电纱线——天线等于被一个损耗很大的罩子罩住了。解决办法有两个方向一是调整PCBA在衣服里的摆放方向让天线尽可能贴近外层衣物且远离导电纱线二是选用外置天线版本的模块通过一根短的同轴线把天线引导到领口或袖口的位置。Hexoskin的实际产品里模块并没有放在正胸口而是放在了左侧肋下靠近腋下偏后一点的位置这个位置皮肤接触好、但离手机口袋通常在前侧或裤兜不算远同时避开了正面导电区域。如果你的产品结构允许尽量在天线附近不要放置任何金属纽扣、拉链头或者RFID标签这些都是隐形的信号黑洞。5.2 连接不稳定与重连机制老实说BLE在贴身穿着场景下的稳定性比实验室里差很多。实测中最常见的问题是手机锁屏进入后台后系统可能暂停BLE回调或者触发链路层超时断开衣服在洗涤、折叠后天线参数变化早期掉线率明显上升。一款智能衬衫要成为可靠产品重连机制比首次连接体验更关键。我在固件里做的处理是把连接状态机设计成“长连接优先、快速重连兜底”的双模式。正常情况下保持长连接但App端加入一个后台保活机制定期发一个空包检测链路。一旦检测到断连模块立即进入低功耗广播模式广播间隔设为100-200毫秒同时缩短广播超时时间避免浪费电App端则做后台扫描和自动重连最大重连次数和时间窗口都做了限制。这套机制让实际掉线后的恢复时间控制在几秒内用户体验上基本可以接受。另外要注意的是BLE协议栈里的“断开连接”有主动和被动之分。模块长时间没有收到主机的数据包会触发超时断开supervision timeout。这个超时值的配置不能太短我见过有人把超时设成500毫秒结果手机锁屏稍微卡一下模块就断连了。一般建议超时在3-6秒给系统留足缓冲。5.3 数据校验与断点续传数据完整性是医疗级产品绕不开的话题。BLE链路层的重传能保证单个包的可靠性但无法保证应用层的连续性和顺序性。我在多轮测试中发现当手机App被切到后台或者系统在做OTA时BLE通知包的到达间隔会出现几十毫秒到几百毫秒的抖动有的包还会被系统丢弃ECG波形上出现肉眼可见的断点。为了把丢数据的影响降到最低我做了两层设计。第一层是业务层校验每个数据帧都带序列号手机端检测到序列号跳变时通过一个控制特征值向模块发起补传请求模块从本地环形缓冲区重新发送缺失的一段数据。这个缓冲区的容量不需要太大以ECG的数据率算缓存10秒钟的数据大约只要5KB用模块内置的Flash或者一个外部SPI Flash很容易实现。第二层是业务层兜底当缓冲区溢出时优先保证ECG数据不丢呼吸和步数等低频数据允许降级。这套优先级策略在很多医疗可穿戴项目里都适用你不可能在所有异常场景下都保持全通道零丢失那就必须明确哪一路数据是“生命线”。6. 复盘与量产实话选型原则、洗水测试和产线筛查6.1 智能服装硬件选型的通用原则做了几个类似的贴身穿戴项目后我总结了一套选型原则不一定全面但足够避开大部分坑。选型时先问自己三个问题团队的射频经验有多少产品的核心竞争力在算法还是硬件传感器的数据量和实时性要求有多高如果射频经验不足直接选带认证的模块比如EZ-BLE PRoC这类如果核心竞争力在算法那么主控的Flash和算力要给够而不是一味追求最低功耗如果是多通道高频数据流BLE协议栈对多连接多个Central设备的支持也要在选型阶段就确认清楚。第二个原则是“模块先行SoC后移”。原型阶段用模块快速验证产品定型后再评估是否需要换成裸SoC以降低成本。Cypress的EZ-BLE PRoC从模块到SoC的迁移路径是相对平滑的固件接口基本一致这让我在项目后期有比较大的调整空间。如果你一开始就焊了一颗裸片等到天线不达标、认证卡壳再改结构的成本就高得多了。第三个原则是要把功耗预算表和RF链路预算表做在前面。不是文档刷墙而是真正把所有状态广播、连接、深度睡眠、传感器采样、事件处理的电流和时间占比列成表格算出平均电流再反推电池容量。我见过太多项目是在原型做完之后才发现电池续航只有6小时那时候再优化功耗牵一发而动全身。先做估算后做验证这是硬件项目里最省钱的工作方式。6.2 从原型到小批量生产的关键差异原型能跑通不代表能批量生产。智能服装有几个在量产阶段才会暴露的问题提前心里有数会少交很多学费。第一个是织物洗涤的可靠性。原型机测试时不会有人真的把衬衫洗50次但量产后的用户一定会洗。织物电极、导线和PCBA之间的连接点在反复洗涤后会出现接触电阻增大甚至断路所以所有这些节点都要做机械加固比如超声波焊接