[参考译文] CC1310：在启用跳频的情况下、传感器节点与 TI 15.4网络中的收集器断开连接的可能原因是什么？

尊敬的 Zhiyong：  

您看到这种行为的是哪个版本的 SDK？  

此致、

SID

传感器和收集器节点均可根据 CC13x0 SDK 4.20.1.03进行定制和构建。

在进一步分析后、我发现、如果外部 MCU 在最长5秒内将多个数据包推送到传感器节点、则稍后的数据包、有时甚至全部都不会发送到收集器。

我是否做了一些错误、或者传感器节点在一段时间内可以处理多少个数据包存在限制？

谢谢。

尊敬的 Zhiyong：

传感器上的报告间隔本身可以小于5秒。 我们提供的默认值是3秒。 因此、这不应该成为问题。 但是、当您说使用外部 MCU 将数据推送到传感器时、您意味着还有另一个串行接口吗？

此致、
SID

是的、我们实现了一个 UART 接口、因此我们只将 CC1310用作无线电、所有其他功能都由 MSP430处理。 我们也没有发现数据报告间隔小于5秒的少量传感器节点存在问题。 但随着网络中传感器节点的数量增加、问题变得显而易见。 我看到数据包不断丢失的网络有9个传感器节点。

我们还启用了跳频、没有 FH 时、TX 功率限制要低得多。 FH 是否也会使网络变得更加脆弱？

您好 Sid、

感谢您提出设置和使用数据包监听器的想法。 我将在下一次尝试。

目前 、我怀疑饱和可能是导致至少一些问题的原因。 我将测试网络减少到3个无线电、1个收集器和2个传感器节点、将它们分开10英尺、一切开始正常工作。 即使在突发 TX 时也是如此。 在以前的测试设置中、有时有10个以上的对讲机、有时对讲机之间的距离只有几英尺。 此外、这些无线电的 TX 功率保留为默认的26dB。

 是否有关于如何管理/避免饱和的指导原则？ 我们设计了无线电覆盖大面积区域、但有时我们还需要将许多区域安装到狭小空间中。 我假设尽可能降低 TX 功率是避免饱和的一种方法。

最棒的

ZL

尊敬的 Zhiyong：  

降低 Tx 功率似乎是测试饱和是否是原因的正确方法、此外、您能否使用接收器上的 Smart RF Studio 测量 RSSI。 具有相同的 PHY 设置？  

此致、

SID

我们通过使用内置的 TI 15.4堆栈来跟踪传感器节点和收集器无线电上的 RSSI。 在我正在进行的测试设置中、两端的 RSSI 介于-26和-42之间、平均值~38。

尊敬的 Zhiyong：

接收到的功率似乎在合理的限制范围内。 您是否认为这是空中交通问题？ 我认为监听器日志可以提供更多见解。 或者、可靠的故障模式也有助于在此时找出问题的根本原因。  

此致、

SID  

这种网络不稳定的实际原因是收集器无线电上的某种堆栈溢出。 我们尝试每5分钟向每个传感器节点发送一次数据包。 表面上看、这看起来不是很好。 但在我们的网络传感器节点中、每分钟仅轮询一次数据、并且有一些后台跟踪数据包。 我想这对于 CC1310来说太难处理了。 关闭此功能后、各种奇怪的行为就会消失。

尊敬的 Zhiyong：  
感谢您回来。 我想稍微澄清一下行为。 您要关闭哪些功能才能解决问题？  

请定义实际的网络流量、可能对 MAC_CFG_TX_DATA_MAX 进行一些更改会有所帮助。 但是、很高兴了解您受限制的内容。  

此致、
SID

感谢您的更新！

/* maximum number of data frames in transmit queue */
// Assuming: 50 sensor nodes, host state packet 1 per 5 minutes, plus 1 time sync packet per hour
// Total packets: 650 packets in one hour
// Worst case: all 50 host state packet queued in 1 polling interval
#ifndef MAC_CFG_TX_DATA_MAX
#define MAC_CFG_TX_DATA_MAX         50
#endif

我们已经将其更改为50、这似乎不会阻止问题的发生。

您在这里尝试过较小的数字吗？ 50可能有点太大。 但数字大于默认值(2？)。 可能是10。 很抱歉、我没有更好的计算该数字、但值得测试一次。  

您好 Sid、

一个相关的问题、是否有办法查询 MAC 层上的待处理 TX 数据包？ 我们 实现了一种手动跟踪来自外部 MCU 推入的数据包的方法。 不幸的是 、这不能很好地工作。 它不会按堆栈本身跟踪后台 TX 数据包。 我发现  频繁调用该函数也会导致网络不稳定。

Error_t Cllc_getTotalPendingDataReq(uint16_t *totalPendingDataReq)
{
    uint16_t pendingDataReqCount = 0;
    for (size_t i = 0; i < CONFIG_MAX_DEVICES; i++)
    {
        pendingDataReqCount += Cllc_associatedDevList[i].pendingDataReq; // Added during customization
    }

    *totalPendingDataReq = pendingDataReqCount;

    return ERROR_OK;
}

尊敬的 Zhiyong：  

如果您只想检查是否存在溢出、最简单的方法是检查 ApiMac_mcpsDataReq 的状态。 它应返回 TransactionOveFlow 状态。  

但是，要跟踪实际的挂起消息数，此函数可能很有用： Mac_CbackCheckPending ()  

此致、

SID

您好 Sid、

我尝试了10， 使用以下设置， MAC_CbackCheckPending ()始终返回0，即使 在 ApiMac_mcpsDataReq()返回溢出错误。

是否有更好的方法来避免溢出？

谢谢、

MAC_CbackCheckPending()

// mac_cfg.c
/* determine whether MAC_MLME_POLL_IND will be sent to the application */
#ifndef MAC_CFG_APP_PENDING_QUEUE
#define MAC_CFG_APP_PENDING_QUEUE   TRUE
#endif

尊敬的 Zhiyong：  

我认为避免溢出本身是因为将命令安排在更长的时间间隔内。 但是、我将研究如何更好地跟踪这些消息、并将返回给您。  

此致、

SID

尊敬的 Zhiyong：  

在 macTask.c 中、您会看到正在使用 macData 实例。 该结构具有队列中的间接和直接消息计数。  

可用于跟踪待处理的消息。  

此致<
SID