https://devzone.nordicsemi.com/f/nordic-q-a/99516/sd_ble_gap_connect-times-out-but-ble_gap_evt_timeout-never-firesIm on an nRF52832, on SDK16.0. I&#39;ve recently discovered that not setting a timeout for sd_ble_gap_connect means the connection attempt cannot be gracefully cancelled. So as the next best available solution, I&#39;ve been testing using the timeout. I noticeden-USTelligent Community 13Mon, 08 May 2023 21:43:15 GMThttps://devzone.nordicsemi.com/thread/424382?ContentTypeID=1Mon, 08 May 2023 21:43:15 GMT137ad170-7792-4731-bb38-c0d22fbe4515:29a04440-435a-41b7-b802-935a10117268tmuir_pct<p>It turns out that I was filtering events by connection state role before checking for the actual events.&nbsp; Since there is no connection at this time, I&#39;m neither a peripheral or a central during a connection attempt.&nbsp; Once I removed this unnecessary filter, I receive the BLE_GAP_EVT_TIMEOUT event for both scanning timeout and connection timeout.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/424379?ContentTypeID=1Mon, 08 May 2023 21:22:43 GMT137ad170-7792-4731-bb38-c0d22fbe4515:2f81014d-ca18-4f64-a8e7-dddf3ca787f0tmuir_pct<p>Correction:&nbsp; I thought I was getting into BLE_GAP_EVT_TIMEOUT&nbsp; when the source was BLE_GAP_TIMEOUT_SRC_SCAN, but I had two different codepaths creating the same log string.&nbsp; BLE_GAP_EVT_TIMEOUT&nbsp; does not get called in either case.&nbsp; I recognize that scanning has ended in NRF_BLE_SCAN_EVT_SCAN_TIMEOUT, handled in the scan event handler, not the ble gap event handler.</p><div style="clear:both;"></div>