• 状态 Resolved
  • 已锁定 已锁定
  • 个回复 6 个回复
  • 名订阅用户 0 名订阅用户
  • 次查看 131 次查看
  • 用户 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：可以使用 wlconf 以不同的方式配置节能功能

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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1227753/wl1837mod-can-power-save-be-configured-differently-using-wlconf

器件型号：WL1837MOD
主题中讨论的其他器件：WL1837

我们应用中的一些模式在本质上是"突发"的。 这意味着我们会发送少量数据(5KB)、然后是一个静默周期(20ms)。 接收设备在收到此信息时绘制图形。 但在这种特定模式下、Wi-Fi 模块的节能行为似乎会定期生效、接收器件获取更大块中的数据(图形的更新会跳转、而不是平滑地滚动数据)。 我们使用了 Wireshark 来确认接收器件指向发送器件上数据的时间戳(这是一个 AP 连接、仅与网络上的两个器件、发送器和接收器相连)。 在本例中、发送方是我们的设备、其中包含：

处理器：i.MX 7 Dual

内核： 5.4.3

wlcore：PHY 固件版本：8.2.0.0.246版

wlcore：已启动固件(版本8.9.0.0.90)

接收设备是运行 iOS 16.4的 iPhone 11。  

启用 wlcore 的内核日志记录并在 图形更新停止时使用 dmesg、我们可以看到日志中充斥着如下信息。 如果 图形更新顺利、没有杂乱、则不会看到这些消息。

[Tue May 9 07:35:32 2023] wlcore：link ps prev Oxc curs 0x0 changed.
[Tue May 907:35:32 20231 wicore: link ps prev 0x0 curOxc changed.
[Tue May 907:35:32 20231 wicore: link ps prev Oxc curs 0x0 changed.
[Tue May 907:35:32 20231 wicore: link ps prev 0x0 curOxc changed.
[Tue May 907:35:32 2023] wicore: link ps prev Oxc curs 0x0 changed.
[月9日07:35:32 2023] wicore: link ps prev 0x0 curOxc changed.
[Tue May 907:35:33 20231 wicore: link ps prev Oxc curs 0x0 changed.
[Tue May 9 07:35:33 2023] wicore: link ps prev 0x0 curOxc changed.
[Tue May 9 07:35:33 2023] wicore: link ps prev Oxc cur, 0x0 changed.
[月9日07：35：33 20231 wIcore：Link ps prev 0x0 curOxc 已更改0xc
[月9日07：35：33 20231 wIcore：Link ps prev Oxc curs 0x0已更改0xc
[月9日07：35：33 20231 wIcore：Link ps prev 0x0 curOxc 已更改0xc
[Tue May 907:35:33 20231 wicore: link ps prev Oxc curs 0x0 changed.
[月9日07：35：33 20231 wIcore：Link ps prev 0x0 curOxc 已更改0xc
[Tue May 907:35:33 20231 wicore: link ps prev Oxc curs 0x0 changed.
[月9日07:35:33 20231 wicore: link ps prev 0x0 curxc changed.
[月9日07：35：33 20231 wIcore：Link ps prev Oxc curs 0x0已更改0xc
[月9日07:35:33 20231 wicore: link ps prev 0x0 curxc changed.
[Tue May 907:35:33 20231 wicore: link ps prev Oxc curs 0x0 changed.

我的问题是在 conf 文件中是否有参数，我们可以调整以影响节电行为(例如，. 附件是 wlconf --get 的输出、用于了解我们的产品配置方式)。

e2e.ti.com/.../melody_5F00_wl18xx_2D00_conf.txt

我谈到的是 core.tx.tid_confX.ps_scheme、core.conn.dynamic_ps_timeout、core.conn.sta_sleep_auth、 wl18xx.ap_sleep.connected_duty_cycle 等文件。

我已经浏览过：

SWRA489 WiLink 8解决方案 WiLink8–wlconf

SWRU422A WL18xx.INI 文件

此外、还有一些关于头文件中各种参数的详细信息：

git.ti.com/.../conf.h

但是、关于设置 A 意味着必须以特定方式设置 B、或者是否实际使用了它们、它们之间的关系并没有任何细节。  

最后、我尝试关闭省电模式、只是想看看使用 iw wlan0将 power_save 设置为 off、是否可以使该行为停止、但它似乎不起作用。

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

    另外、可能感兴趣的是设备上的 tcpdump 输出。 每个分段数据包开始点之间的差值(偏移量0)与20ms 相差不大：

    15：37：53.527731 IP (tos 0x0、TTL 64、id 3382、偏移量0、标志[+]、 原型 UDP (17)、长度1500)
    192.168.20.1.53027>192.168.20.20.49200：UDP、长度错误6180 > 1472
    15：37：53.527820 IP (tos 0x0、TTL 64、id 3382、偏移量1480、标志[+]、 原型 UDP (17)、长度1500)
    192.168.20.1 > 192.168.20.20：IP-proto_17
    15：37：53.527837 IP (tos 0x0、TTL 64、id 3382、offset 2960、flags [+]、 原型 UDP (17)、长度1500)
    192.168.20.1 > 192.168.20.20：IP-proto_17
    15：37：53.527849 IP (tos 0x0、TTL 64、id 3382、offset 4440、flags [+]、 原型 UDP (17)、长度1500)
    192.168.20.1 > 192.168.20.20：IP-proto_17
    15：37：53.527856 IP (tos 0x0、TTL 64、id 3382、offset 5920、flags [无]、 原型 UDP (17)、长度288)
    192.168.20.1 > 192.168.20.20：IP-proto_17


    15：37：53.547730 IP (tos 0x0、TTL 64、id 3384、offset 0、flags [+]、 原型 UDP (17)、长度1500)
    192.168.20.1.53027>192.168.20.20.49200：UDP、长度错误6180 > 1472
    15：37：53.547812 IP (tos 0x0、TTL 64、id 3384、offset 1480、flags [+]、 原型 UDP (17)、长度1500)
    192.168.20.1 > 192.168.20.20：IP-proto_17
    15：37：53.547830 IP (tos 0x0、ttl 64、id 3384、offset 2960、flags [+]、 原型 UDP (17)、长度1500)
    192.168.20.1 > 192.168.20.20：IP-proto_17
    15：37：53.547842 IP (tos 0x0、TTL 64、id 3384、offset 4440、flags [+]、 原型 UDP (17)、长度1500)
    192.168.20.1 > 192.168.20.20：IP-proto_17
    15：37：53.547850 IP (tos 0x0、TTL 64、id 3384、offset 5920、flags [无]、 原型 UDP (17)、长度288)
    192.168.20.1 > 192.168.20.20：IP-proto_17


    15：37：53.567731 IP (tos 0x0、ttl 64、id 3386、偏移0、标志[+]、 原型 UDP (17)、长度1500)
    192.168.20.1.53027>192.168.20.20.49200：UDP、长度错误6180 > 1472
    15：37：53.567811 ip (tos 0x0、ttl 64、id 3386、偏移1480、flags [+]、 原型 UDP (17)、长度1500)
    192.168.20.1 > 192.168.20.20：IP-proto_17
    15：37：53.567828 IP (tos 0x0、ttl 64、id 3386、offset 2960、flags [+]、 原型 UDP (17)、长度1500)
    192.168.20.1 > 192.168.20.20：IP-proto_17
    15：37：53.567839 IP (tos 0x0、TTL 64、id 3386、offset 4440、flags [+]、 原型 UDP (17)、长度1500)
    192.168.20.1 > 192.168.20.20：IP-proto_17
    15：37：53.567847 IP (tos 0x0、TTL 64、id 3386、offset 5920、flags [无]、 原型 UDP (17)、长度288)
    192.168.20.1 > 192.168.20.20：IP-proto_17


    15：37：53.587736 IP (tos 0x0、TTL 64、id 3388、偏移量0、标志[+]、 原型 UDP (17)、长度1500)
    192.168.20.1.53027>192.168.20.20.49200：UDP、长度错误6180 > 1472
    15：37：53.587822 IP (tos 0x0、TTL 64、id 3388、偏移量1480、flags [+]、 原型 UDP (17)、长度1500)
    192.168.20.1 > 192.168.20.20：IP-proto_17
    15：37：53.587839 IP (tos 0x0、TTL 64、id 3388、offset 2960、flags [+]、 原型 UDP (17)、长度1500)
    192.168.20.1 > 192.168.20.20：IP-proto_17
    15：37：53.587849 IP (tos 0x0、TTL 64、id 3388、偏移量4440、标志[+]、 原型 UDP (17)、长度1500)
    192.168.20.1 > 192.168.20.20：IP-proto_17
    15：37：53.587857 IP (tos 0x0、TTL 64、id 3388、偏移量5920、flags [无]、 原型 UDP (17)、长度288)
    192.168.20.1 > 192.168.20.20：IP-proto_17


    15：37：53.607732 IP (tos 0x0、TTL 64、id 3390、偏移0、标志[+]、 原型 UDP (17)、长度1500)
    192.168.20.1.53027>192.168.20.20.49200：UDP、长度错误6180 > 1472
    15：37：53.607783 IP (tos 0x0、TTL 64、id 3390、偏移量1480、标志[+]、 原型 UDP (17)、长度1500)
    192.168.20.1 > 192.168.20.20：IP-proto_17
    15：37：53.607812 IP (tos 0x0、TTL 64、id 3390、offset 2960、flags [+]、 原型 UDP (17)、长度1500)
    192.168.20.1 > 192.168.20.20：IP-proto_17
    15：37：53.607838 IP (tos 0x0、TTL 64、id 3390、偏移量4440、标志[+]、 原型 UDP (17)、长度1500)
    192.168.20.1 > 192.168.20.20：IP-proto_17
    15：37：53.607863 IP (tos 0x0、TTL 64、id 3390、偏移量5920、flags [无]、 原型 UDP (17)、长度288)
    192.168.20.1 > 192.168.20.20：IP-proto_17


    15：37：53.627737 IP (tos 0x0、TTL 64、id 3392、偏移量0、标志[+]、 原型 UDP (17)、长度1500)
    192.168.20.1.53027>192.168.20.20.49200：UDP、长度错误6180 > 1472
    15：37：53.627794 IP (tos 0x0、TTL 64、id 3392、偏移量1480、标志[+]、 原型 UDP (17)、长度1500)
    192.168.20.1 > 192.168.20.20：IP-proto_17
    15：37：53.627821 IP (tos 0x0、TTL 64、id 3392、offset 2960、flags [+]、 原型 UDP (17)、长度1500)
    192.168.20.1 > 192.168.20.20：IP-proto_17
    15：37：53.627847 IP (tos 0x0、TTL 64、id 3392、偏移量4440、标志[+]、 原型 UDP (17)、长度1500)
    192.168.20.1 > 192.168.20.20：IP-proto_17
    15：37：53.627871 IP (tos 0x0、TTL 64、id 3392、偏移量5920、flags [无]、 原型 UDP (17)、长度288)
    192.168.20.1 > 192.168.20.20：IP-proto_17
    15：37：53.647734 IP (tos 0x0、TTL 64、id 3393、offset 0、flags [+]、 原型 UDP (17)、长度1500)
    192.168.20.1.53027>192.168.20.20.49200：UDP、长度错误6180 > 1472

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

    尊敬的 Thomas：

    让我总结一下、看看我的配置和设置是否正确。

    • WL1837设置为 AP、并连接有 iPhone。
    • WL1837正在向 iPhone 传输数据、每20mSec 传输50KB。
    • iPhone 似乎获得更大的数据块,而不是50KB 每20mSec

    如果是这种情况,你可以验证 iPhone 得到的是~250Kb 每~100mSec 吗?

    从 PS 日志来看、iPhone 似乎进入 PS 并在每个信标之前唤醒、因此数据会在 AP 端(WL1837)累积、直到 iPhone 唤醒并获取。 将 WL1837置于唤醒状态对 AP 毫无意义、因为它始终处于唤醒状态。 正确的测试是将电台置于唤醒状态,但因为它是一个 iPhone,我认为这是不可能的。

    如果您看到的是这种情况、请告诉我。

    此致、

    Shlomi.

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

    尊敬的 Shlomi：

    部分更正：

    在此模式下、我们将每20mSec 发送5KB、而不是50KB。  

    似乎发生的是, iPhone 最终接收所有的数据,但它显然在发送端排队。 因此、它似乎并不是每20mSec 就可靠地传输一次、但这些5KB 数据包的集合会延迟、然后再发送。

    关于我的信息,你能否帮助我理解上面 wlcore 消息的含义,这些消息表明这是 iPhone 的节电,而不是 WL 1837的节电? 或者说、在 AP 模式下、WL 1837不采用增强的省电机制、这是否正好符合您的观点？

    此致、

    汤姆

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

    尊敬的 Thomas：

    处于 AP 角色时、器件处于唤醒状态且不会进入睡眠状态、主要是因为它需要始终为基站提供服务。

    如果基站不需要很快收到任何数据并以此种方式节省电力、则可以决定进入睡眠状态(对 AP 使用省电模式)。

    当工作站进入节能模式时、AP 应将待处理数据保存在队列中、并在 TIM IE 中的每个信标向数据发送信号、以便工作站将其拉取。

    在您的情况下发生的情况是, iPhone 进入省电模式,因为20mSec 没有收到任何东西通常会导致设备进入省电模式。 在这种情况下、它需要等待下一个信标、即剩余的80mSec (如果信标间隔为102.4mSec)。 然后、所有待处理的帧都发送到 iPhone。

    我认为情况是这样的原因是：

    • 20mSec 被认为足够长、足以使药柜恢复通电状态
    • 消息"wicore: link ps prev oxc curs 0x0 changed 0xc"、然后"wicore：link ps prev oxc curs 0xc changed 0x0"表明 iPhone 来回切换节能功能

    此致、

    Shlomi.

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

    尊敬的 Shlomi：

    感谢您提供这些信息。 我想最后的一个问题已经解决了。 在 P2P 模式下、如果 WL 1837是 GO (我正在考虑与 Android 的连接)、情况是否相同？ 这意味着如果我们的器件是 GO、那么它将不会进入省电模式？

    此致、

    汤姆

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

    可以、如果该器件最终进入 GO 模式、它将用作 AP。

    此致、

    Shlomi.