[参考译文] 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 示例制作一个非常简单的演示代码、该代码会重现此错误。

此致、

您好！

我进行了许多测试、最终找到了一些解决方案。

最近、我发现 RX 器件会错过很多消息或通过 RF_EventRxNOk 事件接收消息、因此我们放置了更大的外部天线、匹配度更高。 已接收消息的 RSSI 值从-96/-101增加到-47/-51、这是一个很大的差异、现在 Rx 部分将接收每条消息。 此外、我还改进了错误检查机制。 现在有两种错误的可预防性；

对于 PROP_ERROR_RXBUF：

if (RF_cmdPropRx.status == PROP_ERROR_RXBUF) // Check if Free RFQueue entry
{
  uint8_t entryStatus = RFQueue_nextEntry();
     if (entryStatus != DATA_ENTRY_PENDING) // Test if Queue entry is free
     {
        RFQueue_nextEntry(); // Free next entry
     }
}

rxCommandHandle = RF_postCmd(g_initParams.handle, (RF_Op*) &RF_cmdPropRx,
RF_PriorityNormal, Bsp_Rf_rxCallback, RF_EventRxEntryDone);

到目前为止、系统仅进入了 if 条件、如果我在 rxcallback 内放置一个断点、这是合理的、因为我停止 CPU、而不是仍然连续接收消息的射频内核。  

对于 RF_ALLOC_ERROR：

rxCommandHandle = RF_postCmd(g_initParams.handle, (RF_Op*) &RF_cmdPropRx,
                        RF_PriorityNormal, Bsp_Rf_rxCallback,RF_EventRxEntryDone);

    if (rxCommandHandle == RF_ALLOC_ERROR)
    {
         RF_flushCmd(g_initParams.handle, RF_CMDHANDLE_FLUSH_ALL, 1);
    }

系统反复进入内部状态、我不确定原因。 它看起来像冲洗解决了问题,但我喜欢了解的核心的错误,所以如果你有任何猜测,你愿意分享.  

提前感谢您、

此致、

你好、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.