nRF54L15 / Zephyr: No valid RSSI available after BLE connection (HCI Read RSSI returns 127)

[EvonneC]

Hi Nordic team,

I am working on BLE Channel Sounding (Initiator + Reflector) on nRF54L15
using Zephyr / nRF Connect SDK v3.1.1.

I would like to clarify the expected behavior regarding RSSI after a BLE
connection is established.

Environment:
- Device: nRF54L15 DK
- SDK: nRF Connect SDK v3.1.1
- OS: Zephyr
- Role: Central (Initiator), connected to a Reflector
- Feature: BLE Channel Sounding (CS)

What I have observed so far:

1) Scan / Advertising RSSI works as expected
- RSSI values are available during scanning
- Matches what is shown on a mobile phone BLE scanner

2) After BLE connection is established:
- Calling HCI Read RSSI (BT_HCI_OP_READ_RSSI) always returns:
rssi = 127
- According to the spec, 127 indicates "RSSI not available"
- This happens consistently even when the link is stable and active

3) Zephyr currently does not provide an API such as:
bt_conn_le_get_rssi()
(at least not in NCS v3.1.1)

4) Mobile phones still show an RSSI value while connected,
but I understand this is not necessarily the BLE connection RSSI,
and may be derived from other measurements.

My questions are:

- Is it expected that Connection RSSI is not available on nRF54L15?
- Is the HCI Read RSSI command intentionally unsupported or not implemented
for LE connections on this SoC?
- Is there any recommended alternative to estimate link quality
after connection (e.g. Link Quality, packet statistics, CS-related metrics)?
- Are there plans to expose connection RSSI in future Zephyr / NCS releases?

At the moment, we are considering:
- Using Scan RSSI (ADV RSSI) before connection
- Using Channel Sounding tone quality / success rate as a link quality indicator
- Dropping Connection RSSI entirely if it is not supported

I would appreciate confirmation on whether this behavior is expected,
and if there is an official recommendation.

Thanks!

Note:
We are able to run Channel Sounding successfully (RTT / IFFT / PBR),
so the link is clearly active. The lack of connection RSSI seems to be
a limitation rather than a connectivity issue.

[Simonr]

Hi

There is nothing specific that should be limiting you from using a connection RSSI while in a connection on the nRF54L15. What I'm assuming is happening here is that the device is busy doing Channel Sounding estimates, which takes precedence/priority on the radio, so the Bluetooth controller reports that the RSSI isn't available because it is busy doing channel sounding measurements. 

I think your idea of using the Channel Sounding quality will prove more stable/accurate in terms of a link quality indicator while in a connection either way, so I wouldn't really recommend RSSI here. 

Regarding your questions about RSSI, I think it should be supported on other sample projects that don't hog the radio/bluetooth controller as much as the Channel Sounding sample, like the peripheral_lbs sample for instance.

Best regards,

Simon

[Emil Lenngren]

Shouldn't the HCI command immediately return the latest known RSSI value in that case? Note that this command is one of the type that returns immediately, while other ones, such as the Read Remote Features command, first returns a status, and when the reply arrives over the air, delivers the final answer.

[Susheel Nuguru]

0X7F means that there is no valid RSSI value available to give. The continuous CS activity seems to be blocking other BLE activity that can get and record the RSSI value internally. I cannot see the SDC controller implemention now but there might be few things you can try.

1. try to do some GATT level activity by doing a periodic notification or similar now and then, wait for the notification and then do the HCI RSSI read. It might get an updated RSSI then.
2. Maybe do channel sounding activity in bursts giving time for other connection events to run which should update internal RSSI states.
3. Decrease the channel sounding duty by increasing the CS connection interval and/or reduce the event count.