This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Directed Advertising not seen by the addressed device

Hi,

I am testing direct advertising with two nRF52-DK. One performs a direct advertising and the other scans for the directed adverts. Unfortunately, the scanning device cannot see the directed advertising packages.

For simplicty and to reduce variables, I have set a test where I use the below code on a nRF52 dk (nRF52832) and the BLE tool on the nRF Connect SDK for Desktop (using a nRF52840-donge). I have hardcoded the dongle address on the directed advertiser code. Unfortunately, I still cannot see the directed advertising packages. Why is that? Any help most welcome.

prj.conf file:

#
# Copyright (c) 2019 Nordic Semiconductor ASA
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#
#CONFIG_NCS_SAMPLES_DEFAULTS=y
CONFIG_BOARD_ENABLE_DCDC=n

CONFIG_BT=y
CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_EXT_ADV=y
CONFIG_BT_DEVICE_NAME="directed_adv"
CONFIG_BT_PRIVACY=n
CONFIG_BT_EXT_ADV_MAX_ADV_SET=1

CONFIG_BT_GATT_CLIENT=y

CONFIG_BT_SETTINGS=y

CONFIG_HEAP_MEM_POOL_SIZE=1024

CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=y


# RTT Log Enanble
CONFIG_LOG=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_LOG_BUFFER_SIZE=4096
CONFIG_RTT_CONSOLE=y
CONFIG_PRINTK=y

Direct Advertiser logs

*** Booting Zephyr OS build v2.7.0-ncs1  ***
11-directed_adv init
[00:00:01.327,239] <inf> fs_nvs: 6 Sectors of 4096 bytes
[00:00:01.327,270] <inf> fs_nvs: alloc wra: 0, f70
[00:00:01.327,270] <inf> fs_nvs: data wra: 0, 118
[00:00:01.327,392] <inf> sdc_hci_driver: SoftDevice Controller build revision: 
                                         df c0 4e d6 1f 7c 66 09  0a f5 2b a0 98 f2 43 64 |..N..|f. ..+...Cd
                                         62 c5 a6 2a                                      |b..*             
[00:00:01.330,413] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:01.330,413] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:01.330,413] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 223.20160 Build 1719410646
[00:00:01.330,718] <inf> bt_hci_core: No ID address. App must call settings_load()
Bluetooth initialized
[00:00:01.330,902] <err> settings: set-value failure. key: bt/keys/e394a91ee9ef1 error(-2)
[00:00:01.331,634] <inf> bt_hci_core: Identity: F2:A4:36:CA:06:73 (random)
[00:00:01.331,634] <inf> bt_hci_core: HCI: version 5.2 (0x0b) revision 0x12b0, manufacturer 0x0059
[00:00:01.331,634] <inf> bt_hci_core: LMP: version 5.2 (0x0b) subver 0x12b0
Directed B2B Advertising Started addr: C7:45:56:34:0F:F0 (random)

BLE Tool

  • Thanks for your reply Torbjørn.

    Let's see if we can find some common ground for a solution. I need to set a directed advertising with a timeout.

    1. First implmentation. I use bt_le_ext_adv_start. That function allows to specify an advertising timeout using bt_le_ext_adv_start_param:

    int bt_le_ext_adv_start(struct bt_le_ext_adv *adv,
    			struct bt_le_ext_adv_start_param *param)

    However, it seems that it is not possible to discern at the scanner side if an extended advertisement is directed or not. Is that correct?

    2. Second implementation. Using the standard advertising function bt_le_adv_start. However, that function does not define any configuration for specifying an advertising timeout:

    int bt_le_adv_start(const struct bt_le_adv_param *param,
    		    const struct bt_data *ad, size_t ad_len,
    		    const struct bt_data *sd, size_t sd_len)

    Is it possible to implement a standard directed advertising with a timeout?

    Thanks

  • Hi Torbjørn,

    I finally got it to work. A couple of comments for others to come.

    1. Two config parameters were missing on my prj.conf:

    CONFIG_BT_EXT_ADV=y
    CONFIG_BT_SCAN_WITH_IDENTITY=y

    2. Standard or extended directed advertisments can be filter using the advertising PDU properties:

    if(device_info->recv_info->adv_props & BT_GAP_ADV_PROP_DIRECTED)

    Torbjørn if you confirm this is correct, I will verify this answer.

    Thanks for your help!

  • Hi Armand

    I am happy to hear you figured it out Slight smile

    The check of the adv_props field looks correct, yes. This should filter out directed advertise packets, regardless of whether or not extended advertising is used. 

    Best regards
    Torbjørn

  • Many thanks for your help!

Related