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

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

Edvin — Thu, 16 Aug 2018 11:58:58 GMT

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

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

John_Doe — Thu, 16 Aug 2018 09:24:06 GMT

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.

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

Edvin — Thu, 16 Aug 2018 08:38:06 GMT

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