【IoT】产品设计之 BLE 蓝牙连接不稳定的原因和处理方法

时间:2024-04-09 21:41:04

设计 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 通信过程是建立在连接基础之上的,按角色不同可以分为蓝牙主设备、蓝牙从设备,也叫*设备和外围设备,一次蓝牙通信,通常由主机发起,从机响应。

【IoT】产品设计之 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