RF noise connection issues between two NRF54L15

[nikeub]

Hello,

We are observing intermittent connection failures when using two nRF54L15 DK boards. Occasionally the connection fails with the warning:

<warn> bt_conn: conn 0x20015708 failed to establish. RF noise?

We first observed this in our channel sounding application and initially suspected it was related to our implementation. However, after further investigation we were able to reproduce the same behavior using the standard Zephyr central and peripheral samples in NCS 3.2.3. It occurs less frequently in this setup, but still appears roughly 1 in 100 connection attempts.

Setup

Two nRF54L15 DKs on a desk
Distance < 0.5 m
SDK: nRF Connect SDK 3.2.3

Reproduction
samples/bluetooth/central and samples/bluetooth/peripheral, but modified so the central only connects to specific peripheral address and the peripheral so it restarts advertisement after disconnect.

Central sample modification

// prj.conf
CONFIG_LOG=y
CONFIG_LOG_DEFAULT_LEVEL=3

// main.c
static const bt_addr_le_t target_addr = {
    .type = BT_ADDR_LE_RANDOM,
    .a = {{0x41, 0x21, 0xC2, 0xFC, 0x8C, 0xD8}}
};

if (bt_addr_le_cmp(addr, &target_addr) != 0) {
    return;
}

Peripheral sample modification

// prj.conf
CONFIG_BT_PRIVACY=y

// main.c
static struct k_work adv_restart_work;

static void adv_restart_work_handler(struct k_work *work)
{
    int err;
    err = bt_le_adv_start(BT_LE_ADV_CONN_FAST_1, ad, ARRAY_SIZE(ad), sd, ARRAY_SIZE(sd));
    if (err) {
        printk("Advertising failed to restart (err %d)\n", err);
    } else {
        printk("Advertising restarted\n");
    }
}

static void disconnected(struct bt_conn *conn, uint8_t reason)
{
    printk("Disconnected, reason 0x%02x %s\n", reason, bt_hci_err_to_str(reason));
    k_work_submit(&adv_restart_work);
}

Is this a known issue or errata with the nRF54L15 DK or the current Bluetooth controller/stack in NCS 3.2.3?

We have not observed this behavior previously with other Nordic boards such as the nRF52840.

[Menon]

Hello,

Yes, this behavior is consistent with a collision scenario where the advertiser receives both a SCAN_REQ and a CONNECT_IND within the same receive window. Since the device cannot process both simultaneously, one of the procedures may be disrupted, leading to a failed connection attempt.

Configuring the advertiser as non-scannable removes SCAN_REQ packets from the equation, which avoids this overlap and improves connection reliability.

With extended advertising, this situation is addressed differently: scannable and connectable roles are separated, and the connection procedure includes an acknowledgment (AUX_CONNECT_RSP), allowing the central to determine whether the connection request was successfully received.

If extended advertising is not used, a similar effect can be achieved at the application level by leveraging QoS feedback after connection events. By monitoring whether packets are successfully received in the first few events, the application can decide to terminate and retry the connection earlier, rather than waiting for the controller’s default timeout.

Kind Regards,

Abhijith