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.

[参考译文] CC2540:由于重试次数极高、Win10上的 BLE 吞吐量缓慢(监听器日志)

Guru**** 2532350 points


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

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1030529/cc2540-slow-ble-throughput-on-win10-due-to-extremly-high-amount-of-retries-sniffer-log

器件型号:CC2540

您好!

我一直在努力寻找无线固件更新(使用 OAD 目标)在 Windows 10 PC 上花费很长时间的原因、即使它在 Android 或 iOS 设备上运行良好。

在分析了与 BLE 监听器的连接后、我发现通过窗口将连接间隔设置为6ms、从而实现可能的最快连接速度。 但是、每个读取或写入请求最多需要一秒钟的时间才能完成。 由于固件更新需要通过无线方式发送9400个数据块、因此速度非常慢。

但我发现监听器日志中的重试次数极高。 一些写入请求正在发送数百次。 因此、这并不奇怪、它的速度非常慢、但如果同一台设备能够在 Android 或 iOS 上以非常高的速度进行更新、这种情况如何呢。

即使器件就在 PC 旁边、这看起来连接真的很糟糕。 我使用 Android 手机测试了同一台设备、即使我将手机带入另一间有多个房间和墙壁的房间、也能执行更新。

因此、我认为这不是连接问题、至少也不是外围设备本身的问题。 一切似乎都是 Windows 或 PC 的问题、但我不知道这可能是什么、如果我可以做些什么来解决它吗?

监听器日志可能有助于更好地了解这里发生的情况、以及为什么只有 Windows 才会出现此问题、但 iOS 和 Android 手机都不会出现此问题。

正如您在监听器日志窗口中看到的、可以毫无问题地发送块14、15和16。 然后,它试图将第17块发送给几百次的尝试。 这里有什么可能有用的东西吗? 我也可以提供完整日志、但这会重复使用更多的固件数据块。

您可以看到 ACK 状态重试大部分时间、但也可以看到意外的 SN。 我从未见过意外的 NESN。  我完全不知道为什么这种问题只会在 PC 上发生、而这不是一台包含廉价蓝牙软件狗的 PC。 它实际上具有一个外部天线。

Sniffer Log

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

    您好!

    感谢您分享所有详细信息。

    首先、我建议验证是否可以使用其他机器复制相同的内容。 这样,我们至少可以从"嫌疑人名单"中删除一个要素。

    然后、很高兴看到 WiFi 是否会影响传输。 可能会尝试关闭 PC 上的 WiFi 接口。 我之所以建议这样做、是因为蓝牙和 WiFi 都使用相同的2.4GHz 射频频段。 因此、WiFi 信号可能会干扰蓝牙。

    此致、

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

    您好!

    我忘记了写这篇文章、我在多台 PC 上观察到了这一点、但我只是测试了一些其他的东西、希望进一步缩小这一点。

    首先完全停用了我的 PC 的 Wifi 和蓝牙模块、并改用了 USB 蓝牙软件狗、此时会发生完全相同的行为。 不同的蓝牙硬件、但具有相同驱动程序的同一台 PC 等

    然后、我还在内置蓝牙的笔记本电脑上尝试了它、实际上在这台笔记本电脑上没有发生这种情况(也是 Windows 10、但完全不同的硬件)。

    现在、我测试过的任何智能手机上都不会发生这种情况、这种情况在笔记本电脑上也不会发生、但在蓝牙内置的主 PC 上或使用 USB 软件狗时也会发生这种情况。

    我认为这意味着 BLE 外设应该可以、问题出在 PC 上、但 我可以采取一些措施来解决这个问题、或者至少加快这个过程? 不过、我注意到的一件事是笔记本电脑建立了连接、连接间隔较慢。 大约为50ms。 这使得更新速度比 iOS 或 Android 上的更新速度慢、但速度仍然足够快、因此没有问题。

    经过数百次重试的 PC 以6ms 的间隔建立连接。 但是、在外设中选择较慢的连接间隔也会影响所有其他器件的速度、因此这不是一个很好的解决方法。

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

    您好!

    看起来很难跟踪问题...

    也许您可以尝试确认问题是否与连接间隔有关? (对我来说、这听起来只是一个假设-如果您已经确认了这一点、请告诉我)。 这样、我们就可以一起考虑根据作为 OAD 分配器的器件来调整连接间隔的智能方法?

    (请注意、我认为实际连接间隔不是6ms。 根据蓝牙规范、可用的较短连接间隔为7.5ms)。

    此致、

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

    在实际查看监听器数据之前、我认为连接间隔可能是一切都如此缓慢的原因、这就是我提到它的原因、但在查看监听器数据后、我现在知道连接本身的速度是可以达到的(7.5ms 间隔) 但是 、发送的重复数据包数量非常多。

    现在监听器日志已100%确认实际的连接间隔。 在我进行初步猜测之后、我的所有分析都基于实际的监听器日志。 是的、连接间隔为7.5ms、但这对应于监听器日志的固件或 LLData 层中的6ms 间隔。

    6ms * 1.25的连接间隔为7.5ms 实际值。 所有这些都是匹配的。  我在第一次建立连接时直接附加了监听器日志的另一个屏幕截图。 您可以在 LLData (第1部分)中看到、间隔设置为6、正确为6 * 1.25 = 7.5ms。 此外、在监听器日志中、所有记录的数据传输显示的时间差为7 (我认为它不显示分数)

    connection start

    OAD 分配器基本上是一个 Windows WPF 应用程序、因此我无法调整连接间隔或任何连接参数、因为所有这些都是由 Windows 驱动程序处理的。 但是、我现在知道连接间隔确实足够快、不应该成为问题、 剩下的唯一问题是大量重复数据包。 我只是不确定我是否可以在器件固件中执行任何操作来帮助 Windows 更好地管理此问题、或者这实际上是 Windows 驱动程序问题还是 其他问题。

    连接质量也可以排除为问题。 出于某种原因、简单的写入请求会导致几百次重试、甚至可能超过一千次重试、以获得一个简单的20字节数据包。 不是每次都有、但经常足以显著降低整个过程的速度 。

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

    您好!

    我知道。 但是、我们似乎无法在这个问题上为您提供更多帮助。 很抱歉。

    此致、

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

    感谢您的参与。 我当然期待这可能是一个艰难的事情。

    但让我问一个一般性问题。 如果出于某种原因、我们假设此 PC 在传输数据时出现问题、我可以在 BLE 外设侧执行任何操作来帮助建立类似这样的不稳定连接吗? 可能是不同的连接参数?  

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

    您好!

    如果计算机也支持编码 PHY、尝试使用 S2或 S8 PHY 来执行 OAD 可能是有道理的。 当然、这会影响最大吞吐量(但在您的情况下、实际上可能比重新传输每个数据包更好)、并导致更高的功耗。

    此致、