CCS/LAUNCHXL-CC1350: RSSI to dBm equation after reading from register 0x4004 517C

Intellectual 320 points

Replies: 7

Views: 169

Part Number: LAUNCHXL-CC1350

Tool/software: Code Composer Studio

Hi there,

I'm implementing Antenna Diversity in CC1350 based on http://www.ti.com/lit/an/swra523b/swra523b.pdf, and using SmartRF for Tx and PacketRx in CCS.

In addition, I'm reading RSSI values for each antenna using Register 0x4004 517C.

To convert those values do dBm, I'm using the code suggested in DN505, being:

if (rssi_dec >= 128)
rssi_dBm = (INT16)((INT16)( rssi_dec - 256) / 2) - rssi_offset;            // rssi_offset is set to 72
else
rssi_dBm = (rssi_dec / 2) - rssi_offset;  

The problem is that I'm getting strange values for RSSI, which are always below -100dBm event when Rx and Tx are close to each other.

It seems -100dBm (decimal 200) is the saturation value and it can't get better, as shows the image below taken from my terminal.

The part of code which reads, calculates and prints these values is:

I've tested Rx in more than one LP (including LPs with the default PCB antenna) and I got the same results.

Am I using the right equation/offset for RSSI? 

Thank you,

Bruno

7 Replies

  • No Bruno, you are not using the right equation/offset :-)

    The RSSI is given on signed form in dBm and no conversion is necessary.

    Siri

     

  • In reply to Siri:

    Hi Siri, thank you for responding,

    Now I declared rssiAnt0_dBm and rssiAnt1_dBm as int8_t. I'm still stuck at the same max value of decimal 200,  which now is equal to -56dBm (2's complement).

    Also, it's strange that RF_cmdReadRfRegAntenna.value is always indicating that the antenna with less power is being chosen.

    Images from terminal and code below:

    So, to summarize, both registers have a maximum value of decimal 200. This should be converted to the maximum RSSI value, which I would expect should be something close to 0dBm. 

    I'd really appreciate if you or someone else could help me on this.

    Thank you,

    Bruno

  • In reply to Bruno Lau da Costa:

    Hi

    I have done some testing and I see the same thing as you are. When RSSI0 show the strongest signal, it shows that ANT1 is selected, and vice versa. I have reported this to the modem team and are awaiting their feedback (this is probably a documentation bug in the app note).

    When it comes to your comment about 200 decimal should be 0 dBm, I do not understand what you mean. The RSSI is given as a signed int ranging from -128 to +127, where -128 indicates invalid RSSI.

    The dynamic range for the RSSI + 95 dB, starting at the sensitivity level. That means that using the 50 kbps settings, you can read a value from the register from -110 to around -15.

    200 decimal = 11001000b = -56

    Siri

     

  • In reply to Siri:

    Hi Siri, thanks for your answer.

    The thing about -56dBm is that it never gets better than that (a value closer to 0), even when I put the boards one in front of the other and Tx Power set to 14dBm. I usually don't get the same RSSI values for both antennas; however, when they are too close, both get 'stuck' at -56.

    In addition, I can establish a really good connection (send a 200 bytes payload each 50ms without loosing packets) while RSSI is showing -128 (clamped due to int8 limitation). This value is maintained when I keep going further, and connection is still good. However, this seems a non-realistic measurement since receiver sensitivity is about -110dBm. 

    To sum up, these results suggest there might be an offset to add when we read the RSSI, so that the saturation value when boards are close is something nearer 0 (let's say, -15dBm), and we start noticing a bad communication around -90~-100dBm, what is the case when using the Coprocessor project, for example. Also, adding this offset we are able to reach the dynamic range of +95dBm.

    Thank you for helping me,

    Bruno

  • In reply to Bruno Lau da Costa:

    For the differents PHY's and different HW, we measure the RSSI offset when we are doing characterization, and the RSSI offset is configured in the override list.

    The RSSI offset is subtracted from the measured RSSI.

    For the CC1310LP in the 868 MHz band the offset should be adjusted by +5 dB, and the offest written through the override is therefore -5:

    // override_phy_rx_rssi_offset_5db.xml

    // Rx: Set RSSI offset to adjust reported RSSI by +5 dB (default: 0), trimmed for external bias and differential configuration

    (uint32_t)0x00FB88A3,

    In the 433 MHz band, the RSSI should be adjusted by -2, and the ofset is therefore +2:

    // override_phy_rx_rssi_offset_neg2db.xml

    // Rx: Set RSSI offset to adjust reported RSSI by -2 dB (default: 0), trimmed for external bias and differential configuration

    (uint32_t)0x000288A3,

    I guess that since you are using Antenna Diversity you have made your own HW, and you need to measure the offset on your board, and adjust for it using hte proper override.

    BR

    Siri

     

  • In reply to Siri:

    Hi Siri,

    I'm using Antenna DK2 (http://www.ti.com/tool/CC-ANTENNA-DK2) as HW. 

    1 - If I use RSSI offset override, I'm gonna need a huge value to compensate it, let's say about +40. Is that ok?

    2 - In addition, I'm experiencing the same issue when I use only the original CC1350LP with its own antenna. The control output pins toggle, but there's no switch and therefore the antenna used is always the same. On the firmware, however, I keep having different RSSI measurements which differ more than 10dBm in average, as well as a RSSI value that reaches -128dBm at really short distances.

    How could we explain such different measurements (averages with really low standard deviation) when using the same antenna?

    Thank you for helping,

    Bruno

  • In reply to Bruno Lau da Costa:

    Hi

    I have been testing some more and I observe the same thing as you are. I addition to the counters counting up the wrong antenna (or the RSSI register addresses beeing switched), the RSSI also saturates at -56 dBm. If you read the RSSI from the rxStatistics.lastRssi, you read the correct value. I have reported this to the design team, but do not know when I will get some resources to look into this.

    BR

    Siri