CC1310: RF Reception Problem

You say your project is similar to the rfEchoTx / rfEchoRx, meaning that you have done changes to the application.

First of all, have you tested the default examples on your custom HW to make sure that everything works as expected?

I cannot tell you anything regarding what the problem is as I do not know what you are doing in your code, and since I do not know how it fails. You say that the RX side does not receive, but have you verified that the radio is actually in RX while  your transmitter is transmitting or is it in some other state?

I would recommend that you output the LNA and PA signals to some GPIOs and use a logic analyzer to debug this. The LNA signal will be asserted when the radio is in RX and the PA signal when in TX. If you output these two signals on both your transmitter and your receiver code, it would give you useful info as to what is happening and where in your application something goes wrong.

How to output these debug signals are found here:

Routing RF Core Signals to Physical Pins — SimpleLink CC13x0 SDK Proprietary RF User's Guide 2.60.00 documentation

Another debug tip is to check/verify that error situations are handled properly. What happens to the receiver if it receives a packet with CRC NOT, what happens if the buffers overflow etc.

BR

Siri

Hey Siri,

Sorry for late reply, I was running some tests. These are my results and observations;

- Yes, my firmware is completely different than rfEcho examples, only the communication pattern is similar.

- When I test the default examples rfEchoTx/Rx without alter, it works fine. The number of messages sent is equal to number of messages that is received. I am monitoring these numbers with counters I put in callbacks in both Rx and Tx projects. I also sniff with a launch pad and clearly observe that the total number of messages in the air is double of the messages sent or received.

- As you recommended I outputed the LNA and PA signals to some GPIOs and using a logic anaylzer, I saw that devices are in the Rx and Tx modes during the intervals they should be in Rx and Tx. 

- For your last suggestion I tried to check and verify error situations as properly as possible. Since my RF_cmdPropRx.pktConf.bRepeatNok = 1; configuration is like this, I would expected my system return back to listening when received a message with Crc error which it does, I also observed that besides the crc error messages I have not encountered any strange behaviour or error conditions except having RF_ALLOC_ERROR frequently. For the test purposes I frequently restart the communication process again and again which means whenever I end the process I close listening manually with RF_cmdTrigger and and I start it again by posting RF_cmdPropRx. 

Do you think, starting and ending RF command frequently(every 1-2 seconds) may cause having RF_ALLOC_ERROR, and if so do you think this might have a major impact on the RF communication. I also observed that when I have RF_ALLOC_ERROR, RF_cmdPropRx is still in ACTIVE status and can receive the messages most of the time. 

Do you suggest me to use RF_flushCmd when I have RF_ALLOC_ERROR ?

Do youthink does the RF_cancelCmd has an advantage over RF_cmdTrigger when the Rx is started and ended frequently ?

Thanks in advance.

Best Regards,

Hi

Unfortunately I cannot say why anything of what you describes above happens, without knowing the details of your code.

Are you saying that when monitoring the PA and LNA signals, you can see that the radio is in RX, while the transmitter is in TX, but still it is not receiving anything?

I do not know which events you subscribe to in the RX callback, but it might be a good idea to subscribe to all the event that can happen in RX mode, and then check for all these events in the callback to see if a special event occurs before your test is failing.

If you are able to make a VERY simple demo code based on  one of our SDK examples that will reproduce this error on our LPs, you can share that code and I can see if I can reproduce the issue at my end.

Siri

Hi,

- Yes I am saying that the radio is in Rx when PA is high and  in Tx when the LNA is high. I can even see the messages in the air that is sent by the sender but can not receive them.

- I already tried subsribing all of the events. What I observe;

There are times that I receive a lot of CRC Error, occisionally RF_EventRxBufFull and RF_EventRxIgnored and sometimes noting. When it happens, communication stucks which makes sense but the problem is this;

Same system, same exact firmware, sometimes it works like a charm and sometimes it does not. The times it works I do not see many incorrect message. I start considering may be some of the components on the boards get hot  and may be the ambient temperature increases and that effects the communication, besides that there is no any physical change I can think of. Usually, communication get stucks after many repetetive start and stop of the process. 

- Another observation is this:

If I use a launchpad instead of the receiver device and keep the transmitter part same(both hardware and firmware vise), the communication does not stuck. That makes me think that there is room for both the hardware and the firmware development because the hardware works with rfEcho project but the custom firmware works with the launchpads. 

I will try to make a VERY simple demo code based on SDK examples that will reproduce this error.

Best Regards,

Hi again,

I conducted many test and we finally reached some solutions.

Recently, I relazied that RX part either misses a lot of message or receives the messages with RF_EventRxNOk event so, we put a larger external antenna with better matching. The rssi values of the received messages increased to -47 / -51 from -96 / -101 which is a significant difference and now rx part receiving every message. In addition to that I improved the error checking mechanism. Now there is precauitions for two kind of errors;

for 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);

So far, the system has only entered inside the if condition, if I put a breakpoint inside the rxcallback which make sense since I halt the CPU but not the RF core that still continiues to receives messages. 

for 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);
    }

The systems repeatedly enters inside the condition which I am not sure why. It looks like flushing solves the problem but I like the understand the core of the error so if you have any guesses you are welcome to share. 

Thank you in advance,

Best Regards,

There are two things that can cause a buffer overflow:

The packet is too large for the buffer

The status of the buffer that the RF Core is planning to use next, is not set to DATA_ENTRY_PENDING

Since I do not know the size of your buffers, what max length you are using for the radio to filter on, if you include the header in your packet or not, or what status bytes you append, I cannot tell you why you are seeing this error.

Same goes for the handling of the Queue. I strongly recommend that you use our SW for handling the data entries, as this has been tested.

I have never managed to get an RF_ALLOC_ERROR so unfortunately I am not sure why you are seeing this. Again, I will need some code that are able to reproduce the problem to be able to debug it.

Since your code worked much better when you changes the antenna, I would assume that your problems are still related to not handling faulty packets properly (with bad antenna you get bad RF performance and many wrong packets that are causing problems for your SW)

When debugging your issues you should test with a lot of bad packets to see how your SW behaves.

For example:

Transmit packets without CRC so that the CRC check will fail on the RX side

Transmit packets with length byte greater than the max length set by the radio

BR

Siri

Hello Siri,

I already indicated below configuration in the first code snippet I shared.

RF_cmdPropRx.maxPktLen = PAYLOAD_MAX_LENGTH;

RF_cmdPropRx.rxConf.bAutoFlushIgnored = 1; // Discard ignored packets from Rx queue
RF_cmdPropRx.rxConf.bAutoFlushCrcErr = 1; // Discard packets with CRC error from Rx queue
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 is 30 and I do not include anyhing except packet. I discard both the length and the status byte from the stored packet. 

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();
    }
}    

and this how handle inside the rxcallback which is almost identical to your SW handling for data entries. I also now started to encounter with the PROP_ERROR_RXBUF as well which I think is the same reason causing RF_ALLOC_ERROR.

I checked the "rfc_propRxOutput_t rxStatistics", which obtain the output values using RF_cmdPropRx.pOutput = (uint8_t *)&rxStatistics.

 nRxNok, nRxIgnored ,nRxStopped are zero. There is no message with CRC error or ignored but the  nRxBufFull increases occisionally. What do you think might be the reason.  Can I not release the data entries on time or having a packet greater than the entry but our package is fixed length. 

RF_cmdPropRx.pktConf.bVarLen = 0    RF_cmdPropTx.pktConf.bVarLen = 0;

Is there an abnomally that you notice in my rxcallback or any part of the code I shared?

The biggest difference between the example rfecho and our system,

In the example, there are end triggers with abs time or jumped directly to next commandç Also message processing is handled in the callback,

in my code end trigger for RX command is RF_cmdTrigger which means I end the operation manually over and over again. Do you think this might cause anything.  

It is very hard for me to create the same issue on one of the example so I need guidence with this.

Best Regards, 

Hi,

A little update,

I changed the end of my rxcallback from RFQueue_nextEntry();

to 

if (RFQueue_nextEntry() != DATA_ENTRY_PENDING)  // Test if Queue entry is free
{
RFQueue_nextEntry(); // Free next entry
}

with this double check I was able to eliminate the PROP_ERROR_RXBUF. Now I do not observe this error. For some reason, RFQueue_nextEntry() is not enough the release the data entry so it needs double check. It would be good if you have any ideas. Unfortunately, I still observe RF_ALLOC_ERROR and flush the command queue whenever I observe this. 

Any insight or idea is welcomed.

Best Regards, 

I cannot see anything in particular just from looking at your code. Again, for me to be able to help your further, I need you to provide me with a minimal example that runs on our LPs, that will reproduce the error you are seeing so that I can debug it myself.

BR

Siri