This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

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

Guru**** 2581345 points
Other Parts Discussed in Thread: CC2640, CC2650MODA

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/674111/rtos-cc2640r2f-packet-loss-over-the-air-in-sable-x-r2

器件型号:CC2640R2F
主题中讨论的其他器件:CC2640CC2650MODA

工具/软件:TI-RTOS

您好!

我使用 simple_peripheal 示例将数据从传感器发送到 Android 手机。

我能够对数据进行采样并将其发送到 Android。 但有时、我会遇到数据包损耗。

当我们尝试通过无线方式捕获数据时、我们看到 Master 正在发送 Unexp。 SN 作为对丢失的数据包的确认。

我将在这里添加监听器捕获。 我们在 Android 端错过了856号数据包。

为什么会发生这种情况? 是否有办法知道外设侧的这个错误并再次传输同一个数据包?

谢谢、

Bharath。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好 Bharath、

    在这种情况下、嗅探器会混淆 SN/NESN ACK 位。 数据包#856由主器件在数据包#857中应答。

    监听器可能错过了从站对数据包857的响应、因为在858中、SN/NESN 位表示主站已成功接收到至少一个介于857/858之间的数据包。 诚然、SN/NESN 稍微复杂、我建议您阅读蓝牙规范以获得良好的说明。

    在任何情况下、BLE 链路层协议/规范都不允许丢弃数据包、在链路断开或确认数据包之前、LE 控制器将继续重新传输。

    由于存储器分配问题或其他原因、Android/iOS 和(甚至) CC2640可能会在较高的堆栈层上丢弃传入的数据包、但除了具有应用级流控制/确认外、您可以做的事情不多。

    此致、
    Aslak
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Aslak、
    Sniffer 可能会对1或2个数据包感到困惑、但无论何时出现数据丢失、观察结果都是相同的。
    主器件正在发送 ACK-OK、并在下一个数据包中发送 Unexp SN。 该数据包将在 Android 手机上丢弃、而不通知应用层。
    为什么会发生这种情况? 这是什么解决方案?

    谢谢你
    Bharath
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好 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