[参考译文] CC1312R：15.4 堆栈在高流量情况下会断开器件链路连接

尊敬的 Dirk：

听起来、在 OAD 传输期间传感器器件超时。 原因可能是收集器错过了其他传感器的极化请求、因此它们会转换为孤立状态。


您是否可以共享网络的配置（轮询，报告，广播，超时）？

在和 OAD 期间如何发出请求 — 您是使用 TI 15.4 Stack Linux SDK 的流程还是自定义实现？

此致、
Theo

嗨、Theo

我正在与 Dirk 一起处理这个问题。  
我们使用 6s 轮询间隔、60s 报告间隔和 60s 硬播间隔
我们仍在使用以下链接中所述的 TI 原始 OAD 协议。
https://software-dl.ti.com/simplelink/esd/ti15.4stack_linux_x64/2.03.00.06/exports/docs/ti154stack-users-guide/ti154stack/native-oad.html#oad-concept-overview
在 OTA 期间、我们在接收和处理来自其他设备的轮询请求时不会看到问题。
谢谢

Daniel

尊敬的 Daniel：

感谢您提供详细信息。

在 OTA 期间、我们在接收和处理来自其他设备的轮询请求时没有看到问题。
[/报价]

您是否在收集器上跟踪收到的轮询请求 (dataIndCB)、并检查发送的数据包回调 (dataCnfCB -> ApiMac_status_success) 以确保它发送了回复？

我认为要更深入地了解哪些数据包丢失、如果您可以将两个通道映射设置为仅一个通道、然后您可以使用数据包监听器 ( https://www.ti.com/tool/de-de/download/PACKET-SNIFFER-2/1.11.0) 观察网络流量、这将是很好的 

您能否与我分享一份 Sniff 日志、其中显示了传感器 丢失的 szenario？

此致、
Theo

嗨、Theo

感谢您的答复

我以前没有使用剪刀、因此可能需要一些时间进行设置
顺便说一句,我深入到数据包流作为你的建议,加一些更多的日志消息在 API-Mac 上,特别是 data-cnf。 也许与此相关的东西
我发现我们有时会有很长的延迟、甚至丢失 data-cnf、在这方面处理不当可能会导致后续发送消息失败
请问、在缺少 data-cnf 时、正确的处理应该是什么？ 这是清除请求与正确的 msduthandle 总是可以帮助恢复? 或者在再次发送消息之前需要执行任何其他操作？

再次感谢

Daniel

尊敬的 Daniel：

如果您需要更多指导来设置嗅探器、请告诉我。

当您说“日志消息“时、您是否已在使用 TI 记录器？ - https://dev.ti.com/tirex/explore/node?node=A__AUtBCHw9KYI99xItuPjn4w__com.ti.SIMPLELINK_ACADEMY_CC13XX_CC26XX_SDK__AfkT0vQ__LATEST 

如果没有收到确认、堆栈会执行重新发送。 在传感器端、如果未接收到确认、它将转换为孤立模式、并尝试使用退避计时器重新加入网络。

您能否在收集器上看到将消息发送到传感器的 Mac 成功？

我认为我们需要监听器日志来确认实际发送和错过了哪些消息。

此致、
Theo

嗨、Theo

我已经为我们的设置安装了嗅探器、在 OTA 过程中设备断开连接的问题中、附件是 catpure。 请帮助检查此日志是否可以显示原因。  
 e2e.ti.com/.../ota.zip

非常感谢

尊敬的 Daniel：

请帮助我完全理解您共享的日志。

我可以看到所有传感器都试图通过发送 PAS (Pan Advertisement、Pan Advertisement、Pan Advertisement、Pan Advertisement、Pan Advertisement、Pan Advertisement、Pan Advertisement、Pan Advertisement、Pan Advertisement、Pan

在向 1 个单独的射频客户端进行高数据传输期间、堆栈开始丢失与随机其他客户端 (MAC_WS_ASYNC_IND) 的连接

具体情况是、我们在数据包之间以 200ms 的延迟发送数据包（150 字节）、最后大约发送 1k 个数据包（有效地尝试进行固件更新）

我无法看到这种高数据传输到日志中的一个传感器。

您使用哪种 API 和通信模式来运行它？
它在您记录日志时是否正在运行？

此致、
Theo

嗨、Theo

美国频段 915MHz 的此监听器配置是否正确？ 似乎我只捕获了关联消息,但没有数据交换！

嗨、Theo

我们在为传感器执行 OTA 时实现了这种高数据传输、每 200ms 将 128 字节的固件块从收集器发送到传感器。 完全将发送从 900 到 2000 块, 取决于不同种类的传感器。

尊敬的 Daniel：

您使用哪个处理器作为网关、使用哪个 UART 接口与协处理器通信？

此致、

Arthur

嗨、Theo

我们在 Pi CM4 上运行 Linux SDK、与具有 mt-msg 层和 UART 接口的 CC1312 成功模块通信。

尊敬的 Daniel：

感谢您提供详细信息。 我认为 UART 通信应该没有问题。

这里的基本问题是、当您启动 OAD 时、传感器将一直请求数据、直到它收到映像。

由于没有为其他传感器保留的通信时隙、因此很可能与 OAD 消息发生冲突。

如果连续发生多次碰撞、传感器将从重新发送转换为孤立。

现在、为了改善这种情况、您可以在孤立时直接将传感器转换为重新加入、这样可以在收集器完成 OAD 后更快地重新加入。

此致、
Theo

嗨、Theo

我再次确认、我们的器件已经实现了重新加入算法、并且在 OAD 过程中丢失链接后、器件可以再次与收集器配对。 但我们仍然希望对它有更多的了解。  
当一个器件执行 OAD 时、每 200ms 请求一次固件数据包、收集器不断回复 128 字节的固件数据包
然后另一个 deivce 向收集器发送一个 5 个读数的序列、每个读数最多 150 字节。
那么发生冲突会导致 OAD 器件进入孤立模式吗？
这可以通过嗅探器软件捕获吗?  
我们只是想了解更多、以便了解如何调整算法来改进它。
Thansk  

Daniel

尊敬的 Daniel：

1.我试图复制问题,但它还没有发生。 您能否分享您正在使用的 F2 SimpleLink SDK 版本？

2.使用监听器时,是否只映射一个信道用于跳频?

此致、

Daniel

收集器使用 CC1312  6.10.002 Linux 协处理器
传感器使用 CC1312 6.10.002 和 CC1310 1.50.008
使用监听器时、我们使用所有通道进行配置

谢谢 Daniel、

我尝试了运行 SDK  6.10.01.01 的两个传感器节点和一个协处理器节点、但仍然无法重现此问题、可能缺少配置。 您运行的是默认示例代码还是已被修改？

遗憾的是、监听器一次只能在一个频率下工作、因此对于跳频模式、您必须仅使用通道 0（在传感器的 SysConfig 上设置、为收集器设置 collector.cfg）来获取监听器上记录的所有内容。

您是否在 collector.cfg 中启用了所有调试标志？ 您是否看到传感器请求到达协处理器？

此致、

Daniel

您好 Daniel

我们从示例代码开始、但 Shold 已经进行了大量修改。
我将再次尝试在传感器和收集器上设置为通道 0 的监听器。

此致
Daniel

好的、

请告诉我该怎么做。