NCS Scan Request report RSSI value

Hi Fellow NCS-ers, I understand that the configuration setting CONFIG_BT_EXT_ADV,  CONFIG_BT_CTLR_SCAN_REQ_NOTIFY, and  bt_le_ext_adv_create() with the appropriate callback function will allow me to receive scan-requests reports similar to nRF52 SDKs. To get the rssi of the scan-requests, I would also need to set CONFIG_BT_CTLR_SCAN_REQ_RSSI. My question is how would I then parse the rssi value from the bt_le_ext_adv_cb.scanned callback? In the callback, the returned bt_le_ext_adv_scanned_info struct only has an "addr" field but not an rssi field?

My current code snippet looks like...

#define ADV_MIN_INTERVAL        0x160
#define ADV_MAX_INTERVAL        0x190
#define ADV_OPTIONS             (BT_LE_ADV_OPT_SCANNABLE | BT_LE_ADV_OPT_NOTIFY_SCAN_REQ)

static const struct bt_le_adv_param adv_parameters = {
	.options = ADV_OPTIONS,
	.interval_min = ADV_MIN_INTERVAL,
	.interval_max = ADV_MAX_INTERVAL,
};

void on_scanned(struct bt_le_ext_adv *adv, struct bt_le_ext_adv_scanned_info *info)
{
    LOG_INF("on_scanned");
    // get the mac address of the scanned device, and rssi
    char addr[BT_ADDR_LE_STR_LEN];
	bt_addr_le_to_str(info->addr, addr, sizeof(addr));
	//...etc
}

void on_sent(struct bt_le_ext_adv *adv, struct bt_le_ext_adv_sent_info *info)
{
    LOG_INF("on_sent");
}

struct bt_le_ext_adv_cb cb = 
{
    .sent = on_sent, 
    .scanned = on_scanned
};

static int start_advertising(void)
{
	int err;

    err = bt_le_ext_adv_create(&adv_parameters, &cb, &adv_ext);
    if (err) {
		LOG_WRN("Create ext adv err %d\n", err);
		return err;
	}
	//...etc
}

Parents
  • Hi,

    The SoftDevice controller does not support reading RSSI from scan request packets. You will see if you enable the CONFIG_BT_CTLR_SCAN_REQ_RSSI configuration that you get the following (or similar) build warning:

    warning: BT_CTLR_SCAN_REQ_RSSI (defined at subsys/bluetooth\controller\Kconfig.ll_sw_split:944) was
    assigned the value 'y' but got the value 'n'. Check these unsatisfied dependencies:
    BT_CTLR_SCAN_REQ_NOTIFY (=n), BT_LL_SW_SPLIT (=n).

    May I ask what the use case is? We may be able to suggest a workaround.

    Regards,
    Terje

  • hi Terje, that is too bad to hear as we were able to get the RSSI when we are using nRF5 SDK 17.1.0 on another project. We are using NCS for a different piece of hardware, and were hoping to have the same functionality as our other project.  The use case is to gather additional information on BLE devices that are not advertising but are sending scan-request to our device. Getting the RSSI will tell us if the device is near our device. I hope you can suggest a workaround.

    Cheers,

    Dennis

    p.s. will future NCS release also report RSSI for scan-request reports?

  • Hi,

    I definitely see that there can be a use case for probing the RSSI of third party, scan only, centrals. Sadly I do not see any other ways to do that, than to get the RSSI from scan requests, since that is the only packets being sent from the central in that scenario.

    Please note that in the case of third party centrals, RSSI will be an indication of signal strength, but you have no control over properties of the third party device such as antenna directionality, TX power, etc. The indicated signal strength is still correlated to distance, but it can only give a general idea, since what it really estimates is the strength of the radio link. Please note also that it estimates signal strength on the particular channel, and other signals on the same channel may impact the measurements. I do understand that you have used RSSI successfully in the past, which means you are probably in control of this, but I still mention this in case others see this answer in the future.

    I will inform internally that there is request for such functionality, although I can not give any promises as to whether this will at some point be supported or not. You could however reach out to our sales people, who are more concerned with future plans, roadmaps, etc. Here in DevZone we mostly work on stuff that is already released. If you do not know who our sales representative for your area is, then please ask in a private ticket or private message, and we will let you know.

    Regards,
    Terje

Reply
  • Hi,

    I definitely see that there can be a use case for probing the RSSI of third party, scan only, centrals. Sadly I do not see any other ways to do that, than to get the RSSI from scan requests, since that is the only packets being sent from the central in that scenario.

    Please note that in the case of third party centrals, RSSI will be an indication of signal strength, but you have no control over properties of the third party device such as antenna directionality, TX power, etc. The indicated signal strength is still correlated to distance, but it can only give a general idea, since what it really estimates is the strength of the radio link. Please note also that it estimates signal strength on the particular channel, and other signals on the same channel may impact the measurements. I do understand that you have used RSSI successfully in the past, which means you are probably in control of this, but I still mention this in case others see this answer in the future.

    I will inform internally that there is request for such functionality, although I can not give any promises as to whether this will at some point be supported or not. You could however reach out to our sales people, who are more concerned with future plans, roadmaps, etc. Here in DevZone we mostly work on stuff that is already released. If you do not know who our sales representative for your area is, then please ask in a private ticket or private message, and we will let you know.

    Regards,
    Terje

Children
No Data
Related