[参考译文] LAUNCHCC3220MODASF：WiFi 可靠性问题

您好、Charles、

在信号强度较差的情况下、UDP 广播在 WiFi 网络中丢失的数据包百分比通常较大。 对于测试、您可以尝试执行此操作并检查您是否会看到任何差异：

• 尝试使用 UDP 单播
• 将电源策略设置为“Always On”(始终打开)

1月

嗨、Jan、

我尝试将政策更改为"始终开启"、这似乎有所帮助！ 它现在和现在都不会错过、但它的频率要低得多。 我今天没有时间使用单播进行测试、但我想明天应该有更多的时间。

我有点担心、如果我们必须始终坚持政策、那么它将使用更多的电池电量。 我也必须研究一下。 您是否知道是否有更节能的方法来防止丢包？

再次感谢您的帮助、

查尔斯

嗨、Jan、

遗憾的是、我们无法为此应用程序使用单播。

我用正常和始终开启的电源策略做了一些实验、但我仍然很担心出现问题。 我运行了15次测试、在正常模式下、我只接收到信号4次、在始终开启状态下、我只接收到信号11次。 我想至少在常开模式下、我们会接收到所有这些信号、4/15对于正常模式来说非常糟糕。 我们在 Raspberry PIE 上运行了类似的程序、它从未错过任何信号、因此我觉得这应该更好。

再次感谢！

查尔斯

您好、Charles、

由于您使用的是 LaunchPad、我们不能指望硬件设计会出现问题。 如果您确定两个测试用例的信号都正常、则问题可能是由于干扰其他 Wifi 网络或其他2.4GHz 无线电(蓝牙等)。

使用仅依赖 UDP 广播/多播的 IEEE 802.11无线电设计真正(商业)的设备是一个很糟糕的主意。 因为您将在端(客户)端面临许多互操作性问题。 许多 AP 有不同的策略来处理广播和多播。 例如、如果 WLAN 负载较高、许多 AP 会丢弃多播/广播数据包。 例如、我的 Ubiquiti AP 默认启用了根据 WLAN 负载丢弃广播/多播。 是的、此功能可能会被禁用、但需要手动完成。 这是一篇介绍多播 IEEE 802.11问题的好文章。 使用 UDP 广播的情况可能非常相似。

我想在上文第2段中说什么。 即使您在具有相同 AP 的不同客户端设备上运行测试、其中一个设备是可靠的、另一个设备不可靠、您也无法确定丢包问题与客户端或 AP 相关。 由于每个连接的客户端的 AP 的内部管理(例如、AP 侧的数据包可能会丢失、从而承载 WLAN 负载、PHY 速率、RSSI/CSNR 等)。

如果要确定问题的真正原因、则需要使用 WLAN 监听器和受控环境(2.4GHz 时的干扰较低)。 也更适合使用完全受您控制的 AP -例如具有 OpenWRT 的 AP。 但是、即使您能够弄清正在发生的情况并解决您的问题、在迁移到另一个 AP 后、您也可能再次遇到类似的问题。  从我的角度来看、拥有依赖 UDP 广播的 IEEE 802.11设备可能从终端-客户支持方面来说是一场噩梦。

1月

您好、Charles、  

您的环境中是否有大量无线网络流量？ 从根本上说、UDP 不可靠、与繁重的网络流量可靠性相结合时、UDP 的可靠性会进一步降低。 为了确保您始终可以在仅使用 AP 的隔离环境中运行此测试、并且我们的器件可以排除任何疑问。

1月、再次感谢大家的支持。

Jesu

嗨、大家好、

我终于有机会在较低的流量环境中再次运行测试、但我们仍然缺少了始终开启的约1/4 UDP 数据包、而 Raspberry PI 似乎从未错过任何数据包。 我在运行 thark 时也看到了所有的 UDP 数据包、所以我们仍然关注我们的可靠性。 我们知道 UDP 确实会丢弃消息、但奇怪的是、即使在始终开启模式下、我们也会丢弃比 Raspberry PI 更多的消息。 我们希望始终保持至少90%的可靠性、这只是一个不切实际的希望吗？

再次感谢！

查尔斯

您好、Charles、

我已经完成了自己的测试、但我没有看到像您那样丢失这么大的数据包。 我使用 UDP 广播来发现 CC3220器件。 我的器件处于始终开启模式。 我使用了非常简单的 python 脚本、该脚本在100ms 间隔内发送小型 UDP 广播。 在 Python 和 CC3220端对 RX/TX 数据包进行了计数。 我在环境中共同测试了来自 Ubiquiti (Unifi AC Lite)的低射频噪声 AP。

我的测试结果：

• 具有断开天线的 CC3220SF LP (RSSI ~-62dBm)：TX 数据包7367、RX 数据包7285 = 1.1%的 UDP 广播数据包丢失
• 具有 uFL 天线的 CC3220SF LP (RSSI ~-35dBm)：TX 数据包7755、RX 数据包7644 = 1.4% UDP 广播数据包丢失

两个测试用例之间的差异(0.3%)仅为统计偏差。

对于测试、我使用了 CC3220SF LaunchPad Rev A、其代码基于 SDK 版本3_20_00_06和 ServicePack 版本3.12.0.1。

测试时使用了以下简单的 Python 代码：

导入套接字、时间

端口= 30719
主机="192.168.236.8"

s = socket.socket (socket.AF_iNet、sock_DGRAM)
s.setsockopt(socket.SOL_SOCKET、socket.SO_broadcast、1)
msg = CHR (0)+CHR (0)+CHR (0xf6)
cntr = 0；

而 True：
s.sendto(bytes(msg,"iso-8859-1")、("255.255.255.255"、端口)
CNTR = CNTR + 1
打印(cntr)
时间睡眠(0.1) 

1月

嗨、Jan、

您使用什么代码来获取 CC3220？ 我想、在初始化 NWP 时、我们可能会弄乱一些东西、在 launchpad 的示例中找不到正确的示例代码。

再次感谢！

查尔斯

您好、Charles、

对于测试、我使用了自己的具有相当复杂代码的应用。 很遗憾、我无法共享我的代码。 第一组测试是在我的办公室完成的。 我们的办公室具有非常好的射频条件(使用射频屏蔽窗口从增强混凝土建筑而来)。

我在我的公寓里做了另一组测试、其中射频条件要困难得多。

测试设置：

• 我使用了具有板载 SMD 天线的 CC3220SF LaunchPad Rev B (预量产器件)。 使用的软件与第一种情况相同。
• 由于使用了 AP、具有 OpenWRT 18.06.4的历史性 AP TP-Link TL-WR741N/ND v4
• 非常硬的射频环境、包括许多其他 Wifi 网络。 我使用 了 Sennheiser 无线耳机。 此耳机使用专有2.4GHz 无线电、 干扰 Wifi。
• RSSI 约为-60dBm

结果：TX 数据包7310、RX 数据包6474 = 11.4% UDP 广播数据包丢失

在本测试案例中、我无法确定对丢包有更大影响的因素。 无论是糟糕的 AP 还是干扰众多的不良射频环境。

1月

您好、Charles、

您使用的是哪个 SDK 版本？ 我想确保您不会使用带有旧服务包的非常过时的 SDK。  

此外、对于软件、您可以尝试运行网络终端。 您可以通过 CLI 连接到您的 AP 并发送 UDP 数据包。 您不必在此处进行任何软件修改。 只需构建、闪存和打开终端即可发送命令。  

如果您在射频较低的环境中仍能获得相同的行为、请尝试使用不同的 AP。

Jesu

嘿、Jesu、

几个月前我更新了我的 SDK、因此我认为它不应该太旧。 它看起来像是 simplelink_cc32xx_sdk_2_40_02_00。

我将使用网络终端示例进行研究。 我认为这是我们编写 UDP 代码时开始的地方。

再次感谢！

查尔斯

嗨、大家好、

我没有时间再次尝试网络终端示例、但我希望本周花更多的时间来调查我们为什么这么不可靠。 我意识到我们正在使用 FreeRTOS、这是否可能导致一些问题？ 此外、如果发布我的代码会有所帮助、我当然可以尝试发布任何相关内容。

再次感谢、

查尔斯

您好、Charles、

只要您不混合使用 RTOS (即 FreeRTOS 与 TI-RTOS)、就可以了。 启动网络终端测试不应很困难。 我们还提供了该示例的 FreeRTOS 版本。 只需使用 wlanconnect 连接到 AP、然后使用包含相关参数的 send 命令。 运行该示例时、实际 CLI 中提供了更多详细信息。

Jesu