[参考译文] CC1352R：跳频中的孤立模式。 更换收集器。

安德烈斯、您好！

听起来像是一种死机状态。 您能给我更详细地介绍一下以下内容吗：

1) 1)您使用的是 SimpleLink CC13x2/26x2 SDK 的哪个版本？

2) 2)您是否使用了默认传感器和收集器示例或是否进行了任何更改？

谢谢、

玛丽·H.

您好、Marie、

1) 1)我正在使用 simplelink_cc13x2_26x2_SDK_5_10_00_48

2) 2)我正在使用 DMM_154sensor_remote_display_oad_lpstk_app_CC1352R1_LAUNCHXL_tirtos_ccs

我只添加了之前详述的函数。

Collector 是默认的 DMM_154collector_remote_display_app_CC1352R1_LAUNCHXL_tirtos_ccs

安德烈斯

安德烈斯、您好！

首先值得检查的是，“替换”收集器的配置与另一个收集器的配置相同(但我猜您已经检查过)。

其次、SDK 中的示例未考虑该特定情况、因此可能需要进行一些工作。 话虽如此，我认为你走的是正确的道路。

考虑到该示例没有设想有多个收集器，添加 SSF_clearAllNVItems()似乎是一个很好的起点，因为这样，传感器就可以忘记以前的收集器并连接到新收集器。 现在，在上述情况下，传感器将不会重新加入网络，而是加入“新”网络。

我将尝试重现您所看到的内容，然后我将返回给您。

BR、
安德莱姆

你好，安德烈斯

我刷写了两个具有相同收集器项目的 launchpad。 我同意调用 SSF_clearAllNVItems()是一个很好的起点。 实际上、我将其放入 SSF_init 中、以便始终在开始时擦除 NV 存储器。

我的代码是：

if(Jdllc_events & JDLLC_PCS_EVT)
{
    .
    .
    .
    if(devInfoBlock.currentJdllcState == Jdllc_states_orphan)
    {
        scan_orphan_fail++;
        
        if (scan_orphan_fail >= NUMBER_OF_MAX_SCAN_FAILS)
        {

            Jdllc_sendDisassociationRequest();
            //Ssf_clearAllNVItems();
            Util_setEvent(&Sensor_events, SENSOR_START_EVT);
            sendAssocReq();
            scan_orphan_fail = 0;
        }
    }
    .
    .
    .    
}

安德烈斯、您好！

现在、我将复制您看到的内容(两个收集器和一个传感器)。 我将进行一些调试、我将尝试确定是否需要添加其他内容才能使其正常工作。 到目前为止、我已经获得了一些混合结果、因此我仍然需要了解一些情况、但我会尽快向您更新。

BR、
安德莱姆

好的安德烈斯

提前感谢。

安德烈斯、您好！

很抱歉耽误你的回答。 我测试过不同的东西，但这可能需要对传感器示例进行重大修改。 我希望有一个快速的解决方法来轻松更换收集器。 但是、似乎唯一的方法是在 sensor.c 和 jdlc.c 中向状态机实际添加新状态(或状态)

正如您正确指出的那样、当尝试重新加入网络时、LLC 会收到一个 PCS 事件。 您可以在此处检查孤立状态并检测是否需要加入新网络。 这里的问题是、设置 SENSOR_START_EVT 可能不是触发该新连接的最佳选择、因为此事件旨在从头开始执行所有操作、或仅在成为孤立网络后重新加入现有网络。

您需要的是介于两者之间的某个位置。 我认为最好的选择是提出一个或多个新状态、以更好地表示您所需的功能(即、在收集器不再存在后重新加入网络或连接到新网络)。

BR、
安德莱姆

安德烈斯、您好！

我不明白为什么如果我使用 SSF_clearAllNVItems、如果我转弯、请始终与旧收集器连接。

安德烈斯、您好！

为清楚起见、您如何对此进行测试？ 我猜：

1. 移除“旧”收集器以模拟更换需求。
2. 传感器进入 Orphan 模式。
3. 传感器多次无法重新加入以前的网络。
4. 传感器发送解除关联请求、清除 NV 等
5. 插入“新”收集器。
6. 传感器不会从“新”收集器加入网络。
7. 插入“旧”收集器而不删除“新”收集器。
8. 传感器连接到“旧接头”。

我是对的吗？

我还想问一些其他问题。 哪个器件显示其 CUI 中存在连接？ 是传感器还是“旧”收集器？

如果它位于“旧”收集器中，则可能意味着收集器只是将传感器的请求解释为“重新加入”请求。 毕竟，“旧”收集器会记住传感器以前是其网络的一部分，因为其 NV 完好无损。

最后一个问题。 与显示连接的设备无关、它是否表示设备已加入新网络或已重新加入以前的网络？

BR、
安德莱姆

安德烈斯、您好！

是的、您回答正确。 这是测试。

我可以在3个三个 Launchpad (传感器、"旧"和"新"收集器)中访问 CUI。 传感器和“旧”收集器显示其 CUI 中存在连接。

在收集器和传感器项目中，我实际上将 SSF_clearAllNVItems()放入 SSF_init 中，以便始终在开始时擦除 NV 内存。 因此、nV 始终是干净的。

传感器器件显示已加入、(当然)"旧"收集器表示已启动(未重新启动)

谢谢

安德烈斯

安德烈斯、您好！

老实说、我不知道为什么在清除 NV 后这种情况仍在发生。 我应用了您的更改，并且修改了示例代码，以便每次用户按左键时调用 SSF_clearAllNVItems()，但这不起作用。

可能是 SSF_clearAllNVItems()无法正常工作。 或者、可能需要针对 NV 采取一些额外步骤。 就 NV 而言、常规示例(而不是 LPSTK 示例)略有不同、因此让我尝试一下、看看在为传感器使用常规 LP 时是否会发生同样的情况。

BR、
安德莱姆

安德烈斯、您好！

我认为 SSF_clearAllNVItems()工作正常，但我还需要将 devInfoBlock 设置回默认值。

我不是很了解如何做到这一点的

提前感谢

您好、Andr é s、

我想您可以将 API 添加到 Jdlc 以清除 devInfoBlock (如 Jdllc_clearDevInfoBlock())，或者您可以直接在您认为需要的地方重置(更新)结构的成员。 如果添加 API、可能会更干净、并且调试可能更容易。

在代码中实际清除 devInfoBlock 的位置以及要清除的参数是一个不同的问题，因为结构的某些值首先在 jdlc_init()上设置。

因此、可能需要一些时间才能找到调用 API 的适当位置、这样它不会与您可能仍需要的器件的任何先前配置相混乱。 您很可能只想清除该结构的某些成员、而不是全部。

BR、
安德莱姆

安德烈斯、您好！

我删除了 disasocCnfCb ()中的 if (pData->status = ApiMac_status_Success)，因为如果没有收集器来提供 ACK，disassoCnfCb 状态将始终为 ApiMac_status_noAck。
更改后、我可以为新收集器和传感器加电、因为它们处于孤立状态、所以可以正确重新连接。 但我仍然需要知道、我是否应该期望由于这一变化而产生任何"附带影响"。

谢谢

安德烈斯、您好！

这是一个很好的进展！ 让我询问一些对堆栈比较熟悉的人、看看执行此操作可能产生的影响、我会再给您回复。

BR、
安德莱姆