Ble_Central connect to periphral spend a long time

[Irving.Li]

Dear Nordic

I use nRF5 SDK BLE_Central / uart to connect our custom peripherals by address, and I found that it seem need to 4~5 seconds to finish connecting 

Here is the log. Is there any way to improve the connection speed?

Thanks

 [00:00:05.637,329] <debug> ble_scan: Connecting
 
 [00:00:05.637,329] <debug> ble_scan: Connection status: 0
 
 [00:00:06.145,446] <debug> nrf_ble_gatt: Updating data length to 251 on connection 0x0.
 
 [00:00:06.145,507] <info> app: Connecting to target E11xxxxxxx
 
 [00:00:06.145,568] <debug> nrf_ble_gq: Registering connection handle: 0x0000
 
 [00:00:06.145,629] <debug> app: conn set to 4dBm successfully
 
 [00:00:06.326,904] <debug> nrf_ble_gatt: Data length updated to 27 on connection 0x0.
 
 [00:00:06.326,904] <debug> nrf_ble_gatt: max_rx_octets: 27
 
 [00:00:06.326,904] <debug> nrf_ble_gatt: max_tx_octets: 27
 
 [00:00:06.326,904] <debug> nrf_ble_gatt: max_rx_time: 328
 
 [00:00:06.326,965] <debug> nrf_ble_gatt: max_tx_time: 328
 
 [00:00:07.345,642] <debug> app: Requesting to update ATT MTU to 247 bytes on connection 0x0.
 
 [00:00:07.586,975] <debug> nrf_ble_gatt: ATT MTU updated to 247 bytes on connection 0x0 (response).
 
 [00:00:07.586,975] <info> app: ATT MTU exchange completed.
 
 [00:00:07.586,975] <info> app: Ble NUS max data length set to 0xF4(244)
 
 [00:00:07.586,975] <debug> nrf_ble_gq: Processing the request queue...
 
 [00:00:07.845,825] <debug> ble_db_disc: Starting discovery of service with UUID 0xAE30 on connection handle 0x0.
 
 [00:00:07.845,825] <debug> nrf_ble_gq: Adding item to the request queue
 
 [00:00:07.845,825] <debug> nrf_ble_gq: GATTC Primary Services Discovery Request
 
 [00:00:07.845,886] <debug> nrf_ble_gq: SD GATT procedure (2) succeeded on connection handle: 0.
 
 [00:00:08.846,984] <debug> ble_db_disc: Found service UUID 0xAE30.
 
 [00:00:08.846,984] <debug> nrf_ble_gq: Adding item to the request queue
 
 [00:00:08.846,984] <debug> nrf_ble_gq: GATTC Characteristic Discovery Request
 
 [00:00:08.847,045] <debug> nrf_ble_gq: SD GATT procedure (3) succeeded on connection handle: 0.
 
 [00:00:08.847,045] <debug> nrf_ble_gq: Processing the request queue...
 
 [00:00:08.967,773] <debug> nrf_ble_gq: Adding item to the request queue
 
 [00:00:08.967,773] <debug> nrf_ble_gq: GATTC Characteristic Descriptor Request
 
 [00:00:08.967,834] <debug> nrf_ble_gq: SD GATT procedure (4) succeeded on connection handle: 0.
 
 [00:00:08.967,834] <debug> nrf_ble_gq: Processing the request queue...
 
 [00:00:09.086,975] <debug> nrf_ble_gq: Adding item to the request queue
 
 [00:00:09.086,975] <debug> nrf_ble_gq: GATTC Characteristic Descriptor Request
 
 [00:00:09.087,036] <debug> nrf_ble_gq: SD GATT procedure (4) succeeded on connection handle: 0.
 
 [00:00:09.087,036] <debug> nrf_ble_gq: Processing the request queue...
 
 [00:00:09.206,970] <debug> nrf_ble_gq: Adding item to the request queue
 
 [00:00:09.207,031] <debug> nrf_ble_gq: GATTC Characteristic Descriptor Request
 
 [00:00:09.207,031] <debug> nrf_ble_gq: SD GATT procedure (4) succeeded on connection handle: 0.
 
 [00:00:09.207,092] <debug> nrf_ble_gq: Processing the request queue...
 
 [00:00:09.326,965] <debug> ble_db_disc: Discovery of service with UUID 0xAE30 completed with success on connection handle 0x0.
 
 [00:00:09.327,026] <info> app: Discovery complete.
 
 [00:00:09.327,026] <debug> nrf_ble_gq: Adding item to the request queue
 
 [00:00:09.327,026] <debug> nrf_ble_gq: GATTC Write Request
 
 [00:00:09.327,087] <debug> nrf_ble_gq: SD GATT procedure (1) succeeded on connection handle: 0.
 
 [00:00:09.327,087] <debug> nrf_ble_gq: Adding item to the request queue
 
 [00:00:09.327,148] <debug> nrf_ble_gq: GATTC Write Request
 
 [00:00:09.327,148] <debug> nrf_ble_gq: SD is currently busy. The GATT request procedure will be attempted                       again later.
 
 [00:00:09.327,148] <debug> nrf_ble_gq: Pointer to allocated memory block: 0x20009798.
 
 [00:00:09.327,148] <debug> nrf_ble_gq: Processing the request queue...
 
 [00:00:09.327,209] <debug> nrf_ble_gq: GATTC Write Request
 
 [00:00:09.327,209] <debug> nrf_ble_gq: SD is currently busy. The GATT request procedure will be attempted                           again later.
 
 [00:00:09.327,209] <info> app: Connected to device with Nordic UART Service.
 
 [00:00:09.327,514] <debug> nrf_ble_gq: Processing the request queue...
 
 [00:00:09.327,514] <debug> nrf_ble_gq: GATTC Write Request
 
 [00:00:09.327,514] <debug> nrf_ble_gq: SD is currently busy. The GATT request procedure will be attempted                           again later.
 
 [00:00:09.327,575] <debug> nrf_ble_gq: Processing the request queue...
 
 [00:00:09.327,575] <debug> nrf_ble_gq: GATTC Write Request
 
 [00:00:09.327,575] <debug> nrf_ble_gq: Pointer to freed memory block: 0x20009798.
 
 [00:00:09.327,575] <debug> nrf_ble_gq: SD GATT procedure (1) succeeded on connection handle: 0.
 
 [00:00:09.327,575] <debug> nrf_ble_gq: Processing the request queue...

[Jakob Ruhe]

That is a bit slow indeed. It is a bit hard to tell why it is this slow without seeing any source code. Are you sure that you do not have any delays in the applications? Is there an SD card involved here or what is it about? 

That said. One thing that can make the initial negotiation slow, is if the Connection Interval is too high. So one idea is to first check the min/max interval you give the to the controller and then also log the Connection Interval chosen by the controller. The function bt_conn_get_info()() can be used to check this after the connection is up.

[Irving.Li]

Hello 

In Central, MIN_CONNECTION_INTERVAL is 7.5*1.25ms, MAX_CONNECTION_INTERVAL is 60*1.25ms

Does the connection interval of peripherals need to be the same as that of central?

About the function bt_conn_get_info()  , It seems that there is no such function in nrf5 SDK.

[Jakob Ruhe]

Sounds fine. I did not read that you are using nRF SDK 5. The function I mentioned is part of Zephyr and nRF Connect SDK.

For several reasons it probably makes sense to upgrade to and use the newer SDK. This is what Nordic recommends for new projects.

The central decides which Connection interval that should be used for the connection. The peripheral can suggest another interval later. In your case this might be what is happening, but even more likely it is something that your application is doing that takes time. But again, very hard to guess.