开头我在开发一个低功耗传感器节点时遇到了一个很现实的问题硬件产品需要跟手机通信但是BLE协议栈、射频匹配、天线设计这些知识对我来说完全陌生——我是个做单片机的不是做射频的。那阵子天天翻蓝牙协议文档越看越头大。后来同事甩给我一个模块说别折腾了用这个然后丢给我一块E104-BT02。说实话第一次听到5分钟上手这种宣传语我是嗤之以鼻的。但真正把模块接到串口、打开手机调试助手、第一次让数据从手机飞到MCU里那一刻我承认这个说法基本没有水分。E104-BT02是一个BLE透明传输模块模块内部已经把协议栈和射频前端全部封装好了你只需要通过串口或者SPI接口跟它对话。这篇文章我会把这套方案的完整链路拆开——为什么选模块而不是裸芯片、硬件电路怎么接最稳、5分钟打通透传的具体操作路径、开源驱动代码的结构以及我实际踩过的掉线、绑定、低功耗这些坑。适合谁看想快速给产品加手机交互能力的嵌入式工程师、做物联网原型验证的开发者、以及刚接触BLE但不想从协议栈啃起的入门玩家。1. 为什么是E104-BT02模块化BLE开发的选型逻辑1.1 BLE协议栈的复杂度是选模块而非裸芯片的根本原因很多人纠结一个问题现在nRF52832、ESP32-C3这些芯片这么便宜为什么还要用模块我一开始也是这个思路——自己画板子、自己写协议栈多酷。结果第一步就卡住了。BLE协议栈不是简单的库函数调用它涉及GAP层的广播和连接管理、GATT层的服务定义、L2CAP层的分包重组、链路层的加密和跳频机制每一层都有各自的时序要求和状态机。nRF52832的SDK光协议栈相关的源码就有几个G光是配置工程就要折腾一整天。而射频前端是另一个更隐蔽的坑。蓝牙工作在2.4GHz频段天线匹配网络的走线长度、阻抗控制、PCB叠层设计稍有偏差通信距离就会从标称的50米缩水到5米。这些经验不是看几篇应用笔记就能掌握的需要射频测试仪器反复调试。用模块就把这些问题全部屏蔽掉了——模块厂商已经把晶振匹配、天线阻抗、协议栈集成全部做好了并且做了量产级的射频指标测试。对我这种射频门外汉来说这是成本最低的路径。还有一个现实原因认证。产品要做FCC、CE认证射频部分是最容易出问题的环节。使用已经通过认证的模块可以直接引用模块的认证报告大幅缩短认证周期。这也是为什么很多成熟的物联网产品内部用的都是一个小铁壳模块主控的结构。1.2 E104-BT02与市面常见BLE模块的定位差异市面上BLE模块大致分两类一类是串口透传模块比如E104-BT02、HC-08、JDY-08特点是自带协议栈和应用层逻辑MCU只需要发AT指令配置参数之后就可以像操作普通串口一样收发数据另一类是协议栈开放模块比如Nordic原厂的nRF52832模块、TI的CC2540模块这些模块给你一个可以二次开发的SDK你需要在上面自己写应用层代码。E104-BT02属于前一类它基于Nordic nRF52系列芯片支持BLE 5.0。这类透传模块的核心价值不在于芯片本身多强而在于它把BLE的操作抽象成了串口写数据、串口读数据这样简单的接口。硬件设计上它引出了VCC、GND、TXD、RXD、AUX、MD0等核心引脚其中AUX是状态指示输出MD0用于模式切换。相比之下HC-08是蓝牙4.0方案协议栈和兼容性稍老JDY-08在价格上有优势但固件更新不如一线大厂频繁。E104-BT02的优势在于AT指令集完整、资料开源程度高、驱动代码有官方维护后面我会专门讲它的开源电路和驱动代码怎么用。1.3 一套5分钟上手的选型清单在实际项目中我总结了一套固定的选型评估项每个候选模块都要过一遍接口方式是否支持UART透传是否支持SPI你的主控有什么空闲外设。供电范围能否支持你现有的电源系统E104-BT02工作电压1.8到3.6V典型3.3V。功耗指标注意区分峰值电流、平均电流和休眠电流三个指标很多模块宣传的超低功耗指的是休眠态实际连上之后平均电流大不相同。传输速率BLE的吞吐量受到MTU和连接间隔影响官方宣称的波特率是串口速率实际无线吞吐可能只有一半。开源程度电路和驱动是否完整开源遇到问题能不能自己排查。天线形式PCB板载天线适合短距离、成本敏感的产品IPEX天线适合需要拉远距离或者金属外壳场景。这套清单可以帮你快速过滤掉不合适的方案避免选型走弯路。2. 引脚全解与电路连接漏接一个上拉电阻的代价2.1 引脚功能对照与最低系统接线先上一份核心引脚功能表。E104-BT02不同批次引脚排列可能略有差异但功能引脚就这几个对照手册找到即可引脚方向功能说明注意事项VCC输入模块供电范围1.8~3.6V严禁超过3.6V典型用3.3VGND输入电源地必须与主控共地TXD输出模块串口发送接主控的RXRXD输入模块串口接收接主控的TXAUX输出状态指示高电平表示模块忙碌可接MCU的GPIO中断MD0输入模式控制悬空/拉低为透传模式拉高进入配置模式SWCLK/SWDIO输入固件升级和调试接口正常使用可以不接最低系统接线只需要五根线VCC、GND、TXD、RXD外加一个AUX用于状态检测不接AUX也能跑透传但无法判断模块是否已经进入可通信状态。模块的TXD和主控的RXD要交叉连接这是新手最容易犯的错误——我见过好几个人拿着模块干瞪眼发现数据发不出去最后发现是把TXD接到了主控的TX上。一个很重要的细节模块的RXD内部没有做5V容忍如果你的主控是5V供电的比如老款Arduino或者某些电平是5V的STM32板子直接连接可能会把模块的RXD引脚击穿表现为模块有时候能收到数据有时候完全不动。正确做法是用MOSFET电平转换芯片或者最简单的用两个电阻做分压——我用的是BSS138双向电平转换电路成本几毛钱稳定跑了一年多。2.2 串口参数与模式切换的硬件设计E104-BT02出厂默认波特率通常是115200、8数据位、无校验、1停止位。模块上电后默认进入透传模式只要MD0保持低电平或悬空这个模式下所有从串口收到的数据都会通过BLE无线发出手机端发来的数据也会从串口输出。如果要做参数配置需要拉高MD0引脚然后给模块重新上电进入AT指令模式。我在电路设计上踩过一个坑MD0引脚只用一个普通的GPIO去控制没加上拉电阻。结果在强电磁干扰环境下模块偶尔会莫名其妙进入AT模式然后透传数据就全部变成了乱码。排查了很久才找到原因——模块的MD0输入阻抗很高干扰信号能直接拉高这个引脚。解决方案是在MD0和GND之间并一个10k的下拉电阻确保默认状态始终是透传模式同时GPIO控制线也不要走太长尽量靠近模块放置。AUX引脚建议接上主控的一个外部中断输入。模块在上电初始化、进入广播状态、连接成功、数据传输中这些关键节点AUX都会输出不同的电平状态。我用一个GPIO中断去捕获AUX变化在代码里维护一个模块状态机这在量产调试时非常有用——比如用户说手机连不上模块你一看AUX的状态就知道模块到底是在广播、已连接、还是在忙别的。2.3 开源电路图上的几个关键细节E104-BT02的参考电路在官方资料包里是开源的我把它移植到自己的项目里时特别注意了三个地方第一是电源去耦。BLE模块在发送瞬间会有一个比较大的电流尖峰如果电源去耦做得不好这个尖峰会导致模块供电电压跌落轻则丢包重则模块自动复位。参考电路里VCC引脚旁边放了两个去耦电容一个10uF的钽电容承担中频去耦一个0.1uF的陶瓷电容承担高频去耦这两个电容要尽量靠近模块的VCC和GND引脚放置中间不要打过孔。我第一版PCB偷懒把这两个电容放得比较远结果实测通信距离直接从40多米掉到了20米以内。第二是天线的净空区。E104-BT02板载天线那一侧周围至少要保持5mm以上的净空区域不能铺铜、不能走线、不能放置金属器件。我见过一个案例工程师把PCB天线区域正下方放了一颗DC-DC电感天线辐射效率被严重屏蔽iPhone贴脸才能连上。第三是主控和模块之间串口线的串阻。在RXD和TXD上各串一个22欧姆的电阻可以抑制信号反射和振铃尤其是主控和模块分布在PCB两端、走线比较长的时候很有用。这个电阻不会影响信号完整性还能在插错线时起到一定的保护作用。3. 5分钟上手的真实路径从AT指令到手机透传3.1 准备阶段一个USB转TTL、一个手机App我用真实经历跟你说5分钟打通透传是完全可行的前提是材料准备好。硬件上需要一个USB转TTL工具比如CH340或者CP2102小板、几根杜邦线、一个E104-BT02模块。软件上需要一个串口助手我用的是Vofa或XCOM手机上装一个BLE调试助手或者nRF Connect。USB转TTL和模块的接线还是那五根线但有个细节USB转TTL工具上通常有一个3.3V和5V的跳线帽一定要确认输出选择的是3.3V我之前用5V去给模块供电虽然模块没有当场烧掉但芯片发热明显、通信距离缩水后来仔细看规格书才发现超过了最大供电电压。3.2 第一分钟AT指令自检模块接好USB转TTL后插上电脑打开串口助手选择对应的COM口波特率115200。注意模块RXD和主控TX要交叉所以从USB转TTL出来的那个TX要接到模块的RXD。先把模块置于AT指令模式拉高MD0后重新上电然后发送AT两个字看到模块返回OK就说明串口通路是好的、模块固件是正常的。这一步如果失败不要急着怀疑模块坏了先检查三件事TXD/RXD是否接反、波特率是否正确、MD0状态是否正确。接着可以试一下ATMAC查询模块的MAC地址或者ATNAME修改广播名。这几个基础指令能响应说明模块能正常处理配置指令。需要强调一点不同批次模块的AT指令集可能有细微差异具体指令名称以你手里那份官方规格书为准别拿网上老版本的指令集照抄我试过用旧指令集查询新固件参数返回的是error。3.3 第二到第三分钟手机扫描、连接、GATT浏览把模块重新断电MD0拉回低电平重新上电模块进入广播模式。打开手机上的BLE调试助手开始扫描应该能看到一个以EBYTE开头的广播设备具体名称取决于固件里的默认广播名。点进去连接。连接成功后调试助手会列出这个模块所有可用的Service和Characteristic。透传模块的固件通常会暴露一个自定义服务服务UUID一般是FFF0开头的那个下面包含两个关键的Characteristic一个用于手机向模块写数据Write属性另一个用于模块向手机通知数据Notify属性。特性UUID一般在FFF1和FFF2这种顺序上——但别死记直接在App里逐个看就能找到。说到绑定(bond)如果你在调试助手里点击绑定或者Pair模块和手机之间会交换配对密钥并保存长期密钥之后再次连接时无需重新配对。这个功能在实际产品中很重要对应BLE安全机制里的Legacy Pairing或Secure Connections流程。调试助手的绑定功能做得比较直观但注意绑定前先确认模块固件支持配对功能有些定制固件会连配对绑定代码都没有烧录进去。3.4 第四到第五分钟透明传输打通找到Write那个Characteristic之后在调试助手的输入框里输入一个测试字符串比如Hello E104BT02点击发送。同一时刻你电脑上的串口助手应该能收到完全一样的Hello E104BT02——这就实现了手机到串口的单向通路。反过来验证串口到手机的通路在串口助手里发送一串字符手机调试助手的Notification接收区域应该立刻显示出来。注意Notify功能需要先在调试助手界面点一下开启通知有的App叫Subscribe或Listen for notifications否则串口发过来的数据手机端收不到。这个细节特别容易忽略我帮别人排查过几次都是卡在这里。双向都通了透传链路就算打通了。这个流程熟练之后真的只需要五分钟左右。但如果只是到这里就停下你对模块的理解只停留在会用了距离能用好还很远。3.5 5分钟之后必须补的功课5分钟上手解决的是跑通问题但实际项目里还得补几个功课。第一你需要在AT模式下配置模块的关键参数广播间隔、连接间隔、发射功率、MAC地址是否可复用等。第二调试助手的数据流里你看到的是一字不差的透传真实场景中BLE底层是分包传输的长数据会拆成多个BLE包你需要确认模块固件对超过MTU的数据做了什么处理——是自动分包还是丢弃这会直接影响你上层协议的设计。第三透传模式的数据格式完全由你自己定推荐在最开始就设计一个简单的帧协议哪怕只是帧头长度负载CRC这个级别都能在后续排查通信异常时省下大量时间。4. 开源电路与驱动代码的价值拆解4.1 开源电路不是让你抄板而是让你理解射频设计边界官方开源电路包含完整的原理图和PCB参考设计。很多人拿到这些文件直接照搬这当然是最快的路径但如果你想做差异化设计或者遇到射频问题还是得理解背后的边界条件。E104-BT02的参考电路核心是Nordic参考设计加外围匹配网络。你会注意到模块外围的元件数量少得惊人除了电源去耦电容几乎没有额外的分立元件。这是因为BLE SoC内部已经集成了大量的射频前端电路外部只需要提供一个干净的电源和正确的天线环境。参考电路图中天线附近的那几颗微小电容和电感组成的匹配网络是厂商经过阻抗调校后定下来的建议直接照抄不要随意修改参数。我见过有人为了省成本把匹配网络的两个电容去掉结果模块灵敏度直接掉了接近10dBm。还有一点值得学习的是参考电路里电源部分的处理不仅包含去耦电容还在电源入口增加了ESD保护和磁珠。磁珠在高频噪声抑制上的作用是立竿见影的特别是在与马达、继电器这类电磁干扰源共板设计时。我在一个带直流电机的项目里加了磁珠后模块死机频率从每天几次降到了几个月一次。4.2 驱动代码的分层结构从HAL库到应用事件回调官方开源驱动代码的价值甚至比电路还大。很多透传模块只给你一个串口收发demoE104-BT02的驱动是按平台抽象层AT指令层事件处理层三层结构组织的这个设计思路值得借鉴。平台抽象层是移植的关键。驱动代码里定义了一个结构体把所有与具体MCU相关的操作全部封装起来typedef struct { void (*uart_send)(uint8_t *buf, uint16_t len); void (*delay_ms)(uint16_t ms); void (*gpio_set_level)(uint8_t pin, uint8_t level); void (*gpio_get_level)(uint8_t pin, uint8_t *level); } ble_platform_t;移植到新的MCU上你只需要实现这四个函数串口发送、毫秒延时、IO输出、IO读取。这个设计把所有硬件相关的代码隔离在一个薄层里剩下的大部分驱动代码可以原封不动地跨平台复用。我在STM32F103和GD32E230两个平台之间移植这个驱动只花了不到半小时改的就是串口发送和延时这两个函数的实现。AT指令层处理的是发出指令、等待响应、解析结果这个同步过程。核心是一个带超时保护的指令发送函数int ble_at_cmd(ble_platform_t *plt, const char *cmd, uint8_t *ack, uint32_t ack_len, uint16_t timeout_ms) { uint32_t start; uint16_t recv_len 0; plt-uart_send((uint8_t *)cmd, strlen(cmd)); start plt-delay_get_tick(); while (plt-delay_get_tick() - start timeout_ms) { recv_len ble_rx_buffer_pop(ack, ack_len); if (recv_len 0) { return recv_len; /* 返回实际收到的应答长度 */ } } return -1; /* 超时无应答 */ }这个函数的意义在于你可以安全地同步调用AT指令而不至于卡死主流程——只要超时时间设置合理一般配置类指令给500ms到1s就够了。4.3 移植到STM32的完整步骤我以STM32F103的标准HAL库为例给你梳理一下移植的完整步骤第一步用CubeMX配置两个串口一个用于调试打印一个用于和E104-BT02通信假设用USART2。配置USART2为115200-8-N-1打开全局中断。再配置一个GPIO用于接收AUX状态一个GPIO用于控制MD0。第二步新建一个ble_port.c文件实现平台抽象层的四个函数。串口发送直接在HAL库里调用void ble_uart_send(uint8_t *buf, uint16_t len) { HAL_UART_Transmit(huart2, buf, len, 100); }第三步实现串口接收中断和空闲中断的配合。这个是从HAL库角度实现串口收到一段以空闲为结束标志的数据的标准做法void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart huart2) { ble_rx_buffer_push(huart2.pRxBuffPtr, Size); HAL_UARTEx_ReceiveToIdle_DMA(huart2, ble_rx_dma_buf, BLE_RX_BUF_SIZE); } }需要注意启动后要调用一次HAL_UARTEx_ReceiveToIdle_DMA开启第一个接收周期之后每次回调里再重新开启。第四步初始化时配置MD0引脚的状态调用驱动里的ble_init()然后注册一个全局事件回调。这个回调会收到三类事件透传数据到达、AT指令应答、连接状态变化。写应用层代码时你只需要关心这个回调里的事件类型不用管底层的串口解析逻辑。4.4 驱动代码里的一个关键状态机驱动代码中有一个状态机值得单独说就是模块工作模式的切换。模块在透传模式和AT模式之间的切换严格依赖MD0引脚电平和时序static ble_mode_t ble_cur_mode BLE_MODE_TRANSPARENT; int ble_set_mode(ble_platform_t *plt, ble_mode_t mode) { if (mode ble_cur_mode) return 0; plt-gpio_set_level(PIN_MD0, (mode BLE_MODE_AT) ? 1 : 0); plt-delay_ms(50); /* 模式切换后建议复位模块确保状态完全切换 */ plt-gpio_set_level(PIN_RESET, 0); plt-delay_ms(20); plt-gpio_set_level(PIN_RESET, 1); ble_cur_mode mode; return 0; }这个状态机的核心思想是先改变MD0电平再延迟一段时间等待模块内部稳定最后通过复位让模块以新的模式启动。我不建议在模块处于透传连接状态下直接切换模式实测中这样切换会导致连接异常断开而且模块可能无法重新进入广播状态必须复位才能恢复。正确做法是先断开BLE连接再切换模式切换完成后再重新广播。5. GATT、MTU、广播类型BLE入门的五个必懂概念5.1 广播类型为什么开关扫描就能影响连接BLE的数据通路分为两个阶段广播阶段和连接阶段。广播阶段是一对多的通信任何在附近的扫描者都能收到广播包连接阶段是一对一的双向通信需要先建立连接关系。广播类型有四种组合可连接且可扫描、可连接但不可扫描、可扫描但不可连接、不可连接且不可扫描。听起来绕但核心就两条轴能不能被扫描请求触发扫描响应以及能不能被其他设备发起连接。E104-BT02处于可被手机连接的模式它在广播包里会打上可连接标记这样你一打开手机App就能扫描到并点进去连接。如果你自己用蓝牙芯片写广播配置需要设置advertising type和advertising data两个参数。我发现很多人混淆了广播数据和扫描响应数据——广播数据是周期性广播的扫描响应数据是收到扫描请求后才回发的通常用于存放设备名这类长度较长的信息。调试BLE设备和排查广播问题时最关键的工具是手机上的nRF Connect这个App它不仅能看设备名还能把完整的广播包解析成十六进制让你逐个字节检查。5.2 连接过程三个参数决定连接稳定性当手机主动连上模块后BLE链路上会进行连接参数协商。这套参数包括连接间隔、从设备延迟、监控超时三个值它们共同决定了连接的功耗和实时性。连接间隔两个连接事件之间的事件间隔单位是1.25ms的倍数范围从7.5ms到4s。间隔越短数据吞吐越高、实时性越好但功耗也越高。从设备延迟从设备允许跳过的最多连续连接事件数范围0到499。这个参数是个省电利器——从设备跳过了多个连接事件就可以在中间保持睡眠。监控超时超过这个时间没有收到对方的连接包连接就被判定为断开范围100ms到32s。E104-BT02的固件里通常会提供一组默认的连接参数你可以在AT指令模式下修改。但要注意一个坑iOS系统对连接参数有严格的审核连接间隔不能小于15ms即12个1.25ms单位从设备延迟建议为0监控超时必须在连接间隔的6倍以上。如果你的模块设置了过快的连接间隔在iPhone上可能会出现时连时断的现象而Android手机上却一切正常。5.3 GATT模型Service、Characteristic、Descriptor三层BLE的数据模型用GATT通用属性协议来组织它就是一个三层树形结构Service服务 - Characteristic特征 - Descriptor描述符。一个设备可以有多个Service一个Service下面包含多个Characteristic每个Characteristic是实际的数据通道。拿E104-BT02举例固件里定义了一个数据服务服务UUID是FFF0我只拿这个当例子说明具体以你模块固件为准下面有两个CharacteristicFFF1用于接收手机端写入的数据FFF2用于向手机端通知数据。你在调试助手里看到的就是这几个UUID它们的名字不重要UUID和属性才重要。一个Characteristic由三部分组成声明包含权限和UUID、值实际数据、描述符可选用于扩展信息。调试助手能读、写、通知一个特征对应的就是GATT层的读操作、写操作和通知操作。理解了这个模型你就知道为什么调试助手里总能看到一堆看不懂的Service——因为BLE设备的功能全部是靠这些服务来暴露的不是像串口那样一根线收发数据。5.4 MTU与20字节限制为什么一次只能发这么少BLE在链路层规定了一个数据包的最大长度这就是MTU最大传输单元。BLE 4.0/4.1时代默认MTU是23字节其中3个字节被协议头占用留给用户数据只有20字节。所以网上很多人说BLE一次最多传20字节这就是来源。实际上MTU可以在连接建立后协商增大最大可以到247字节。E104-BT02这类透传模块在固件里通常已经做了MTU升级协商所以你在串口里直接发送一条几百字节的数据模块也能透传过去——它会自动拆分成多个BLE包。但如果底层MTU没有升级一次发超过20字节就会被链路层丢包。这就引出一个重要的排查思路如果你用模块做数据采集发现MCU通过串口发给模块的超过几百字节的数据手机端收到的顺序乱了或者丢了一段优先检查模块的MTU协商结果。在调试助手的连接信息界面里一般都能看到当前的MTU值。另一个建议是上层协议设计时仍然要把应用层数据包控制在20字节以内做分包这样即使换了不同固件的模块也不至于出现问题。5.5 BR与BLE经典蓝牙和低功耗蓝牙的区别很多人分不清蓝牙和低功耗蓝牙这两个概念。传统蓝牙BR/EDR和低功耗蓝牙BLE虽然都叫蓝牙但协议栈和物理层设计完全不同——BR/EDR适合持续传输大量数据比如蓝牙音箱的音频流BLE适合小数据量、低功耗、周期性传输的场景比如传感器、手环、智能门锁。E104-BT02只支持BLE不支持BR/EDR所以它做不了音频传输但做数据采集和控制信号绰绰有余。这个区分在实际选型中很重要。之前有个客户非要用BLE模块传音频我跟他说要么换方案、要么降级音质BLE的理论数据速率远低于BR/EDR再怎么做都是事倍功半。反过来如果你只是传温度湿度、开关状态、控制指令这些几十字节的数据用BR/EDR方案就太浪费了——功耗高、成本高、体积大完全没必要。BLE在这个场景下可以做到纽扣电池供电跑一两年这是BR/EDR很难实现的。6. 实测中的掉线、配对与功耗问题排查6.1 现象一AT指令没有响应这是我遇到最多的一个问题统计下来有几种原因。第一是接线问题TXD和RXD交叉关系错了或者RXD这路没有正确连接现象是发送AT后完全没有数据返回。第二是波特率不对你设了9600但模块出厂是115200返回的自然是乱码如果串口助手里的接收区能收到乱码大概率就是波特率或校验位问题。第三是模块根本不在AT模式MD0没有拉高就上电了此时模块在透传模式AT指令会被当作透传数据发出去不会返回OK。排查思路是从链路底层往上走先短接USB转TTL的TXD和RXD在串口助手里自发自收确认串口链路本身是通的再接上模块发送AT失败就进入乱码判断分支最后确认MD0电平。这个排查顺序能帮你在5分钟内定位问题。还有一个小概率原因模块使用了低电平复位电路但你的USB转TTL供电能力不足模块一进发射模式电压就被拉低了表现是发AT偶尔能回复偶尔完全没反应。这时候试试换一个带独立供电的USB口或者用万用表量一下模块VCC引脚的上电电压是否稳定。6.2 现象二手机扫描不到设备手机扫描不到模块大多数人第一反应是模块坏了但大多数时候不是硬件问题。先看模块的AUX引脚状态和电流消耗如果模块确实在正常广播AUX应该呈现周期性的电平变化电流也有几毫安的周期性波动。如果电流极小而且AUX没反应大概率是模块没有正常启动先检查供电。再看广播参数。检查AT配置里的广播使能开关是不是被关掉了还有广播间隔设置。如果广播间隔设置成几秒钟手机会比较难扫到需要耐心等一会儿。还有一类情况是广播名称被设置成了不可见或者自定义的格式不对扫到了但是显示不出名称——这时候用nRF Connect看原始广播数据就能看到实际广播内容。还有一个容易被忽略的环境因素如果模块的板载天线被金属外壳完全包裹射频信号会被屏蔽掉手机即使面对面也扫不到。我在第一版样机里就是把模块放进了全铝外壳内部天线朝下结果完全扫描不到。解决办法是给天线区域开窗或者改用IPEX外置天线方案。6.3 现象三连接后频繁掉线掉线问题排查起来最折腾。我总结出两个最常见的根源连接参数不合理以及电源纹波过大。连接参数方面前面已经说过iOS对连接间隔的审核要求。我在实际项目中把模块的广播间隔设为100ms、连接间隔设为30msAndroid上非常稳定但iPhone总是一两分钟就断开一次。后来查到iOS的连接参数偏好把连接间隔调整到了50ms超时时间设为4s问题就解决了。如果你的主控要求低功耗可以适当增大连接间隔到100ms以上但要注意应用层的重传机制必须能容忍这种延迟。电源纹波引发的掉线最为隐蔽。模块在发射瞬间的大电流会导致电源电压瞬间跌落如果电源路径上的储能电容不足这个跌落的幅度可能达到几百毫伏超过模块内部电压监控的阈值导致模块复位。掉电复位的现象在日志里最迷惑——连接断了但模块还在不停地重新广播。解决思路和前面提到的电源去耦一样在VCC和GND之间加足够容量的电容最好加一个100uF的电解电容或者钽电容做储能保证瞬态电流有足够余量。6.4 现象四绑定后重连时的坑BLE绑定是个周期性出现的坑。第一次连接时调试助手弹窗问你是否要配对你点了确认绑定了。之后手机和模块之间已经交换了密钥。正常逻辑是下次连接时通过密钥直接完成认证不需要再次配对。但我实测遇到过一种诡异情况模块断电重新上电之后手机提示已连接但马上变成未连接反复循环。查了模块的日志才发现模块内部保存的配对信息在断电后丢失了而手机保存的配对信息还在双方拿着不一致的密钥进行认证自然一直失败。解决方法很粗暴手机端把该设备的配对信息删除在蓝牙设置里忽略此设备或者调试助手里解除绑定然后重新扫描连接让双方重新走一遍配对流程。在官方文档里这属于模块的bond信息存储机制问题涉及芯片的NVDS区域配置。后面我做了两步保险一是模块固件里关闭自动绑定请求让应用层主动决定是否需要绑定二是在产品说明里写明如果出现重连失败先解除配对。这个经验在量产设备返修排查时特别有用。绑定能力的另外一个实际影响是安全等级。如果你的产品对通信安全有要求比如数字钥匙这种场景就必须启用绑定和加密。BLE的加密分为非加密连接和加密连接两种后者在绑定完成后会自动激活。在绑定之前所有的数据交换都是明文的任何人在附近用一个BLE嗅探器就能抓取你透传的数据。所以设计产品时凡是涉及控制指令、账号信息、密钥数据一定要使用绑定后的加密连接。这是很多工程师容易忽视的风险点。6.5 现象五低功耗模式下模块电流异常最后聊一下功耗问题这是低功耗物联网项目里绕不开的坎。我第一次测整机功耗时发现产品在休眠状态下电流高达2mA远超预期。一顿排查后发现罪魁祸首是模块——模块虽然在未连接状态下会自动进入广播模式但广播本身的功耗就不低几次固定的唤醒发射就会拉出平均几百微安的电流。解决思路是这样的。如果产品大部分时间不需要通信可以让主控通过MD0引脚控制模块的电源实现真正的零待机功耗。在需要通信时才给模块上电初始化后建立连接完成数据传输后立刻断电。这个方案的问题在于连接建立和参数协商需要时间从给模块上电到第一个数据包到达大概需要1到3秒取决于广播间隔和连接参数。如果产品需要在几秒内响应这个延迟是可以接受的。另一个优化手段是用AT指令配置模块在空闲时不广播需要时通过串口唤醒它进入广播态。这种方法比直接断电好一些因为模块内部的时钟和协议栈状态不需要重新初始化但是要注意模块的配置模式切换本身的耗时和可靠性。我现在的做法是混合策略常态下模块完全断电主控自己进入深度睡眠外部事件唤醒后先给模块上电等待AUX拉低表示模块启动完成然后直接发串口透传数据不用等BLE连接建立——因为连接建立是手机侧发起的行为。这套流程在智能门锁场景里跑得很稳整机待机电流降到了50uA以下。说到底E104-BT02这类模块的5分钟上手是真的但它解决的是从零到跑通的问题而不是从跑通到量产的问题。我在这套方案上踩过的坑——MD0的上下拉、电源去耦位置、iOS连接参数、绑定信息不一致——每一个在官方的开源电路和驱动代码里都有对应的线索只是需要亲手碰一遍才知道边界在哪。如果你准备拿这个模块做产品我的建议是先花五分钟跑通Demo建立信心再用一整天把文档里的AT指令逐条测一遍最后留出一周做连接稳定性、功耗和认证的全面验证这些时间花得值。 
长河君 · 2026/9/5 10:01:54 · 阅读 1.2k E104-BT02 BLE模块实战：从串口透传到低功耗设计
开头我在开发一个低功耗传感器节点时遇到了一个很现实的问题硬件产品需要跟手机通信但是BLE协议栈、射频匹配、天线设计这些知识对我来说完全陌生——我是个做单片机的不是做射频的。那阵子天天翻蓝牙协议文档越看越头大。后来同事甩给我一个模块说别折腾了用这个然后丢给我一块E104-BT02。说实话第一次听到5分钟上手这种宣传语我是嗤之以鼻的。但真正把模块接到串口、打开手机调试助手、第一次让数据从手机飞到MCU里那一刻我承认这个说法基本没有水分。E104-BT02是一个BLE透明传输模块模块内部已经把协议栈和射频前端全部封装好了你只需要通过串口或者SPI接口跟它对话。这篇文章我会把这套方案的完整链路拆开——为什么选模块而不是裸芯片、硬件电路怎么接最稳、5分钟打通透传的具体操作路径、开源驱动代码的结构以及我实际踩过的掉线、绑定、低功耗这些坑。适合谁看想快速给产品加手机交互能力的嵌入式工程师、做物联网原型验证的开发者、以及刚接触BLE但不想从协议栈啃起的入门玩家。1. 为什么是E104-BT02模块化BLE开发的选型逻辑1.1 BLE协议栈的复杂度是选模块而非裸芯片的根本原因很多人纠结一个问题现在nRF52832、ESP32-C3这些芯片这么便宜为什么还要用模块我一开始也是这个思路——自己画板子、自己写协议栈多酷。结果第一步就卡住了。BLE协议栈不是简单的库函数调用它涉及GAP层的广播和连接管理、GATT层的服务定义、L2CAP层的分包重组、链路层的加密和跳频机制每一层都有各自的时序要求和状态机。nRF52832的SDK光协议栈相关的源码就有几个G光是配置工程就要折腾一整天。而射频前端是另一个更隐蔽的坑。蓝牙工作在2.4GHz频段天线匹配网络的走线长度、阻抗控制、PCB叠层设计稍有偏差通信距离就会从标称的50米缩水到5米。这些经验不是看几篇应用笔记就能掌握的需要射频测试仪器反复调试。用模块就把这些问题全部屏蔽掉了——模块厂商已经把晶振匹配、天线阻抗、协议栈集成全部做好了并且做了量产级的射频指标测试。对我这种射频门外汉来说这是成本最低的路径。还有一个现实原因认证。产品要做FCC、CE认证射频部分是最容易出问题的环节。使用已经通过认证的模块可以直接引用模块的认证报告大幅缩短认证周期。这也是为什么很多成熟的物联网产品内部用的都是一个小铁壳模块主控的结构。1.2 E104-BT02与市面常见BLE模块的定位差异市面上BLE模块大致分两类一类是串口透传模块比如E104-BT02、HC-08、JDY-08特点是自带协议栈和应用层逻辑MCU只需要发AT指令配置参数之后就可以像操作普通串口一样收发数据另一类是协议栈开放模块比如Nordic原厂的nRF52832模块、TI的CC2540模块这些模块给你一个可以二次开发的SDK你需要在上面自己写应用层代码。E104-BT02属于前一类它基于Nordic nRF52系列芯片支持BLE 5.0。这类透传模块的核心价值不在于芯片本身多强而在于它把BLE的操作抽象成了串口写数据、串口读数据这样简单的接口。硬件设计上它引出了VCC、GND、TXD、RXD、AUX、MD0等核心引脚其中AUX是状态指示输出MD0用于模式切换。相比之下HC-08是蓝牙4.0方案协议栈和兼容性稍老JDY-08在价格上有优势但固件更新不如一线大厂频繁。E104-BT02的优势在于AT指令集完整、资料开源程度高、驱动代码有官方维护后面我会专门讲它的开源电路和驱动代码怎么用。1.3 一套5分钟上手的选型清单在实际项目中我总结了一套固定的选型评估项每个候选模块都要过一遍接口方式是否支持UART透传是否支持SPI你的主控有什么空闲外设。供电范围能否支持你现有的电源系统E104-BT02工作电压1.8到3.6V典型3.3V。功耗指标注意区分峰值电流、平均电流和休眠电流三个指标很多模块宣传的超低功耗指的是休眠态实际连上之后平均电流大不相同。传输速率BLE的吞吐量受到MTU和连接间隔影响官方宣称的波特率是串口速率实际无线吞吐可能只有一半。开源程度电路和驱动是否完整开源遇到问题能不能自己排查。天线形式PCB板载天线适合短距离、成本敏感的产品IPEX天线适合需要拉远距离或者金属外壳场景。这套清单可以帮你快速过滤掉不合适的方案避免选型走弯路。2. 引脚全解与电路连接漏接一个上拉电阻的代价2.1 引脚功能对照与最低系统接线先上一份核心引脚功能表。E104-BT02不同批次引脚排列可能略有差异但功能引脚就这几个对照手册找到即可引脚方向功能说明注意事项VCC输入模块供电范围1.8~3.6V严禁超过3.6V典型用3.3VGND输入电源地必须与主控共地TXD输出模块串口发送接主控的RXRXD输入模块串口接收接主控的TXAUX输出状态指示高电平表示模块忙碌可接MCU的GPIO中断MD0输入模式控制悬空/拉低为透传模式拉高进入配置模式SWCLK/SWDIO输入固件升级和调试接口正常使用可以不接最低系统接线只需要五根线VCC、GND、TXD、RXD外加一个AUX用于状态检测不接AUX也能跑透传但无法判断模块是否已经进入可通信状态。模块的TXD和主控的RXD要交叉连接这是新手最容易犯的错误——我见过好几个人拿着模块干瞪眼发现数据发不出去最后发现是把TXD接到了主控的TX上。一个很重要的细节模块的RXD内部没有做5V容忍如果你的主控是5V供电的比如老款Arduino或者某些电平是5V的STM32板子直接连接可能会把模块的RXD引脚击穿表现为模块有时候能收到数据有时候完全不动。正确做法是用MOSFET电平转换芯片或者最简单的用两个电阻做分压——我用的是BSS138双向电平转换电路成本几毛钱稳定跑了一年多。2.2 串口参数与模式切换的硬件设计E104-BT02出厂默认波特率通常是115200、8数据位、无校验、1停止位。模块上电后默认进入透传模式只要MD0保持低电平或悬空这个模式下所有从串口收到的数据都会通过BLE无线发出手机端发来的数据也会从串口输出。如果要做参数配置需要拉高MD0引脚然后给模块重新上电进入AT指令模式。我在电路设计上踩过一个坑MD0引脚只用一个普通的GPIO去控制没加上拉电阻。结果在强电磁干扰环境下模块偶尔会莫名其妙进入AT模式然后透传数据就全部变成了乱码。排查了很久才找到原因——模块的MD0输入阻抗很高干扰信号能直接拉高这个引脚。解决方案是在MD0和GND之间并一个10k的下拉电阻确保默认状态始终是透传模式同时GPIO控制线也不要走太长尽量靠近模块放置。AUX引脚建议接上主控的一个外部中断输入。模块在上电初始化、进入广播状态、连接成功、数据传输中这些关键节点AUX都会输出不同的电平状态。我用一个GPIO中断去捕获AUX变化在代码里维护一个模块状态机这在量产调试时非常有用——比如用户说手机连不上模块你一看AUX的状态就知道模块到底是在广播、已连接、还是在忙别的。2.3 开源电路图上的几个关键细节E104-BT02的参考电路在官方资料包里是开源的我把它移植到自己的项目里时特别注意了三个地方第一是电源去耦。BLE模块在发送瞬间会有一个比较大的电流尖峰如果电源去耦做得不好这个尖峰会导致模块供电电压跌落轻则丢包重则模块自动复位。参考电路里VCC引脚旁边放了两个去耦电容一个10uF的钽电容承担中频去耦一个0.1uF的陶瓷电容承担高频去耦这两个电容要尽量靠近模块的VCC和GND引脚放置中间不要打过孔。我第一版PCB偷懒把这两个电容放得比较远结果实测通信距离直接从40多米掉到了20米以内。第二是天线的净空区。E104-BT02板载天线那一侧周围至少要保持5mm以上的净空区域不能铺铜、不能走线、不能放置金属器件。我见过一个案例工程师把PCB天线区域正下方放了一颗DC-DC电感天线辐射效率被严重屏蔽iPhone贴脸才能连上。第三是主控和模块之间串口线的串阻。在RXD和TXD上各串一个22欧姆的电阻可以抑制信号反射和振铃尤其是主控和模块分布在PCB两端、走线比较长的时候很有用。这个电阻不会影响信号完整性还能在插错线时起到一定的保护作用。3. 5分钟上手的真实路径从AT指令到手机透传3.1 准备阶段一个USB转TTL、一个手机App我用真实经历跟你说5分钟打通透传是完全可行的前提是材料准备好。硬件上需要一个USB转TTL工具比如CH340或者CP2102小板、几根杜邦线、一个E104-BT02模块。软件上需要一个串口助手我用的是Vofa或XCOM手机上装一个BLE调试助手或者nRF Connect。USB转TTL和模块的接线还是那五根线但有个细节USB转TTL工具上通常有一个3.3V和5V的跳线帽一定要确认输出选择的是3.3V我之前用5V去给模块供电虽然模块没有当场烧掉但芯片发热明显、通信距离缩水后来仔细看规格书才发现超过了最大供电电压。3.2 第一分钟AT指令自检模块接好USB转TTL后插上电脑打开串口助手选择对应的COM口波特率115200。注意模块RXD和主控TX要交叉所以从USB转TTL出来的那个TX要接到模块的RXD。先把模块置于AT指令模式拉高MD0后重新上电然后发送AT两个字看到模块返回OK就说明串口通路是好的、模块固件是正常的。这一步如果失败不要急着怀疑模块坏了先检查三件事TXD/RXD是否接反、波特率是否正确、MD0状态是否正确。接着可以试一下ATMAC查询模块的MAC地址或者ATNAME修改广播名。这几个基础指令能响应说明模块能正常处理配置指令。需要强调一点不同批次模块的AT指令集可能有细微差异具体指令名称以你手里那份官方规格书为准别拿网上老版本的指令集照抄我试过用旧指令集查询新固件参数返回的是error。3.3 第二到第三分钟手机扫描、连接、GATT浏览把模块重新断电MD0拉回低电平重新上电模块进入广播模式。打开手机上的BLE调试助手开始扫描应该能看到一个以EBYTE开头的广播设备具体名称取决于固件里的默认广播名。点进去连接。连接成功后调试助手会列出这个模块所有可用的Service和Characteristic。透传模块的固件通常会暴露一个自定义服务服务UUID一般是FFF0开头的那个下面包含两个关键的Characteristic一个用于手机向模块写数据Write属性另一个用于模块向手机通知数据Notify属性。特性UUID一般在FFF1和FFF2这种顺序上——但别死记直接在App里逐个看就能找到。说到绑定(bond)如果你在调试助手里点击绑定或者Pair模块和手机之间会交换配对密钥并保存长期密钥之后再次连接时无需重新配对。这个功能在实际产品中很重要对应BLE安全机制里的Legacy Pairing或Secure Connections流程。调试助手的绑定功能做得比较直观但注意绑定前先确认模块固件支持配对功能有些定制固件会连配对绑定代码都没有烧录进去。3.4 第四到第五分钟透明传输打通找到Write那个Characteristic之后在调试助手的输入框里输入一个测试字符串比如Hello E104BT02点击发送。同一时刻你电脑上的串口助手应该能收到完全一样的Hello E104BT02——这就实现了手机到串口的单向通路。反过来验证串口到手机的通路在串口助手里发送一串字符手机调试助手的Notification接收区域应该立刻显示出来。注意Notify功能需要先在调试助手界面点一下开启通知有的App叫Subscribe或Listen for notifications否则串口发过来的数据手机端收不到。这个细节特别容易忽略我帮别人排查过几次都是卡在这里。双向都通了透传链路就算打通了。这个流程熟练之后真的只需要五分钟左右。但如果只是到这里就停下你对模块的理解只停留在会用了距离能用好还很远。3.5 5分钟之后必须补的功课5分钟上手解决的是跑通问题但实际项目里还得补几个功课。第一你需要在AT模式下配置模块的关键参数广播间隔、连接间隔、发射功率、MAC地址是否可复用等。第二调试助手的数据流里你看到的是一字不差的透传真实场景中BLE底层是分包传输的长数据会拆成多个BLE包你需要确认模块固件对超过MTU的数据做了什么处理——是自动分包还是丢弃这会直接影响你上层协议的设计。第三透传模式的数据格式完全由你自己定推荐在最开始就设计一个简单的帧协议哪怕只是帧头长度负载CRC这个级别都能在后续排查通信异常时省下大量时间。4. 开源电路与驱动代码的价值拆解4.1 开源电路不是让你抄板而是让你理解射频设计边界官方开源电路包含完整的原理图和PCB参考设计。很多人拿到这些文件直接照搬这当然是最快的路径但如果你想做差异化设计或者遇到射频问题还是得理解背后的边界条件。E104-BT02的参考电路核心是Nordic参考设计加外围匹配网络。你会注意到模块外围的元件数量少得惊人除了电源去耦电容几乎没有额外的分立元件。这是因为BLE SoC内部已经集成了大量的射频前端电路外部只需要提供一个干净的电源和正确的天线环境。参考电路图中天线附近的那几颗微小电容和电感组成的匹配网络是厂商经过阻抗调校后定下来的建议直接照抄不要随意修改参数。我见过有人为了省成本把匹配网络的两个电容去掉结果模块灵敏度直接掉了接近10dBm。还有一点值得学习的是参考电路里电源部分的处理不仅包含去耦电容还在电源入口增加了ESD保护和磁珠。磁珠在高频噪声抑制上的作用是立竿见影的特别是在与马达、继电器这类电磁干扰源共板设计时。我在一个带直流电机的项目里加了磁珠后模块死机频率从每天几次降到了几个月一次。4.2 驱动代码的分层结构从HAL库到应用事件回调官方开源驱动代码的价值甚至比电路还大。很多透传模块只给你一个串口收发demoE104-BT02的驱动是按平台抽象层AT指令层事件处理层三层结构组织的这个设计思路值得借鉴。平台抽象层是移植的关键。驱动代码里定义了一个结构体把所有与具体MCU相关的操作全部封装起来typedef struct { void (*uart_send)(uint8_t *buf, uint16_t len); void (*delay_ms)(uint16_t ms); void (*gpio_set_level)(uint8_t pin, uint8_t level); void (*gpio_get_level)(uint8_t pin, uint8_t *level); } ble_platform_t;移植到新的MCU上你只需要实现这四个函数串口发送、毫秒延时、IO输出、IO读取。这个设计把所有硬件相关的代码隔离在一个薄层里剩下的大部分驱动代码可以原封不动地跨平台复用。我在STM32F103和GD32E230两个平台之间移植这个驱动只花了不到半小时改的就是串口发送和延时这两个函数的实现。AT指令层处理的是发出指令、等待响应、解析结果这个同步过程。核心是一个带超时保护的指令发送函数int ble_at_cmd(ble_platform_t *plt, const char *cmd, uint8_t *ack, uint32_t ack_len, uint16_t timeout_ms) { uint32_t start; uint16_t recv_len 0; plt-uart_send((uint8_t *)cmd, strlen(cmd)); start plt-delay_get_tick(); while (plt-delay_get_tick() - start timeout_ms) { recv_len ble_rx_buffer_pop(ack, ack_len); if (recv_len 0) { return recv_len; /* 返回实际收到的应答长度 */ } } return -1; /* 超时无应答 */ }这个函数的意义在于你可以安全地同步调用AT指令而不至于卡死主流程——只要超时时间设置合理一般配置类指令给500ms到1s就够了。4.3 移植到STM32的完整步骤我以STM32F103的标准HAL库为例给你梳理一下移植的完整步骤第一步用CubeMX配置两个串口一个用于调试打印一个用于和E104-BT02通信假设用USART2。配置USART2为115200-8-N-1打开全局中断。再配置一个GPIO用于接收AUX状态一个GPIO用于控制MD0。第二步新建一个ble_port.c文件实现平台抽象层的四个函数。串口发送直接在HAL库里调用void ble_uart_send(uint8_t *buf, uint16_t len) { HAL_UART_Transmit(huart2, buf, len, 100); }第三步实现串口接收中断和空闲中断的配合。这个是从HAL库角度实现串口收到一段以空闲为结束标志的数据的标准做法void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart huart2) { ble_rx_buffer_push(huart2.pRxBuffPtr, Size); HAL_UARTEx_ReceiveToIdle_DMA(huart2, ble_rx_dma_buf, BLE_RX_BUF_SIZE); } }需要注意启动后要调用一次HAL_UARTEx_ReceiveToIdle_DMA开启第一个接收周期之后每次回调里再重新开启。第四步初始化时配置MD0引脚的状态调用驱动里的ble_init()然后注册一个全局事件回调。这个回调会收到三类事件透传数据到达、AT指令应答、连接状态变化。写应用层代码时你只需要关心这个回调里的事件类型不用管底层的串口解析逻辑。4.4 驱动代码里的一个关键状态机驱动代码中有一个状态机值得单独说就是模块工作模式的切换。模块在透传模式和AT模式之间的切换严格依赖MD0引脚电平和时序static ble_mode_t ble_cur_mode BLE_MODE_TRANSPARENT; int ble_set_mode(ble_platform_t *plt, ble_mode_t mode) { if (mode ble_cur_mode) return 0; plt-gpio_set_level(PIN_MD0, (mode BLE_MODE_AT) ? 1 : 0); plt-delay_ms(50); /* 模式切换后建议复位模块确保状态完全切换 */ plt-gpio_set_level(PIN_RESET, 0); plt-delay_ms(20); plt-gpio_set_level(PIN_RESET, 1); ble_cur_mode mode; return 0; }这个状态机的核心思想是先改变MD0电平再延迟一段时间等待模块内部稳定最后通过复位让模块以新的模式启动。我不建议在模块处于透传连接状态下直接切换模式实测中这样切换会导致连接异常断开而且模块可能无法重新进入广播状态必须复位才能恢复。正确做法是先断开BLE连接再切换模式切换完成后再重新广播。5. GATT、MTU、广播类型BLE入门的五个必懂概念5.1 广播类型为什么开关扫描就能影响连接BLE的数据通路分为两个阶段广播阶段和连接阶段。广播阶段是一对多的通信任何在附近的扫描者都能收到广播包连接阶段是一对一的双向通信需要先建立连接关系。广播类型有四种组合可连接且可扫描、可连接但不可扫描、可扫描但不可连接、不可连接且不可扫描。听起来绕但核心就两条轴能不能被扫描请求触发扫描响应以及能不能被其他设备发起连接。E104-BT02处于可被手机连接的模式它在广播包里会打上可连接标记这样你一打开手机App就能扫描到并点进去连接。如果你自己用蓝牙芯片写广播配置需要设置advertising type和advertising data两个参数。我发现很多人混淆了广播数据和扫描响应数据——广播数据是周期性广播的扫描响应数据是收到扫描请求后才回发的通常用于存放设备名这类长度较长的信息。调试BLE设备和排查广播问题时最关键的工具是手机上的nRF Connect这个App它不仅能看设备名还能把完整的广播包解析成十六进制让你逐个字节检查。5.2 连接过程三个参数决定连接稳定性当手机主动连上模块后BLE链路上会进行连接参数协商。这套参数包括连接间隔、从设备延迟、监控超时三个值它们共同决定了连接的功耗和实时性。连接间隔两个连接事件之间的事件间隔单位是1.25ms的倍数范围从7.5ms到4s。间隔越短数据吞吐越高、实时性越好但功耗也越高。从设备延迟从设备允许跳过的最多连续连接事件数范围0到499。这个参数是个省电利器——从设备跳过了多个连接事件就可以在中间保持睡眠。监控超时超过这个时间没有收到对方的连接包连接就被判定为断开范围100ms到32s。E104-BT02的固件里通常会提供一组默认的连接参数你可以在AT指令模式下修改。但要注意一个坑iOS系统对连接参数有严格的审核连接间隔不能小于15ms即12个1.25ms单位从设备延迟建议为0监控超时必须在连接间隔的6倍以上。如果你的模块设置了过快的连接间隔在iPhone上可能会出现时连时断的现象而Android手机上却一切正常。5.3 GATT模型Service、Characteristic、Descriptor三层BLE的数据模型用GATT通用属性协议来组织它就是一个三层树形结构Service服务 - Characteristic特征 - Descriptor描述符。一个设备可以有多个Service一个Service下面包含多个Characteristic每个Characteristic是实际的数据通道。拿E104-BT02举例固件里定义了一个数据服务服务UUID是FFF0我只拿这个当例子说明具体以你模块固件为准下面有两个CharacteristicFFF1用于接收手机端写入的数据FFF2用于向手机端通知数据。你在调试助手里看到的就是这几个UUID它们的名字不重要UUID和属性才重要。一个Characteristic由三部分组成声明包含权限和UUID、值实际数据、描述符可选用于扩展信息。调试助手能读、写、通知一个特征对应的就是GATT层的读操作、写操作和通知操作。理解了这个模型你就知道为什么调试助手里总能看到一堆看不懂的Service——因为BLE设备的功能全部是靠这些服务来暴露的不是像串口那样一根线收发数据。5.4 MTU与20字节限制为什么一次只能发这么少BLE在链路层规定了一个数据包的最大长度这就是MTU最大传输单元。BLE 4.0/4.1时代默认MTU是23字节其中3个字节被协议头占用留给用户数据只有20字节。所以网上很多人说BLE一次最多传20字节这就是来源。实际上MTU可以在连接建立后协商增大最大可以到247字节。E104-BT02这类透传模块在固件里通常已经做了MTU升级协商所以你在串口里直接发送一条几百字节的数据模块也能透传过去——它会自动拆分成多个BLE包。但如果底层MTU没有升级一次发超过20字节就会被链路层丢包。这就引出一个重要的排查思路如果你用模块做数据采集发现MCU通过串口发给模块的超过几百字节的数据手机端收到的顺序乱了或者丢了一段优先检查模块的MTU协商结果。在调试助手的连接信息界面里一般都能看到当前的MTU值。另一个建议是上层协议设计时仍然要把应用层数据包控制在20字节以内做分包这样即使换了不同固件的模块也不至于出现问题。5.5 BR与BLE经典蓝牙和低功耗蓝牙的区别很多人分不清蓝牙和低功耗蓝牙这两个概念。传统蓝牙BR/EDR和低功耗蓝牙BLE虽然都叫蓝牙但协议栈和物理层设计完全不同——BR/EDR适合持续传输大量数据比如蓝牙音箱的音频流BLE适合小数据量、低功耗、周期性传输的场景比如传感器、手环、智能门锁。E104-BT02只支持BLE不支持BR/EDR所以它做不了音频传输但做数据采集和控制信号绰绰有余。这个区分在实际选型中很重要。之前有个客户非要用BLE模块传音频我跟他说要么换方案、要么降级音质BLE的理论数据速率远低于BR/EDR再怎么做都是事倍功半。反过来如果你只是传温度湿度、开关状态、控制指令这些几十字节的数据用BR/EDR方案就太浪费了——功耗高、成本高、体积大完全没必要。BLE在这个场景下可以做到纽扣电池供电跑一两年这是BR/EDR很难实现的。6. 实测中的掉线、配对与功耗问题排查6.1 现象一AT指令没有响应这是我遇到最多的一个问题统计下来有几种原因。第一是接线问题TXD和RXD交叉关系错了或者RXD这路没有正确连接现象是发送AT后完全没有数据返回。第二是波特率不对你设了9600但模块出厂是115200返回的自然是乱码如果串口助手里的接收区能收到乱码大概率就是波特率或校验位问题。第三是模块根本不在AT模式MD0没有拉高就上电了此时模块在透传模式AT指令会被当作透传数据发出去不会返回OK。排查思路是从链路底层往上走先短接USB转TTL的TXD和RXD在串口助手里自发自收确认串口链路本身是通的再接上模块发送AT失败就进入乱码判断分支最后确认MD0电平。这个排查顺序能帮你在5分钟内定位问题。还有一个小概率原因模块使用了低电平复位电路但你的USB转TTL供电能力不足模块一进发射模式电压就被拉低了表现是发AT偶尔能回复偶尔完全没反应。这时候试试换一个带独立供电的USB口或者用万用表量一下模块VCC引脚的上电电压是否稳定。6.2 现象二手机扫描不到设备手机扫描不到模块大多数人第一反应是模块坏了但大多数时候不是硬件问题。先看模块的AUX引脚状态和电流消耗如果模块确实在正常广播AUX应该呈现周期性的电平变化电流也有几毫安的周期性波动。如果电流极小而且AUX没反应大概率是模块没有正常启动先检查供电。再看广播参数。检查AT配置里的广播使能开关是不是被关掉了还有广播间隔设置。如果广播间隔设置成几秒钟手机会比较难扫到需要耐心等一会儿。还有一类情况是广播名称被设置成了不可见或者自定义的格式不对扫到了但是显示不出名称——这时候用nRF Connect看原始广播数据就能看到实际广播内容。还有一个容易被忽略的环境因素如果模块的板载天线被金属外壳完全包裹射频信号会被屏蔽掉手机即使面对面也扫不到。我在第一版样机里就是把模块放进了全铝外壳内部天线朝下结果完全扫描不到。解决办法是给天线区域开窗或者改用IPEX外置天线方案。6.3 现象三连接后频繁掉线掉线问题排查起来最折腾。我总结出两个最常见的根源连接参数不合理以及电源纹波过大。连接参数方面前面已经说过iOS对连接间隔的审核要求。我在实际项目中把模块的广播间隔设为100ms、连接间隔设为30msAndroid上非常稳定但iPhone总是一两分钟就断开一次。后来查到iOS的连接参数偏好把连接间隔调整到了50ms超时时间设为4s问题就解决了。如果你的主控要求低功耗可以适当增大连接间隔到100ms以上但要注意应用层的重传机制必须能容忍这种延迟。电源纹波引发的掉线最为隐蔽。模块在发射瞬间的大电流会导致电源电压瞬间跌落如果电源路径上的储能电容不足这个跌落的幅度可能达到几百毫伏超过模块内部电压监控的阈值导致模块复位。掉电复位的现象在日志里最迷惑——连接断了但模块还在不停地重新广播。解决思路和前面提到的电源去耦一样在VCC和GND之间加足够容量的电容最好加一个100uF的电解电容或者钽电容做储能保证瞬态电流有足够余量。6.4 现象四绑定后重连时的坑BLE绑定是个周期性出现的坑。第一次连接时调试助手弹窗问你是否要配对你点了确认绑定了。之后手机和模块之间已经交换了密钥。正常逻辑是下次连接时通过密钥直接完成认证不需要再次配对。但我实测遇到过一种诡异情况模块断电重新上电之后手机提示已连接但马上变成未连接反复循环。查了模块的日志才发现模块内部保存的配对信息在断电后丢失了而手机保存的配对信息还在双方拿着不一致的密钥进行认证自然一直失败。解决方法很粗暴手机端把该设备的配对信息删除在蓝牙设置里忽略此设备或者调试助手里解除绑定然后重新扫描连接让双方重新走一遍配对流程。在官方文档里这属于模块的bond信息存储机制问题涉及芯片的NVDS区域配置。后面我做了两步保险一是模块固件里关闭自动绑定请求让应用层主动决定是否需要绑定二是在产品说明里写明如果出现重连失败先解除配对。这个经验在量产设备返修排查时特别有用。绑定能力的另外一个实际影响是安全等级。如果你的产品对通信安全有要求比如数字钥匙这种场景就必须启用绑定和加密。BLE的加密分为非加密连接和加密连接两种后者在绑定完成后会自动激活。在绑定之前所有的数据交换都是明文的任何人在附近用一个BLE嗅探器就能抓取你透传的数据。所以设计产品时凡是涉及控制指令、账号信息、密钥数据一定要使用绑定后的加密连接。这是很多工程师容易忽视的风险点。6.5 现象五低功耗模式下模块电流异常最后聊一下功耗问题这是低功耗物联网项目里绕不开的坎。我第一次测整机功耗时发现产品在休眠状态下电流高达2mA远超预期。一顿排查后发现罪魁祸首是模块——模块虽然在未连接状态下会自动进入广播模式但广播本身的功耗就不低几次固定的唤醒发射就会拉出平均几百微安的电流。解决思路是这样的。如果产品大部分时间不需要通信可以让主控通过MD0引脚控制模块的电源实现真正的零待机功耗。在需要通信时才给模块上电初始化后建立连接完成数据传输后立刻断电。这个方案的问题在于连接建立和参数协商需要时间从给模块上电到第一个数据包到达大概需要1到3秒取决于广播间隔和连接参数。如果产品需要在几秒内响应这个延迟是可以接受的。另一个优化手段是用AT指令配置模块在空闲时不广播需要时通过串口唤醒它进入广播态。这种方法比直接断电好一些因为模块内部的时钟和协议栈状态不需要重新初始化但是要注意模块的配置模式切换本身的耗时和可靠性。我现在的做法是混合策略常态下模块完全断电主控自己进入深度睡眠外部事件唤醒后先给模块上电等待AUX拉低表示模块启动完成然后直接发串口透传数据不用等BLE连接建立——因为连接建立是手机侧发起的行为。这套流程在智能门锁场景里跑得很稳整机待机电流降到了50uA以下。说到底E104-BT02这类模块的5分钟上手是真的但它解决的是从零到跑通的问题而不是从跑通到量产的问题。我在这套方案上踩过的坑——MD0的上下拉、电源去耦位置、iOS连接参数、绑定信息不一致——每一个在官方的开源电路和驱动代码里都有对应的线索只是需要亲手碰一遍才知道边界在哪。如果你准备拿这个模块做产品我的建议是先花五分钟跑通Demo建立信心再用一整天把文档里的AT指令逐条测一遍最后留出一周做连接稳定性、功耗和认证的全面验证这些时间花得值。