nRF54L15 BLE advertising not seen in mobile apps

[jLYV3r]

Hey there!

I am facing a very frustrating issue, where my nRF54L15 (custom board) BLE peripheral  just won't appear in mobile apps.

For example, right now I am trying to set up the MCUmgr via BLE and I have everything configured but neither iOS nor Android
will show the device, be it with the nRF Connect or the Device Manager apps. Also other thirdparty BLE dev apps don't work.

When scanning with the nRF BLE Sniffer on a Mac, the peripheral instantly shows up perfectly fine. The package seems to be structured
right and at this point I don't know what else to do... I know that it can't be the hardware itself because (1) Sniffing shows valid packets going through the air, and (2) in an earlier stage, I was able to see ADVs perfectly fine with the exact same hardware, sadly I can't restore that exact code.

Below is the advertising packet in code and after that the raw bytes captured by Wireshark using the BLE sniffer.

struct bt_le_adv_param param =
    BT_LE_ADV_PARAM_INIT(BT_LE_ADV_OPT_CONN, BT_GAP_ADV_FAST_INT_MIN_2,
                         BT_GAP_ADV_FAST_INT_MAX_2, NULL);

static const struct bt_data ad[] = {
    BT_DATA_BYTES(BT_DATA_FLAGS, (BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)),
    BT_DATA_BYTES(BT_DATA_UUID128_ALL, SMP_BT_SVC_UUID_VAL),
};

static const struct bt_data sd[] = {
    BT_DATA(BT_DATA_NAME_COMPLETE, CONFIG_BT_DEVICE_NAME,
            sizeof(CONFIG_BT_DEVICE_NAME) - 1),
};

The LE link layer bytes.

0000   d6 be 89 8e 40 1b 2c a4 7c 6c 79 e1 02 01 06 11   ....@.,.|ly.....
0010   07 84 aa 60 74 52 8a 8b 86 d3 4c b7 1d 1d dc 53   ...`tR....L....S
0020   8d 11 d2 67                                       ...g

Is anyone facing a similar experience?

[Nishant Gaurav]

Hi, jLYV3r

Try temporarily removing the scan response (sd) entirely and see if the device appears in mobile apps with just the advertising packet.

To remove the scan response, simply pass NULL and 0 for the scan response parameters in bt_le_adv_start().

err = bt_le_adv_start(&param, ad, ARRAY_SIZE(ad), NULL, 0);
if (err) {
LOG_ERR("Advertising failed to start (err %d)", err);
return;
}

By passing NULL instead of sd and 0 instead of ARRAY_SIZE(sd), no scan response packet will be sent. This was confirmed to produce a valid ADV_NONCONN_IND (or connectable, depending on your params) advertising packet visible in Wireshark. [Non-connectable advertising]

Since your param uses BT_LE_ADV_OPT_CONN, the device will still advertise as connectable — just without the scan response. If mobile apps can now see the device, it confirms the issue is in your sd array (likely the sizeof(CONFIG_BT_DEVICE_NAME) length problem discussed earlier).

thanks & regards

Nishant

[jLYV3r]

Hi Nishant,

thanks for your quick response. I was able to sort it out - it wasn't a problem with the scan response.

I built the Zephyr Beacon sample for the BL54L15u DVK, and see there, it popped up immediately. So I was sure that it had to be something within the default DTS/Kconfigs, comparing the DTS I saw that the BL54L15u DVK has explicitly set;

&lfxo {
	load-capacitors = "internal";
	load-capacitance-femtofarad = <15500>;
};

&hfxo {
	load-capacitors = "internal";
	load-capacitance-femtofarad = <15000>;
};

I did not have these explicit values set; after applying this in my case, the ADV was immediately picked up by the nRF Connect app on Android, so I guess this solves my problem - still have to do some research on why that is ;) My guess is that this messes up some timings, which results in Android/iOS dropping the packets, but it still is weird, as I was able to connect and communicate between nRFs perfectly fine...