SDK/Toolchain:
- nRF Connect SDK version:
[ v3.3.0 ] - Board: Custom board based on nRF54L15 (cpuapp core)
- Role: Central (continuous passive scanning + initiating connections to discovered peripherals), also acts as Peripheral (multirole)
Summary:
We run continuous passive scanning with scan_interval = 36 (22.5 ms) while also initiating new connections to discovered peripherals. We tested several scan-window values on this interval:
| scan.window (ticks, 0.625 ms units) | window (ms) | idle gap (ms) | Result |
|---|---|---|---|
| 32 | 20.000 | 2.500 | Works normally |
| 33 | 20.625 | 1.875 | Discovery becomes extremely slow; connection attempts to new peripherals consistently time out |
We independently arrived at window=33 via four different percentage inputs (92%, 93%, 94%, 95% of the 22.5 ms interval) — all four round to the identical 33-tick window through our percentage→ms→tick conversion, and all four reproduce the identical failure, confirming the behavior is tied to the absolute tick values, not the percentage.
Reproduction:static struct bt_le_scan_param scan_param = {
.type = BT_LE_SCAN_TYPE_PASSIVE,
.interval = 36, /* 22.5 ms */
.window = 33, /* 20.625 ms -- fails */
/* .window = 32 -- 20.000 ms -- works */
.timeout = 0,
};
bt_le_scan_start(&scan_param, NULL);
/* concurrently, on discovering a target peripheral: */
bt_conn_le_create(peer_addr, &create_param, &conn_param, &conn);
Observed logs:[00:03:31.362,559] <wrn> bt_hci_core: Connection creation timeout triggered
[00:04:19.219,706] <err> bt_att: ATT channel not connected
[00:07:29.333,660] <err> bt_att: ATT Timeout for device EA:82:E1:83:8D:B3 (random). Disconnecting...
[00:07:46.095,420] <err> bt_att: ATT channel not connected
[00:07:46.095,604] <err> bt_att: ATT channel not connected
This same scan/connect logic does not show the problem on our nRF52840-based boards even at tighter ratios.
Question:
- What could cause scanning and connection-initiation to become unreliable when the idle time between scan windows drops from 2.5 ms to 1.875 ms on nRF54L15? Is there a scheduling constraint in the controller that this might be hitting?
- Is there a recommended minimum idle time (or minimum gap between scan window and scan interval) for reliable scanning and connection initiation on nRF54L15?
- Would the same idle-time constraint apply to nRF52/nRF53 devices or is this specific to nRF54L15?
