What is the communication interval during service, characteristic and descriptor discovery?

[John_Doe]

I am using SDK 12.3.0 and S130 2.0.1.

In example ble_app_uart and ble_app_uart_c,

Central setting:

#define MIN_CONNECTION_INTERVAL     MSEC_TO_UNITS(7.5, UNIT_1_25_MS) 
#define MAX_CONNECTION_INTERVAL     MSEC_TO_UNITS(4000, UNIT_1_25_MS)
#define SLAVE_LATENCY               0 
#define SUPERVISION_TIMEOUT         MSEC_TO_UNITS(32000, UNIT_10_MS)

Peripheral setting:

#define MIN_CONNECTION_INTERVAL     MSEC_TO_UNITS(20, UNIT_1_25_MS) 
#define MAX_CONNECTION_INTERVAL     MSEC_TO_UNITS(75, UNIT_1_25_MS)
#define SLAVE_LATENCY               0 
#define SUPERVISION_TIMEOUT         MSEC_TO_UNITS(32000, UNIT_10_MS)

Why it took so long to discover service, characteristic and descriptor?

After connection establishment, the connection interval should be 75ms. But it looks like central and peripheral using 4000ms as connection interval for db discovery and then the connection interval is 75ms after db discovery.

[Edvin]

Hello,

It is always the central that decides the connection interval. The peripheral can request changes, but it is the central that has the final saying. The only thing the peripheral can do if it does not get the desired connection parameters, is disconnect.

The softdevice will, when given a max and min conn_interval, always use the MAX, since it is the most power efficient, so thus, the 4s connection interval is used in this case.

The peripheral will try to negotiate after a certain amount of time, FIRST_CONN_PARAMS_UPDATE_DELAY, which is typically set to 5 seconds. You can try to shorten this. The important thing is that this must be called after service discovery, and hence the delay is often set to 5 seconds.

The central will in this case accept the new connection parameters, since the desired value is within the MIN-MAX range.

 

Best regards,

Edvin

[John_Doe]

Hello Edvin,

What do you mean by "this must be called after service discovery"? After BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP or BLE_GATTC_EVT_DESC_DISC_RSP??

From ble_db_discovery.c in central,

    switch (p_ble_evt->header.evt_id)
    {
        case BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP:
            on_primary_srv_discovery_rsp(p_db_discovery, &(p_ble_evt->evt.gattc_evt));
            break;

        case BLE_GATTC_EVT_CHAR_DISC_RSP:
            on_characteristic_discovery_rsp(p_db_discovery, &(p_ble_evt->evt.gattc_evt));
            break;

        case BLE_GATTC_EVT_DESC_DISC_RSP:
            on_descriptor_discovery_rsp(p_db_discovery, &(p_ble_evt->evt.gattc_evt));
            break;

        case BLE_GAP_EVT_DISCONNECTED:
            on_disconnected(p_db_discovery, &(p_ble_evt->evt.gap_evt));
            break;

        default:
            break;
    }

Here is some questions,

When would FIRST_CONN_PARAMS_UPDATE_DELAY start to count down?

Does peripheral start "connection parameters negotiation" request in this uart example automatically when the countdown is finished or I need to  use ble_conn_params_change_conn_params function to start the negotiation request?

What is the use of NEXT_CONN_PARAMS_UPDATE_DELAY? 

What would happen if peripheral sent "connection parameters negotiation" request before service discovery task is completed.

Most of the time it is central (client) to do service discovery task. So, does peripheral (server) know when would service discovery task is completed?

Sorry for so many questions.

[Edvin]

1. FIRST_CONN_PARAMS_UPDATE_DELAY starts to count down from the BLE_GAP_EVT_CONNECTED event.

2. It starts automatically. You can see it in ble_conn_params.c.

3. If the negotiation fails, and is rejected, it starts a new timer with NEXT_CONN_PARAMS_UPDATE_DELAY.

4. Sorry. My bad. I heard that once, but it looks like it is not recommended to do so, because typically, phones connect with a short connection interval, and since you want to do the service discovery quick, it was not recommended to change to a longer connection interval before this was finished. You can negotiate at once, if you like. You can see the connection parameters in the BLE_GAP_EVT_CONNECTED event:

case BLE_GAP_EVT_CONNECTED:
NRF_LOG_INFO("conn_int = 0x%x", p_ble_evt->evt.gap_evt.params.connected.conn_params.min_conn_interval;

it doesn't matter whether you check min_conn_interval or max_conn_interval. They have the same value in this event.

 

Best regards,

Edvin