E104-BT02 BLE透传模块实战：从硬件连接到STM32驱动开发

1. 这块模块到底值不值得用：E104-BT02的定位与选型逻辑

先说一个我自己的经历。早几年做低功耗无线产品，蓝牙方案基本两条路：要么用HC-05、HC-06这类经典蓝牙串口模块，要么直接上手nRF52832原生SDK做开发。前者确实简单，但SLC蓝牙放在今天做IoT产品已经有点尴尬，功耗高、生态老旧、手机兼容性也一般；后者功能倒是强大，可光是搭建nRF5 SDK环境、理解协议栈回调机制，就能卡住新手半个月。

所以当我第一次拿到E104-BT02这种“贴片式BLE透传模块”时，第一反应是：这不就是给嵌入式工程师准备的中间路线吗？它把BLE协议栈、射频前端、天线匹配全部封装在模块内部，对外只暴露UART串口和一组GPIO。你不需要理解BLE链路层怎么建连、GATT服务怎么定义，把它当成一个“无线串口”用就行。

E104-BT02这颗模块用的是Nordic nRF52832方案，支持BLE 5.0，发射功率可调范围-20dBm到+8dBm，空旷环境下实测传输距离大概能到100米级别。模块本身主从一体，既能作为从机被手机连接，也能作为主机主动扫描并连接其他BLE设备。它的通信接口是标准的UART，默认波特率通常为115200，通过AT指令可以修改。模块内部还带EEPROM存储配置参数，所以断电后广播名、MAC地址、串口参数这些设置都不会丢。

适合用它的场景很明确：

• 传统MCU项目需要快速加蓝牙功能，不想动原有主控代码架构
• 产品原型验证阶段，需要几天内跑通手机与硬件的双向通信
• 做传感器数据采集、智能家居控制、小型穿戴设备，数据量不大但要求稳定

不适合的场景也要说清楚：如果需要高速连续传输音频、需要自定义GATT服务与手机APP深度交互、或者成本敏感到必须用裸芯片方案，那直接上nRF52832原生开发更合适。E104-BT02的价值在于“快速、稳定、省心”，而不是“极致性能”。

选型还有一个容易被忽略的点：模块尺寸和天线形式。E104-BT02是贴片封装，板上自带PCB天线，占板面积很小，适合做小体积产品。如果产品外壳是金属材质，或者安装环境对天线遮挡严重，可以考虑带IPEX座的版本外接天线，但这会稍微增加成本和装配复杂度。我一般建议在原理图阶段就把天线净空区预留出来，后续切换天线版本不用改PCB。

2. 5分钟接线与上电配置：开源电路里真正要注意的细节

2.1 硬件连接的最小系统

拿到模块先别急着写代码，把硬件通路打通再说。E104-BT02的引脚不算多，核心就几根：VCC、GND、TXD、RXD，外加一对硬件流控引脚RTS、CTS和若干PIO复用脚。

电源是第一个坑。模块工作电压范围标称2.0V到3.6V，典型3.3V。很多人图省事直接接在MCU的3.3V上，如果这个3.3V本身是从锂电池经LDO出来的，问题不大；但如果是从DC-DC出来的，一定要关注纹波。BLE射频发射瞬间电流会有一个明显的脉冲，峰值可能到几十毫安，如果电源纹波太大，会直接影响射频灵敏度和连接稳定性。我的建议是在模块电源引脚旁边放一个10uF陶瓷电容和一个0.1uF高频去耦电容，位置尽可能靠近VCC引脚。

UART连接这里是第二个坑。模块的TXD接MCU的RX，模块的RXD接MCU的TX，这个交叉关系看着简单，实际接反的人不在少数。还有电平问题，E104-BT02的UART电平是3.3V TTL，不要直接接5V单片机的串口，否则长期运行有烧毁风险。如果主控是5V系统，中间一定要加电平转换电路。

RTS和CTS这两个引脚，如果只是做简单的单向透传或者小数据量双向通信，可以不接。但如果你的应用场景是主控通过蓝牙向手机持续传大量数据，建议把硬件流控打开。我后面会专门讲这个，这里先记住：硬件流控是保证“大数据量不丢包”的关键手段。

PIO引脚方面，模块通常引出若干GPIO，可以配置为输入检测或者输出控制。典型的应用场景是：通过手机APP远程控制一个IO口输出高低电平，或者读取外部传感器的电平状态并通过BLE上报。这部分功能是通过AT指令配置的，不需要修改模块固件。

2.2 开源电路设计的三个关键点

我把自己画板时整理出的开源电路要点说一下，这些细节是数据手册里不会特意强调的。

第一个是天线净空区。模块的PCB天线区域正下方和正上方，禁止铺铜、禁止走任何信号线。这个区域如果处理不好，天线性能会严重劣化，表现就是连接距离大幅缩短、信号不稳定。整板设计时，模块最好放在板边，天线朝外，净空区延伸到PCB边缘。如果是金属外壳，天线正上方尽量不要有金属遮挡。

第二个是模块底部焊盘的散热与接地处理。E104-BT02底部通常有大面积接地焊盘，焊接时保证接地良好，既有利于散热，也有助于射频接地。PCB上对应位置要开足够多的过孔，把接地焊盘连接到主地平面。

第三个是串口走线的长度和干扰。模块的UART引脚走线尽量短，避免与电源线、射频走线平行。如果板内空间紧张，可以加33欧姆的串联电阻来抑制反射噪声。这个电阻在高速UART场景下效果不太明显，但成本极低，画板时预留位置不吃亏。

采用了这些电路设计之后，模块的射频性能和通信稳定性才真正有保障。很多朋友反映“同一批模块有的好用有的不好用”，大部分情况不是模块本身差异，而是板上天线环境和电源质量不一样。

2.3 上电时序与AT指令验证

硬件接好之后，上电不要急。模块上电后内部有一个启动初始化过程，大概需要200到300毫秒。如果主控上电后立刻发AT指令，大概率收不到响应，这不是模块坏了，而是它还没准备好。实际项目中我习惯在主控初始化代码里加一个500毫秒的延时，确保模块稳定后再开始通信。

验证模块是否工作，最简单的办法是接一个USB转TTL工具，打开串口助手，发一条AT指令。模块正常会回复OK。如果没反应，按这个顺序排查：先量电源电压是否在正常范围，再确认TXD/RXD有没有接反，最后检查串口助手的波特率设置是否与模块一致。这里有个小技巧，把模块的TXD和RXD短接，然后在串口助手里发数据，如果能收到自己发的数据，说明串口通路是通的，问题在模块端；收不到则说明USB转TTL工具或接线有问题。

3. 最核心的实战验证：用BLE调试助手跑通双向透传

3.1 广播与连接：从手机看到模块的第一步

模块上电后默认处于从机模式，会持续广播。打开手机上的BLE调试助手APP（我常用nRF Connect，也试过LightBlue，都挺好用），扫描设备列表，能看到一个名字类似“E104-BT02_xxxx”的设备，这就是模块的默认广播名。

点击连接，状态变为已连接之后，在APP里通常能看到模块暴露的服务列表。透传模块一般会提供两个特征值：一个用于写入数据（手机发给模块），一个用于通知数据（模块发给手机）。不同固件版本的服务UUID可能不一样，但操作逻辑相同。

我见过不少朋友卡在这一步：能扫描到设备，但点击连接总是失败。常见原因有三个：一是模块可能还连着一个别的设备，一个从机同时只能被一个主机连接，被占用的时候其他设备自然连不上；二是模块进入休眠状态，不对外广播，需要先通过PIO唤醒或者重新上电；三是手机蓝牙缓存了旧的广播信息，在APP里清除绑定记录或者换个设备试试。

3.2 发送和接收：透传模式的核心体验

连接成功后，在BLE调试助手的写入特征值里输入“hello”，点击发送，模块的TXD引脚立刻会输出这串字符。用串口助手接到模块的TXD，就能看到“hello”原样出现在串口里。反过来，在串口助手里发一段文字，手机APP的通知特征值会立刻弹出来。这个过程就是BLE透传，一收一发，没有协议转换，没有编解码，你的MCU只需要当作普通串口来处理数据即可。

这里我要提醒一个新手最容易困惑的点：BLE协议的单次数据包长度是有限的。默认情况下，BLE的MTU（Maximum Transmission Unit，最大传输单元）是23字节，扣掉协议头，实际用户数据一次最多只能传20字节。如果通过透传模块发一长串字符串，模块内部会帮我们自动分包，但对端接收时需要自己拼包。如果你用的是BLE调试助手，在消息日志里能看到收到的数据被分成了多段。

怎么解决这个问题？两种思路。一是应用层自己做拆包和合包，每包控制在20字节以内，按序号发送，接收端按序号拼接。二是协商增大MTU，比如协商到247字节，这样单包实际可以传244字节，效率大幅提升。MTU协商这块后面详细说，它在BLE开发里非常重要。

3.3 用两个模块做主从互传的完整测试

单模块配合手机调试助手能跑通，只算完成了第一步。真正做产品，很多时候是两个E104-BT02模块之间互相通信，一个配成主机，一个配成从机。

我把这个测试流程整理一下，大家可以直接照做：

• 从机配置：不用改，默认就是从机模式，广播名沿用默认即可
• 主机配置：用AT指令把模块A设置为主机模式，并将目标从机地址配置为模块B的MAC地址
• 主机发起连接：模块A上电后会自动扫描目标设备并发起连接，连接成功后两个模块的串口就相当于被一条无线通道串起来了
• 验证双向通信：在模块A的串口发数据，模块B的串口能收到；反过来也一样

这个主从互传测试很值得做，因为它验证的不只是透传功能，还验证了连接过程的稳定性和数据通道的完整性。实际调试中我遇到过一个问题：主机配置好目标地址之后，有时候上电不会自动连接，而是隔很久才连上。查了一圈发现是广播间隔设置的问题。从机的广播间隔越长，主机扫描到它的时间就越长。适当把从机的广播间隔调短（比如从1000ms调到100ms），连接速度立竿见影。

4. 广播、连接、绑定与MTU：把BLE协议的关键机制讲透

4.1 广播类型与广播间隔：功耗与连接速度的博弈

用E104-BT02这种透传模块，很多人只关心AT指令怎么配，忽略了广播参数背后的物理意义。但恰恰是这些参数，决定了你的产品续航和用户体验。

BLE广播类型主要分可连接广播、可扫描广播、不可连接广播这几类。对普通双向透传场景，必须用可连接广播，这样手机或主机才能连上来。不可连接广播通常用于纯单向的信标应用，比如室内导航、资产追踪，只往外发数据，不允许连接。

广播间隔是另一个关键参数。模块默认的广播间隔可能是100ms，意思是每100ms发一次广播包。广播间隔越短，设备被发现的速度越快，连接响应越迅速，但功耗也越高。广播间隔越长，功耗越低，但手机扫描到设备的时间可能从几百毫秒变成好几秒。

这里给一个经验值：如果产品需要快速配对，广播间隔设50ms到100ms；如果产品是低功耗传感器，平时不着急连，广播间隔可以拉到500ms甚至1000ms。手机APP连接成功之后，模块通常会停止广播并进入连接状态，此时功耗会进一步下降，所以广播间隔主要影响的是“待机寻找”这个状态的耗电。

4.2 GATT与连接过程：BLE通信的两个阶段

说到调试助手里的服务列表，就不得不提GATT（Generic Attribute Profile，通用属性协议）。我尽量用人话说清楚：BLE设备之间传数据不是像串口那样随便发，而是要先约定好“数据放在哪里”。从机把数据组织成一个个服务（Service），每个服务里包含若干个特征值（Characteristic），特征值才是真正读写数据的入口。

透传模块出厂固件里通常内置了透明的UART服务，本质就是一个自定义GATT服务，包含写特征和通知特征。写特征用于主机往从机写数据，通知特征用于从机主动往主机的方向推送数据。这个过程对用户完全透明，所以叫“透传”。

BLE连接过程本身也值得了解。两个设备从空闲到建立连接，通常经历扫描、广播同步、连接参数协商这几个阶段。连接建立之后，还有一步是交换MTU（Maximum Transmission Unit，最大传输单元）。MTU决定了收发双方单包数据能承载的最大长度。默认MTU为23字节，其中协议头占3字节，用户数据最多20字节。如果双方协商将MTU提升到247字节，单包用户数据可以达到244字节。

在E104-BT02的开发中，如果手机APP是现成的（比如用调试助手），APP通常会主动发起MTU协商。但如果你自己写APP，记得要调用requestMtu之类的接口主动发起，否则一直用默认20字节，大数据量场景效率会很低。模块作为从机，一般会支持MTU协商，具体支持的上限要看固件版本，多数能到185或者247。

4.3 配对与绑定（Bond）：安全性到底怎么选

配对这个词在BLE里经常被误解。我遇到很多朋友问：我的模块都连上了，为什么还要配对？是不是不配对就不能通信？

实际上，BLE连接后默认就能通信，不需要安全性高的配对过程。配对（Pairing）的作用是建立一个安全的加密连接，防止数据被第三方窃听或篡改。绑定（Bonding）是在配对的基础上，双方保存密钥，下次重连时直接恢复加密关系，不需要再次弹窗确认。

E104-BT02模块是否支持配对绑定，取决于固件和AT指令配置。打开BLE调试助手，连接模块后如果APP弹出配对确认框，说明模块开启了强制配对；如果没有弹窗就正常通信，说明模块当前处于“Just Works”或“No Security”模式。

从产品角度我给两点建议。第一，如果你的产品传的是传感器温度、湿度这类不敏感数据，没必要开绑定功能，省点交互复杂度，用户体验更好。第二，如果产品涉及隐私数据或者远程控制类动作（比如智能锁、开关门），务必开启配对绑定并选择支持加密的通信模式。还有个细节，模块MAC地址在BLE协议栈里会体现为静态随机地址或者公共地址，开启绑定之后，部分手机系统（特别是iOS）会要求APP调用配对相关接口，否则无法完成加密握手。这些就需要在APP开发阶段处理好。

4.4 连接参数：影响数据吞吐的关键

连接间隔（Connection Interval）和从机延迟（Slave Latency）这两个参数，直接决定了你的数据能跑多快。连接间隔是主机和从机之间的数据交互周期，比如100ms一次，那每次都轮询一次数据。连接间隔越小，吞吐越高，但功耗也越高。从机延迟允许从机在连续几个连接事件内不响应主机，从而省电，但如果延迟过大，APP发送的数据要等更久才能被模块收到，实时性下降。

透传模块的固件一般允许通过AT指令配置连接参数偏好。如果想追求高速率，把连接间隔设为最小值（比如7.5ms——注意这是协议允许的极限，实际要看模块支持范围），同时从机延迟设为0。如果追求低功耗，连接间隔设大一些，从机延迟可以设两三跳。这里要提醒一点：最终连接参数是由主机决定的，从机只是广播自己期望的参数。如果对端APP没有配置连接参数并且不发连接参数更新请求，那么从机的偏好参数可能不会被采用。用nRF Connect这类调试工具可以手动设置连接参数，自研APP就需要调用相应的连接参数更新接口。

5. HAL库驱动代码移植：从初始化到中断收发的一次性讲清

5.1 为什么我用HAL库而不是标准库

E104-BT02对主控来说就是一个串口设备，所以驱动代码的核心其实就是串口驱动。现在的STM32开发基本都用STM32CubeMX生成HAL库工程，所以我的示例代码基于HAL库。选HAL库的原因不是它比标准库性能好，而是CubeMX生成工程方便，管脚配置、时钟树、串口中断这些都不用手写，降低了出错概率。对于通信模块驱动这种对时序要求不高的场景，HAL库的开销完全足够。

也有朋友问：能不能用LL库？当然可以。LL库更接近寄存器操作，代码体积更小，但可读性稍差。我个人在透传模块驱动场景下还是用HAL，因为代码逻辑不复杂，没必要为了性能微优化牺牲可维护性。

5.2 驱动代码的整体架构

我的驱动代码分三个层次：

• 底层串口初始化：调用MX_USART2_UART_Init完成串口参数配置，使能接收中断
• 数据收发层：提供BT_UART_SendData发送函数，接收回调统一处理
• 应用层：处理接收到的数据，根据协议解析指令，或者在OLED等外设上显示信息

这里展示核心的初始化代码：

void BT_UART_Init(void) { // 串口参数在CubeMX中已配置，波特率默认115200 // 数据位8，停止位1，无校验，无硬件流控 // 此处主要做接收中断使能 HAL_UART_Receive_IT(&huart2, &rx_data, 1); }

接收采用单字节中断的方式。每收到一个字节就进一次中断，存入缓冲区，直到收到帧结束符或者达到最大长度，然后置标志位通知主循环处理。这个方案实现简单，适合大多数透传场景。如果数据量特别大，可以换成DMA加空闲中断的方式，效率更高，但代码复杂度上去了。

接收中断回调的核心代码：

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart->Instance == USART2) { if (rx_len < RX_BUFFER_MAX) { rx_buffer[rx_len++] = rx_data; } // 重新使能接收中断，等待下一个字节 HAL_UART_Receive_IT(&huart2, &rx_data, 1); } }

提示一下：HAL库的中断回调里有好几处地方可能看起来相似，比如HAL_UART_TxCpltCallback和HAL_UART_RxCpltCallback，分别对应发送完成和接收完成，别混淆了。还有，中断回调函数内不要做耗时操作（比如解析复杂协议、驱动OLED），只做数据搬运和标志位置位，耗时操作放到主循环里做，否则会导致后续字节丢失。

5.3 上电配置AT指令的最佳实践

前面提到模块上电需要几百毫秒的初始化时间，所以主控在发送AT指令之前必须等待模块就绪。我习惯的做法是上电后延时500ms，然后发一条空的AT指令测试模块是否响应。如果收到OK，说明模块就绪，可以继续下发配置命令。

在实际项目中，很多配置并不需要每次上电都下发。比如广播名、波特率、主从模式这些参数已经存到模块EEPROM里了，断电不会丢失。所以我的推荐做法是：量产时用AT指令一次性配置好，或者出厂前用串口工具配置好，设备运行时主控只需要做串口通信，不再重复下发配置指令。这样既减少开机时间，也避免代码逻辑复杂化。

如果确实需要在运行时动态改配置（比如通过按键切换广播名），那就在主循环里加一个状态机：

• 发送AT指令
• 等待模块回复
• 解析回复内容
• 根据结果执行下一步

千万不要一条AT指令发完就立刻发下一条，模块处理需要时间，串口又可能有回显，不做好等待机制很容易出现指令错乱。

5.4 处理不定长数据的透传缓冲方案

E104-BT02作为透传模块，MCU这边接收到的数据可能是任意长度的。为了处理这种情况，我通常会定义一个环形缓冲区，接收中断把数据写入环形缓冲，主循环从环形缓冲取出数据做处理。环形缓冲的好处是收发解耦，中断不阻塞，主循环按自己的节奏消费数据。

#define RING_BUFFER_SIZE 512 uint8_t ring_buffer[RING_BUFFER_SIZE]; uint16_t head = 0; uint16_t tail = 0; void RingBuffer_Write(uint8_t data) { uint16_t next_head = (head + 1) % RING_BUFFER_SIZE; if (next_head != tail) // 未满 { ring_buffer[head] = data; head = next_head; } // 如果满则丢弃，简化处理 }

在接收中断回调里调用RingBuffer_Write，主循环里检查head和tail是否相等，不相等就读取数据。这个方案代码量不大，但可靠性比简单数组高很多。编写代码时要注意临界区保护，尤其是在中断里写、在循环里读的情况下。

5.5 搭配OLED显示模块数据的思路

很多朋友做BLE项目是为了做一个小型的可视化设备，比如环境监测仪、运动数据记录器。E104-BT02配合STM32和OLED屏，就可以在本地显示传感器数据，同时通过蓝牙把数据同步到手机。这个组合非常常见。

OLED驱动我一般用SSD1306方案的I2C接口屏幕，HAL库下面移植开源驱动很快。核心逻辑是：在串口接收处理函数中，把收到的数据更新到OLED显示。数据处理里有两个经验：第一，OLED的I2C速率建议设为400KHz，显示刷新才够流畅；第二，别在中断回调里直接驱动OLED，I2C操作耗时较长，会拖慢串口接收，应该把需要显示的数据缓存起来，由主循环统一刷新。

如果还需要存储历史数据，模块搭配一颗SST25VF080B之类的SPI Flash也很常见。SPI Flash的驱动写起来也不复杂，但要注意擦除扇区后再写入的逻辑，以及掉电时避免数据损坏的处理。这部分我就不过多展开了，思路与普通SPI外设一致。

6. 蓝牙与串口蓝牙的区别：常用概念的对比与澄清

我在各种技术群里经常看到有人把BLE和经典蓝牙搞混，或者在选型时拿错方案。这里专门用一个段落来对比一下，因为在E104-BT02开发中理解这个区别对排查问题很有帮助。

经典蓝牙（BR/EDR）和低功耗蓝牙（BLE）是蓝牙标准中的两套独立协议，硬件射频前端有不少相似之处，但协议栈完全不同，数据格式、连接机制、功耗特性差异非常大。经典蓝牙的“经典SPP透传”方式适合传输持续流式数据，比如蓝牙耳机、音箱、串口数据不间断传输。BLE的特点是低功耗、连接快、广播效率高，适合周期性小数据量传输。

E104-BT02属于BLE，所以它不适合长时间满速跑大数据。持续传文件这种需求，需要评估数据量和功耗能不能接受。另外，市面上有些“蓝牙串口模块”是经典蓝牙SPP方案，和BLE模块的驱动方式、AT指令往往不同，不要买错。我的经验是：如果产品是手机蓝牙4.0以上，优先BLE；如果对端是老旧设备或者需要兼容很多年前的手机，才需要考虑经典蓝牙。

还有一个容易混淆的点：蓝牙与BLE的射频差异。BLE运行在2.4GHz ISM频段，有40个信道，其中3个用于广播，37个用于数据通信。BLE采用跳频机制，在多个信道上跳变，抗干扰能力比经典蓝牙好。这也是为什么BLE虽然单包数据量小，但在实际复杂环境中连接稳定性往往超出预期。

对E104-BT02使用中常见的对比场景，我列一个表格方便查阅：

理解了这些差异，你在项目选型和参数配置上就会从容很多。比如遇到“用E104-BT02传图片传输特别慢”的反馈，你就能判断出这属于数据量设计不合理，而不是模块故障。

7. 这几个月实测下来的经验与避坑记录

7.1 大数据量传输：硬件流控与背压机制

我前面提到RTS/CTS硬件流控，这里展开说。透传模块本身内部有一个缓冲区，数据进来先存缓冲区，再由BLE协议栈按MTU大小分包发送。如果主控一次性灌给模块大量数据，模块缓冲区满了却还在收，新数据就会丢失，表现就是手机端收到的数据不完整。

解决这个问题有两个办法。一个是软件限速，主控每发一包数据后延时几毫秒再发下一包，这是“土办法”，能用但不优雅，而且在不同波特率下参数要反复调。另一个是开启硬件流控，把模块的RTS/CTS与主控的串口对应引脚连接起来。当模块缓冲区快满时，RTS引脚拉高通知主控暂停发送，等缓冲区有空余再拉低允许继续。这是真正工程化的方案。

实测数据供参考：在115200波特率、MTU协商到185字节、开启硬件流控的情况下，连续向手机发送大量日志数据，全程不丢包。如果不开启硬件流控，一旦发送速率超过BLE空口吞吐，丢包几乎是必然的。

7.2 功耗测试的意外发现：PIO引脚和广播间隔的影响

我用E104-BT02做过一次功耗测试。待机模式下（不广播、不连接、无PIO活动），模块电流非常低。但一进入广播模式，电流就明显上升。广播间隔设为100ms时，平均电流大概在几十微安到几百微安的区间浮动（具体数值取决于发射功率和广播数据长度）；如果广播间隔拉到1000ms，待机电流能下降一个明显量级。

还有个容易被忽略的功耗来源是PIO引脚的内部上拉电阻。如果设置了内部上拉或者下拉，即使外部没有接任何负载，每个PIO也会有一点点漏电流。这些漏电流在主供电下看不到什么影响，但在纽扣电池供电的产品里就是不可忽视的消耗。

低功耗项目的调试建议是：用一块E104-BT02小模块板，配合电流分析仪实测各个状态下的电流，然后反向优化广播间隔、发射功率和PIO配置。数据说话，不要凭感觉调参。

7.3 连接断开后的自动重连问题

我做产品原型时遇到一个很头疼的问题：手机和模块连接正常，但手机锁屏后蓝牙连接会断开，解锁后模块不自动重连。后来排查才明白，这是由多个因素叠加造成的。

一是手机系统的蓝牙省电策略。很多手机在锁屏后会暂停蓝牙扫描或者拉长连接间隔，尤其是低功耗模式，导致连接被系统断开。二是模块端的连接参数，如果从机延迟设置过大，手机端即使暂时收不到数据也不会立刻判断断连，但一旦超过超时时间，连接就被判为超时断开。三是APP的扫描策略，很多调试助手没有自动重连功能，连接断开后需要手动点击。

E104-BT02模块本身没有掉线自动重连的逻辑，这是需要主控代码来做的。我的处理办法是：主控通过串口给模块发指令查询连接状态，如果发现当前没有连接，则尝试重新配置模块进入广播模式；如果是主从互传模式，主机端则会周期性地扫描从机并发起连接。这个逻辑在量产设备里非常重要，否则产品断电重启之后配对信息丢失，用户需要手动恢复连接，体验会差很多。

7.4 供电纹波导致的重连风暴

有一个故障我印象特别深。某次测试中发现模块随机断连，而且断连后反复广播、反复被连接，像“抽风”一样。刚开始以为是模块故障，换了好几个模块都这样。后来用示波器量模块电源引脚，发现有一个十几毫伏、频率很高的纹波，而这个纹波在射频发射瞬间被明显放大，导致无线电发射性能恶化，连接质量差，频繁掉线。

排查过程其实很曲折：模块单独供电测试完全正常，一旦装入整机就出问题。最后锁定为整机电源走线不合理，射频地与数字地没有区分开，导致电源噪声耦合到射频部分。解决方法是重新画了电源走线，在模块电源输入处增加磁珠和更大容量的储能电容，问题彻底消失。

这个案例给我们的启示是：BLE模块的性能不只是模块自己的事，整个PCB的电源设计、地平面设计、天线环境都直接影响最终效果。遇到连接不稳定的问题，先排查硬件再做软件优化，顺序别搞反。

7.5 关于“5分钟上手”的落地建议

最后说点实际的。E104-BT02这个模块确实能做到5分钟上电跑通透传，前提是你手里已经有适配的底板或者转接板。从零画板的话，建议分三步走：先用官方EVB或转接板配合USB转TTL工具把模块的基本功能验证一遍，确认模块没问题；再画一块最小系统板，把电源、串口、天线净空区处理好，验证自研板卡的射频性能；最后才把它集成到正式产品里。

驱动代码的移植也是如此，不要一上来就追求完美架构。先写一个简单的轮询收发Demo跑通，再逐步加中断、加环形缓冲、加协议处理、加OLED显示，每一步都有明确的验证方法，出了问题也容易定位。我自己带新人时一直强调这个思路——先跑通，再做好。

驱动代码和开源电路图我会继续维护更新，有新的调试经验也会补充进来。毕竟BLE开发表面上看着简单，真正做好稳定性和低功耗，需要踩过不少坑才能积累出一套可靠的设计方法。