E104-BT02 BLE透传模块实战：从选型、驱动移植到硬件调试全指南

我和这个模块打了快两年交道，从最初照着数据手册接线点灯，到后来把它塞进量产项目里做数据透传，中间踩过的坑确实不少。E104-BT02这颗模块在国产BLE方案里算是个“小钢炮”，体积小、功耗低、价格也压得下来，最关键的是亿佰特把硬件参考设计和底层驱动都开源出来了，这意味着你不需要从零啃nRF52832那套复杂的SDK，也能快速把蓝牙功能集成进自己的产品里。这篇文章就围绕这块模块，把从选型、搭环境、改驱动、调电路到排查问题的完整链路捋一遍，给正在评估或者已经入坑的朋友一份能直接“抄作业”的参考。

1. 先搞清楚E104-BT02到底是个什么东西

很多朋友上来就问“这模块能不能传音频”“能不能跑OTA”，其实都是没搞懂模块的定位。E104-BT02本质上是一个基于Nordic nRF52832芯片的BLE透传模块，它做的事情很简单：通过UART或者SPI接口接收你MCU发来的数据，然后按照BLE协议栈打包发送给手机或者另一个模块。反过来，手机发过来的数据也会通过这个模块的串口转发给MCU。它不负责跑业务逻辑，业务逻辑全在你的主控芯片里，模块只做“管道”这一件事。

1.1 核心参数和选型思路

E104-BT02用的是nRF52832-CIAA，Cortex-M4F内核，主频64MHz，自带512KB Flash和64KB RAM。BLE协议栈支持到5.0，发射功率从-40dBm到+4dBm可调，接收灵敏度实测在-96dBm左右（1Mbps速率下）。这里有个关键参数容易被忽略：最大发射功率。市面上有些模块标称+8dBm甚至+10dBm，但nRF52832的硬件上限就是+4dBm，标得更高的基本都是虚标或者靠外挂PA实现的，而外挂PA会显著增加功耗和PCB面积。所以选型时看到+4dBm这个参数基本就能确定是原生的nRF52832方案。

另一个值得关注的是接收灵敏度。很多人只盯着发射功率看，觉得功率越大信号越好。实际上在BLE这种短距通信场景里，接收灵敏度对链路预算的贡献往往比发射功率更关键。E104-BT02在1Mbps速率下能做到-96dBm，意味着在开阔环境下实测通信距离能达到80米左右（手机做主机时），这个数据在同类模块里属于中上水平。

1.2 为什么选择模块而不是直接用芯片

直接画nRF52832的板子也不是不行，但你要面对的是0.4mm间距的QFN封装、射频匹配网络调试、天线阻抗匹配、协议栈烧录这些硬骨头。E104-BT02把这些都帮你搞定了，模块内部已经做了50欧姆阻抗匹配，你只需要保证模块底部的射频焊盘到天线之间的走线短而直就行。

模块的引脚间距是2.0mm，手焊毫无压力，洞洞板都能玩。官方的开源底板设计用的是邮票孔方式，我在量产项目里用的是半孔工艺，成本差别不大但可靠性会好一些。另一个选择模块的理由是认证。E104-BT02本身过了SRRC和FCC认证，如果你的产品发射功率和天线形式跟模块一致，可以直接引用模块的认证报告，省下几万块的认证费用和时间，这对小团队来说非常关键。

1.3 模块的开源程度到底有多高

亿佰特官网提供了完整的技术资料包，包括数据手册、硬件参考设计（原理图和PCB， Allegro格式）、软件驱动代码、测试工具和上位机软件。硬件设计文件是可以直接拿去打样的程度，软件方面提供了基于官方SDK的透传固件源码，以及STM32平台的驱动示例代码。

这里我要说明一点：模块出厂默认烧录的是透传固件，你拿到手只要接上串口就能用，不需要自己写蓝牙协议栈。但如果你需要自定义服务、自定义特征值、或者做OTA升级这类高级功能，就需要基于官方SDK重新开发固件。官方提供的驱动代码是很好的学习起点，但直接拿来量产的话，建议还是要自己捋一遍代码逻辑，尤其是协议栈事件处理部分尽量不要动，容易出问题。

2. 驱动代码移植：从跑马灯到数据透传的关键一步

官方驱动代码的核心思路很简单：MCU通过UART与模块通信，模块内部把串口数据封装成BLE Notification发送出去，同时监听BLE Write事件并把收到的数据从串口吐出来。整个透传过程是双向的，但逻辑是串行处理的，不理解这一点会在后面调试时走弯路。

2.1 代码架构先看清楚再动手

官方STM32例程的代码结构大致是这样的：主循环里调用BLE_HandleEvent()处理模块上报的事件，这些事件包括连接状态变化、数据接收完成、发送缓冲区空等。串口接收用中断+环形缓冲区的方式，保证主循环不被阻塞。蓝牙数据接收是异步的，模块收到手机数据后通过串口主动上报，MCU的串口中断把数据丢进环形缓冲区，主循环再取出来处理。

我建议移植的时候保留这套架构，不要自己改成查询方式接收串口数据。BLE的数据到达时间是完全随机的，查询方式会丢数据，而且主循环被串口接收阻塞后，无法及时处理模块上报的断开连接事件，会导致异常断连后MCU感知不到，一直傻等。

// 官方例程核心逻辑简化版，注意这是伪代码，具体以官方SDK为准 int main(void) { // 初始化串口、GPIO等外设 BLE_UART_Init(); while (1) { // 处理BLE模块上报的事件（连接、断开、数据到达） BLE_HandleEvent(); // 处理串口接收到的数据，通过BLE发送 if (ring_buffer_has_data(&rx_buf)) { uint8_t len = ring_buffer_read(&rx_buf, temp_buf, MAX_SEND_LEN); BLE_SendData(temp_buf, len); } } }

2.2 MTU的大小决定了单包能传多少数据

这是BLE开发里最容易踩坑的地方之一。BLE 4.2之前默认MTU是23字节，去掉2字节头，实际有效载荷只有20字节。E104-BT02支持协商MTU，但需要手机端主动发起MTU Exchange Request。iOS系统会自动协商到185字节，Android 5.0及以上版本系统也默认协商，但部分定制ROM会有问题。

在实际项目中，我把模块的MTU配置到了247字节（这是nRF52832的上限），这样单包最多可以传244字节的有效载荷。注意，这个配置需要主机端和从机端都支持才行。如果手机端的BLE库没有主动协商MTU，那数据会被链路层拆成多个20字节的包发送，接收方需要自己处理重组逻辑。所以如果你的项目涉及大数据包传输，建议在手机端代码里显式调用requestMtu()方法（Android）或者配置CBPeripheralManager的maximumWriteValueLength（iOS）。

2.3 广播类型和连接参数的坑

E104-BT02默认的广播类型是不可连接广播还是可连接广播，取决于固件配置。透传固件出厂默认是可连接广播，设备名默认是“E104-BT02”。如果你在应用里需要同时被多个设备扫描到，就要注意广播类型和广播间隔的配置。

广播间隔默认是100ms，这意味着扫描端大约每100ms能发现一次这个设备。如果应用对连接速度敏感，可以把这个值改小到20ms（BLE协议允许的最小值），但代价是功耗增加。对于电池供电的设备，广播间隔建议设置在200ms以上，这样平均功耗能控制在几十微安的级别。

连接参数的坑在于连接间隔。模块默认请求的连接间隔是7.5ms到30ms之间，从机可以通过更新连接参数请求来调整。如果你的应用是数据透传型的，建议请求7.5ms的短连接间隔，这样可以获得更低的延迟；如果是低功耗传感器型，请求30ms以上的长连接间隔更合适。这里有个经验值：连接间隔7.5ms时，实际传输吞吐量大约在60-80kbps之间，已经足够大部分业务使用了。

另外，调试的时候记得用手机上的nRF Connect工具查看模块的广播和连接参数，这个工具免费而且功能强大，能看到很多细节信息。

2.4 配对（Bonding）和绑定关系管理

热词里出现了“ble调试助手绑定(bond)”，说明很多人在这一块有疑问。BLE的配对（Pairing）和绑定（Bonding）是两回事：配对是临时性的安全认证过程，绑定是在配对后把密钥保存下来，下次连接时直接使用，不需要重新配对。

E104-BT02的透传固件默认不要求配对，也就是说任何主机都可以连接并读写数据。如果你的产品需要保护数据不被第三方截取，就需要开启配对绑定流程。在nRF52832的SDK里，这涉及到Security Manager的配置，包括配对方式（Just Works、Passkey、Out of Band）和IO能力（键盘、屏幕、无输入输出）的设置。

遇到比较多的问题是：明明配对了，但重新上电后又要重新配对。这是因为绑定信息存在模块内部Flash里，但模块重新上电后如果固件没有实现加载绑定信息的功能，或者绑定的模式是“临时”而非“持久”，就会出现这种问题。排查方向是先确认固件里Security Mode设置是否正确，然后确认模块的复位引脚在系统复位时有没有被拉低导致模块也跟着复位，模块一复位，RAM里的绑定信息就丢了，如果固件没有在Flash里持久化，就回到未配对状态了。

3. 硬件电路设计：照着参考设计改是快的，但要知道为什么

官方提供的参考设计覆盖了电源、天线、调试接口三个部分。很多新手直接照着画，画完打样回来发现信号强度差很多，问题就出在供电和天线上。

3.1 电源设计：LDO比DC-DC更适合

E104-BT02的工作电压是1.8V到3.6V，典型值3.3V。模块内部已经有DCDC转换器，所以你外部供电只要提供稳定的3.3V就行。

我踩过的坑是电源纹波。BLE在发射时瞬时电流可以达到10mA左右，如果供电电压纹波过大，会导致射频性能下降，具体表现是发射功率不达标、接收灵敏度变差。建议在模块的VCC引脚旁边放一个10uF的陶瓷电容和一个0.1uF的高频去耦电容，并且这个电容要尽量靠近模块引脚。如果电路板空间允许，再放一个4.7uH的电感做电源滤波。

对于电池供电的产品，LDO用HT7333这种微功耗LDO就很好，静态电流只有几个微安。不要用DC-DC模块给BLE模块供电，除非你的DC-DC开关频率远离2.4GHz，否则开关噪声会直接耦合到射频前端，导致灵敏度下降几个dB。实测过某款DC-DC给E104-BT02供电后，通信距离从80米掉到了40米，换了LDO立竿见影。

3.2 参考时钟和晶振的注意事项

E104-BT02模块内部集成了32MHz晶振和32.768kHz的RTC晶振，所以你不用外部再挂晶振，这也是模块小巧的原因之一。但需要注意，模块的32MHz晶振精度是+-10ppm，这个精度对于BLE通信是足够的。你唯一要关心的是，不要在你的主板上放一个工作在32MHz附近的强辐射源（比如另一个高速MCU的晶振），否则会干扰模块的射频接收。

实测过一块板子，主控MCU用的24MHz晶振，离模块的射频区域太近，导致BLE接收灵敏度下降了3dB左右。后来把MCU晶振位置挪到了板子另一侧，问题就解决了。所以layout时给模块让出一条“干净”的射频通道很重要。

3.3 天线的选择和布局

E104-BT02有PCB板载天线和IPEX座子两种版本，型号上后缀不一样。板载天线版本的天线区丝印有一块白色区域，下面就是PCB天线，layout时这区域不能走线、不能覆铜，周围要保持净空。IPEX版本的好处是天线可以引出到外壳外部，信号更好，但成本也会高一些。

比较常见的错误是：板载天线版本的模块放置在金属外壳内，或者天线区域附近有大面积的地平面或走线，这会破坏天线的阻抗匹配和辐射方向图，导致信号衰减。实测金属外壳对板载天线的衰减可以达到20dB以上，基本就没法用了。

如果需要放在金属外壳里，一定选IPEX版本，把天线通过馈线引出到外壳开窗的位置。天线选型方面，2.4G频段的陶瓷天线或FPC天线都可以，注意天线的接地要求，有的天线是“2地1信号”，有的是“1地1信号”，别接错。

3.4 开源电路的复用和修改

官方参考设计里的底板包含USB转串口、指示灯、按键、LDO等电路。如果你的产品不需要USB调试功能，可以只保留串口、供电和复位电路。我通常会把参考设计里的串口芯片换成更便宜的CH340N，因为CH340N体积小且不需要晶振，对省PCB面积很有帮助。

还需要注意一个细节：E104-BT02的RST引脚是低电平复位，设计按键复位电路时，建议在RST引脚上拉一个10k电阻到VCC，同时并联一个0.1uF电容到地，做简单的硬件防抖。软件复位虽然方便，但在模块死机时不好用，硬件复位还是必要的。

4. BLE调试：从扫描到连接的完整流程

这一节内容更像是给新手朋友的“地图”，因为BLE的开发调试链路跟传统串口调试不太一样，没有一个“万能调试助手”能一次搞定所有问题。实际项目里，我常用的组合是nRF Connect（手机端）+ Wireshark + USB dongle（抓包用）。

4.1 用nRF Connect走一遍基本流程

nRF Connect在手机上的使用步骤大概是这样的：

1. 扫描：打开应用，开始扫描，能看到周围所有广播的设备，包括设备名、MAC地址、RSSI值
2. 查看广播包：点开一个设备的广播包详情，能看到设备名称、服务UUID、厂商自定义数据等
3. 连接：点击连接按钮，观察连接参数协商结果（连接间隔、延迟、超时时间）
4. 查看服务：连接成功后，下方会列出设备的Service列表，找到透传服务的UUID（官方默认是FEE7），展开里面的Characteristic
5. 收发测试：在可写的Characteristic上点击“写”按钮，可以向模块发送数据；在可通知的Characteristic上点击“通知”按钮，可以接收模块发来的数据

这套流程走通之后，再回到自己的代码调试，思路会清晰很多。

4.2 广播类型怎么选

热词里有“ble广播类型”，这里详细说一下。BLE广播类型主要分四种：

• 可连接非定向广播（Connectable Undirected）：默认类型，可以被扫描到，也可以被连接
• 可连接定向广播（Connectable Directed）：快速连接场景使用，只在指定设备存在时广播，功耗更低
• 不可连接非定向广播（Non-connectable Undirected）：纯广播模式，不能被连接，用于Beacon等场景
• 可扫描非定向广播（Scannable Undirected）：可被扫描，但连接请求要等active scan后才能发起

对于大多数数据透传产品，用第一种就够了。做Beacon或者电子围栏项目时，用不可连接广播+厂商自定义数据的方式，功耗能做到最低。

还有一个容易忽视的概念是广播数据里的Flags字段，它指示设备是否支持LE、是否支持BR/EDR（传统蓝牙）。热词里“蓝牙br ble区别”问的就是这个。BR是传统蓝牙，用于音频传输（蓝牙耳机），功耗高、连接慢；BLE是低功耗蓝牙，用于数据透传和传感器，功耗低、连接快。E104-BT02只支持BLE，不支持BR。所以广播包里的Flags字段会设置成“仅支持LE”，手机端可以据此判断设备类型。

4.3 GATT 和 服务/特征值的关系

GATT（Generic Attribute Profile）是BLE数据传输的“规则书”，服务（Service）和特征值（Characteristic）是GATT的两个核心概念。打个比方，一个服务就是一个抽屉，特征值就是抽屉里的小格子，数据就存在小格子里。手机要跟模块通信，本质上就是读写模块暴露出来的特征值。

E104-BT02透传固件的默认服务UUID是FEE7，里面有写特征值（Write）和通知特征值（Notify）。写特征值是手机往模块发数据的通道，通知特征值是模块往手机发数据的通道。理解这个概念后，调试时就清楚该怎么操作了：写特征值通信是双向的，通知特征值只能模块主动发，手机只能订阅。

如果自定义固件，你可以添加自己的服务，比如给传感器数据单独建一个服务，给控制指令单独建一个服务，这样应用层管理更方便。

4.4 使用Wireshark抓包定位问题

手机端nRF Connect能解决大部分“能不能连接”“能不能收发”的问题，但遇到“设备会周期性断开”“广播时断时续”这类疑难杂症时，必须上抓包工具。用一块nRF52840 DK板或者nRF52832 DK板配合Wireshark就能抓空中包。

抓包能看到的细节很多：广播包内容、连接请求参数、连接参数协商过程、数据通道上的每一个包、断连原因（原因码能直接告诉你是因为超时、还是对方主动断开、还是MIC认证失败）。这些信息对排查问题非常关键。比如设备周期性断连，抓包发现是连接超时（原因码0x08），那问题多半出在连接间隔和从机延迟的配置上，不能盲目修改协议栈代码。

5. 进阶玩法：数字钥匙、BLE配网和低功耗设计

模块的基础功能跑通之后，可以做一些更贴近实际应用的事情。热词列表里有“ble数字钥匙”“esp32-s3 ble配网”，这些都是BLE目前很典型的应用场景。

5.1 BLE数字钥匙的实现思路

数字钥匙的应用场景是：手机靠近设备，设备自动解锁。核心逻辑是手机和模块建立加密连接，然后进行身份认证。E104-BT02支持安全连接（LESC），通过ECDH密钥交换来实现加密和安全配对。

实现方案通常分两步：

1. 配对绑定：手机首次靠近设备时，发起配对，交换密钥并保存
2. 认证开门：后续靠近时，通过绑定的密钥快速建立加密连接，然后一个简单的Challenge-Response流程完成认证

这里的难点在于，配对绑定的初始化流程要设计好。通常需要一个触发机制，比如按键进入配对模式，防止其他手机在用户不知情的情况下配对上设备。在实际项目中，我用过一个方案：量产时模块内部预置一个初始密码，首次配对时手机和模块通过这个密码完成绑定，绑定成功后模块主动修改或清除这个初始密码，防止二次使用。

5.2 BLE配网：ESP32-S3和蓝牙模块的配合

热词里有两个朗的“esp32 ble controller”“esp32-s3 ble配网”。这其实是个很常见的组合：ESP32充当BLE配网的“管道”，它同时有Wi-Fi和BLE能力，通过BLE App把Wi-Fi的SSID和密码传给ESP32，ESP32再用这些信息去连接路由器。

用E104-BT02做配网时，主控MCU不一定有Wi-Fi功能，你可以把E104-BT02接到任何一个MCU上，让MCU通过BLE模块接收手机发来的配网信息，然后MCU再把配网信息通过UART或SPI发给Wi-Fi模组（比如ESP8266、ESP32）。这样就把BLE配网能力赋予了一个不具备蓝牙功能的传统MCU。

不过要留意的是，nRF52832的Flash只有512KB，如果你通过E104-BT02传输较大的固件包做OTA升级，Flash会相对紧张，需要合理规划存储分区。

5.3 低功耗：让设备用一颗纽扣电池跑一年

BLE模块最大的优势就是低功耗，但也要在软硬件层面都做好，才能真正实现“静默运行”。E104-BT02在休眠模式下，待机电流可以做到微安级别。实现低功耗的核心是：模块在没有数据需要发送时尽量进入睡眠状态，有数据时快速唤醒。

具体操作包括：

1. 建立业务分级：非关键数据（如状态心跳）延长发送间隔
2. 广播策略优化：不需要被连接时，把广播间隔拉长，或者直接关闭广播
3. 连接参数协商：在不需要高频通信时，请求增加从机延迟（Slave Latency），这样模块可以跳过多个连接事件，只在有数据时才醒来
4. 硬件设计配合：MCU同样进入睡眠模式，用RTC唤醒或者模块的某个引脚唤醒

做低功耗设计时还要警惕“假睡眠”问题。有次实测模块待机电流有很高的mA级别，排查了半天发现是模块的某个GPIO悬空了，引脚上产生了漏电流。后来在未使用的GPIO上统一配置成输出低或者上拉，问题就消失了。这个经验对于所有低功耗BLE项目都适用：GPIO状态一定要处理好。

5.4 存储扩展：SST25VF080B和其他Flash芯片

热词里有“sst25vf080b驱动代码”和“tm1621驱动代码”，这两个都是嵌入式开发中常用的外围器件。SST25VF080B是一个8Mbit的SPI NOR Flash，常用于存储较大的固件备份或数据日志。E104-BT02的nRF52832内部Flash只有512KB，如果应用需要存很多数据，可以考虑外挂一片SPI Flash。

驱动SPI Flash的代码很成熟，网上能搜到很多现成驱动，注意根据自己的MCU平台适配SPI的读写函数就行。一个容易踩的坑是擦除和写入的时间不同，SST25VF080B扇区擦除最长时间是40ms，实时性要求高的任务不能阻塞等待擦除完成，可以安排一个任务队列，把擦除任务放到后台执行。

6. 常见问题排查与奇怪Bug实录

这部分内容是我个人觉得最有价值的，因为问题排查的过程往往比正常流程更能加深蓝牙协议栈的理解。下面是我在实际项目里遇到过的几个典型问题，希望能给大家提供一些排查思路。

6.1 模块连上了但发不了数据

在一次调试中，手机能连上模块，但写数据没有反应。排查思路是先通过nRF Connect看写操作有没有报错，结果发现报错是“Write request rejected”，原因值显示“Invalid attribute value length”。这说明手机端写入的数据长度超过了特征值允许的最大长度。

E104-BT02官方透传固件的写特征值最大长度默认是20字节（老版本固件）或者更长的值（新版本固件可以配置到MTU-3）。如果手机端没有协商MTU，系统默认按20字节来写入，超过后就会报错。解决方法是手机端先发起MTU协商，或者把数据按20字节分包发送。

这个问题的坑在于：有时候发送端把数据分包了，但接收端没有处理拆包逻辑，导致收到的是各个包的“头”和“尾”拼接。所以分包发送和拆包重组是BLE透传方案里最常见的功夫活，建议封装一层简单的协议，比如在每包数据前面加上包序号和总包数。

6.2 设备会周期性断开连接

真实项目中遇到过一类问题：设备连接的稳定性不稳，设备连接运行一段时间后，会突然断开，并在几秒后重新广播。抓包后发现是连接超时（原因码0x08），看连接参数发现连接间隔被设置为15ms，连接超时时间被设置为2秒（最小值），并且从机延迟有时候被设置为0。

当系统负荷大或者刷卡的时候，链路层因为调度不及时错过了一个连接事件，就会导致连接超时。解决办法是：在连接参数里把连接超时时间调大（比如调到10秒），同时把从机延迟设置为1或2。这样即使主从双方偶尔抖一下，链路也不会立即断掉。

对比一下：连接超时时间太短，会导致频繁断连；连接超时时间太长，会让通信中断的感知变得迟钝。实际设计时建议从机请求的超时时间在5~10秒之间，这是多数BLE设备的常用配置。

6.3 模块不广播了怎么办

开机后发现模块完全不广播，nRF Connect扫描不到设备。排查分三步：

1. 确认模块的供电电压是否正常（用万用表量VCC对GND）
2. 确认模块的RST引脚不是一直被拉低（模块卡在复位状态就不工作）
3. 确认模块有没有烧录过固件（出厂是透传固件，如果你改过固件，可能固件本身就没启动广播）

有一次排查到最后发现是MCU的某个GPIO把模块的RST引脚拉低了，导致模块一直在复位循环。后来把GPIO配置成高阻输入模式才解决。

6.4 BLE广播时有时无、信号忽强忽弱

这个跟布局关系很大。之前做手持设备，BLE信号在一米内就断了，排查了很久发现是主板上的一个DC-DC电感正好在模块天线旁边，电磁干扰直接打掉了灵敏度。把电感挪到离天线5cm外，信号正常了。

所以再次建议：板载天线版本的E104-BT02，周围一定要净空；IPEX版本的天线要远离大电流走线和电感、晶振等器件。

6.5 bluetoothctl关闭BR保留BLE的差异

热词里有“bluetoothctl关闭br保留ble”，这其实是Linux环境下蓝牙调试的技巧。在Linux下用bluetoothctl管理蓝牙适配器时，默认可能启用BR/EDR和BLE双模。如果只调试BLE设备，可以关闭BR/EDR只用BLE，这样扫描结果更干净，也避免一些兼容性问题。

操作方法是：

# 查看当前适配器状态 bluetoothctl show # 关闭BR/EDR，只保留LE sudo btmgmt -i hci0 bredr off # 或者使用更底层的命令 sudo hciconfig hci0 down sudo hciconfig hci0 up

这样调试并行设备时，扫描列表里不会混入传统蓝牙设备，排查起来更高效。

7. 实测记录：通信距离、功耗和稳定性数据

这部分放一些我在实际项目中实测的数据，给大家一个直观参考。

7.1 自由空间通信距离测试

用E104-BT02透传固件+手机nRF Connect做测试，环境为室外空旷场地：

• 发射功率 +4dBm，BLE 1Mbps，手机为iPhone 12，实际稳定通信距离大约75~85米
• 手上拿板子的角度会影响信号，板子侧面对手机时RSSI会比正面低5~10dBm
• IPEX版本+外置2dBi鞭状天线，距离可以到100~120米，但注意天线要竖立起来

对比了一下某款国产同价位模块（也是nRF52832方案），E104-BT02的表现属于中上，尤其是接收灵敏度这一项比好些模块能高1~2dBm，别小看这1~2dBm，在临界距离处往往就是连得上和连不上的区别。

7.2 功耗实测数据

这些数据说明一个问题：想让电量撑得久，广播间隔和连接参数必须根据不同阶段动态调节，不能一套参数走到底。

7.3 稳定性测试的压力结果

做过一个48小时连续通信测试，MCU每秒向手机发100次数据（每次20字节），手机端也随机下发指令。48小时总共发送约170万包数据，丢包率在0.01%以下，期间没有出现断连或假死的情况。使用的连接参数是：连接间隔7.5ms、从机延迟0、超时5秒。

这个稳定性成绩让我对E104-BT02比较放心了，当然前提是硬件layout和固件配置都做对了。如果layout乱、电源脏，那再好的模块也可能不稳定。

8. 开源生态和后续扩展思路

最后聊聊这个系列还能怎么玩。

8.1 WCH BLE Central方案对比

热词里有“wch ble central”，指的是沁恒的BLE主从一体方案。如果你需要让两个E104-BT02模块之间通信，也就是组一个BLE网络，直接用两个模块互相连接是可行的，但要注意：E104-BT02的透传固件默认是从机模式，它只能被连接，不能主动连接别的设备。要实现模块对模块通信，必须把其中一个模块刷成主机模式固件，或者用沁恒CH57x系列这种主从一体的MCU来做主机端。

我自己试过的方案是：一个ESP32（开BLE Central）作为主设备，连接多个E104-BT02从设备组成星型网络，往一个节点发数据时其他节点不受影响，实测连接5个从设备的稳定性还可以。如果从设备数量更多，比如超过10个，广播和连接管理的复杂度会明显上升，需要合理设计扫描策略和连接策略。

8.2 其他外设驱动的开源资源

热词里还提到“tm1621驱动代码”“hal库驱动oled代码”这类外设驱动。这些驱动在网上都有大量开源资源，找代码不算难，难的是适配自己的MCU平台。我的习惯是：先把外设的时序图画出来（比如SPI或I2C的时序），然后对照现有代码一个bit一个bit地核对，排错速度比乱试快得多。

8.3 数据帧协议和产品化建议

如果你要基于E104-BT02做产品，建议在上层加一层简单的协议，比如：

帧头（2字节） + 长度（1字节） + 类型（1字节） + 数据（N字节） + 校验（1字节）

这样做的好处是：连接的两端能区分“数据包”和“控制包”，也能应付BLE分包、粘包的问题，产品迭代时也方便加新指令。我之前一个项目就是用Frame格式封装后，一个月内加了6条新指令，代码基本没怎么动。

产品化阶段还有两个建议：

1. 把模块的MAC地址打印到产品标签上，方便保修和运维时识别设备
2. 产线测试阶段写一个简单的PC工具，通过USB转串口连接模块，自动测试收发和信号强度，能大幅提升产线效率

写在最后的两个小技巧

根据我的经验，决定BLE项目成败的往往不是代码本身，而是那些容易被忽略的细节。

第一点是天线净空。画板子的时候，再喜欢把元件摆满，也给天线区域多留一点空间，别为了省一两平方厘米的板面积把性能搭进去。

第二点是先做最小系统验证再做功能开发。拿到模块的第一天，建议按官方例程跑通一个最简单的透传，手机能发数据、能收数据，再考虑怎么改协议、怎么加高级功能。如果一上来就想一步到位做完整系统，出了问题你很难判断是模块的问题、固件的问题还是电路的问题。

我用E104-BT02做了好几个项目，它给我的印象是“性价比高、上手快、稳定可靠”，但再好的模块也要用得对才行。希望这篇文章能让你少走一些我们已经走过的弯路，把更多的精力花在业务功能上，而不是和蓝牙协议栈较劲。有问题欢迎在评论区交流，我看到了会回复的。