Nrf Connect SDK peripheral always reads RSSI as 127 upon a connection

RE: Nrf Connect SDK peripheral always reads RSSI as 127 upon a connection

Einar Thorsrud — Thu, 24 Feb 2022 08:50:44 GMT

I see the same in nRF Connect SDK 1.6.1. There is no error indicating that it is not ready (the status still indicates 0). This is fixed in 1.7 and later, though. For 1.6 I suggest you simply discard 127 as that can never be a valid value.

RE: Nrf Connect SDK peripheral always reads RSSI as 127 upon a connection

CodeLoader — Wed, 23 Feb 2022 18:54:32 GMT

So I was doing basically that, and what I've found out, is that right away after the connection the BLE controller seems to be not ready for the RSSI query, and it returns 127.
It always returns a normal negative value when I query RSSI after receiving a BLE message, but I need it to be resolved in the connection handler
I created an infinite loop to run this RSSI-querying function in the connection handler until it gives a normal value, and it usually gets it from 10th-20th attempt. Although sometimes it's at the first attempt.

So I wonder, why there is no error status or any way to signal this not-readiness?

RE: Nrf Connect SDK peripheral always reads RSSI as 127 upon a connection

Einar Thorsrud — Wed, 23 Feb 2022 15:37:14 GMT

[quote user="CodeLoader"]I'm not sure I understand you, how can I call bt_hci_rp_read_rssi as it is a struct not a function?[/quote]

hah, good point. I must admit I was very quick when looking at this earlier 🙂

[quote user="CodeLoader"]Maybe in the latest Zephyr update it was changed? I'm using Zephyr 1.6.1, by the way.[/quote]

I assume you are referring to nRF Connect SDK 1.6.1 (as Zephyr 1.6.1 is really old)? If so, then the approach demonstrated in the hci_pwr_ctrl should work, and I just tested on a nRF5340 DK, where I get the RSSI reading without any issues.

[quote user="CodeLoader"]And what is sdc_hci_cmd_sp_read_rssi_return_t? Can you please provide a code example for better understanding?[/quote]

That is the type of the struct holding the rssi in the SoftDevice controller API. The only code example you should refer to is the hci_pwr_ctrl which does this. If. you are using 1.6.1, then that would be this:

static void read_conn_rssi(uint16_t handle, int8_t *rssi)
{
	struct net_buf *buf, *rsp = NULL;
	struct bt_hci_cp_read_rssi *cp;
	struct bt_hci_rp_read_rssi *rp;

	int err;

	buf = bt_hci_cmd_create(BT_HCI_OP_READ_RSSI, sizeof(*cp));
	if (!buf) {
		printk("Unable to allocate command buffer\n");
		return;
	}

	cp = net_buf_add(buf, sizeof(*cp));
	cp->handle = sys_cpu_to_le16(handle);

	err = bt_hci_cmd_send_sync(BT_HCI_OP_READ_RSSI, buf, &rsp);
	if (err) {
		uint8_t reason = rsp ?
			((struct bt_hci_rp_read_rssi *)rsp->data)->status : 0;
		printk("Read RSSI err: %d reason 0x%02x\n", err, reason);
		return;
	}

	rp = (void *)rsp->data;
	*rssi = rp->rssi;

	net_buf_unref(rsp);
}

I suggest you use that as reference, and simply copy-paste the handling from there, and verifies it still works in your app. After that you can always modify as needed.

RE: Nrf Connect SDK peripheral always reads RSSI as 127 upon a connection

CodeLoader — Wed, 23 Feb 2022 14:53:59 GMT

To me it seems my attempt to read RSSI is the same as in the hci_pwr_ctrl example, the only difference is that casting from void pointers is needed in C++.
As in the example it is like this:

err = bt_hci_cmd_send_sync(BT_HCI_OP_READ_RSSI, buf, &rsp);
if (err) {
	uint8_t reason = rsp ?
		((struct bt_hci_rp_read_rssi *)rsp->data)->status : 0;
	printk("Read RSSI err: %d reason 0x%02x\n", err, reason);
	return;
}

rp = (void *)rsp->data;
*rssi = rp->rssi;

I'm not sure I understand you, how can I call bt_hci_rp_read_rssi as it is a struct not a function? And I'm reading its fields after it's returned in the response buffer. Maybe in the latest Zephyr update it was changed? I'm using Zephyr 1.6.1, by the way.

struct bt_hci_rp_read_rssi {
	uint8_t  status;
	uint16_t handle;
	int8_t   rssi;
} __packed;

And what is sdc_hci_cmd_sp_read_rssi_return_t? Can you please provide a code example for better understanding?

RE: Nrf Connect SDK peripheral always reads RSSI as 127 upon a connection

Einar Thorsrud — Wed, 23 Feb 2022 14:02:07 GMT

Hi,

Have you considered doing as demonstrated by the hci_pwr_ctrl sample (see how read_conn_rssi() is implemented in zephyr/samples/bluetooth/hci_pwr_ctrl/src/main.c)?

Ignoring the above and looking at what you have attempted to do, you configurations look good. However, while I must admit I am rusty in modern C++, your way of obtaining the RSSI before you print it looks odd to me. Have you tried simply calling bt_hci_rp_read_rssi() the old fashioned way, and the accessing rssi in the returned struct(sdc_hci_cmd_sp_read_rssi_return_t)?

RE: Nrf Connect SDK peripheral always reads RSSI as 127 upon a connection

CodeLoader — Tue, 22 Feb 2022 22:03:50 GMT

Also, extended advertising features work and setting TX power in the same connection handler also works