[参考译文] CC1352P：如何在 TI-15.4非信标模式下处理 panID 冲突

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1302265/cc1352p-how-to-handle-panid-conflict-in-ti-15-4-non-beacon-mode

您好！

我正在使用 SDK V7.10中的示例收集器/传感器工程测试 TI-15.4堆栈非信标模式。 在收集器项目中、可使用以下函数检查具有相同 panID 的网络是否已经存在、如果已经存在、panID 会递增1。

/*!
 * @brief       Determine parameters to be used to send Start request from
 *              results of energy scan and active scan
 *
 * @param       channel - best channel to start the coordinator
 */
static void configureStartParam(uint8_t channel)
{
    /* parse incoming beacons to search if another
     *  coordinator exists with this PAN ID */
    while(coordInfoBlock.panID == (findChannel(coordInfoBlock.panID, channel)))
    {
        /* another coordinator with this PAN ID exists,
         *  so we change our PAN ID*/
        coordInfoBlock.panID = coordInfoBlock.panID + 1;
    }
}

这在负责启动网络的收集器中很简单、但对于传感器无线电来说、这变得不可预测。 思想实验是这样的。 两个无线电、收集器无线电(CRA)和传感器无线电(SRB)都经过预配置、可使用共享的 panID (0x1234)和网络加密密钥形成网络。 当 CRA 尝试启动一个 panID = 0x1234的网络时、它会发现另一个 panID = 0x1234已存在、因此它会启动一个 panID = 0x1235的网络。 但是、当传感器无线电 B 上电时、它只会以 panID = 0x1234加入另一个网络、而不是由收集器无线电 A 启动的网络。

只要传感器无线电知道 panID 和通道、就可以加入任何网络。 测试时、如果网络加密密钥不匹配、传感器无线电将无法与收集器无线电通信。 因此、这可能是生产部署期间的一个问题。 在 FH 模式中、对 FH netowrk 名称进行额外检查、它最多可以包含32个字符、这样就基本上避免了网络 ID (panID + name)冲突。 但使用非信标模式时、单单是 panID 无法提供如此高的保证。

我们应该如何处理这种情况？ 我认为、在部署完成后、我们不能统计所有网络是否都被设置为不允许加入。

请提前告知、并表示感谢。

ZL