• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 53 subscribers
  • Views 2284 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Starterware/LAUNCHXL-CC1350: Making sense of RSSI from CC1350

Tim Simerly
Genius 9975 points
Part Number: LAUNCHXL-CC1350
Other Parts Discussed in Thread: CC1350, CC1200, CC1120

Tool/software: Starterware

Dear Support:

I am trying to get the RSSI from the CC1350 using RF Driver.  From what I understand, there are 2 options:  use the RF Driver API RF_getRSSI( hRF ) or set the append RSSI field in the receive command (i.e. .rxConf.bAppendRssi = 0x1 ).  However there are a few issues that I am confused about how to go about doing this:

1.)  with RF_getRSSI, when issuing the receive command, I was anticipating issuing this call in the receive callback routine, but from what I understand, this won't work since this command needs to be issued while it is receiving the packet.  I issue the command and then block waiting on the packet to be received, so when I am supposed to issue this RF_getRSSI(...) call since I can't do this in the callback?  I tried issuing this in a repetitive loop after issuing the receive command, but that doesn't work either.  Please advise how you are supposed to go about using this RF_getRSSI(...) call after issuing the receive command.

2.)  Preferably, I would like to just do this in the callback and access the appended data at the end of the received packet.  However I couldn't find any documentation on how to know where this appended byte is relative to the received data in the received packet.  From what I can tell, it looks like it is the 1st byte at the end of the received packet, but not sure - please advise as where documentation is that describes where the appended bytes are located after setting the bit fields in the receive command to append the desired bytes (i.e. RSSI, Timestamp, Status, etc).

3.)  As an alternative, I found documentation that advises to perform the following to get the RSSI :

rfc_propRxOutput_t rxStatistics;

RF_cmdPropRx.pOutput = &rxStatistics;

...

in the callback routine:

RSSI = &rxStatistics.lastRssi;

but I couldn't get this to work.  Is there any documentation (i.e. example code) that describes how to go about getting RSSI using this method?  

4.)  Finally once I get the RSSI properly, are there any adjustments/modifications I need to make to this returned value to get this in terms of an accurate RSSI dBm reading?  Please advise.

Thanks,
Tim

  • 0
    TI__Guru**** 317180 points
    1) getRSSI is meant to be used to find the energy in the channel, not the energy of a given packet.
    3) This is the preferred method. I did a brief test and had no issues getting it to work.

    I tested in the rfPacketRx example, changes are made in the rfPacketRx.c file
    Place

    static rfc_propRxOutput_t rxStatistics;
    int8_t RSSIout;

    on the top of the file together with the other declarations.

    Place

    RF_cmdPropRx.pOutput = (uint8_t*)&rxStatistics;

    under the other RF_cmdPropRx.pOutput settings under /* Modify CMD_PROP_RX command for application needs */

    Add

    RSSIout = rxStatistics.lastRssi;

    to the call back, I placed it on the line under currentDataEntry = RFQueue_getDataEntry();

    If that doesn't work for you, please describe in detail.

    4) The RSSI value is adjusted from the chip. The RSSI offset is compensated in the following override:

    // override_phy_rx_rssi_offset_5db.xml
    // Rx: Set RSSI offset to adjust reported RSSI by +5 dB
    (uint32_t)0x00FB88A3,
  • 0 in reply to TER
    TI__Genius 9975 points
    Hey TER:

    Thanks for your answers and the explanation. Makes sense now that I know that getRSSI() is doing so thanks for making that clear. As for getting RSSI via appending to the end of the packet vs using the pOutput element in the Rx command, why is the pOutput method preferred?

    As for getting the pOutput method to work, thanks for the example - I was using the & to get the data and had an error in my code - it does indeed work the way you described. So thanks for making that clear. I'll use pOutput for now, but would like to know why this is the preferred path.

    As for what you wrote in answer 4.), yes I saw that in the smartrf_settings.c file but it wasn't clear what that meant. Why this adding of 5 dB and when I get an RSSI from the chip and does it correspond to the actual value I would expect from a spectrum analyzer for the same power level or is there an adjustment I would need to make to get an accurate reading?

    Thanks,
    Tim
  • 0 in reply to Tim Simerly
    TI__Guru**** 317180 points
    4) Using the overrides provided by SmartRF Studio: If you apply Y dBm on the input with a signal generator the chip will rea that you have Y dBm, in other words you will get an accurate reading.
  • 0 in reply to TER
    TI__Genius 9975 points
    Hey TER:

    Ok, thanks for the explanation on RSSI. And why did you say that the pOutput method is the preferred method to get RSSI? Just for my information, do you where there is documentation on how to know where the RSSI, Timestamp, Status is located in the packet when using the append method to the end of the packet?

    Thanks,
    Tim
  • 0 in reply to Tim Simerly
    TI__Guru**** 317180 points
    23.7.4.1 Receive Buffers in the TRM describe how to append RSSI to the receive buffer.
  • 0 in reply to TER
    TI__Genius 9975 points
    Hey TER:

    The TRM? Of course. I was looking through the developers guide, google searches and code examples - forgot about the rather lengthy section on the Radio in the TRM. Thanks for helping me find the info needed. Now one last question - you mentioned that the pOutput is the preferred method to get RSSI - why did you say that?

    Thanks,
    Tim
  • 0 in reply to Tim Simerly
    TI__Guru**** 317180 points
    I probably was too fast when writing that it's the preferred method. Basically it's the method the more software centric support engineers has shown me.
  • 0 in reply to TER
    TI__Genius 9975 points
    Hey TER:

    Ok, thanks - I kind of like the append to the packet method since it is the way the CC1120 and CC1200 devices worked and wanted to stay consistent with that unless there was some efficiency improvement of using pOutput. Good to know I can go either way and thanks for your help in explaining what to do and helping me getting this to work.

    Thanks,
    Tim