• 状态
  • 已锁定 已锁定
  • 回复 9 回复
  • 订户 0 订户
  • 视图 375 视图
  • 用户 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.

[参考译文] LAUNCHCC3220MODASF：LAUNCHCC3220MODASF：在 WiFi-UDP 模式和原始模式下丢包。

admin
Guru**** 2589300 points
Other Parts Discussed in Thread: CC3200, CC3100, CC3220SF, UNIFLASH

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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/697062/launchcc3220modasf-launchcc3220modasf-packet-drops-in-wifi-udp-mode-and-in-raw-mode

器件型号：LAUNCHCC3220MODASF
主题中讨论的其他器件： CC3200、 CC3100、 CC3220SF、 UNIFLASH

您好！

我尝试使用"radotool"命令(收发器/原始模式)和"send/recv"命令通过 Wi-Fi 进行 UDP 传输。

目的是在屏蔽环境中检测数据包丢失、仅限单向流量。  这是一个 LAUNCHCC3220MODASF 正在发送、另一个正在接收。

相应地修改了代码。

所做更改的简要概述如下。

在为命令"radotool"提供服务的代码中：

  1. 添加了数据包标识符字段以检测丢失的数据包数量。
  2. 该功能是通过计时器添加的、能够配置发送每个数据包后以微秒(us)为单位的延迟、例如500us。  目的是减少丢失的数据包数量。

在提供命令"send/recv"的代码中：

  1. 添加了数据包标识符字段。
  2. 添加了计时器以准确测量时间(以便更准确地计算吞吐量)。

PER 计算如下：

PER =(最后接收到的数据包的数量-成功接收到的数据包的数量)/最后接收到的数据包的数量

如果是"无线电工具"、则通过将每个 sl_Send 之后的延迟从0us 更改为500us、将 PER (丢失的数据包数/预期的数据包总数)从0.01降至0.00013。  500 us 延迟带来了最佳结果、在400 us、300 us 和600或700 us 时、丢失的数据包数超过500 us 时观察到的数据包数。

如果是"发送/接收"(使用 UDP 通过两  个 LAUNCHCC3220MODASF 板之间的 WiFi 连接执行)、则对于100个数据包、PER 为0、但如果传输的数据包数为1000、10000或100000、PER 约为0.3 (30%)。

现在、我的问题是、由于环境是屏蔽的(受到外部射频辐射的屏蔽)、并且流量仅在一个方向上(TX 和 Rx 之间的模式没有变化)、为什么数据包会被丢弃？  我希望0个数据包丢失。

--

此致、

Neeraj Sallh

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

    以下几点和问题：
    -您是否使用了最新的 SDK 和 Service Pack？
    －您如何设置电源策略？ 是否可以使用 SL_WLAN_ALE_AUSE_ON_PO则 重新测试？

    我不确定这是否与第二代产品相关、但在 CC3200中、收发器模式下 TX 侧必须具有较小的延迟。 我不确定该延迟的最短长度是多少。

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

    SDK 为"simplelink_cc32xx_sdk_1_50_00_06"
    2.服务包为"CC3100_CC3200_ServicePack_1.0.1.11-2.9.0.0"

    3.
    从"swru368a.pdf"部分4.6.2中、我看到 sl_WLAN_Aways_on_policy 的用法。
    但是、其中的说明文本还提到用户可以提供目标延迟系数。

    描述文本如下：
    "•始终开启–Wi-Fi 子系统始终保持完全激活状态、提供最佳 WLAN 流量
    性能。 此策略是用户定向的；用户可以提供目标延迟数字。 以进行设置
    始终开启的电源管理策略使用：
    SL_WlanPolicySet (sl_policy_PM、sl_always_ON_policy、NULL、0)"

    问题1："提供此目标延迟"必须使用哪个 API？ 是否可以有指向相关文档的指针？
    问2如果用户在将策略配置为 WLAN_ALOW_ON_PO保 单时不提供目标延迟、默认值是什么？

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

    您好！

    我真的很困惑您使用的是什么器件？ 它是 CC3200还是 CC3220？

    - simplelink_cc32xx_sdk_1_50_00_06 -适用于 CC3220的 SDK

    - CC3100_CC3200_ServicePack_1.0.1.11-2.9.0.0 - CC3200的 ServicePack

    - swru368a.pdf - CC3200文档

    我不确定 SWRU368中针对 CC3200的说法的含义。 但我认为、当您设置"始终开启"策略时、NWP 不会进入睡眠模式、您可以获得最佳性能(=目标延迟)。 如果您设置了其他策略、 则 NWP 本身会增加延迟(由于睡眠)。

    您能否使用始终开启策略的最新 SDK (simplelink_cc32xx_sdk_2_10_00_04)+ ServicePack (3.7.0.1_2.0.0.0_2.2.0.6)重新测试？

    1月

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

    您好 Jan、

    由于我正在使用 CC3200和 CC3220板、因此弄清楚 SDK 版本、Service Pack 和文档等对我来说也很困惑。

    实际上、我在查询中讨论的项目是对"network_terminal_CC3220SF_LAUNCHXL_tirtos_ccs"项目的修改。

    它正在使用的 SDK 1.5.0.06从"tirtos_builds_CC3220_LAUNCHXL_release_ccs"项目继承而来。

    我的安装目录还显示了 SDK 1.50.06。

    但我无法找到有关已应用的 Service Pack 的任何提示。

    您能否提供将 Service Pack 应用到 SDK 的文档参考？

    同时，我也会尝试永远的情。

    --

    此致、

    Neeraj Sallh

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

    是的、我还使用 CC3200和 CC3220。 从我的角度来看、一切都非常清楚、但这并不重要。

    CC3220中的 ServicePack 的工作原理与 CC3200中的工作原理相同。 CC3200和 CC3220的 ServicePack 不同、因为网络处理器中的固件不同。 ServicePack 应用于器件本身(分别上载到 sFlash 中)、而不是应用于 SDK。 可以使用 Uniflash 软件上载 ServicePack。 ServicePack 位于 SDK 子目录\tools\cc32xx_tools\servicepack-cc3x20\。 说明如何使用 Uniflash、请访问 www.ti.com/lit/ug/swru469b/swru469b.pdf

    请使用具有正常和常开电源策略的最新 SDK 和 ServicePack 重新测试。 我希望这个问题仍然存在、但我们需要知道这一点才能取得下一个进展。

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

    你好 Jan D福音，

    只需再分享一个发展/观察。  这一个是积极的、您可以帮助深入了解这种行为。

    在更改 SDK 和 Service Pack 之前、我尝试了另外一件事。

    我在两个连续的发送呼叫之间引入了延迟。  延迟600us 后、PER 变为0、即使是100万个数据包也是如此。

    1. 因此，此行为是否与发件人内部的队列有关？
    2. 是什么解释了 PER 的这种改进？

    --

    此致、

    Neeraj Sallh

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

    我不确定。 您首次开机自检与此测试之间有何区别？

    但是、如果我们讨论收发器模式、可能会在发送之间出现一些小延迟、正如我在第一篇文章中所说的那样。

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

    您好、Jan、

    在我的第一个帖子中、延迟仅在收发器模式发送中引入、即在实现"radotol"命令中引入。

    在发送呼叫之间引入延迟时、收发器案例的 PER 会有所减少、这与您的观察结果一致、即 在收发器模式下、两个发送呼叫之间需要(至少在第一代中)一些延迟。

    在上一篇文章中、我讲述 了在 WiFi 模式下尝试类似操作的结果、其中 UDP 数据从一个 CC3220泵送到另一个 CC3220。

    我可能无法正确地介绍我想要分享的内容。  这次我会以更好的方式再试一次。

    目的是分享我的调查结果：

    1. 即使在 WiFi 模式下、两个发送呼叫之间的有限延迟也提高了 PER。
    2. 在收发器模式的情况下、改进效果更好。  在收发器模式下、我们得到的数据包数量为10E-4、即百万包中的100个。  而在使用 UDP over WiFi 时、PER 为0、即百万包中的0。
    3. 最后，我想与大家分享，这项改善是在没有一贯推行权力政策的情况下取得的。  
    4. 还有一个问题、如果在两个发送呼叫之间使用延迟是确保低 PER 的良好/可靠方法？

    --

    此致、

    Neeraj Sallh

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

    好的、现在一切都很清楚。 我不知道您为什么会看到这种行为。 always_on 策略可能适合仅在 STA 模式下使用。

    1月