过去几年我在嵌入式项目里折腾过不少无线通信方案从早期的蓝牙2.0模块一路做到现在的BLE 5.x踩过的坑能填满一个仓库。手头这个E104-BT02模块是亿佰特出的BLE蓝牙通信模块主打低功耗和透传最让我满意的是官方把参考电路和底层驱动代码都开源了改起来非常顺手。这篇博文就围绕“5分钟上手”这个目标带你把硬件连接、AT指令配置、驱动代码移植到实际项目联调整个流程走一遍。E104-BT02本质上是把一颗支持BLE 5.0的SoC系统级芯片连同射频匹配网络、晶振、天线全部集成在一个小板上对外暴露串口和几个控制引脚。你不需要关心蓝牙协议栈怎么跑只要通过串口发AT指令或者直接透传数据就行这对那些精通单片机但不太熟悉蓝牙协议栈的工程师来说是很友好的工作方式。再加上官方提供了参考电路图以及兼容STM32、ESP32等平台的示例驱动代码无论你是在做智能家居网关、传感器数据采集还是便携式医疗设备都能快速把BLE通信能力集成进去不用自己从零开始啃蓝牙核心规范。老规矩先说清楚这篇文章适合谁看手里有E104-BT02模块但不知道怎么下手的初学者想把模块快速集成到现有产品里的嵌入式工程师以及正在选型BLE透传模块的方案评估人员。如果你对BLE协议栈已经有深入了解那这篇文章的部分内容可能偏基础但关于驱动移植和低功耗调试的章节应该还是能给你一些启发。1. 内容整体设计与思路拆解1.1 E104-BT02的核心定位与选型理由先聊聊为什么选E104-BT02而不是市面上其他BLE模块。BLE透传模块有很多选择比如经典的CC2541方案、nRF52832方案或者国产的TLSR8258方案。E104-BT02用的是泰凌微TLSR8258芯片这颗芯片在国产BLE方案里出货量很大稳定性经过市场验证而且模块价格相对进口方案有明显优势。从选型角度看这里有几个关键决策点值得展开BLE 5.0协议支持相比BLE 4.2BLE 5.0的广播速率提升了8倍广播数据包速率从1Mbps提升到2Mbps虽然实际透传达不到但广播扫描的效率和响应速度确实有提升广播数据长度从31字节扩展到255字节这意味着一包能传更多业务数据。对于需要广播自定义数据的场景比如ibeacon或设备状态广播BLE 5.0优势很明显。主从一体设计模块既可以作为从机被手机连接也可以作为主机主动去连接其他从机设备。这个特性在做网关类产品或者蓝牙桥接方案时非常实用比如用两个E104-BT02模块实现串口透传桥接替代有线连接。完整透传协议模块内部已经实现了UART数据到BLE GATT服务的映射你发串口数据远端就能在BLE特征值里读到远端写特征值你这边串口就能收到。省掉了自己设计UUID、特征值、通知开关等协议层工作。开源电路和驱动这一点是加分项。官方开源的参考电路可以直接拿去做产品主板设计驱动代码覆盖了主流MCU平台节省了大量底层的适配时间。1.2 BLE方案的“透传”模式与AT指令模式的本质区别在说透传之前得先把E104-BT02的两种工作模式理清楚。理解这两种模式是上手的第一步我发现很多用户在这里被绕晕导致后面配置出现各种“莫名其妙”的问题。第一种是AT指令模式模块上电后先进入AT指令模式你可以通过串口发送AT指令来配置模块的参数比如修改设备名称、广播间隔、串口波特率、MAC地址等。这些配置是持久化存储在模块内部的Flash里的配置完成后复位模块就会进入透传模式。这里有个细节要注意工作模式是由MD0和MD1两个引脚的组合电平决定的不是纯软件切换硬件上必须留出这两个引脚的控制IO。第二种是透传模式模块在正常工作状态下串口收到的所有数据都会自动打包成BLE数据包发送出去远端设备通过GATT特征值读写就能收发数据完全不需要关心蓝牙底层的组包拆包。反过来也一样。这种模式最适合“串口替换”类应用原来设备之间用串口通信现在把一端换成E104-BT02另一端用手机或者另一个模块接物理链路就变成无线了但应用层的代码几乎不用改。还有一个更进阶的玩法是主从透传模式模块作为主设备主动去连接另一个作为从设备的E104-BT02模块建立连接后两个模块之间的所有串口数据会自动互传。这种模式非常适合工业现场的两台设备无线通信等效于一根无线串口线。1.3 低功耗设计思路BLE的核心竞争力在哪BLE和经典蓝牙BR/EDR的一个核心区别就是功耗。经典蓝牙在连接状态下功耗普遍在几十毫安级别而BLE的峰值电流虽然也在十几毫安级别但占空比极低平均功耗能做到微安级别。E104-BT02贴片封装的模块在广播状态广播间隔200ms下平均电流大约在50-60μA在连接状态下则取决于连接间隔通常在几十微安到几百微安之间。这里的“低功耗”不是单纯靠芯片本身的硬件能力更重要的是你的使用方式。BLE功耗的关键在于两个参数广播间隔Advertising Interval和连接间隔Connection Interval。广播间隔越长模块处于待机/睡眠状态的时间越长平均功耗越低但被扫描设备发现的速度就越慢。连接间隔越长每次连接事件发送的数据量越大由单次事件内的数据包数量决定平均功耗越低但延迟会升高。实际项目中我一般这样权衡需要被手机快速发现的应用广播间隔设置在100-200ms对功耗极其敏感且不要求快速发现的场景比如传感器标签广播间隔可以拉到1秒以上。需要强调一下E104-BT02默认的连接间隔经过厂商调优在大多数场景下不需要修改除非你有明确的低延迟或低功耗需求否则用默认值就好。2. 硬件连接与开源电路解读2.1 引脚定义与典型接线参考E104-BT02模块本身的引脚不多典型封装是半孔贴片常用的引脚定义如下引脚名称方向功能说明备注VCC电源输入模块供电范围1.8-3.6V推荐3.3V纹波尽量小GND电源地接地尽量短靠近退耦电容TXD输出UART发送接MCU的RXRXD输入UART接收接MCU的TXMD0输入模式控制引脚0拉低进入透传模式拉高进入AT模式MD1输入模式控制引脚1通常接GNDAUX输出状态指示模块上电或连接状态变化时会输出低电平脉冲可用于MCU检测模块状态接线时需要考虑两个容易出问题的地方供电纹波BLE模块在射频发射瞬间电流会有较大波动瞬态电流可达20-30mA如果电源纹波太大可能导致模块复位或发射功率下降。建议在模块供电引脚旁边就近放置一个10μF或22μF的电容加上一个100nF的高频退耦电容。电平匹配E104-BT02的UART是1.8V-3.6V电平兼容但不是5V耐压的。如果你的MCU是5V供电比如经典AVR或某些STM32的5V容忍引脚串口TX到模块RXD之间最好加个电阻分压或者电平转换电路。我见过不少用户直接把5V接到VCC或者把5V串口信号怼到模块RXD上模块工作不稳定甚至烧毁就是这个原因。2.2 原理图设计从官方参考电路到产品化改良官方开源的参考电路是E104-BT02模块的核心价值之一说明厂商是真心想让用户把模块用进产品里的。参考电路里关键的部分就几个电源部分模块VCC前面加了一个LC滤波或磁珠电容的π型滤波结构这个结构主要是为了滤除高频噪声防止噪声通过电源引脚耦合进射频前端影响发射频谱纯净度。天线部分使用的是板载PCB天线或外置天线座天线周围的布线有明确的净空区要求参考设计里已经给出了这个禁区范围。复位电路模块的RST复位引脚接了一个上拉电阻和一个小电容上电时确保模块正常复位。产品化时我在参考电路上做了两个改动分享给你参考第一在天线禁区下面加了一排过孔via fence。这些地过孔把天线的辐射区域与主板其他铺铜区域隔开能有效减少主板电路对天线辐射性能的影响。实测下来加了过孔栅栏之后天线效率大约提升了1-2dB。第二把模块的AUX引脚接入MCU外部中断。官方参考电路里AUX是可选的但实际项目中这个引脚的用处很大模块连接状态变化、数据发送缓冲区从满到空、模块启动完成等事件都会在AUX引脚上产生脉冲。用MCU的外部中断去捕捉这些脉冲可以实现阻塞式发送判断、连接状态监控等功能比轮询串口缓冲区要可靠高效得多。2.3 天线布局经验为什么你的模块收发距离比别人近一半关于天线布局这是最容易踩坑的地方很多用户遇到过同样的两个模块桌上测试好好的装进外壳里距离直接砍半甚至完全连不上。这里的问题十有八九出在天线周围的环境上。E104-BT02的板载天线是全向天线辐射方向性近似一个“甜甜圈”形状最大辐射方向是垂直于天线所在平面的方向。在实际布局时模块的天线端要尽量放置在外壳的边缘或角落天线正上方和周围3-5mm范围内不要有金属物体螺丝、屏蔽罩、电池等不要有整片的铺铜。还有一个容易忽视的细节天线正下方的主板内层。如果在模块天线区域的背面顶层对应模块底层或内层有完整的铺铜相当于在天线下面放了一片反射板天线的等效辐射效率会下降。你可以做一个小实验找两块同样的E104-BT02模块一块模块天线区下方的PCB全部掏空另一块保留铺铜实测无误的结论是掏空后的接收灵敏度普遍好1-3dB。3. 驱动代码与AT指令实操要点3.1 快速初始化从AT指令到广播开起来模块上电后默认是透传模式要进行配置需要先把MD0引脚拉高然后复位上电进入AT指令模式。这一步对很多用户来说是个“先有鸡还是先有蛋”的问题模块在透传模式下串口收到的是普通数据不会被当指令解析所以必须先切换模式才能配置。我一般用串口调试助手波特率默认115200发送指令整个初始化流程如下AT // 测试指令模块返回 OK ATE0 // 关闭回显指令不会回显到未应答内容中很多用户忘记这步导致透传数据时混入指令回显 ATNAMEE104-BT02-Demo // 修改广播名称 ATMAC112233445566 // 修改MAC地址按需配置要确认模块是否允许修改 ATBAUD115200 // 设置串口波特率 ATADVINT200 // 设置广播间隔为200ms ATRESET // 复位模块使配置生效这里要注意几点每条AT指令必须以\r\n回车换行结尾这是很多初学者第一次用AT指令时最容易忽略的地方。指令不分大小写但参数有区分比如名字里的字母会按ASCII原样保存。ATRESET之后模块会重启并进入透传模式前提是MD0拉低。之后所有串口收到数据都会直接转发到BLE链路。如果你想在这个流程中快速验证模块是否正常广播可以先用手机打开蓝牙扫描或使用专用的BLE调试工具手机应用商店里搜索“BLE调试助手”“nRF Connect”等扫描列表中会出现你在ATNAME里设置的名字。3.2 驱动代码结构官方示例代码怎么移植官方开源的驱动代码是按“平台外设抽象”的思路设计的核心逻辑在中间层底层串口驱动和定时器驱动通过几个弱函数接口对接。你拿到代码后一般只需要做两件事第一实现串口收发接口。官方提供了STM32平台和标准C平台的示例。如果你用的是STM32可以把示例代码里对HAL库的调用往自己的工程里搬如果是其他平台就用你最顺手的串口驱动替换掉底层那几十行代码。第二配置串口参数宏。在e104bt02.h头文件里有几个宏定义比如串口实例的句柄、波特率、数据位、停止位等。把这些宏改成你自己的串口资源就可以。下面是一个官方STM32示例代码中串口发送接口的简化结构/* e104bt02_port.c — 平台适配层 */ void E104BT02_UART_Init(uart_handle_t *huart) { /* 硬件串口初始化波特率默认1152008N1 */ HAL_UART_Init(huart); } void E104BT02_UART_Send(uint8_t *data, uint16_t len) { /* 把数据通过串口发送给模块 */ HAL_UART_Transmit(huart, data, len, 100); } void E104BT02_UART_ReceiveCallback(uint8_t data) { /* 从模块收到的数据丢给协议层处理 */ e104bt02_handle_rx_byte(data); }移植的关键点在于接收数据不能丢字节。BLE透传模块的串口波特率一般是115200也就是每秒约11.5KB的数据量。如果MCU的中断响应不及时或接收缓冲区太小数据就会溢出丢失。官方示例代码里用的是环形缓冲区缓冲区建议至少256字节能覆盖单次BLE事件的最大数据量。3.3 透传模式下收发数据的优化技巧透传模式下把串口数据变成BLE数据再发出去这里有个性能卡口MTU大小。BLE的默认MTU是23字节其中数据部分最多只有20字节。这意味着如果你一次性发500字节数据模块会帮你分成好多个20字节的包来发送这会导致吞吐量上不去。E104-BT02支持MTU协商Network层手机端或者主设备发起MTU协商请求后双方可以协商到更大的MTU最大能到247字节。这样透传的每个数据包就能装下最多244字节的数据吞吐量能提升好几倍。实际操作中手机端主控如果使用BLE调试助手通常在连接建立后会在“MTU”设置里发起协商选择247字节即可。模块端不需要额外配置自动响应协商请求。但要注意的是MTU协商成功后你发给模块的串口数据依然是“流式”的模块会按当前MTU大小自动分片。从一个数据包大小只有20字节的设备收到246字节的串口数据到MTU协商完毕后收包大小的变化这个过程中应用层的拆包逻辑基本不用改因为透传模式对应用层数据本身不做业务拆包处理只负责把数据从短包聚合或者分开塞进BLE链路。如果你对数据吞吐量有更高要求还可以考虑调整两个参数连接间隔模块与主设备的连接间隔默认通常是30ms-50ms。连接间隔越短单位时间内能传输的事件越多吞吐量越高但功耗也越高。如果项目对实时性要求高可以把连接间隔配置到15ms但这对模块端功耗会带来明显影响。单次连接事件的数据包数量这个参数一般没有对外暴露模块固件内部已经做了优化。如果非要对吞吐量死磕建议直接联系原厂技术支持确认固件版本是否支持参数调整。3.4 广播类型与扫描响应包的配置选择广播行为在BLE协议栈里是个绕不开的话题E104-BT02提供了多种广播类型配置查询AT指令手册能看到类似ATADVTYPE...的指令。广播类型主要分为几类实际项目中根据应用场景选择广播类型说明适用场景可连接非定向广播默认类型可以被任何扫描设备扫描和连接通用透传手环智能灯泡可连接定向广播只针对指定MAC地址发起连接点对点绑定场景比如遥控器与接收器固定配对不可连接非定向广播只广播数据不允许连接信标类应用iBeacon、传感器广播状态可扫描非定向广播可以被扫描但不允许连接被动式传感器发布状态数据我在实际项目中最常用的就是“可连接非定向广播”和“不可连接非定向广播”两种。传感器标签类应用用不可连接广播发完数据就进睡眠功耗最低但手机需要挂上扫描才能收集数据。需要双向通信的设备比如车锁数字钥匙、门禁系统用可连接广播手机连上后走GATT通道收发指令。还有一个概念容易被忽视扫描响应包Scan Response。普通广播包Advertising Data最多31字节如果你想广播的信息超过31字节可以把一部分内容放到扫描响应包里。扫描响应包只有在设备发出扫描请求Scan Request时才会回复效率低于广播包但能有效扩大广播数据的容量。E104-BT02也提供了对应的配置指令在需要广播较多自定义数据时可以用上。4. 从BLE连接机制到常见问题排查4.1 一次典型的BLE连接过程是怎么走的看懂了连接过程你就理解了模块很多隐晦工作状态的来源。一次标准的BLE连接建立流程大致是这样的第一步广播与扫描。从设备E104-BT02在广播通道上周期性地发送广播包包里包含设备地址、设备名称可省略、是否可连接等信息。主设备手机或另一个模块在扫描时收到广播包决定是否要对此设备发起连接请求。第二步连接请求。主设备向从设备发送一个CONNECT_REQ连接请求里面携带了接下来连接使用的参数连接间隔、从设备延迟、监督超时等。从设备收到这个请求后双方就从广播态切换到了连接态。第三步连接事件与参数协商。连接建立后主从设备按照约定的连接间隔定期唤醒交换数据。在这个过程中双方还有机会通过“Connection Parameter Update Request”来协商连接参数比如把连接间隔调长或调短。第四步MTU协商。为了让数据链路效率更高双方通过Exchange MTU Request/Response交换各自支持的MTU大小取较小的那个作为之后通信的MTU上限。第五步服务发现。主设备发现从设备的GATT服务列表找到需要读写的Characteristic至此通信准备完成。熟悉这个流程对排查E104-BT02的很多问题非常有帮助。比如“手机能扫描到模块但连接不上”那问题大概率出在第三步之前要么广播类型配置成了不可连接要么模块被上一个连接占着一个从设备同一时间只能维护一个连接。4.2 BLE中的绑定Bond与配对Pairing手机连接模块时常见的坑“绑定”这词在BLE调试助手里很常见热搜词里出现“ble调试助手绑定(bond)”不是偶然。很多用户遇到的问题是手机第一次连接模块后把模块设为需要配对Pairing且要求绑定Bond第二次连接时手机与模块两边的密钥不一致导致连接失败。BLE的“配对”指的是建立加密链路的过程而“绑定”是指在配对过程中生成并存储长期密钥LTK以便下次重连时无需重新配对。E104-BT02模块支持在配置指令中使能配对/绑定要求。如果模块开启了“需要配对”但手机端BLE调试助手恰好不支持自动配对弹窗就会出现扫描到了却连不上的尴尬。解决方案分两种如果模块只是透传用不涉及敏感数据可以直接关闭配对/绑定功能简化连接流程避免不必要的兼容性问题。如果产品确实需要加密通信比如开锁指令建议在模块配置中将配对模式设置为“Just Works”或“Passkey Entry”手机端需要主动弹出配对确认或输入PIN码。这个过程中手机端需要在BLE调试助手设置里开启“自动接受配对请求”否则连接会卡在配对阶段。我个人建议除非有明确的安全需求配对加密功能在前期原型验证阶段可以直接关掉等产品逻辑跑通后再开启否则会浪费大量时间在蓝牙安全模型上。4.3 手机扫描不到/连接不上的常见排查清单结合以往的经验我把E104-BT02常见的“手机端异常”问题整理成一张速查表异常现象可能原因排查顺序扫描不到模块模块处于AT指令模式未复位或广播间隔太长或模块未上电1. 确认串口能返回AT指令响应2. 确认MD0为低电平并复位3. 缩短广播间隔到100ms再测扫描到但连不上模块已被其他设备连接或配对模式导致连接卡住或信号强度太弱1. 重启模块释放连接2. 关闭配对功能测试3. 把模块和手机放近到10cm内排除射频问题连接后串口收发无数据串口TX/RX接反或波特率不一致或数据在透传模式被协议层缓存未触发发送1. 用示波器/逻辑分析仪看串口波形2. 确认两端波特率都是1152003. 检查透传模式下数据字节是否超过单次BLE包长度需等待分组发送数据收发很慢MTU过小或连接间隔过长或两端BLE协商失败1. 手机端主动协商MTU到2472. 确认连接成功后再测速3. 用nRF Connect查看连接参数4.4 低功耗项目的功耗排查与优化建议E104-BT02宣称是低功耗模块但很多用户在实际项目里测出来的功耗并不低甚至比预期高一个数量级。排查思路我总结如下检查是否存在空闲态频繁唤醒模块在没有数据时是否进入了睡眠模式如果MD0/MD1引脚配置不正确模块可能一直维持在某种工作状态无法进入睡眠。检查模块有没有持续在串口上收到噪声/垃圾数据如果MCU的TX引脚在模块睡眠期间产生毛刺模块会被错误唤醒并尝试处理垃圾数据造成电流异常升高。解决方法是在模块RXD串联一个1kΩ电阻限制毛刺电流同时在软件上确保MCU串口引脚在空闲时保持稳定电平。校准平均功耗的正确测量方法BLE的功耗是脉冲式的用万用表的直流档测出来的电流值会是平均值反应慢测不出瞬时尖峰。正确做法是用电流探针配合示波器或者用功耗分析仪记录一段时间内的电流波形再计算平均功耗。低功耗调优是一个持续优化的过程先用示波器抓广播峰值电流和连接峰值电流再用万用表或功耗分析仪测平均电流最后根据实际占空比计算理论平均功耗与实测对比。如果实测远高于理论值基本可以确定是模块频繁被异常唤醒或没有正确进入睡眠模式。5. 开源资料的实战延伸与扩展玩法5.1 基于开源电路做产品化改板时的几个厂商不细说的细节官方开源的原理图能让你少走很多弯路但产品化改板时有几个细节官方资料里没有明确强调这里我花点篇幅展开模块的晶振负载电容。官方电路图中晶振旁边标注了电容值但在实际布局时电容的位置、走线长度都会影响晶振起振的稳定性。如果模块出现上电后偶尔无响应、AT指令偶尔超时多半跟晶振布局有关。保持晶振靠近芯片引脚走线尽量短两个负载电容对称放置这是最基本的要求。射频匹配网络尽量不要改动。100nF、1pF这些电容的容值在射频频率下会因为寄生参数发生偏移官方参考电路里的数值是经过网络分析仪调校过的。如果你想在改板时调整这些电容必须要用矢量网络分析仪重新调试匹配网络否则发射功率和接收灵敏度都会劣化表现为“收发距离严重缩短但功能正常”。天线净空区落实到位后还要考虑外壳对天线的影响。模块放在塑料外壳里一般没问题但如果外壳里靠近天线位置有金属支架、螺丝柱、电池弹片天线谐振频率会发生偏移。稳妥的做法是在天线正上方留出至少5mm的空腔或者微调匹配电容补偿谐振频偏。5.2 官方驱动代码基础上能做的三个实用扩展官方驱动代码虽然能用但离“产品级”还有距离。我在实际项目中在它上面叠了三个扩展扩展一串口分包/粘包处理。BLE透传天然是“包”式的而串口应用更习惯“流”式。如果远端设备一次性发来500字节模块会分多个BLE包发过来你的串口接收端如果简单地把数据拼起来发到应用层应用层很难分辨这是哪一包。我在驱动代码里加了一个简单的帧格式帧头长度数据CRC校验。应用层只有收到一帧完整数据才做业务处理。这个改动彻底解决了“数据多了就乱套”的问题。扩展二FOTA固件空中升级预留接口。BLE透传模块固件本身可以升级但如果你在自己的产品上把模块焊死在主板上再想通过有线方式升级固件就很麻烦。我在驱动代码里预留了FOTA功能通过BLE虚拟串口接收升级固件的数据流在应用层暂存到外部Flash比如ST25VF080B这类SPI Flash校验通过后通过模块的串口写入模块的固件升级模式。这个功能在产品出厂后的维护阶段能省掉大量拆机返工成本。扩展三断言与日志系统。嵌入式开发里最怕“偶发问题”。我在驱动代码里加了一个简易日志系统所有串口收发事件、BLE连接状态变化、关键配置参数的变更都会带时间戳记录到日志Flash同时设备支持通过特定AT指令导出日志。产品在用户现场出了问题先导日志再分析排查效率能提高好几倍。5.3 组合玩法E104-BT02在数字钥匙与网关类项目中的应用思路热搜词里有个“BLE数字钥匙”用它作为收尾例子很合适。E104-BT02在数字钥匙类项目里有几种典型用法车载数字钥匙模块作为车端BLE从机手机通过加密通道与车辆建立连接完成身份认证后执行开锁、启动等操作。这个场景对安全性要求极高模块必须支持配对绑定和链路加密同时需要低功耗让车辆在休眠状态下仍能保持广播检测。智能门锁模块作为门锁端的BLE从机手机APP通过GATT发送开锁指令。这种场景下模块平时要进入低功耗监听状态当手机靠近时通过RSSI信号强度触发唤醒完成开锁操作。RSSI触发阈值的调优是个细活设得太高会频繁误触发设得太低则用户体验不好。室内定位/蓝牙网关E104-BT02作为主设备扫描周围的BLE信标把收到的广播数据包括设备MAC、RSSI通过串口传给网关MCUMCU再通过WiFi/以太网传到服务器实现设备定位和追踪。这种用法里主设备扫描时的功耗和扫描效率是关键指标。类似地如果你想用ESP32-S3做BLE配网或者用esp32跑BLE controller做更多定制化开发E104-BT02也完全可以作为一个低功耗从设备去配合ESP32的方案完成整个系统的拼图。BLE生态的玩法很多模块只是其中一块积木真正的价值取决于你如何组合这套开源电路和驱动代码。6. 写在最后的几条实测心得从第一次拿到E104-BT02到现在我在好几个项目里都用过这个模块整体评价是上手成本低、文档相对完善、稳定性对得起价格。下面这几条是我在实际使用中沉淀下来的心法供你参考第一永远不要跳过串口回环测试。拿到模块的第一件事先不要接MCU直接用USB转串口接模块用调试助手发AT指令确认模块本身工作正常。这一步能排除掉“模块本身有问题”的最坏情况。第二电源对这个模块来说比什么参数都重要。我遇到过模块随机死机、透传丢包、广播偶尔消失最后都排查到电源上锂电池供电时电芯内阻大模块发射瞬间电压跌落导致芯片复位。加了100μF钽电容后问题彻底消失。BLE模块对电源动态响应要求很高这一点怎么强调都不过分。第三透传数据最好加自己的通信协议。很多用户把E104-BT02当成一根无线的线串口发什么就透传什么表面上看没什么问题但一旦数据量上来、多个数据源交错发送数据边界就混乱了。我的做法是应用层自己做分包、编号、校验宁可牺牲一点吞吐量保证数据完整性。BLE链路其实并不可靠空中的干扰、连接参数的抖动都会导致数据在某一层被丢弃如果应用层完全没有校验重传机制数据的正确性就只能靠运气了。第四低功耗是一个系统设计不是模块参数设置。你可以在模块端把功耗参数调得很好但如果MCU每个几十毫秒就唤醒一次发一个字节整机的平均功耗依然会很高。设计低功耗产品时要从系统级做功耗预算明确每个外设的唤醒周期、工作时间、工作电流然后优化整机调度。最后再分享一个小技巧调试E104-BT02时手机端不要只装一个BLE调试助手。我一般是nRF Connect和“BLE调试助手”两个应用配合着用——nRF Connect看GATT服务、连接参数、MTU协商等细节另一个应用用来做透传压力测试。两者各有侧重能覆盖绝大多数调试场景。如果你手头还有逻辑分析仪记得把模块的串口TX/RX接上去很多“模块不工作”的问题从波形上基本一眼就能看穿。