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.

CC1120 RSSI problem

Other Parts Discussed in Thread: CC1120

Hi all,

we have some CC112xEM Rev. 1.1 modules with CC1120 mounted running our application at 868 MHz that is already working fine on CC1101EM modules and we are porting it to the CC1120. Now it seems that the readout of the RSSI value from the CC1120 makes no sense. It jumps in dimensions of some 10dBm, mostly near the noise floor (down to -118dBm) and then grows up to +3dBm and back again, where the modules are placed on a desk. The same application on a CC1101EM module does give a stable RSSI of about -14dBm.
We have tested a few CC1120 modules, but always the same effect. We have also checked and evaluated the register settings so that the RSSI values are valid, AGC gain and RSSI are frozen and rssi_valid_cnt is at 5 calculations. Also played around with the register settings, but there is still no change in the behaviour of the chips. Even a fixed value set in AGC_GAIN_ADJUST register does effect the same.

Is there any tweak to get proper RSSI values? Are we doing anything wrong?

  • Hi Zenubi,

    I use APPEND_STATUS mode and RSSI value added to rx fifo seems to reasonable value.

    Would you try this.

  • Yasuhiro, thanks for your reply!

    Yes, this was our first thought, but it will trail a lot of changes in the protocol processing. So is there no other solution to get the RSSI the normal way?

  • When I have looked at RSSI values for CC1120 they have been stable.

    - If you use SmartRF Studio  in "Continuous RX" and look at the RSSI graph using the same register settings you are using in your application, is the RSSI value still jumping up and down?

    - Do you have something in the test environment that could cause the RSSI value to go up and down? (Other senders, multipath, people in front of the sender/ receiver etc)

  • Hi

    In cases where AGC_CFG1.AGC_SYNC_BEHAVIOR is set to freeze the RSSI value after a sync word is detected, it is important that preamble and sync word is long enough so that the RSSI represent the RSSI of the packet and not of noise received prior to the preamble.

    Assume a data rate of 5 ksps and the following register configurations:

    CHAN_BW.ADC_CIC_DECFACT = 0

    CHAN_BW.BB_CIC_DECFACT = 16

    AGC_CFG1.AGC_WIN_SIZE = 2

    AGC_CFG0.RSSI_VALID_CNT = 2

    T2 is the time the AGC uses to measure the signal strength and can be calculated using the equation below:

    T2 >= ((2^(AGC_WIN_SIZE + 4)) * BB_CIC_DECFACT * Decimation Factor + 46)/fXOSC = (2^6 * 16 * 20 + 46) / 32000000 = 641.43 us

    AGC_CFG0.RSSI_VALID_CNT gives the number of RSSI estimates required before the next update of the RSSI value.

    RSSI_VALID_CNT = 2 means that 5 RSSI estimates are required before the RSSI value is updated, hence the RSSI update rate = 5∙T2 = 5∙641.43 µs = 3207 µs.

    To guarantee that the RSSI measurement is done during the packet and not on noise, preamble + sync word should be greater than twice the RSSI update rate.

    With a data rate of 5 ksps this means that a minimum of 32 bits preamble/sync must be received for the RSSI readout to be correct. For this example it is assumed that the radio has been in RX for a time longer than the max CS response time (see Equation 16) when the preamble and sync word is received.

    BR

    Siri

  • Hi

    I did a mistake in my previous post and forgot to include T1 in the equations.

    Please see the following post: http://e2e.ti.com/support/low_power_rf/f/156/t/156257.aspx

    BR

    Siri