[参考译文] CC1314R10：802.15.4 数据轮询问题

e2e.ti.com/.../8865.test.zip

网络流量转储

这是没有人能帮助我们吗?

您好、

感谢您发送编修。

我建议您在发生这种情况时检查收集器统计信息（全局变量：collector_statistics） 。  

您能否估算故障发生的频率？ （网络规模达到 20 个传感器后，是否每个封装都有？）

谢谢、

Marie H

您好、

请这么做。

您是否还能检查增加收集器上的 TX 和 Rx 缓冲区是否有所帮助？ （如果在收集器应用程序尝试归档数据包时没有可用的 TX 缓冲区，则无法发送数据包。）

谢谢、
Marie H

我们重复了测试、计数器没有增加、我们显示。 仅增加  sensorMessagesReceived

collector_statistics.ackFailures

Collector_statistics.channelAccessFailures
collector_statistics.otherTxFailures
collector_statistics.rxDecryptFailures
collector_statistics.txEncryptFailures
collector_statistics.txTransactionExpired
collector_statistics.txTransactionOverflow
Collector_statistics.sensorMessagesReceived

很奇怪的是、我们没有看到仅对一个传感器的响应、而是看到来自同一传感器的数据请求之间的响应（重试之间）我们看到协调器和其他传感器之间的通信成功、看起来只有一个传感器通信“卡住“。 但下次使用另一个传感器时会随机发生。

您好、

是否启用了帧计数器（我认为它适用 MAC_SECURITY）？ 如果此数据包不同步、收集器将开始忽略数据包（出于安全原因）。

谢谢、
Marie H

下一个视频。 您能否解释一下“不同步“的含义？

您好、

不同步意味着在这种情况下、帧计数器不再与数据包编号匹配。

由于您看到 Collector_statistics.sensorMessagesReceived 计数器增加、这意味着已收到消息、但存在某种错误、因此没有向传感器发送响应。

此计数器由 收集器上的 dataIndCB 增加。 如果需要、您可以使用回调用例检查收到的消息。

此致、
Theo

谢谢 Theo、

我们将  Collector_statistics.sensorMessagesReceived++;放置到 dataIndCB、然后在 sendMsg 之后、所以我们的程序将数据发送到传感器问题、这就是为什么协调员在轮询请求之后不发送它。 我们在向协调器发送数据和数据请求后看到 ACK、我想这意味着协调器收到了轮询请求、但之后没有数据。

您好、

传感器通过轮询请求从收集器请求数据。 收集器应确认轮询请求并向传感器发送数据。

您能否在收集器数据 IndCB 中跟踪它收到了轮询请求并且向传感器发送了一条消息在收集器数据 CnfCB 中返回 Mac 成功？

请帮助我了解通信在哪一点失败。

此致、
Theo

我们使用禁用的 MAC_SEC 进行了新的测试  

#define CONFIG_SECURE         错误  

而确定

收集器侧

下面的网络转储仅过滤了一个有问题的传感器。 因为您可以看到协调器 5 次没有响应、传感器状态更改为 Orphan、然后是协调器重新调整事件。 在转储时、您看不到、但在任何类型的消息数据或数据请求之后、协调器向传感器发送了 ACK。

e2e.ti.com/.../network-dump.zip

尊敬的 Theo：

不确定我是否理解您的问题。 对于轮询、有另一个回调函数 pollIndCB、为什么我们应该跟踪  轮询请求的 dataIndCB？

e2e.ti.com/.../network-dump-full.zip

完整的网络转储

高 SV、  

感谢您的完整拍摄。  

很抱歉弄错了。 您对轮询指示回调是  pollIndCB。 我要引用的是,当收集器发送消息成功的时候,Mac 层返回 与 API Mac 状态成功的 dataCnfCB。  

但在您的监听日志中、我们现在可以清楚地看到收集器没有将数据发送到轮询传感器、因此它转换为孤立。

该日志还显示收集器在 2s 后收到另一个数据请求。我认为、这里实际上可能会出现时序问题、因为收集器会尝试使用配置消息来设置传感器计时器、使每个传感器都有不同的插槽。


为了在我们进行进一步调试之前进行确认、您是否以 5s（而不是 2s）的轮询和报告间隔测试了同一网络、那么错误是否持续存在？

此致、
Theo

我们更改了周期、问题 在 5 秒周期中似乎并不常见、而在 10 秒周期中则更少、因此取决于周期。

不确定我是否理解“收集器尝试使用配置消息来设置传感器计时器、以便每个传感器都有不同的插槽。“

我们修改了协调器的原始代码、收集器不会向传感器发送任何配置、我们仅使用不带任何配置选项的数据消息、因为我们不需要它。 您能否详细解释一下协调器算法、配置消息和时隙？ 时隙是否是必要的、我想该消息可以在任意随机时间出现在协调器上、并且应该进行处理？

您好、

感谢您的确认。 我来解释一下发生了什么。

当运行 15.4-Stack 且传感器加入收集器时、它需要向收集器发送配置请求。 收集器将以下配置消息发送到 sensor.c processConfigRequest () 中接收的传感器。 这会重新初始化轮询和报告计时器、并通过在不同时间将配置消息发送到不同的传感器、最终在可能重叠或冲突的不同“时隙“触发其计时器。

在您的情况下、似乎正是这种碰撞导致一些传感器不再接收数据。

您是否 从应用程序中删除了 processConfigRequest ()（传感器）和配置消息发送（收集器）?

此致、
Theo

我们删除了 协调器端的 processConfigRequest 和 config 处理。 您能解释一下协调器在发送配置之前的作用吗？ 据我所知、传感器只会改变上传数据的时间段。 协调员如何选择时隙？

我 在新的示例项目中检查了 generateConfigRequests、但在那里找不到任何“时隙“  

“收集“仅使用这些预定义的间隔

CONFIG_REPORT_INTERVAL
CONFIG_POLLING_INTERVAL

高 SV、

我想这就是问题的原因所在。 网络设置需要配置请求。
请参阅下面的过程摘要。

工程设置
-在传感器 SysConfig 中,您可以配置报告和轮询间隔。
-在收集器 SysConfig 中、您可以配置报告和轮询间隔。

网络加入
-收集器打开网络。
-传感器开始查找网络并使用传感器 SysConfig 中的报告和轮询间隔。
-传感器加入收集器网络。
-传感器将配置请求发送给收集器,并通过配置消息进行回复。
-传感器处理配置消息,并使用收集器 SysConfig 报告和轮询间隔重新初始化其网络计时器。

最后一步确保传感器的网络计时器在不同时间点重新初始化、从而有助于避免冲突并创建“不同的插槽“。

是否可以尝试使用配置消息过程？

此致、
Theo

在 ALG 下方、收集器如何选择“时隙“。

正如您所看到的、对于所有使用的传感器、固定数据上传周期、我在每个传感器间隔中没有看到任何个人、如果我错了、请纠正我。

我们使用固定的  CONFIG_REPORT_INTERVAL、因此不需要配置消息。

CONFIG_REPORT_INTERVAL
CONFIG_POLLING_INTERVAL

/*！
*@为所有关联设备生成配置请求
*需要一个。
*/
静态 void generateConfigRequests (void)
｛
#ifndef POWER_MEAS
int x；

if (certification_test_mode)
｛
/*在认证模式下,只能背对背上行链路
*应支持数据流量*/
返回；
}

/*清除所有超时事务*/
适用于 (x = 0；x < CONFIG_MAX_DEVICE；x++)
｛
if (((Cllc_associatedDevList[x].shortAddr！= CSF_INVALID_SHORT_ADDR)
&&(Cllc_associatedDevList[x].status & CLLC_Assoc_STATUS_ALIVE)
｛
if (((Cllc_associatedDevList[x].status &
(Assoc_config_sent | Assoc_CONFIG_RSP))
==(Assoc_config_sent | Assoc_CONFIG_RSP))
｛
llc_associatedDevList[x].status &=~(Assoc_config_sent)
| Assoc_CONFIG_RSP)；
}
}
}

/*确保我们一次只发送一个配置请求*/
if (findDeviceStatusBit (Assoc_config_MASK、Assoc_config_sent)== NULL)
｛
/*在所有设备上运行*/
适用于 (x = 0；x < CONFIG_MAX_DEVICE；x++)
｛
/*确保该条目有效。 */
if (((Cllc_associatedDevList[x].shortAddr！= CSF_INVALID_SHORT_ADDR)
&&(Cllc_associatedDevList[x].status & CLLC_Assoc_STATUS_ALIVE)
｛
uint16_t status = Cllc_associatedDevList[x].status；

/*
设备是否已发送或已收到配置请求？
*/
if ((((status &(assoc_config_sent | assoc_config_RSP))== 0)))
｛
ApiMac_sAddr_t dstAddr；
collector_status_t stat；

/*设置目标地址*/
dstAddr.addrMode = ApiMac_addrType_short；
dstAddr.addr.shortAddr =
llc_associatedDevList[x].shortAddr；

/*发送配置请求*/
STAT = Collector_sendConfigRequest (
&dstAddr、(CONFIG_FRAME_CONTROL)、
(CONFIG_REPORT_INTERVAL)、
(CONFIG_POLLING_INTERVAL))；
if (stat == collector_status_success)
｛
/*
标记消息已发送并等待响应
*/
Cllc_associatedDevList[x].status || Assoc_config_sent；
Cllc_associatedDevList[x].status &=~Assoc_CONFIG_RSP;
}

/*一次只执行一个*/
休息；
}
}
}
}
#endif
}

高 SV、没有单独的时间间隔。

当传感器从收集器接收到配置消息时、它正在重新初始化其轮询和报告计时器。

配置消息会在不同时间点发送给所有传感器、这意味着它们会在不同时间重新初始化计时器。

这会导致“不同的槽位“。

您可以在 sensor.c -> processConfigRequest () 中看到传感器计时器的重新初始化。

请使用此配置消息进行测试、因为它是默认设置。

此致、
Theo

谢谢 Theo、

不幸的是、测试起来会非常困难、因为我们必须重写大部分 代码。 我仍然不明白如果收集器在预定义的时间内没有期望来自传感器的数据包（对于协调器和传感器上的时隙时钟也应该同步，但该功能不存在）、它将会有何帮助、因此、无论如何、到达时间将是随机的、收集器应处理该数据包。

我们还能做些什么来诊断问题？  

高 SV、  

收集器处于空闲状态、始终处于 RX 状态。  

这会有所帮助、因为收集器会在不同的时间向每个传感器发送配置消息。 因此、传感器计时器的重新初始化点在不同时间发生、这有助于减少碰撞。

我建议您执行自己的“配置“消息。 网络设置完成后、您可以逐个向每个传感器发送一条消息、触发传感器重新初始化其轮询和报告计时器。 通过逐一创建时隙。

此致、
Theo

我们使用一个传感器进行了新的测试、发现了相同的问题、因此不是由碰撞引起的。  

e2e.ti.com/.../18.07.25_2D00_sensor_5F00_side_2D00_wireshark-_2800_1_2900_.pcapng.zip

您好、SV、感谢您运行此测试并共享日志。  

由于您正在将 Linux 协处理器用于收集器和嵌入式传感器：您如何删除代码中的配置消息以及对应用程序进行了哪些其他修改？

其中一个计时器会导致传感器成为孤立的。 要跟踪哪一个、我需要了解传感器预期接收的信号。

此致、
Theo