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.

[参考译文] CC3351:CC3351:并发蓝牙扫描期间 WiFi 性能严重下降

Guru**** 2796825 points

Other Parts Discussed in Thread: CC3351, AM62P

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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1618569/cc3351-cc3351-severe-wifi-performance-degradation-during-concurrent-bluetooth-scan

器件型号: CC3351
主题: AM62P 中讨论的其他器件

您好:

我观察到、当蓝牙扫描并行处于活动状态时、CC3351 的 WiFi 性能显著下降。

设置:

SoC(定制 PCBA):AM62P 和 CC3351。 将 SDIO 用于 WiFi、将 UART 用于蓝牙。

使用 iperf3 进行测试:

  1. 将 Linux 笔记本电脑连接到 CC3351 的 WiFi AP(此处使用 2.4GHz、但使用 5GHz 时结果相同)、并在笔记本电脑上启动了 iperf3-Server (iperf3 -s -p 5901)  
  2. 已在 AM62P 上启动 iperf3-Client () iperf3 -c <IP-address> -p 5901 -t120

测试结果:

激活蓝牙扫描:

bluetoothctl
代理

打开默认代理打开
扫描打开

[ ID]间隔          传输       比特率          RETR
 [5] 0.00-120.01 秒   234 MB  16.4 MB/秒   409       发送方
 [5] 0.00-120.18 秒   231 MB  16.1 MB/秒             接收器

未激活蓝牙扫描:

扫描关闭 

[ ID]间隔          传输      比特率           RETR
 [5] 0.00-120.00 秒   626 MB  43.7 MB/秒    0       发送方
 [5] 0.00-120.08 秒   623 MB  43.5 MB/秒            接收器

问题:

  1. 在并发蓝牙扫描期间、预计吞吐量会下降吗?
  2. 是否有建议的共存配置参数来提高 WiFi 吞吐量、特别是减少重试次数?
  3. 主动 BLE 扫描期间的最大 WiFi 吞吐量是否存在已知限制?

感谢您的帮助!

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

    您好、Stefan:

    是的、由于 CC33x1 在 BLE 和 WiFi 之间只有一个共享无线电、因此预计会出现降级、由于蓝牙规范中需要更严格的时序要求、BLE 优先于 WiFi。

    此致、

    Rogelio

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

    您好 Rogelio、

    感谢您的答复。

    共享无线电架构导致的一般性能下降是可以理解的。 然而、我对这种下降的幅度感到关注。 特别是、Wi-Fi 重试次数明显增加的情况对于我们的应用来说是不可接受的。

    根据进一步的分析、我得以专门将问题缩小到 BLE 扫描过程。

    为了使设置保持可比性和可重现性、仅使用执行了其他测试 iperf3.  来测量 Wi-Fi 流量和 bluetoothctl  控制蓝牙。
    请查看以下结果:

    bluetoothctl
    agent on
    default-agent
    power off

      [ ID]间隔       传输   比特率      RETR
       [5]  0.00-120.01 秒  603 MB 42.1 MB/秒  0       发送方
       [5]  0.00-120.06 秒  602 MB 42.1 MB/秒          接收器

    power on

      [ ID]间隔       传输   比特率      RETR
       [5]  0.00-120.00 秒  645 MB 45.1 MB/秒  0       发送方
       [5]  0.00-120.07 秒  644 MB 45.0 MB/秒          接收器

    advertise on

      [ ID]间隔       传输   比特率      RETR
       [5]  0.00-120.00 秒  634MB 44.3MB/ 秒  0       发送方
       [5]  0.00-120.07 秒  632 MB 44.2 MB/秒          接收器

    advertise off
    scan on

      [ ID]间隔       传输   比特率      RETR
       [5]  0.00-120.00 秒  227 MB 15.9 MB/秒 539       发送方
       [5]  0.00-120.16 秒  225MB 15.7MB/ 秒          接收器

    您能否确认是否预计会出现这种程度的重试次数下降和增加、以及是否存在有助于减轻影响的配置参数(例如,扫描间隔/窗口调整或共存设置)?

    此致、
    Stefan

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

    您好、Stefan:

    扫描是 BLE 必须做到的资源最繁重的事情、因此我们认为这是 WiFi 吞吐量下降的最大原因。 最好的解决方案是尽量减少扫描时间。 值得庆幸的是、对于大多数用例、扫描非常罕见、因为每个连接只需要进行一次扫描。 以进一步提高扫描期间的吞吐量。 缩短器件扫描的活动时间最好。

    这意味着:

    增加扫描间隔

    减小扫描窗口

    减少扫描持续时间

    此致、

    Rogelio