[参考译文] LP-EM-CC1314R10：孤立传感器重新连接问题-不触发孤立扫描。

尊敬的 Muniyappan：

一旦传感器处于孤立状态、它就会启动退避计时器、这意味着它将在断开连接的时间越长、发送下一个孤立扫描之前连续等待更长的时间。 您可以在 SysConfig 中修改退避指数。

1.您发送的两个日志是否具有不同的断开连接时间？
2.您对传感器孤立后重新连接的要求是什么?

此致、
等等

1.您发送的两个日志是否具有不同的断开连接时间？

断开时间意味着退避计时器？  

两个日志取自相同的设置。

以下是我们进行的操作、

1.将传感器代码刷写到一个板中,将收集器代码刷写到另一个板中。 已附加屏幕截图供您参考。

2.已创建 PAN 网络并在 PAN 网络中关联了传感器。 已连接收集器和传感器并按预期工作。

3.现在我们关闭收集器(移除电源),观察传感器的运行情况。

4.传感器成为孤立传感器后、我们将再次 打开收集器、并查看传感器需要多长时间才能重新与收集器连接。

我们将多次重复步骤3和4进行测试。 因此、我们可以看到收集器关闭后的2种情形、

a.传感器每4秒定期发送孤立通知 ( 工作流程 -日志)。

b. 传感器每7分钟发送一次孤立通知( 问题流程日志  )-发生非常罕见。

我们假设每当收集器关闭时、传感器都将以相同的时间间隔发送孤立通知(取决于退避指数)。 我们的理解是否正确？

2.您对传感器孤立后重新连接的要求是什么?

目前、我们的目标是在3分钟内让传感器重新加入网络。 但它可能会因传感器的电流消耗而异(因为在我们的设置中、传感器将由电池供电、并且 孤立扫描可能需要更多功率)。 我们更侧重于了解此孤立机制、并根据功耗实现理想的孤立扫描间隔。

注意：

**在整个测试中,我们永远不会为传感器重新安装电源。

***我们已按如下所示配置有关回退指数,

希望收到您的反馈。 感谢您的持续支持。

此致、

Muniyappan R. M

尊敬的 Muniyappan：

我测试了您发布的配置、 无法重新生成发送孤立通知的不同间隔。 当我查看数据包监听器日志时、可以看到孤立消息始终按照相同的间隔(根据孤立计时器的配置)发送。

您能否执行完整的闪存擦除、然后对芯片重新编程、以确保旧配置不会留下任何内容。


请注意、如果重新连接收集器时出现问题、很可能是由于收集器侧重新打开网络。 当您对 收集器执行循环操作时、您需要另外重置收集器并再次按下按钮1以 正确重新启动网络。 这是由于应用示例的原因、对于最终产品、您当然可以调整软件、这样就无需按下按钮、并且每次启动时都会重新启动网络。


如果仍然存在任何错误、请告知我。

此致、
等等

尊敬的 Theo：


根据您的建议、我们在收集器和传感器上启用了 AUTO_START 功能、以正确重新启动网络。 此外、我们在刷写代码后执行了完全闪存擦除。

再次测试相同,即启动 nw,加入传感器和断电收集器,

关闭集电极板电源后、我观察到两种情况、

场景1 (工作流程)：

传感器板每4秒发送一次孤立通知。 如果我现在为收集器供电、传感器将重新加入网络。

场景2 (问题流-非常罕见)：

传感器板在420000 ms (大约7分钟)后发送第一个孤立通知、然后每4秒定期发送一次孤立通知。 (我 在孤立状态下运行了传感器板大约8个小时)。 因此、只有在第一次、传感器需要7分钟来发送孤立间隔。

情景2非常罕见、但时间正好在7分钟左右。 我们没有数据包监听器、因此无法监听数据包。

但是、每当出现该问题时、  sendScanReq (ApiMac_scantype_oran)->  ApiMac_mlmeScanReq (&scanReq) ;被触发、且仅在7分钟后触发配置回调。

您能帮助我们了解 cnf 回调和的实现方式吗  ApiMac_mlmeScanReq () 是否在工作？


此致、
Muniyappan R. M

尊敬的 Muniyappan：

这听起来很奇怪,我们从来没有听说过这样的情况。

首先介绍链路控制器的行为。 一旦器件对于定义的最大允许数据故障数未收到任何对其数据请求的响应、它就会将状态切换为孤立状态。 此状态更改将触发孤立扫描、使用所链接的 ApiMac_mlmeScanReq (&scanReq)；其中 scanReq =孤立扫描。 孤立回调将检查是否收到响应、并使用退避间隔更改 SysConfig 中定义的孤立扫描间隔。

我尝试重现您报告的内容、并使用数据包监听器观察到网络流量。 如下图所示、第一个孤立扫描在达到允许的最大数据故障数后触发、然后根据定义的间隔执行。

在达到最大数据故障数后、我永远不会遇到初始孤立扫描需要任何延迟的情况。

我的问题是：
- 由于您不使用监听器,如何生成日志并观察网络流量?
-我可以看到,对于此配置,从最后的数据请求(58.2秒)到第一次孤立扫描(65.8秒)的时间约为7秒,因为重新发送数据请求,直到达到允许的最大数据故障数。 这是您指的吗？ 您可以通过更改定义 CONFIG_MAX_DATA_FAULTS 来更改允许的数据故障数、并通过更改定义 CONFIG_MAX_RETRIES 来更改最大重试次数。 默认情况下、两者都配置为5、初始请求为6x6=36个请求、直到孤立扫描开始(如上面 Wireshark 记录中所示)。

此致、
等等

尊敬的 Theo：

感谢您的努力。

关于您的问题、
 由于未使用监听器、如何生成日志并观察网络流量？
>>由于我没有设置监听器、因此我使用调试打印件进行调试(使用单独的调试 UART)。 我发布的日志也是通过添加调试打印内容生成的。
-我可以看到,对于此配置,从最后一个数据请求(58.2秒)到第一次孤立扫描(65.8秒)的时间约为7秒
>>在我的情况下,它需要大约420000毫秒。    在我的固件中、CONFIG_MAX_DATA_FAULTS 和 CONFIG_MAX_RETRIES 也设置为5。

会进行更多相关调试。

您能单独帮我解决以下问题吗？

您提到过孤立扫描、
 ApiMac_mlmeScanReq (&scanReq)；其中 scanReq =孤立扫描。 孤立回调将检查是否收到响应、并使用退避间隔更改 SysConfig 中定义的孤立扫描间隔。

在本例中、每当出现此问题时 scanCnfCb () 7分钟后触发  ApiMac_mlmeScanReq ()。

这是预期的流程吗？ (因为在工作流程中 scanCnfCb () 一旦请求扫描、将立即触发回调)。 我们认为传感器可能在7分钟内没有发送孤立扫描(它是否锁定在某些状态？)、 但我们无法得出任何结论、因为我们没有设置嗅探器进行确认。

此致、
Muniyappan R. M  

尊敬的 Muniyappan：

在过去的8个小时里、我一直在一边进行测试、但我无法再现。

扫描将需要更长的时间、使用更多的信道、但由于我假设您只使用一个信道、它应该在完成重新发送后过渡到发送孤立的消息。 您可以在我上一篇文章的日志中看到的是转换到孤立模式时的预期行为。

我假设您 在链路控制器中调用 UART 打印 功能、这可能会减慢某些极少数的临界情况下的状态转换速度。 您是否将 UART 初始化为非阻塞模式？

通常、我们建议不要使用来自链路控制器的任何阻塞任务。

此致、
等等

尊敬的 Theo：

感谢 快速响应。 关于您的问题、

我假设您 在链路控制器中调用 UART 打印 功能、这可能会减慢某些极少数的临界情况下的状态转换速度。 您是否将 UART 初始化为非阻塞模式？

>>是的、我已经在非阻塞模式下启用了 UART。

通常、我们建议不要使用来自链路控制器的任何阻塞任务。
>>了解。 我们将更改 UART 模式。

我已请求我的团队购买另一个 LaunchPad (CC1352P)来安排监听器设置。  设置监听器后、我将删除调试打印件 (也删除 UART 配置)、然后测试同样的场景。

此致、

Muniyappan R. M