TI中文支持网
TI专业的中文技术问题搜集分享网站

CC2640R2F: 蓝牙链接后在通讯一段时间会概率性断链。

Part Number:CC2640R2F

1. CC2640R2F,使用的SDK simplelink_cc2640r2_sdk_5_30_00_03 2.

2. 在数据通讯中,出现3s超时,然后断链。

3. 链路rssi的,70db。

从上面的交互看,设备在通讯中,主设备收不到心跳包。最终超时,导致断链。

请问一下,

1. 是否有手段,查看一下empty包是否在协议栈上收到?

2. 影响收不到报文的原因有那些,怎么排查?

谢谢!

Galaxy Yue:

您好,

关于问题一,最好的方式是抓包

,

quan chen:

你好!抓包的方式只是抓包仪的显示;在接收端上,是否可以把这个空包的事件报上来?我们在程序中增加一个统计?

,

Galaxy Yue:

在协议栈层捕获和识别所有接收的数据包,包括空包。

如果您使用的是空中协议LL,或者主机控制器接口(HCI)层来实现,您需要加一个钩子(hooks)或者一个处理程序(handlers)以识别空包。

空包不只是明确标记为空的,还有没有有效载荷的数据包,需要详细查看每个接收到的数据包,对其大小内容做出判断。

hooks

是一种可以拦截系统的函数调用或者消息的方法。它可以在特定的位置“挂起”程序,允许你注入自己的代码

handlers

当一个特定的事件发生时,例如接收到数据包,处理程序会被调用以进行相应的响应。

您如果进行到这一步,需要添加的相关代码是侦听并识别空数据包

这两种操作都需要对底层协议修改,包括在固件或者驱动程序级别。有些很底层的并非开源的。

,

Galaxy Yue:

您能详细说一下这个统计吗?

不是很理解

,

quan chen:

你好!谢谢你的解释。

我们的问题是在断链前3s的时间段内,看到主机一直没有收到期望的报文,反复请求,直到超时。

1. 对于空包,我个人理解就是主从双方的心跳包。—这个理解是否正确,请给确认一下。

2. 在主从断链的前3s时间段内,主机接收失败,从新发送请求,获取期望的报文(这个是从NESN,SN的顺序上看),从机响应一直正常,但是主机一直没有收到。最终,3s超时后,从新协商建链。

3. 基于问题2的表现,我们想知道,主机上的心跳(这里是空包)是否接收正常?想到的办法就是把接收的空包中,通过协议栈回调,应用层统计,查看是否接收正常?

4. 如果3中的办法不可行,是否有别的办法,确认主设备接收是正常的?目前分析是主设备上的问题,但是这种问题要怎么解决,没有思路了。

谢谢!

,

quan chen:

另外

1.使用HCI层,有配置的流程与接口吗?我只需要看这3s中,是否有报文就可以的。

2. 在正常报文收发中,这个期间应该是不关注空包的吧?

,

Galaxy Yue:

1.理解正确。主从设备定期发送数据包进行交互,即使没有实际的数据需要传输,也会发送一个空数据包,类似心跳机制,用于保证连接状态并检查连接质量。

3.我认为是个好方法

quan chen 说:把接收的空包中,通过协议栈回调,应用层统计,查看是否接收正常?

4.常用的就是 利用主设备的系统日志,蓝牙抓包,以及完全用另一台设备进行测试

,

Galaxy Yue:

相关接口和API和看如下两个link

https://software-dl.ti.com/simplelink/esd/simplelink_cc2640r2_sdk/2.40.00.32/exports/docs/ble5stack/ble_user_guide/html/ble-stack-5.x/hci.html

https://software-dl.ti.com/simplelink/esd/simplelink_cc2640r2_sdk/4.10.00.10_new/exports/docs/ble5stack/ble_user_guide/html/ble-stack-5.x-guide/api-reference-cc2640.html

,

Galaxy Yue:

2.我认为是有必要的

因为它是一种正常连接的标志

它在主从设备之间建立同步,处理时序。

是有用的,但是看你们项目需求,能实时监控到自然是更好

赞(0)
未经允许不得转载:TI中文支持网 » CC2640R2F: 蓝牙链接后在通讯一段时间会概率性断链。
分享到: 更多 (0)