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.
Part Number: LAUNCHXL-CC1350
Tool/software: Code Composer Studio
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
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?
No Bruno, you are not using the right equation/offset :-)
The RSSI is given on signed form in dBm and no conversion is necessary.
I'm on vacation until August 10th. Sorry for the inconvenience this might cause. Feel free to open up a new thread if you find questions are not getting picked up by someone else (remember to link back to the old thread)
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
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.
In reply to Bruno Lau da Costa:
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
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,
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:
// Rx: Set RSSI offset to adjust reported RSSI by +5 dB (default: 0), trimmed for external bias and differential configuration
In the 433 MHz band, the RSSI should be adjusted by -2, and the ofset is therefore +2:
// Rx: Set RSSI offset to adjust reported RSSI by -2 dB (default: 0), trimmed for external bias and differential configuration
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.
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,
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.
First of all, sorry that this has taken so long.
I have now confirmation from the designers that there is a bug in the documentation, and that RSSI0 and RSSI1 should be switched.
Further, the RSSI value written to 0x4004517C will saturate since during antenna switching the RxGain is forced to maximum (no AGC).
To read the actual RSSI of the received packet you need to append the RSSI to the packet or read the RSSI from the output structure.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.