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.

CC2642R: Regarding the issue of slow RSSI acquisition on CC2642

Part Number: CC2642R

Dear TI Official Engineers,

We are using the **simple_peripheral** example project for the CC2642R chip and need to obtain the RSSI value of the connected device.
Our current implementation creates a timer to call `HCI_ReadRssiCmd(connHandle)` every 50ms, and then retrieves the RSSI value afterward.
1.png

However, the RSSI update rate is very slow – we only get a new reading approximately every 300ms.

Is there any way to increase the frequency of RSSI readings?
Looking forward to your reply.
Sincerely
Deng Junjie 

  • Hello Deng,

    Thanks for reaching out! We will take a look at your issue and get back to you ASAP. In the meantime, what SDK version are you using?

    Best Regards,

    Tarek D

  • Hello Tarek D,
    The SDK version I am using is simplelink_cc13xx_cc26xx_sdk_8_32_00_07.
    Supplementary note: We start the timer in the case GAP_LINK_ESTABLISHED_EVENT: block and its callback function.
    Best Regards,
    Deng Junjie

  • Hey Deng,

    This is a great question! So the way the HCI_ReadRSSICmd command works is by calling a link layer APi that checks the RSSI of the last received data packet.

    So, I believe this will rely purely on your connection interval (and potentially peripheral latency and supervision timeout), since the RSSI value will only be updated when a connection event occurs and it's RSSI value is calculated.

    I hope this answers your question!

    Best Regards,

    Tarek D

  • Hello Tarek D,

    I have set it up as shown in the figure below, but this does not seem to work.
    I understand that the mobile device may have rejected such a frequent connection interval. In this case, do I need to frequently send a 1-byte data packet or an empty packet to obtain RSSI frequently? If so, how to implement this, or where to send it to minimize the impact on performance? Please help me find a suitable location to send the data.
    Looking forward to your reply. Thank you!
    Best regards,
    Deng Junjie

     

  • Hey Deng,

    Yes, that's a very big possibility (and a great observation). However, I believe that the cell phone could be sending a connection parameter update request of it's own (most cell phones do). What I would recommend would be to wait until the phone sends a connection parameter update request, and reject it (via the BLEAPPUTIL_LINK_PARAM_UPDATE_REQ_EVENT event), and then send a connection parameter update request of your own.

    One way to verify what's going on would be by providing a packet sniffer log. This will help us understand exactly what's going on, and make an informed decision based of that.

    I hope this helps!

    Best Regards,
    Tarek D