【IoT】产品设计之 BLE 蓝牙连接不稳定的原因和处理方法_两个蓝牙芯片传输数据就断开连接是为什么

设计 BLE 相关产品时经常会遇到连接突然断开的情况，比如刚连接上就断开、连接成功之后传输数据随机断开。

一般有四种原因：

天线匹配、芯片兼容性、连接参数以及代码逻辑。

1、天线匹配

一般严格按照官方 DEMO 板的参考设计不会有什么问题，但为了适应自己板子的要求做了一些修改，会造成天线匹配问题、信号不稳定、信号范围小等问题，最终导致连接的不稳定。

这个就需要做阻抗匹配、找天线厂家匹配天线等。另外晶振参数（尤其是频偏）也可能影响到 RF 射频的性能，所以选用晶振的时候最好使用官方 DEMO 板建议的晶振或者相同参数的晶振代替。

2、芯片兼容性

通过调节连接参数进行改善，如果还不行就只能换一个芯片试一下，或者直接找原厂的 FAE 支持。

以上两个原因是硬件问题，需要具体调试解决。

3、连接参数

广播间隔、最大连接间隔、最小连接间隔、连接监听时间等都会影响连接的稳定性。

4、代码逻辑

一般有两种情况，一个是刚连接就断开，在连接成功之后执行的一些代码有问题，直接排查连接之后执行的函数即可。

另一种情况就是连接成功之后，可以传输数据，但是会随机断开，有时候连接很稳定。

尤其对于定时发送数据的时候，当把时间间隔调的长一点时，稳定性明显提高；

时间间隔短的时候稳定性就明显降低，出现这种情况是因为 BLE 将数据发送出去之后需要收到底层的确认信号才能进行下一次发送，如果在没有收到底层的确认信号就调用发送函数会报错，从而触发看门狗复位导致断开连接。

在高数据率通信的情况下，调用 BLE 发送函数之后，一定要在收到底层的确认信号之后才能再次调用 BLE 发送函数进行下一次数据的发送。

以 NRF52832 的蓝牙串口例程为例，当我们调用发送函数 ble_nus_string_send 发送函数发送数据之后，如果发送成功则会进入 ble_nus_on_ble_evt（串口服务的 ble 事件中断），该函数中有一个事件为发送完成 BLE_GATTS_EVT_HVN_TX_COMPLETE。

对于以上问题可以优先排除连接参数和代码逻辑问题，因为这些修改容易、成本低。

如果问题依然存在就是天线、兼容性的问题了，后面再集中精力去解决。最后，如果有条件直接联系原厂的技术支持是最好的。

5、其他异常断连

BLE 通信过程是建立在连接基础之上的，按角色不同可以分为蓝牙主设备、蓝牙从设备，也叫中央设备和外围设备，一次蓝牙通信，通常由主机发起，从机响应。

上图中，设备 A 是蓝牙主机，B 是蓝牙从机，BLE 的连接过程，大致分为 6 个步骤：

1）主机进入连接态，侦听待连接设备的广播包，如果在指定时间内没侦听到，会导致连接超时，这个时间由开发者指定；

2）主机成功接收到从机的广播包；

3）主机发送一个连接请求包；

4）主机发出连接请求包后，不管从机有没有收到，都会立即转入连接状态，同时报给用户层一个“已连接上”的消息，也就是图中的 4A。

如果从机能收到这个连接请求包，则从机也立即转入连接状态，并报给用户层一个“已连接上”的消息。

如果从机未能收到连接请求包，则不会发 4B 的消息。

5）主机随即发送一个同步包；

6）从机收到同步包后，回给主机一个同步包，然后不停循环 5 和 6 两个步骤，连接才是真正建立了。

如果 5 和 6 任何一个包丢失，都会导致连接建立失败，报 0x3e 的断开原因。

丢失第 5 步或者第 6 步的数据包，导致连接建立失败。

而这两个包丢失，通常发生在周围存在很多蓝牙设备，导致信道十分拥挤的情况下。

通过在空旷无多余蓝牙设备的地方实验发现，出现这个现象的概率大大降低，由此验证了这个推论。

当周围蓝牙设备不可避免地过多时，应用层可以通过多次重连来规避这个问题。

refer：

https://blog.csdn.net/cheer_me/article/details/84545359 

https://blog.csdn.net/fun_tion/article/details/83722034