• 状态
  • 已锁定 已锁定
  • 回复 6 回复
  • 订户 0 订户
  • 视图 764 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] WL1837MOD：蓝牙延迟高于预期

admin
Guru**** 2543400 points
Other Parts Discussed in Thread: WL1837MOD, WL1835MOD

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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1160084/wl1837mod-bluetooth-latency-higher-than-expected

器件型号：WL1837MOD
Thread 中讨论的其他器件： WL1835MOD

团队、  

我的客户希望在~6ms 的范围内实现低蓝牙延迟。 但是、当使用 WL1837MOD 进行测试时、差异很大：

当我们寻求具有极低延迟的蓝牙通信时、我们使用 l2ping 命令来测量两个 WL1837MOD 之间消息的延迟。 因此、我们观察到、l2cap 回波请求不会立即发送、而是会延迟不同的时间。

这是从 Wireshark 导出 l2ping 的 hcidump：

 

时间[s]

源

目的

协议

长度

方向

信息

0.689

本地主机()

TexasIns_2c：90：63 (bluez 5.50)

L2CAP

57.

已发送

已发送回波请求

0.695

控制器

主机

HCI_EVT

8.

接收到

接收已完成数据包的数量

0.697.

TexasIns_2c：90：63 (bluez 5.50)

本地主机()

L2CAP

57.

接收到

接收回波响应

1.697.

本地主机()

TexasIns_2c：90：63 (bluez 5.50)

L2CAP

57.

已发送

已发送回波请求

1.714

控制器

主机

HCI_EVT

8.

接收到

接收已完成数据包的数量

1.717.

TexasIns_2c：90：63 (bluez 5.50)

本地主机()

L2CAP

57.

接收到

接收回波响应

2.718.

本地主机()

TexasIns_2c：90：63 (bluez 5.50)

L2CAP

57.

已发送

已发送回波请求

2.725.

控制器

主机

HCI_EVT

8.

接收到

接收已完成数据包的数量

2.727.

TexasIns_2c：90：63 (bluez 5.50)

本地主机()

L2CAP

57.

接收到

接收回波响应

3.727.

本地主机()

TexasIns_2c：90：63 (bluez 5.50)

L2CAP

57.

已发送

已发送回波请求

3.735

控制器

主机

HCI_EVT

8.

接收到

接收已完成数据包的数量

3.737.

TexasIns_2c：90：63 (bluez 5.50)

本地主机()

L2CAP

57.

接收到

接收回波响应

4.737.

本地主机()

TexasIns_2c：90：63 (bluez 5.50)

L2CAP

57.

已发送

已发送回波请求

4.764

控制器

主机

HCI_EVT

8.

接收到

接收已完成数据包的数量

4.767

TexasIns_2c：90：63 (bluez 5.50)

本地主机()

L2CAP

57.

接收到

接收回波响应

5.767

本地主机()

TexasIns_2c：90：63 (bluez 5.50)

L2CAP

57.

已发送

已发送回波请求

5.794

控制器

主机

HCI_EVT

8.

接收到

接收已完成数据包的数量

5.79

TexasIns_2c：90：63 (bluez 5.50)

本地主机()

L2CAP

57.

接收到

接收回波响应

 

据我们了解，数据包是在主机收到“已完成数据包的接收数量”事件之前发送的。 这是第一个回波请求发送后6ms、第二个回波请求发送后17ms、第三个回波请求发送后7ms、第四个回波请求发送后8ms、第五个回波请求发送后27ms、第六个回波请求发送后27ms。

这些是典型的时间。 在较长的测量中、我们观察到最小值为4.5ms、平均值为25ms、最大值为34.8ms。

这些值适用于 WLAN 接口关闭的情况。

 

您能告诉我们在发送 l2cap 数据包之前延迟的原因是什么？ 是否有任何方法来配置 WL1837mod 蓝牙器件以更小的延迟发送数据包？

 

我们希望在99.99%的所有情况下实现小于10ms 的蓝牙延迟。

到目前为止、我们尝试配置深度睡眠和重传号码、但这些没有影响。 我还尝试配置流控制、但没有成功：似乎不支持保证的服务类型。

主机 CPU： NXP i.MX6
Linux 内核： 5.4.17
WL18x 固件： 8.9.0.0.79
蓝牙堆栈： bluez 5.50

谢谢、
 Robert

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

    您好、Robert、

    我正在研究这一点、明天我应该为您提供合适的答案。

    此致、

    Rogelio

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

    您好、Robert、

    您可以更改为保证连接、我建议您在 VS HCI 命令中签出 HCI_VS_Configure_DDIP (0xFD55)。

    很难说出导致该延迟的确切原因。 我知道 L2CAP 会检查回显请求的有效性、我会更深入地查看它、看看是否有办法从收到请求和发出响应的时间中减轻延迟。 我会让您保持最新状态。

    BR、

    Rogelio

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

    您好、Rogelio、  

    感谢您的建议！ 不幸的是、它没有帮助：

    我没有成功、将连接更改为保证：

    我尝试了 HCI_VS_Configure_DDIP 命令：

    # hcitool cmd 3F 155 60 02 07 02 01 FF FF
    < HCI 命令：ogf 0x3f、ocf 0x0155、PLEN 9
     60 60 02 07 02 01 01 FF FF
    >HCI 事件：0x0E PLEN 4.
     01 55 FD 00

    据我所知、该命令确实成功、但只需在页面、查询和持续低功耗蓝牙扫描期间配置 ACL 的百分比即可、并保证为96%、轮询周期为2。 它不会更改连接的服务类型。 对测量的延迟没有影响：

    2022-10-13 16：32：28.973230 < ACL 数据：处理1个标志0x00 dlen 52
       L2CAP：echo req：dlen 44
    2022-10-13 16：32：28.989491 > HCI 事件：已完成数据包数(0x13) PLEN 5.
       处理1个数据包1.
    2022-10-13 16：32：28.991926 > ACL data：handle 1 flags 0x02 dlen 52
       L2CAP：echo rsp：dlen 44

    回波响应发送需要16毫秒、2毫秒内收到响应。

    此外，我还尝试了 QoS 设置命令，以保证用于 l2ping 的连接的设置：

    2022-10-13 16：28：43.782223 < HCI 命令：QoS 设置(0x02|0x0007) PLEN 20
       句柄1标志0x00
       服务类型：2.
       令牌速率：-1
       峰值带宽：-1
       延迟：6.
       延迟变化：0
    2022-10-13 16：28：43.783997 > HCI 事件：命令状态(0x0F) PLEN 4.
       QoS 设置(0x02|0x0007)状态0x00 ncmd 1.
    2022-10-13 16：28：43.784159 > HCI 事件：QoS 设置完成(0x0d) PLEN 21
       状态0x27句柄1标志0
       错误：不支持请求的 QoS

    因此、QoS 设置完成事件显示不支持服务类型。 我尝试了不同的参数、但没有接受任何参数。

    您能帮个忙吗？我需要设置哪些参数才能保证连接？

     

    谢谢、
     Robert

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

    您好、Rogleio、

    我还收到了更多反馈/问题：

    您的意思是 HCI_VS_Configure_DDIP (0xFD55)命令、本文档中的第4.1.1.9章对此进行了介绍？

    https://www.ti.com/lit/ug/swru442b/swru442b.pdf

    命令说明指出：

    此命令用于配置 ACL 之间的带宽分配(尽力或保证连接)
    和查询/页面/蓝牙低功耗扫描。 …μ A

    该命令没有连接句柄的参数、因此我假设它通常会配置带宽分配。 由于在页面/查询/低功耗扫描过程中，ACL 百分比有两个参数用于获取最佳工作 ACL 和保证 ACL，因此我知道该命令确实配置了最佳工作 ACL 和保证 ACL 与页面/查询/低功耗扫描的百分比。

     

    我找不到任何关于在尽力和有保证之间切换连接类型的信息。

    相比之下、HCI_Flow_Specification 和 HCI_QOS_Setup 都支持为连接指定服务类型(尽力而为或保证)(但是、每当我尝试将服务类型设置为保证(如之前所写的那样)时、我都会得到不支持的 QoS 重放。

    您能否确认我正确理解了这些命令的含义？

    我还使用参数0应用了 HCI_Write_Scan_Enable 命令、以确保没有页面/查询扫描活动(对延迟没有影响)。
    与 HCI_LE_Set_Scan_Enable 相同–两者都没有影响。

    为了检查是否没有其他蓝牙器件有任何影响、我在 EMC 试验箱(= Faraday 笼)内执行了测量、但没有其他无线器件处于活动状态：

    我得到的结果与之前完全相同、L2CAP 回波所需的时间为5到30 ms、平均时间超过20毫秒。

     

    一个新的观察结果是、当我执行角色更改时、直到完成的数据包数量发生变化的延迟。

    具有主角色的蓝牙设备从发送 L2CAP 数据包到接收完成的数据包数量事件的延迟为3到4毫秒。 但从器件的延迟在5到27毫秒之间变化。

    除了用于 L2CAP 回波测量的连接外、没有其他连接。

     

    我知道蓝牙从设备无法随时发送数据。 但是、仅连接1个且没有扫描活动的情况下、大约20毫秒的延迟似乎太高了。

     

    我明白、不支持 BlueZ 堆栈。 但是、我确实会观察 HCI 命令、事件和数据、以检查是否存在任何与低延迟冲突的情况。

    使用 bluez 的 l2ping 命令、我可以看到发出以下 HCI 命令：

    • HCI_Create_Connection 0x0405、通过命令状态事件、角色更改事件(远程设备为从设备)和连接完成事件进行响应
    • HCI_READ_Remote_Supported_Features 0x041B 由命令状态、最大插槽更改(5)和读取远程支持的功能事件(ff Fe 2D FED b ff 7b 87 =几乎支持所有功能)进行响应
    • HCI_READ_Remote_Extended_Features 0x041C 以命令状态事件和远程扩展功能完成事件进行响应
    • HCI_Remote_Name_Request 0x0419以命令状态事件和远程名称请求完成事件进行响应
    • 带有 L2CAP 命令的 ACL 数据包信息请求(扩展功能)通过多个已完成的数据包事件和一个信息响应数据包进行响应
    • 由于远程信息请求(+大量已完成的数据包事件)而产生的具有 L2CAP 命令信息响应(扩展功能)的 ACL 数据包
    • 带有 L2CAP 命令的 ACL 数据包信息请求(固定通道)响应了多个已完成的数据包事件和一个信息响应数据包
    • 由于远程信息请求(+大量已完成的数据包事件)而产生的具有 L2CAP 命令信息响应(固定通道)的 ACL 数据包
    • 已响应 L2CAP 回显请求的 ACL 数据包、其中包含多个已完成的数据包事件和一个 L2CAP 回显响应

    我以 btsnoop 文件格式附加了所描述的通信作为记录。

    为了实现低延迟连接、您是否识别出缺失或错误的某些命令/设置？

    您能否提供一个 HCI 命令序列(或 btssnoop 记录或类似记录)、以较小的延迟显示连接设置和多个 L2CAP 回波？

    感谢您的分析。

    附件： e2e.ti.com/.../l2ping1_5F00_echo.btsnoope2e.ti.com/.../l2ping1.loge2e.ti.com/.../l2ping1.btsnoop

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

    您好、Rogelio、

    我得到了客户的进一步反馈。 WL18x 与另一 BT 器件通信时取得了一定的成功、但 WL18x 器件之间没有成功：

    在我们方面，我进行了一系列进一步的测试，但不幸的是，我尚未取得突破，而是一个令人困惑/担忧的结果。  我们尚未成功使 Bluetopia 堆栈并运行。

    我们已经准备好了安装了 TI WL1835MOD 的 BeagleBone Blue 电路板，因此我们可以进行独立测试。 我能够使用此板重新创建完全相同的行为，因此我越理解问题是在 TI 蓝牙模块固件中而不是在操作系统中。

    此外、我们直接在 HCI 接口上执行了许多测试、以消除蓝牙堆栈作为错误源的问题。

    最后、我在配置蓝牙通信服务质量方面取得了一些进展。 这使我能够获得8ms 的平均延迟(L2CAP 回波请求/响应、在25ms 范围内输出为10%)–我们将完全满足小于15ms 的延迟。

    但是、这仅适用于 TI WL1837MOD 和另一个蓝牙模块。 一旦我在2个 TI WL1837MOD 模块之间建立连接、我就会确认服务质量配置、但延迟仍为25至30ms。

    我必须在这里作进一步的努力。

     

    在研究不同蓝牙模块之间的延迟时、结果更加令人困惑。

    虽然 TI WL1837MOD 器件的连接延迟仅低于30ms、但几乎没有异常器件。 不过、有时延迟会在8ms 范围内发生变化、然后在30ms 再次发生变化。

    根据尝试的不同、我会获得不同的延迟模式、但在这里、我只重复使用 L2CAP echo 建立连接并测量延迟的相同命令：

    在 TI WL1337MOD 和 Intel 蓝牙模块之间、该实验的结果更加极端。

    在现有连接期间、我还执行了主从开关、这可以理解地改变了延迟模式。

    但是、根据用于构建初始连接的模块、延迟和振荡差异很大。

    这是 TI 蓝牙模块、在该模块中、我可以与其他蓝牙模块以不同的组合反复看到这些振动、而其他蓝牙模块之间的连接几乎始终具有恒定的延迟和很少的跳闸。

    通过一种在蓝牙连接的链路管理器协议级别记录命令的方法、我无法检测到模块之间的任何显著差异、连接过程仍然是相同的。

    目前、我无法解释振动或大异常值来自何处、以及它们为何如此极端。

    但这只是一个小问题、但希望它能向您展示调查有多困难。

     

    如果 TI 有一份应用手册、其中说明了如何使用 TI 模块连接到蓝牙低延迟以及该延迟取决于哪些参数、那将会有所帮助。

    或者、说明 TI 固件如何配置蓝牙模块之间的通信插槽。 您的同事使用 HCI_VS_CONFIGURE DDIP 命令时提到查询/页面扫描时间、ACL 通信和 SCO 通信之间存在一个分割。 还将保留用于低功耗通信的插槽。
    但是、由于我关闭了低功耗通信、并且任何不属于其他通信的扫描(并且关闭深度睡眠不会影响)、TI 固件似乎播放了另一个–我不知道。

     

    谢谢、  
     Robert

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

    感谢您提供新信息。 我将尝试使用蓝阿片版的 l2ping 来复制它。

    此致、

    Rogelio