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.

Peripheral RSSI on connection events

Other Parts Discussed in Thread: CC2541

I am running a CC2541 device in Peripheral role. During a master/slave connection, I can read an RSSI with a callback during Central solicited attribute r/w transactions, however for periodic Central device initiated Supervision connection events the reported RSSI value is stuck at the value reported during the last Central solicited attribute r/w transaction.

Question: How can one read accurate RSSI values for periodic Central device initiated Supervision connection events?

  • Hey Brendan,

    I'm afraid there is no way to read the RSSI value of these packets from your application. A LL data packet with an LLID value of 01b along with a PDU length of 0 is an empty PDU. LL Data PDUs with this designation are discarded during L2CAP processing so are never passed up to the application.

    -Matt

  • Thus it would imply that, for a fixed path loss constant set on a Proximity Monitor and reported transmit power level by a Proximity Reporter, dynamic modulation of Proximity Reporter transmit power level could be used by the Proximity Reporter to asynchronously cause the Proximity Monitor to cause the Proximity Reporter to Immediate Alert. 

  • It's not possible to incrementally step Tx power for the TI BLE protocol stack as the only three options are 0dbm, -6dbm and -23dbm. So I guess the only other options are to use a Connection Parameter Update Request or write directly to the TXPOWER[7:4] where we can get 12 increments rather than three in BLE.

  • I've looked at this more and I may have jumped the gun on saying you couldn't read the RSSI of every connection event.

    You can register for a connection event notice through the hci (HCI_EXT_ConnEventNoticeCmd()), which will set a specific event for a specific task that you pass as arguments, at the end of every connection event. When handling this event you can call HCI_ReadRssiCmd() which should grab the last RSSI value for that connection handle and send a message to the GAP layer. This will invoke your RssiRead call back.

    -Matt

  • Hmmm ... I live to learn ;-)

  • HCI guide says that "Note: Only a Slave connection is supported." This suggests that the function is only supported on a Central that is connected to a Peripheral.

    It would have been nice if the function was similarly supported on a Peripheral.

    As per you suggestion that there may be an implementation error for the current RSSI callback, I would say so. So how would a fixed implementation work? Would RSSI be available to a Peripheral within the duration only prior to a subsequent payload-less Supervision connection event?

  • With respect to the latter, the current implementation is convenient in the sense that the last payload communication's RSSI was xxx and stays that way till the next payload comm event but possibly very misleading for the Peripheral which would have to either wait for a Central Tx or do a Connection Parameter Update Request kludge. Ok, so this is not exactly a high data rate communications protocol but is there any BLE protocol requirement that specifically states that HCI_EXT_ConnEventNoticeCmd() be only implemented for a Central? Are there any hardware deficiencies that preclude TI from applying the function to both a Central and Peripheral in the library?

    Connection Parameter Update Request

  • Suppose I'm a Peripheral advertiser and desire to perform some logic based upon a current connection to a Central, such as disconnect incumbent upon RSSI without having the requirement of a payload transaction and its associated energy requirement and spectrum usage. The above is an instance where application of the HCI_EXT_ConnEventNoticeCmd() function to a Peripheral could come in useful.

  • Hey Brendan,

    The HCI_EXT_ConnEventNoticeCmd() is currently only supported on a slave device which is your peripheral device. The LL slave is the device is the device which was advertising prior to the connection request and cannot transmit a packet until it successfully receives one.

    As far as getting a the RSSI values for connection events of empty PDUs it's not currently supported for the slave device. I think it is an issue of the controller not updating the RSSI memory mapped register on empty LL payloads. The best advice I can offer is to send connection update requests or some other request in order to force the update.

    -Matt