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.

  • Resolved

CC1121: RSSI appended to the packet is abnormal

Genius 5085 points

Replies: 16

Views: 199

Part Number: CC1121

Hi,

My customers send and receive using products with CC1121.
CC1121 is set to append RSSI to the packet.(PKT_CFG1.APPEND_STATUS=1)
After communicating for a few minutes, the RSSI value of the packet will be abnormal.

They compared packet's RSSI value with register's RSSI value. It is usually the same value, but sometimes the packet's value becomes abnormal.

Question 1:
How is the RSSI value of a packet calculated? Is it the same as the register value?

Question 2:
Their product outputs the RSSI of the packet to the LCD. They want this value to be normal. Would you tell me the solution?

Register settings (SmartRF Studio & EVM)

Tx

TX_CC1120.xml

Rx

RX_CC1120.xml

Regards,

Rei

  • Genius 289540 points

    The RSSI value in the RSSI register and the appended value will be the same if the packet is successfully received. I would assume that when you got a difference the packet is not received correctly.

    Also you should correct the RSSI with the RSSI offset (given in SmartRF Studio) to get the real RSSI.

     

  • Genius 5085 points

    In reply to TER:

    Hi TER,

    We are checking the packet with CRC and the packet is being received correctly. Problem is that the value given to the packet is different from the register value. Why is the appended value different from the register value? I have confirmed with the default settings of SmartRF studio and CC1120, I suspect the register setting.

    I'm sorry, I accidentally pressed Resolved.

    Regards,
    Rei

  • Genius 289540 points

    In reply to rei:

    The RSSI register is the only source for the RSSI value, if the attached RSSI value is different it sounds like something wrong with the receiption.

    - The data you present is not compensated for RSSI offset,. Could you show the same graph but with correct offset. What would be more interesting is to show the content of the packet with unexpected RSSI and compare with the packet s just before and after. I would need more details.

     

  • Genius 5085 points

    In reply to TER:

    Hi TER, 

    Compensate RSSI Graphs

     

    Before and after wrong data

     data.csv

    The values before and after are normal. It's a very strange phenomenon..

    Have a great holiday!

     

    Regards, Rei

  • Genius 289540 points

    In reply to rei:

    I was trying to look at the register settings but when I imported the RX settings into SmartRF Studio I got strange results. Could you check if th .xml file gives the wanted register settings?

     

  • Genius 5085 points

    In reply to TER:

    Hi TER,

    Sorry, I got the xml file again.

     0447.RX_CC1120.xml

    3527.TX_CC1120.xml

    The problem is occurred when one Rx and three Tx.

    Regards, Rei

  • Genius 289540 points

    In reply to rei:

    Meaning that they don't see an issue if they have one RX and one TX?

    If that is the case, how does the TX software handle that only one TX node should send at a given time? 

     

  • Genius 5085 points

    In reply to TER:

    I have checked with the customer. In the case of one Rx and one Tx, this issue does not occur.

    This issue occurs when three asynchronous Tx nodes send data every 500ms.

  • Genius 289540 points

    In reply to rei:

    Meaning that the software has not implemented LBT or similar to avoid more than one TX node sending at the same time? I suspect that what they see is caused by a collision on the air (or similar)  

     

  • Genius 5085 points

    In reply to TER:

    Each Tx node performs carrier sense to prevent collisions. 

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.