[参考译文] CC1310：RF 接收问题

您说您的工程类似于 rfEchoTx / rfEchoRx、表示您对应用程序进行了更改。

首先、您是否在定制硬件上测试了默认示例、以确保一切都按预期运行？

我不能告诉你什么是问题,因为我不知道你在你的代码中做什么,因为我不知道它是如何失败的。 您说 RX 端不接收、但您 是否在发射器发射时验证了无线电是否实际处于 RX 状态、或者它是否处于其它状态？

我建议您将 LNA 和 PA 信号输出到一些 GPIO、并使用逻辑分析仪对其进行调试。 当无线电处于 RX 状态时、LNA 信号有效；当无线电处于 TX 状态时、PA 信号有效。 如果你在发送器和接收器代码上输出这两个信号、它将为你提供有用的信息、告诉你正在发生什么、在你的应用中哪里发生了问题。

如何输出这些调试信号、如下所示：

将射频内核信号路由到物理引脚—SimpleLink CC13x0 SDK 专有射频用户指南2.60.00文档

另一个调试提示是检查/验证错误情况是否得到了正确处理。 如果接收器接收到没有 CRC 的数据包、接收器会发生什么情况、如果缓冲区溢出等、会发生什么情况

Br

Siri.

嗨、Siri、

很抱歉我的回复太晚了、我正在运行一些测试。 这些是我的结果和观察结果；

-是的,我的固件是完全不同的 rfEcho 示例,只有通信模式是相似的。

-当我测试默认示例 rfEchoTx/Rx 没有改变,它工作正常。 发送的消息数等于接收的消息数。 我正在使用我在 Rx 和 Tx 项目中置入回调的计数器来监视这些数字。 我还通过一个发射板嗅探,清楚地观察到在空中的消息总数是发送或接收的消息的两倍。

-正如你所建议的,我把 LNA 和 PA 信号输出给一些 GPIO 和使用逻辑分析仪,我看到设备在 Rx 和 Tx 的时间间隔内处于 Rx 和 Tx 模式。  

-对于您的最后一个建议,我试图检查和验证错误情况尽可能正确。 由于我的 RF_cmdPropRx.pktConf.bRepeatNok = 1； 配置就像这样、当接收到一条带有 CRC 错误的消息时、我希望我的系统返回到侦听、但这条消息确实发生了 CRC 错误消息、除了 经常出现 RF_ALLOC_ERROR 之外、我还没有遇到任何奇怪的行为或错误条件。 为了进行测试、我经常不断地重新启动通信过程、这意味着只要我结束该过程、我就会手动使用 RF_cmdTrigger 关闭监听、然后 通过发布 RF_cmdPropRx 重新启动它。  

您认为频繁启动和结束射频命令(每1-2秒)可能会导致  RF_ALLOC_ERROR、如果出现这种情况、您认为这可能对射频通信产生重大影响。 我还观察到、当我遇到 RF_ALLOC_ERROR 时、RF_cmdPropRx 仍处于活动状态、并且可以在大部分时间接收这些消息。  

有 RF_ALLOC_ERROR 时、您是否建议我使用 RF_flushCmd？

您是否认为  当 Rx 频繁启动和结束时，RF_cancelCmd 是否比 RF_cmdTrigger 具有优势？

提前感谢。

此致、

大家好

遗憾的是、我无法解释您所描述的上述情况为什么会发生、而且我不知道您的代码的详细信息。

您是否说在监控 PA 和 LNA 信号时、可以看到无线电处于 RX 状态、而发送器处于 TX 状态、但仍然没有收到任何信号？

我不知道您在 RX 回调中订阅了哪些事件、但订阅 RX 模式下可能会发生的所有事件可能是一个好主意、 然后、在回调中检查所有这些事件、以查看在测试失败前是否发生特殊事件。

如果您能够根据 我们的某个 SDK 示例创建一个非常简单的演示代码、该示例将在我们的 LP 上重现此错误、您可以共享该代码、并且我能够在最后看看我是否能够重现此问题

Siri.

您好！

-是的,我是说,当 PA 是高的时候,无线电是 在 Rx 中,当 LNA 是高的时候,无线电是在 Tx 中。 我甚至可以看到发送者发送的广播消息、但无法接收这些消息。

-我已经尝试了淹没所有的事件。 我观察到的内容；

有时候、我会收到很多 CRC 错误、在不可接受的情况下  会收到 RF_EventRxBufFull 和 RF_EventRxIgnored、有时也会收到提示。 发生这种情况时、会出现有意义的通信残桩、但问题是：

相同的系统,相同的固件,有时它像一个魅力,有时它不。 它工作的时间,我看不到很多错误的消息。 我开始考虑可能板上的某些组件变热 、可能是环境温度升高、从而影响通信、除此之外、我能够想到的物理变化不大。 通常、通信会在该过程经过多次重复启动和停止后得到 STUCK。  

-另一个观察是:

如果我使用 Launchpad 而不是接收器器件、并保持发送器器件相同(硬件和固件副总裁)、则通信不会卡滞。 这使我认为硬件和固件都有空间进行开发、因为硬件可以与 rfEcho 项目配合使用、但定制固件可以与 LaunchPad 配合使用。  

我将尝试 根据 SDK 示例制作一个非常简单的演示代码、该代码会重现此错误。

此致、

有两种情况会导致缓冲区溢出：

数据包对于缓冲区来说太大

射频内核计划在下一步使用的缓冲区状态未设置为 DATA_ENTRY_PUNDING

我不知道缓冲区的大小、无线电要过滤的最大长度、是否在数据包中包含标头、或者您附加的状态字节、我无法告诉您为什么会看到此错误。

队列的处理也是如此。 我强烈建议您使用我们的软件来处理数据条目、因为这已经过测试。

我从未成功获得 RF_ALLOC_ERROR、因此很遗憾、我不知道您看到这种情况的原因。 同样、我需要一些能够重现问题并对其进行调试的代码。

由于您的代码在更换天线时运行得更好、因此我假设您的问题仍然与不能正确处理故障数据包相关(使用不良的天线、您将获得不良的射频性能以及许多错误的数据包、这些数据包会导致软件出现问题)

在调试问题时、您应该测试大量不良数据包、以了解软件的行为。

例如：

在没有 CRC 的情况下传输数据包、以便 CRC 校验在 RX 端失败

传输长度字节大于无线电设置的最大长度的数据包

Br

Siri.

你好、Siri、

我已在我共享的第一个代码片段中说明了如下配置。

RF_cmdPropRx.maxPktLen = PAYLOAD_MAX_LENGTH；

rf_cmdPropRx.rxConf.bAutoFlushIgnored = 1；//丢弃 Rx 队列中忽略的数据包
rf_cmdPropRx.rxConf.bAutoFlushCrcErr = 1；//从 Rx 队列中丢弃具有 CRC 错误的数据包
rf_cmdPropRx.rxConf.bIncludeHdr = 0；
rf_cmdPropRx.rxConf.bIncludeCrc = 0；
rf_cmdPropRx.rxConf.bAppendRssi = 0；
rf_cmdPropRx.rxConf.bAppendTimestamp = 0；
rf_cmdPropRx.rxConf.bAppendStatus = 0；

PAYLOAD_MAX_LENGTH 为30、除数据包外、我不包括任何兴。 我从存储的数据包中丢弃长度和状态字节。  

static void Bsp_Rf_rxCallback(RF_Handle h, RF_CmdHandle ch, RF_EventMask e)
{

    if (e & RF_EventRxEntryDone) // Check if Rx is successful
    {
        gp_currentDataEntry = RFQueue_getDataEntry(); // Get current unhandled data entry
        g_recievedMessage = 1;      // Set message received flag

        /* Handle the packet data, located at &gp_currentDataEntry->data. Length is not the first byte with the current configuration */

        gp_packetPointer = (uint8_t*) &(gp_currentDataEntry->data); // Get the address of the Packet (Data)

        /* For the moment packet parsing is conduct somewhere else but if the packets comes too frequently and the application speed can not keep up
         * the parsing should be moved into this callback*/

        /* memcpy(Packet, gp_packetDataPointer, g_packetLength);          Deprecated since the address of the packet is returned not the packet content */

        RFQueue_nextEntry();
    }
}    

这种处理方式在 rxcallback 内部进行、而 rxcallback 内部的处理方式几乎与您对数据条目的 SW 处理相同。 我现在还开始遇到 PROP_ERROR_RXBUF 问题、我认为这也是导致 RF_ALLOC_ERROR 的原因。

我检查了"RFC_propRxOutput_t rxStatistics"、后者使用 RF_cmdPropRx.pOutput =(uint8_t *)&rxStatistics 获取输出值。

 nRxNok、 nRxIgnored、nRxStopped 为零。 不存在 CRC 错误或被忽略的消息、但  nRxBufFull 会以八倍频程的方式增加。 您认为原因可能是什么。  我不能按时发布数据条目、或者数据包大于该条目、但我们的软件包是固定长度的。  

rf_cmdPropRx.pktConf.bVarLen = 0  rf_cmdPropTx.pktConf.bVarLen = 0；

您是否注意到我的 rxcallback 或我共享的代码的任何部分？

示例 rfecho 和我们的系统之间的最大差异是，

在该示例中，有具有 abs 时间的结束触发器或直接跳转到下一个 commandç 另外，消息处理是在回调中处理的，

在我的 RX 命令代码 END 触发 器中是 RF_cmdTrigger、这意味着我可以手动反复结束操作。 您认为这可能会引起任何问题吗？   

我很难在其中一个示例上创建相同的问题、因此我需要相关指导。

此致、  

您好！

有一点更新、

我从  RFQueue_nextEntry ()中更改了 rxcallback 的结尾;

至  

if (RfQueue_nextEntry()!= data_entry_pending ) //测试队列项是否空闲
｛
RFQueue_nextEntry ();//空下一个条目
}

通过这项仔细检查、我能够消除  PROP_ERROR_RXBUF。 现在、我没有观察到该误差。 出于某种原因,RFQueue_nextEntry ()对数据条目的释放不够,因此需要仔细检查。 如果您有任何想法、那会很好。 不幸的是、我仍然观察到 RF_ALLOC_ERROR、并且每当我观察到这个情况时清除命令队列。  

欢迎任何见解或想法。

此致、  

我看不到任何特别的东西、只能看一下您的代码。 同样、为了能够进一步帮助您、我需要您为我提供一个在我们的 LP 上运行的最小示例、该示例将重现您看到的错误、以便我可以自己对其进行调试。

Br

Siri.