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.

[参考译文] WL1831MOD:连接第二个器件后的 BLE 缓慢响应时间

Guru**** 2391355 points


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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/981997/wl1831mod-follow-up-on-slow-ble-response-times-after-second-device-is-connected

器件型号:WL1831MOD

通过将连接间隔从7.5毫秒增加到10毫秒、我们基本上消除了与多个器件通信的问题。

我们仍在努力更好地了解7.5毫秒连接间隔导致故障的原因。 我们认为、这些故障连接到从 Wireshark 跟踪计算通道映射、这些布线显示了将 LL_CHANNEL MAP_IND 发送到从器件时同时出现的故障。

我正在插入来自 TI 蓝牙记录器的屏幕截图。 请注意、关联的.lgr 文件是通过在7.5ms 连接间隔内监测 wl18xx 调试线路与2个从器件的连接而创建的、其中一个连接由于长时间延迟而最终失败。 此文件显示良好通道的数量在28至37之间变化。

 "良好信道数 MWS 受害者79、MWS 施源器79 "是什么意思

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

    您好!

    "MWS 受害人%i、MWS 攻击者%i"的打印反映了来自 MWS 机制的 AFH 状态机输入。 基本上、WL18xx 器件具有通过 MWS 处理共存的规定、如 BT 核心规范中所述。 不过、您不太可能使用该设备、这在打印件中是隐含的-始终报告所有79个 BT 信道均可使用。 实际上、MWS 机制不保留任何频道。 因此、我认为打印与您的问题无关。

    此致、

    Michael

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

    您好、Michael、

    屏幕截图显示所有37个 BLE 通道均可用于通道映射。 但是、在.lgr 日志文件的其他位置、我们可以看到可用通道数下降到28。 我想将.lgr 文件附加到该邮件中、以便您可以查看它。 但是、这个错误报告工具似乎不允许我插入或附加.lgr 文件、即使这是专有的 TI 格式。

    如何向您提交完整的.lgr 文件?

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

    您好!

    请尝试将您的.lgr 重命名为.lgr.txt 文件或仅重命名为.txt 文件。 更改文件扩展名应允许您避开文件类型筛选器。 至少这就是我可以将任意文件上载到 E2E 上的帖子的方式-您的发布权限可能有所不同。

    此致、

    Michael

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

    我尝试将 LQ3.0.2_bad_run_1.lgr 重命名为 LQ3.0.2_bad_run_1.lgr.txt 并将其插入此处。

    TI 网站上周末发生的重大变化使情况更加糟糕。 以前、我可以浏览上传并插入重命名的文件、但新的更改似乎可以防止这种情况发生。  

    您能否为我提供上传文件的链接? 当我们遇到与此相关的错误(e2e.ti.com/.../3534489 )的问题时,我们获得了一种上载二进制文件(包括.lgr 文件)的方法。 遗憾的是、我们从未收到任何有关其内容的回复。 甚至不清楚 TI 的任何人是否使用 TI 蓝牙记录器打开了.lgr 文件。

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

    您好、Elliot、

    最新的 E2E 网站更新也是我要调整的内容。

    我已向您的帐户发送友谊请求、在请求中、您应该会看到一个指向您可以上传到的文件共享的链接。 它是公共写入、因此您可以在此处上载您的.lgr。 我可以在此线程中发布链接、但如果链接可公开写入、我们将面临其他人编辑该文件夹的风险。

    请告诉我您是否可以访问共享文件夹并上传您的文件。

    此致、
    Michael

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

    您好、Michael、

    我已将 LQ3.0.2_BAD_RUN_1.lgr 上传到您的位置。 你能看到吗?

    --埃利奥特

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

    您好、Elliot、

    我已经下载了您的.lgr 文件、现在可以在我的记录器工具中打开它。 请给我一两天时间来查看和分析您的日志。

    此致、

    Michael

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

    ldr 文件是否向您提供了任何建议?

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

    您好!


    查看.lgr 文件、似乎没有任何明显的错误。 通道映射偶尔会获得少量通道、但绝不会低于20个通道、根据 BT 规范、该通道是 AFE 的最小通道。

    日志数据是否是实时捕获的、时间戳是否有效? 日志的一个部分朝向中间、从条目29600开始、似乎 AFE 通道分类过程重复发生、可能超出预期。 为了确认我对该问题的理解、这是否与发生 BLE 响应时间问题的时间段相对应?

    似乎通道分类由 lm_lc_Gemini_COEX 中断触发。 我将需要检查并查看导致该中断的原因。

    此致、
    Michael

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

    实时捕获.lgr 文件数据、因此时间戳应该有效。 很难将.lgr 文件中的时间戳与我们的应用程序日志时间戳相关联。 原则上、如果我们重新运行测试、我们应该能够关联时间戳。 这种设置需要一段时间、因此我不打算马上进行。

    请注意、在使用 WL18xx 控制器与传感器通信时、我们主要设法通过将蓝牙连接间隔从7.5ms 更改为10ms 来避免此问题。

    使用在 Mac、Windows、Chrome、Android 等上运行的蓝牙控制器时、我们未发现此问题。 因此、我们认为问题是 wl18xx 控制器、而不是传感器。 7.5ms 连接间隔适用于这些其他硬件配置。

    我们看到的最清晰的数据似乎涉及 WL18xx、这是使用 Wireshark 获得的。 这对您有什么建议吗?

    Wireshark 的屏幕截图位于 https://e2e.ti.com/support/wireless-connectivity/wifi/f/wi-fi-forum/955480/wl1831mod-slow-ble-response-times-after-second-device-is-connected 上的原始错误 中。

    我无法在此处插入文件,但已将 wireshark1.png 和 Eureka_fail.pcapng 上载到 tidrive.ext.ti.com。

    谢谢、

    埃利奥特

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

    您好、Elliot、

    感谢您将这些文件上传到 ext 驱动器、我现在将它们放在我的 PC 上。

    一般而言、问题可能不容易隔离、可能是由于如果您有多个 LE 链路连接到连接间隔非常短的不同器件、那么您可能会触发一些瓶颈或类似条件、从而延迟您的所有链路。 主要的解决方法是增加连接间隔、这样控制器就不会承受任何压力。

    我仍在研究在您的特定情况下导致延迟的原因、但它看起来更像是 WL18xx 更常见现象的症状、并且不太适合您的用例。

    此致、

    Michael