[参考译文] CC1352P：快速传输时、使用 TI 15.4收集器-传感器示例的射频数据包损耗

您好！
此外、我想提供一些背景信息。

我们的应用程序仍基于 CC1352P SDK 的3.20版本。 应用的性质是每50ms 按方向交换一个射频数据包。 跳频在50ms 驻留时间内使用。

在研究低射频性能时、我们使用传导射频路径进行了测试设置、以最大程度地减小外部(例如、占用的通道)的影响。
我们观察到"射频性能"反复出现的低模式(每 x 小时左右重复出现)。 在这些间隔之间、行为符合预期。
由于这是一种传导设置、我们认为问题是由(闭源) TI 15.4堆栈引起的、我们无法对此进行进一步调查。
我们还将 CC1350用作嗅探器器件、并将其与 TI 射频应用和 Wireshark 结合使用、令人惊讶的是、即使堆栈没有将所有数据包全部交付给我们、我们也可以捕获射频的所有数据包。

那么、下一步是最小化更改 SDK 3.20的收集器+传感器示例、如果我们能够再次观察到这种行为。

最后、我们对 SDK 5.40的这些示例进行了相同的更改。 这是上述报告。 因此、我们提供了一个问题描述、希望您能够轻松深入了解问题所在。 我们只能看到15.4堆栈为黑盒。


到目前为止、我们已获得的知识：

-发送器和接收器这两个堆栈的时基略有差异，这是由两个振荡器的变化引起的。 时基基于 CC1352P 的 LF 时钟。 我们可以在应用中观察到、如果我们将 LF 源从 HF XOSC 更改为 LF RCOSC、重复模式的速度会改变。

- 根据 e2e.ti.com/.../cc1352p-ti-15-4-stack-with-frequency-hopping-chance-of-missing-a-packet 上的答案、我们知道堆栈可能会延迟射频数据包的传输、直到它适合接收器的一个驻留间隔。 我们怀疑传输速度太快、并将数据包速度从每次迭代的50ms 更改为100ms。 但仍然可以观察到相同的重复模式、尽管有两次时间将数据包放入驻留间隔。


根据包含最新 SDK 默认示例的错误报告(上一篇文章)、我们需要您深入了解问题。 如果无法在堆栈中修复它、它可以帮助我们了解问题的实际情况、并在我们的应用中采取对策。 请帮助我们！ 谢谢你。

您好！

感谢您的详细解释！

您能否发布监听器日志文件？

由于您经常发送数据(收集器和传感器侧每50ms 发送一次数据)、+通过 UART 为每个数据包编写一条消息、我想知道数据包在哪里丢失：

1)未从发件人发送的数据包(似乎您的监听器日志不能证明这一理论)

2)未通过无线方式接收数据包(在这里、我非常好奇监听器日志的内容。)

3) 3) MAC 层和接收端应用之间的数据包丢失。 要进行调查、您能否暂停调试会话并检查 Collector_statistics 和 /或 Sensor_msgStats 全局变量？  

4) 4)应用程序和 UART 终端之间的数据包丢失

谢谢、

玛丽·H

嗅探器日志文件似乎太大、无法附加它。 这可能是我们基于3.20 SDK 的应用程序的运行结果、我们在其中首次发现了这种行为。

对列出的数据包丢失位置的选项的注释：

1) 1)我们将尝试确定在传输-应答模式中数据包丢失在哪一侧。

2) 2)这将是我们看到的第一个选项。 CC1350监听器件捕获数据包的可能性是否存在、但 CC1352P 器件不捕获数据包的可能性？ (例如、由于监听器器件始终处于 RX 模式、应用器件在 RX 和 TX 之间切换？)

3) 3)如果我们将监听器结果与应用中接收到的数据包进行比较、这将是我们看到的第二个选项、至少对于我们的应用而言是如此。 对于更改后的示例、我们将读取 Collector_statistics 和 Sensor_msgStats、我将发布这些数据。

4) 4) UART 消息包含计数器和丢失消息的数量。 此错误很容易找到、我们没有在日志中观察到。

此致、

HKR

您好！

如果您可以将文件托管在其他服务器上(例如 Dropbox 或 Google docs)、我可以从那里下载。 或者、您可以向我发送朋友请求、并将请求发送给我。 最好使用 SDK 的最新版本捕获日志。 我相信这将会告诉我们很多关于正在发生的事情！

2) 2)如果 CC1352P 接收到数据包、则应发送 ACK。 如果没有 ACK、我们可以假设 CC1352P 没有接收到数据包。  

4) 4)我担心您的应用可能会花费大量时间进行 UART 传输、因此没有足够的时间来执行 TI 15.4-Stack 活动。 是否可以在没有 UART 写入的情况下运行测试？ (例如、将值写入全局变量、或使用 GPIO 切换指示故障？)

谢谢、

玛丽·H

您好！

我们将尝试为5.40示例准备监听器日志。

AD 2)我们的所有传输都配置为不重试和没有 ACK。

AD 4)我怀疑 UART 通信会影响实际堆栈活动。 我们将在非阻塞模式下打开 UART、并每50ms 传输几个字节。 这对于 UART (驱动程序)而言应该是相当可行的。

此致、

HKR

您好！

2) 2)在这种情况下、可能值得对 Rx 和 Tx 引脚进行逻辑分析仪跟踪。 请参阅调试指南：

https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_6_10_00_29/docs/ti154stack/html/ti154stack-guide/debugging-index.html#debugging-rf-output

谢谢、

玛丽·H

感谢 Rx 和 Tx 引脚的提示、我们将对其进行设置并进行尝试。

同时、我们成功地运行了另一个夜间测试并从中获取日志和监听器数据。

这个具有12dBm 的传导功率、上一个具有0dBm 的功率。 我们注意到模式发生了变化、但仍然有一种重复出现的丢包模式：

传感器：

收集器：

我已在此处上传.pcapng Wireshark 监听器日志和 Excel 文件 ：https://e1.pcloud.link/publink/show?code=kZ3bMzZc00QV8PEOhVnprPnbp7N5jcWwnLy

我们还在连接了调试器的情况下进行了超过2小时的另一次运行、并读出了统计信息。

传感器：

收集器：

谢谢、

HKR

您好！

从您的屏幕截图中、似乎数据包确实在无线传输过程中丢失了。 但是、当我按下链接下载您的文件时、没有任何反应、因此我无法查看日志。 (您能问 Andreas 如何使用 TI 驱动器进行文件传输吗？)

如果我理解正确、您的收集器能够发送所有数据包、但传感器无法按预期回传？

谢谢、

玛丽·H

您好！

我刚刚重试了、我的同事也尝试了、但我们无法从该链接下载。 TI 网络上可能有一些东西阻止了我们。

如果您可以设置 google 驱动器或分接盒、我们应该能够访问这些驱动器或分接盒。

谢谢、

玛丽·H

很抱歉、这里是 Dropbox 链接。 希望这能更好地工作： https://www.dropbox.com/sh/j1fd7500av12u49/AACZ-rM-y7f0hpMFhdRsroJUa?dl=0

此致、

HKR

您好！  

感谢您提供新链接、我们能够下载这些文件。 我们现在可以查看日志。  

此致、

SID

您好！

它对这个问题有些沉默。

您能否同时获得见解？ 您是否重现和/或跟踪了数据包丢失的来源？

谢谢、

HKR

您好！

很抱歉、该主题的响应延迟。 我们在团队中遇到一些带宽问题、但我们正在调查此问题。 请在下周收到一些回复和反馈。  

此致、

SID

您好！

此问题是否有任何新闻？

我们在应用中仍然面临问题、并付出了相当大的努力来创建这份可追溯的错误报告、而不涉及我们的应用。 因此、我们希望您能够重现我们的观察结果、并让我们(如果不是解决方案)更深入地了解或解决如何最好地规避此问题。

谢谢你。

HKR

您好、HKR、  

我们理解并赞赏您的努力。 很抱歉耽误你的时间。 我们正在进行此项工作、我们将很快向您提供一些反馈。

此致、

SID   

谢谢！

您好、HKR、

再次感谢您提交报告和项目。 它非常全面。

我们有几个观察结果。

1.请详细说明第二组图形是如何 生成的？

传感器：

在这里、传感器或收集器连续发送的消息被视为丢失的数据包、这种情况可能并非总是如此。

例如、如果收集器发送两条带有帧计数器1和2的消息。 然后、传感器回传帧1和帧2、这些帧不会丢失、但传感器在接收到消息2之前没有要传输的通道。

2.另外一个可能的错误来源(可能不太可能)可能是  processModificationIncomingMsg()中的 memcpy。

如果设置事件  sensor_return_data_EVT，并且 Sensor_process()尚未处理该事件，则尚未回传数据。

同时，如果此时还有另一个 dataIndCb，并且您调用  processModificationIncomingMsg()，则会覆盖缓冲区，并再次设置 sensor_return_data_EVT。 处理此数据后、您将回显下一帧、丢失一帧。  

在覆盖缓冲区之前、最好添加检查以查看是否已存在未处理的 sensor_return_data_EVT。

简单的如果检查就行了。  

if((Sensor_events & SENSOR_RETURN_DATA_EVT)

话虽如此、如果您还可以发送生成的 UART 日志、那将会很棒。 尤其是在测试运行有相应的监听器日志时。 如果数据完全不是由收集器发送、或者如果数据是传感器没有响应、这可以帮助我们更深入地探究数据的丢弃位置。  

我们将尝试进一步调查我们的一方。  

此致、

SID

您好 Sid、

1。

第二组图形与第一组的"丢失帧"图形相同。
如果存在条目"1"、则表示跳过1个帧。
如果收集器发送两条带有帧计数器1和2的消息、并且它接收到帧计数器1和2、那么根据我们的图、没有"丢失帧"。

除此之外、如果我们使用的驻留时间为50ms、并且发送的数据包的传输持续时间低于25ms、我们实际上预计不存在消息分组、但会传输单个消息。 我们希望每个器件每50ms 传输一次、每25ms 传输一次。 您的期望是否与此不同？

2.

我们暂时怀疑存在相同的问题、并在实施中使用了环形缓冲器、但存储元素的数量不会随着时间的推移而增加、因此我们将此排除在问题原因之外。
我们观察到，总是有足够的时间来复制帧，并通过 ApiMac_mcpsDataReq()安排帧的传输(它始终返回 ApiMac_STATUS_SUCCESS)。

3.

我已将 UART 日志放入已知的 Dropbox 文件夹(www.dropbox.com/.../AACZ-rM-y7f0hpMFhdRsroJUa )、希望这些日志对您的进一步调查有所帮助。

谢谢！

HKR

您好、HKR、  

感谢您的日志和解释。 我们将对此进行研究、 并将很快返回给您。

但是、为了澄清前面有关消息分组的评论、如果通道处于繁忙状态、器件可能会延迟传输、这可能会导致连续的收集器传输或连续的传感器传输。  

此致、
SID

在我们的传导设置中、我们根本不会想到信道繁忙。 如果某个通道从未繁忙、则我们预计不会有数据包丢失。

一个相关的问题-如果我们设置了 ApiMac_mcpsDataReq_t 的以下 txOptions：

   dataReq.txOptions.noRetransmits = true；
   dataReq.txOptions.ack = false；

通道报告为忙(我们可以从数据确认回调中获取此信息)、我们期望堆栈丢弃已发送的当前数据包、而不将其保留在其 TX 队列中。 是这样吗？

谢谢、

HKR

您好、HKR、  

一个相关的问题-如果我们设置了 ApiMac_mcpsDataReq_t 的以下 txOptions：

   dataReq.txOptions.noRetransmits = true；
   dataReq.txOptions.ack = false；

是的、如果 notransmit 设置为 true 并且 ACK 设置为 false、则 Mac 不会等待接收器的应答、也不会重新传输消息。 它将返回成功、因为它将立即传输或返回信道访问失败(在您的情况下、很可能是成功传输)。 但请注意、由于 CSMA 回退、传输本身可能会延迟。

通过进一步的测试和 Rnd 的反馈、您看到的数据包丢失似乎会下降到消息之间的短时间(50ms/100ms)。 它有以下可能的说明。

故障的最重要原因是传感器侧或收集器侧的事务溢出。

应用程序将消息排队到 Mac 发送队列中、该队列的大小可在文件 mac_cfg.c 中找到、默认大小为 MAC_CFG_TX_MAX = 5。 理想情况下、大小足够、Mac 可以处理此队列大小。 但在应用程序中，您发送的消息速率会导致此队列中出现溢出。

在您的测试应用程序中， 在 Sensor_sendMsg 和 sendMsg 中，您可以检查 ApiMac_mcpsDataReq ()函数返回的状态，在大多数情况下，此函 数的状态是成功，但您还应该看到 ApiMac_STATUS_transactionOverflow。  当发送队列已满并且您正在调用此 API 以发送更多消息时、就会发生这种情况。 由于 CSMA 回退、即使没有 ACK 或重新传输也会发生这种情况。 因此、您不会重新传输消息、而是在回退后进行传输。  

将每个直接消息的消息传输速率降低到100ms 以上应该会大大有助于实现这一目的。 在这种情况下、由于传感器回传消息、因此尝试在收集器消息之间使用200ms 的延迟。

只是想知道、我们能否知道最终应用中消息的频率是多少？

此致、

SID  

您好 Sid、

感谢您的澄清。 (我们已将应用中的 CSMA 退避次数设置为零。)

>在测试应用程序中，在 Sensor_sendMsg 和 sendMsg 中，可以检查 ApiMac_mcpsDataReq()函数返回的状态，

我们已将测试应用更改为输出有关事务溢出的信息。 在16小时内、我们没有在传感器上看到这样的情况。
在收集器上、刚开始时有一些(7)、但随后只有3个事务溢出。
我们在传感器和收集器上的事务溢出计数器没有发生变化的情况下、肯定观察到了丢失的封装。

>只是想知道、我们是否知道最终应用程序上的消息频率是多少？

2个射频器件之间的消息频率为每秒20次、因此、在50ms 内一条消息加一条回复。 最大用户数据约为70字节。

>、默认大小为 MAC_CFG_TX_MAX = 5

我们已将测试应用更改为 MAC_CFG_TX_MAX=1、因为我们根本不需要排队。
我们更经常地观察到事务溢出、但总的数据包丢失率没有变化。


因此、对于大多数丢失的数据包、我们不会收到事务溢出错误。

考虑到我们仍然在没有外部射频干扰的情况下进行传导、并已关闭所有数据包、重试和折返、因此丢失数据包的来源问题仍然存在。
－是否是堆栈固有的问题？
堆栈的配置是否可以针对我们的用例进行优化？
-您是否希望在我们的实验室测试设置中不会出现数据包丢失？ 是否已对此类设置进行过测试？

谢谢！
HKR

您好、HKR、  

当我在办公桌上测试您的项目时、我没有使用传导、也没有将 CSMA 退避降至0。 也许这就是我测试中交易溢出的原因。  

该堆栈通常用于报告间隔为500ms 及以上的低功耗传感器网络并进行测试。 但它已经在每条消息之间经过了长达100ms 的测试。 因此、您所使用的数据速率和所测试的 ping 设置不太可能经过测试。

但是、我将检查 Rnd 是否已执行一些额外的测试、并检查有关堆栈配置的反馈。  

此致、

SID