[参考译文] CC3135MOD：几天后消耗量会增加

您好！

这可能是 AP 的 IOP 问题。

您使用的是什么供应商和型号？

这里的监听器很好、但也有 NWP 日志和 MAC 固件日志。

请尝试捕获 NWP 日志(请参阅编程人员指南(https://www.ti.com/lit/swru455)第20章中的详细信息)。

还需要 MAC 日志。 该过程与 NWP 相同、但引脚为60、而不是62。

由于它是 cc3135、而不是 cc3225、因此您不需要在软件上进行任何 MUD 操作、您已经将这些代码混合出来了。

Shlomi

您好、Shlomi、

感谢您的快速响应。

请查找随附的 zip 文件、其中包含 MAC 和 NWP 的调试输出。 我们仍在努力捕获监听器日志。

附件还显示了电流消耗测量的结果。 所有日志都是同时获取的。 最初、WiFi 模块连接到服务器、然后我开始将模式改回断电模式、并恢复到完全操作模式。 您可以在上述电流测量中看到这些事件的功耗步骤。

如果您需要进一步的详细信息(在监听数据旁边)、请随时通知我。

谢谢、祝你一切顺利。

e2e.ti.com/.../CC3135_5F00_Consumption.zip

您好、Shlomi、

感谢您的回答。

我不确定这些广播是导致消费增加的(主要)原因。
让我怀疑的是、我们设置了20个相同的器件、物理位置彼此靠近(在同一办公桌上)。 它们具有相同的 WiFi 配置(相同的 SSID、DTIM 等)。 但是、观察到的消费量增加是随机发生的、每天只有很少的消耗量。

在器件与 AP 取消关联并关联后、消耗水平立即下降到正常水平。 当在第一个器件上完成此"恢复"时、这当然不会影响其余器件。 需要在每个上执行取消关联和关联。
之后、这些器件在几天内再次正常消耗... 在平均时间内、其他几个方面会出现增加。 随机变化。

如果广播是原因、我希望所有器件的行为都非常相似。


我在前一条消息中发送的日志是在另一个具有公开调试输出的硬件上捕获的(此外、位于另一个房间内、连接到另一个 AP)。 我们所做的是将此"调试器件"移至前面提到的20个器件、并对其应用相同的设置。
您可以在接下来的几天内从该设备获得新的完整日志集。


此致

感谢您的更新。

我同意广播不是唯一的贡献者、因为其他设备也应该经历类似的行为。

此外、如果在广播仍然传输的情况下重新关联、则应立即导致高功耗。

当您有更多日志时、请告诉我。

Shlomi

您好、Shlomi、

我设置了一些自动脚本并捕获了可疑事件。 它仅持续3秒(请参阅下面的功耗图)、但该数据可能仍然有用。

zip https://drive.google.com/file/d/1jis5fFpm2F-ekR-m2Highk8eNvnvKkK8中提供的日志 收集了30分钟、事件在7分钟后发生。

output.csv 文件包含电流消耗数据、421秒后此事件将出现在其中(时间戳421094.56)。 日志记录从脚本开始、逐个启动日志捕获项目、因此、文件中的相关项目之间可能存在轻微的时间偏移(我认为< 1秒)。

感谢您的任何反馈。

我将继续收集关键事件的日志...

此致

您好！

日志有点损坏、因此很难看到。 此外、MAC 日志似乎很短。

您能否详细说明基站和 AP 的 MAC 地址？

Shlomi

您好、Shlomi、

再次感谢您的快速响应。

器件的 MAC 为34：03：DE：11：bb：d6、AP 的 MAC 01：00：5e：00：fb。

可能是我采用的读取 UART 数据方法不适合该波特率。 我将对此进行调查。

此致

您好！

MAC 01：00：5e：00：00：fb 只是多播、而不是 AP MAC。

根据 DUT、您的 AP 是具有 MAC BA：fb：E4：84：82：21的 Ubiquiti。

420秒后、我在监听器中看不到什么奇怪的东西、但问题是 gLogger 还向我展示了它所连接的 AP 的 TSF、而 TSF 远不及监听器中显示的 Ubiquiti 的 TSF。 它必须相同。

您可以进行双重检查吗？

Shlomi

您好、Shlomi、

我更改了 UART 数据读数(现在使用 PuTTY)、并捕获了下面所附的相同3秒增加电流消耗的情况。

日志 zip： https://drive.google.com/file/d/1rIk13RhCC81UKpnKDZjwA3pt15TrYvzq

此事件在启动后682秒发生。

硬件设置保持不变。

希望日志内容现在保持一致且更有用？

此致。