• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 3 answers
  • Subscribers 53 subscribers
  • Views 416 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/CC1310: WOR example packet loss problem

user4959119
Expert 2210 points
Part Number: CC1310

Tool/software: TI-RTOS

Hi Team，

In the process of using the WOR example, I encountered a packet loss problem, and it is difficult for me to figure out what the reason is.I only added the print function, the test method is to count the number of times sent and received. Generally they should be equal, but in reality they always have differences.

Tx side:

/* Send packet */
RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropTxAdv, RF_PriorityNormal, NULL, 0);

/* Update display */
seqNumber ++;
Display_printf(uartDisplayHandle, 0, 0, "Pkts sent: %u", seqNumber);

Rx side:

if (e & RF_EventRxEntryDone)
    {
        do
        {
            /* Toggle LED on RX */
            PIN_setOutputValue(ledPinHandle, Board_PIN_LED1, !PIN_getOutputValue(Board_PIN_LED1));
            Display_printf(uartDisplayHandle, 0, 0, "rxStatistics.nRxOk=%u,rxStatistics.nRxNok=%u,rxStatistics.nRxBufFull=%u,rxStatistics.nRxIgnored=%u,rxStatistics.nRxStopped=%u", 
                           rxStatistics.nRxOk,rxStatistics.nRxNok,rxStatistics.nRxBufFull,rxStatistics.nRxIgnored,rxStatistics.nRxStopped);
......

Result:

  • 0
    TI__Guru* 81491 points
    I do not know what cahnges you have done to the code (settings, packet interval, preamble length etc.) but a good way to debug a WOR application is to monitor the LNA active signal on the receiver, so that you know when the radio is in RX mode.
    This signal is already routed out to LED1:

    /* Route out LNA active pin to LED1 */
    PINCC26XX_setMux(ledPinHandle, Board_PIN_LED0, PINCC26XX_MUX_RFC_GPO0);

    On the TX side, you can route out the PA active signal in the same way, and then you will hopefully figure out why you are missing packets.

    /* Route out PA active pin to LEDx */
    PINCC26XX_setMux(ledPinHandle, Board_PIN_LEDx, PINCC26XX_MUX_RFC_GPO1);

    Siri
  • 0 in reply to Siri
    Expert 2210 points
    Hi Siri，
    I only added the serial port printing function on the RX side, I have not changed anything else.I understand your method, but this phenomenon rarely occurs, so capturing it is a bit difficult.What are the possible reasons?
  • 0 in reply to user4959119
    TI__Guru* 81491 points
    first of all, you need to make sure that the serial port printing does not mess up the timing of your receiver. If it does not wake up at the correct interval, it might loose packets. Other reasons for loosing packets can be interferes on the same channel.

    Siri
  • 0 in reply to Siri
    Expert 2210 points
    I can guarantee that the surrounding environment does not interfere with the channel. I put the serial print function in the receive interrupt and executed it quickly. I think it should not affect the timing.There is no packet loss on the RX side using smartstuio7. Is there any good way to test the packet loss rate of the WOR example?
  • 0 in reply to user4959119
    TI__Guru* 81491 points
    If you receive all packets with Studio (which is in RX all the time), and not with the WOR example (that only is in RX from time to time), it indicates that your receiver is not in RX when your transmitter is transmitting.

    How to verify this and figure out how the timing should be changed, you can find out from following the debug advice I gave you Tue, Mar 19 2019 9:05 AM.
    I assume you are using the WOR TX example as transmitter, to ensure long enough preamble for the WOR receiver.

    Siri