RSSI value on nRF Connect app DIFFERENT to RSSI value from read_conn_rssi function from Bluetooth sample app: HCI Power Control

[adam_atmo]

Hi,

I am developing the nRF52833 DK with NCS v2.00.

I am using a function in my source code that reads the current RSSI of the connection. The function, read_conn_rssi (attached below), is taken from the Bluetooth sample, Bluetooth: HCI Power Control. I am printing the RSSI (using printk) on the nRF terminal. I am also connecting the SoC to my Android phone and reading the remote RSSI using the macros provided on the app. The RSSI on the application is always different to the RSSI that is read from the read_conn_rssi function. The RSSI on the nRF Connect app is always about ~15-20 dBm weaker than that read by the read_conn_rssi function.

Any idea why this may be? Perhaps someone could please repeat this experiment and see if there is also a discrepancy in RSSI readings?

Thanks very much,

Adam

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);
}

[Joakim Jakobsen]

Hi Adam! 

This is actually expected behavior.

RSSI (Received Signal Strength Indicator) is a term used to measure the relative quality of a received signal to a client device. The RSSI  will vary depending on a lot of factors. 

In your case, there will most likely be variations to RSSI due to different radios (on the phone and the nRF), they will have different antennas, sensitivity etc. that will affect the RSSI.

Br 
Joakim

[adam_atmo]

Thanks Joakim,

I know that the macros calculate the RSSI of a signal received by the android device. Are you saying that the above function (which is in the peripheral source code) calculates the RSSI of a received signal by the peripheral?

If so, is there any way to send the RSSI of Central device to the peripheral? 

Is there possibly an algorithm that relates these two different RSSI values?

Thanks,

Adam 

[Joakim Jakobsen]

Hi. 

Sorry, maybe I didn't explain well enough in my last post. 

The RSSI is an indication of the signal strength. RSSI is very sensitive to external factors as well as the RF design of your device. 
You will most likely see different values for the RSSI on the phone and on the nRF device due to the design differences, different antennas, sensitivity etc. 

Please let me know if I am misunderstanding something here. 

Br, 
Joakim

[adam_atmo]

Hi Joakim,

Perhaps I am not understanding your first message...

RSSI is defined as the relative signal strength of a received signal by a particular device. So the strength of received signal by an Android smartphone will be different to the strength of a received signal by the nRF52833 radio. Is this correct?

That is my understanding as to why the RSSI values printed by the peripheral and central are different.

Thanks,

Adam

[Joakim Jakobsen]

Yes, that is correct.

Some fluctuation in RSSI is expected.

Br,
Joakim

[adam_atmo]

Thanks.

So is there a way to specifcally read the RSSI on the central side as opposed to the peripheral? I want to know what the strength of the received signal by the smartphone is.

Adam.

[Joakim Jakobsen]

If you are using the nRF Connect for mobile application, the RSSI is displayed there.

Br,
Joakim

[adam_atmo]

The issue is that this is done through macros which cannot be automatically restarted after auto connection. Therefore, I want an alternative way of measuring the RSSI on the central side. Is there a way to do this? The RSSI function that I attached originally is very useful to calculate the RSSI on the peripehral side but not the central.

Thanks,

Adam

[Joakim Jakobsen]

If the central device is a nRF device, you can refer to the function you mentioned earlier. 

If the central device is a smart phone running nRF Connect for mobile and that doesn't provide the functionality you require, you will most likely develop an application that can match your requirements. 

The only thing I can do on my side wrt nRF Connect, is make a feature request to our mobile developers.
But I can't guarantee that this will be added and I can't provide any timeline for it. 

Br, 
Joakim