[参考译文] CC1312R：回复：传感器发送消息算法

您好！

对响应延迟表示歉意。 感谢您提供数据图。 我已经建立了类似的网络、并将研究重现问题以获得更好的理解。 我将在下周早些时候提供一个答案。

此致、

马尔文

您好！

描述中有错误。 两项测试均在 BO = 10时进行。

此致、

卢卡斯

尊敬的 Lukas：

您使用了哪个监听器固件？

此致、

马尔文

尊敬的 Marvin：

我使用了 SmartRF 数据包监听器2目录内 cc1312lp 文件夹中的固件。

此致、

卢卡斯

再次大家好、Lucas、

我在使用200kbps GFSK 868MHz 配置时、无法使用监听器读取可行的数据。 我能不能问您所使用的 SmartRF 监听器是哪种类型的版本、以及您在监听器设置中指定了哪个 PHY？

此致、

马尔文  

尊敬的 Marvin：

我使用了 SmartRF 数据包监听器2、版本：1.10.0。 由于此版本没有针对200kbps GFSK 868MHz 的预定义 PHY 设置、我是这么做->

我从预定义的配置中选择了915MHz 200kbps GFSK PHY、并通过 SysConfig 工具将其基础频率编辑为0通道频率->

此致、

卢卡斯

尊敬的 Lukas：

再次对响应延迟表示歉意。 您会说传感器执行 LBT 操作并丢弃消息、或者不执行 LBT 操作并在稍后重新传输1-2个信标。 这让我觉得、当执行 LBT 的传感器掉落时、没有要发送的消息。 我做了一些测试、发现传感器仅在需要发送数据时才执行 LBT。 它放弃执行 LBT 的唯一时间是没有要发送的数据时。 第一个测试仅涉及让其中一个传感器发送数据、另一个测试涉及两个传感器发送数据。  

两个传感器正在发送数据：

一个传感器用于发送数据：

在第一个测试中可以看到、两个传感器都在执行 LBT、只有一个传感器发送数据。 在第二个测试中、第二个传感器不执行 LBT、因为它没有要发送的数据。

以下是两个测试的捕获结果：

e2e.ti.com/.../Session-0.sal

e2e.ti.com/.../Session-1.sal

此致、

马尔文

尊敬的 Marvin：

您能否告诉我、您在这些测试中使用的是哪个 SDK 版本？

此致、

卢卡斯

我正在使用7.10.01.24

此致、

马尔文

尊敬的 Marvin：

感谢您的深入理解。

我已经将我的应用程序上的 SDK 更新到7.10.01.24、问题仍然存在。 至于你的意见-

Unknown 说：

这让我觉得当传感器丢失执行 LBT 时，没有要发送的消息

我使用更新的 SDK 做了额外的测试,修改了我们的应用程序以在调用 Sensor_sendMsg ()中的 ApiMac_mcpsDataReq ()之前启用 GPIO ,并在之后立即禁用它。

在以下示例中、 捕获了传感器0x0002事件 。

CH1 - RX、CH2 - TX、CH3 -调用 ApiMac_mcpsDataReq ()(打包消息传输到堆栈的 TX 队列)。

嗅探器日志-

第一种情况-

监听器日志显示传感器0x0001已成功将消息发送给协调器。 振荡器显示、传感器0x0002确实已将形成的消息发送到堆栈、但未执行 LBT。

第二种情况-

此处可以看到不必要的重新传输。 堆栈以某种方式确定它需要在此信标上发送消息、即使较早时在队列1信标上收到了打包的请求也是如此。 CH3在整个过程中都处于低电平状态、这证明了我们的应用程序的行为符合预期。

第三例-

上面的振荡器显示了预期行为。 传感器0x0002 Did LBT、通道空闲、因此发送了消息。

第4起案件-

上面的振荡器显示了预期行为。 与第3种情况类似、但据监听器称、这两个传感器都成功发送了消息、这当然是因为 LBT 是在它们之间的不同时间启动的。

我还设法捕获了情况、当传感器0x0002实际执行 LBT 而不重新传输时-

这种情况是预期行为。 如果堆栈接收到数据发送请求、则应启动 LBT、如果当时通道被占用、则丢弃消息。 可以在监听器日志中看到、此时传感器0x0001正在发送消息。

我还在应用程序中添加了跟踪来跟踪来自 beaconNotifyIndCb ()的响应、对 ApiMac_mcpsDataReq ()的调用以及来自堆栈的 MAC_MCPS_DATA_CNF 事件状态响应-

Log 显示,在每4个信标指示回调时,传感器通过调用 ApiMac_mcpsDataReq ()向协调器发送消息。 在每一种情况下,ApiMac_mcpsDataReq ()响应0 (ApiMac_STATUS_SUCCESS ), 因此 数据肯定会成功发送到堆栈。 如果堆栈甚至尝试对从队列中弹出的消息执行某种操作、则发出 MAC_MCPS_DATA_CNF 事件、并使用状态0 (ApiMac_STATUS_SUCCESS)调用 dataCnf 回调-这将解释 dataCnf 跟踪。

在行23中可以看到不必要的重新传输、前面的行19显示堆栈接受了该消息、 但出于某些未知原因、决定在之后向其传输2个信标。 如果甚至尝试在此处执行 LBT、则 MAC_MCPS_DATA_CNF 事件将以状态0xE1 (ApiMac_STATUS_channelAccessFailure)发出。

因此、关于 ETSI 调节200kbps 带宽的重新传输问题是一个问题。

另一个问题-堆栈的 CSMA-CA 算法与 IEEE 802.15.4标准不符。 在本注释和问题描述的附加示例中、可以看到 时间间隔在 即使我们已将最小退避指数配置为0、将最大退避指数配置为1、LBT 也已启动。 标准的指定 CSMA-CA 算法包括以下公式、用于在 CCA 阶段之前进行随机时间计算-

在本例中、它应为2^0 - 1 = 0。 那么、随机时间计算的公式是什么、以及最小/最大退避指数对这一次的影响如何？

此外、为方便起见、请附加所有调试文件。

此致、

卢卡斯

e2e.ti.com/.../new_5F00_sdk_5F00_tests.zip

您好、Lucas：

您能否尝试将 mac_cfg.c 文件中找到的 MAC_CFG_TX_DATA_MAX 从2更改为1、看看是否遇到了同样的问题？

此致、

马尔文

尊敬的 Marvin：

感谢您发送编修。 我可以看到、 ，但仍然可以看到重新传输。 附加监听器日志。

此致、

卢卡斯

e2e.ti.com/.../MAC_5F00_CFG_5F00_TX_5F00_DATA_5F00_MAX_3D00_1_5F00_2sensors.zip

您好、Lucas：

我明白了。 您能尝试在 sensor.c 文件的 sendMsg 函数中将 dataReq.txOptions.noRetransmits 设置为 true 吗、然后查看是否得到相同的结果。

此致、

马尔文

尊敬的 Marvin：

遗憾的是、我得到相同的结果。

此致、

卢卡斯

e2e.ti.com/.../dataReq.txOptions.noRetransmits_3D00_true_5F00_2sensors.zip

您好、Lucas：

返回到传输队列中。 我本来希望将 MAC_CFG_TX_DATA_MAX 设置为1能够起作用、因为 Mac 可能只删除传输队列中的一条消息。 您能否尝试  也将 MAC_CFG_TX_MAX 设置为1。 这适用于所有类型的帧、而不仅仅是数据。 例如 ACK 帧。

此致、

马尔文

尊敬的 Marvin：

我得到相同的结果。 我认为这个问题与 TX 队列长度无关、 正如测试表明、堆栈甚至不会尝试执行 LBT -它必须与从 TX 队列接收消息和堆栈决定执行 LBT 之间的过程相关。

此致、

卢卡斯

e2e.ti.com/.../MAC_5F00_CFG_5F00_TX_5F00_MAX_3D00_1_5F00_2sensors.zip

您好、Lucas：

我会和研发部门讨论这个问题、看看会出现什么问题。

此致、

马尔文

尊敬的 Marvin：

您能从研发的角度介绍一下这个问题的现况吗？

此致、

卢卡斯

您好、Lucas：

是的,我在上周五与他们举行了一次会议。 R&D 也不清楚导致这种行为的问题是什么。 但是、我们有一些想法需要测试。 当我有一些答案时、会向您回复。 感谢您的耐心等待。

此致、

马尔文

尊敬的 Marvin：

此问题的状态如何？

此致、

卢卡斯