Getting strange RSSI values from Bluetooth scans

[Nicholas Robinson]

I am new to this device, so please bear with me during the inevitable simple misunderstandings!

I am scanning for bluetooth devices and getting sensible numbers of devices with MAC addresses that tally with other methods. However, I am getting a mixture of positive and negative values for the RSSI. I have researched other questions on this and other fora, but all seem to be all positive rather than a mix. Analysing the data more closely reveals that the values for both negative and positive values rarely, if ever, change. One device in particular has been reporting the same RSSI of +86 for ten of thousands of scans over the past few hours. This is with many revisions of the code, so I very much doubt it is memory corruption, etc. This is my scanning callback:

static void scan_recv_cb(const struct bt_le_scan_recv_info *info,
                        struct net_buf_simple *buf)
{
    static uint32_t last_debug_log = 0;
    static uint32_t total_scan_count = 0;
    uint32_t current_time = k_uptime_get_32();
    
    total_scan_count++;

    char addr_str[BT_ADDR_LE_STR_LEN];
    bt_addr_le_to_str(&info->addr, addr_str, sizeof(addr_str));
    
    /* Log every scan for specific problematic device (using string comparison) */
    if (strcmp(addr_str, "28:56:5A:30:43:2E (random)") == 0 || 
        strcmp(addr_str, "28:56:5A:30:43:2E (public)") == 0) {
        LOG_INF("PROBLEMATIC DEVICE SCAN: %s, RSSI: %hhd, Time: %u ms, Count: %u", 
                addr_str, info->rssi, current_time, total_scan_count);
    }
    
    update_beacon_info(&info->addr, info->rssi, NULL, 0);
}

If I put in a test such as `if (info->rssi) ...` then it behaves as though the value is positive, so it isn't some problem with conversion on trying to print it out using printf or LOG_DBG.

[Nicholas Robinson]

My test is if (info->rssi > 0) and not as shown above!

[Kenneth]

Hello,

I tried to recreate your problem by using \ncs\v3.1.0\nrf\samples\bluetooth\scanning_while_connecting\src\main.c with the following modification of scan_recv()

static void scan_recv(const struct bt_le_scan_recv_info *info, struct net_buf_simple *buf)
{
	/** We're only interested in connectable advertisers to
	 * show faster connection establishment
	 */
	if (info->adv_type != BT_GAP_ADV_TYPE_ADV_IND &&
		info->adv_type != BT_GAP_ADV_TYPE_EXT_ADV) {
		//return;
	}

	char name_str[ADV_NAME_STR_MAX_LEN] = {0};

	bt_data_parse(buf, adv_data_parse_cb, name_str);

	uint32_t current_time = k_uptime_get_32();
	char addr_str[BT_ADDR_LE_STR_LEN];
    bt_addr_le_to_str(info->addr, addr_str, sizeof(addr_str));

	static uint32_t total_scan_count;
	total_scan_count++;

	/* Log every scan for specific problematic device (using string comparison) */
    LOG_INF("PROBLEMATIC DEVICE SCAN: %s, RSSI: %hhd, Time: %u ms, Count: %u", 
                addr_str, info->rssi, current_time, total_scan_count);

	if (strncmp(name_str, adv_name, ADV_NAME_STR_MAX_LEN) == 0) {

		char addr_str[BT_ADDR_LE_STR_LEN] = {0};

		bt_addr_le_to_str(info->addr, addr_str, sizeof(addr_str));

		uint32_t bytes_written = cache_peer_address(info->addr);

		if (bytes_written > 0) {
			LOG_DBG("Scanned and cached connectable addr %s", addr_str);
		}

		try_connect();
	}
}

Though it seems to work as intended here:

What nRF54L15-DK are you using and which nRF Connect SDK are you using?

Kenneth

[Nicholas Robinson]

Hello,

Thank you for looking at this. I am using an NRF54L15_xxAA_REV2 and v3.1.1 (zephyr 4.1.99).

[Kenneth]

Can you try opening the same example as me and replace scan_recv() as suggested to check on your end?

Kenneth

[Nicholas Robinson]

All devices are now showing good (and varying) RSSI values!