[参考译文] RTOS/CC2640R2F：可寻址 X-R2中的无线数据包丢失

您好 Bharath、

主设备未发送 Unexp SN、这是监听器的解释。 您可以看到通道0x21上的上一个从站数据包设置了 MD 位、表明它将在数据包857之后发送一些内容。

我发现监听器很不可能由于与实际数据丢失相关的任何原因而丢失数据包、因为您可以看到主器件已确认数据包。 您如何知道监听器中丢失的数据包恰好是 Android 应用中丢失的数据包？

至于监听器缺少数据包的原因、射频本身不可靠、因为随时都可能存在干扰。 在主/从连接中、通常有一种方法可以让任一端请求重新传输丢失的数据包。 监听器不能要求这样做。

您可能会尝试从从设备发送比 Android 愿意接收更多的数据包。 在这种情况下、具有有限数量插槽的从器件上的传出 TX 缓冲区将被填满、当您调用 GATT_Notification 发送数据包时、您将获得成功(0x00)以外的状态。 然后、您的应用程序将负责稍后再次发送此消息。

Android 和其他手机在每次连接事件允许的数据包数量有限、因为它们还必须有时间进行 WiFi 和常规蓝牙等

此致、
Aslak

您好、Aslak、
1) 1)我们通过查看接收到的数据以及与监听器捕获相关的数据、验证了 Android 端丢失的数据包。
2) 2)当我们的 Tx 缓冲区被覆盖时、我们有一个逻辑来指示是否存在覆盖。 但我们看不到在 Android 端接收到的数据中发生任何覆盖。

3) 3)为了消除 WiFi 的干扰、我们始终保持 WiFi 关闭。

让我清楚地告诉您这个问题。
我们使用 CC2650MODA 执行相同的操作。 由于缓冲区覆盖可以保存500ms 数据、因此我们收到了覆盖错误。 由于存储器限制、我们无法增大缓冲区大小。
因此、我们开始使用基于 CC2640R2的 SaBLE-X-R2、该模块缺少实际的 BLE 数据包。 甚至在出现覆盖错误时也不会出现。
当我们查看丢失的数据包和监听器捕获时、我们看到主器件未确认数据包或正在发送 Unexp SN。

谢谢、
Bharath