Using the new Connection State module to decide role

[Chris]

I'm developing an application supporting concurrent central and peripheral connections and using the new Connection State module in SDK 10 to decide whether a BLE stack event should be handled by the central or peripheral event handler.

My ble_evt_dispatch() function is based closely on the Nordic ble_app_hrs_rscs_relay example, i.e.:

static void ble_evt_dispatch(ble_evt_t *p_ble_evt)
{
    uint16_t conn_handle;
    uint16_t role;

    ble_conn_state_on_ble_evt(p_ble_evt);   // Must be called before any event handler that uses conn state module

    // The connection handle should really be retrievable for any event type.
    conn_handle = p_ble_evt->evt.gap_evt.conn_handle;
    role = ble_conn_state_role(conn_handle);

    if (role == BLE_GAP_ROLE_PERIPH)
    {   
        on_ble_peripheral_evt();
        ...
    }
    else if (role == BLE_GAP_ROLE_CENTRAL)
    {
        on_ble_central_evt();
        ...
    }
}

This worked fine until I had a scan timeout and discovered that the BLE_GAP_EVT_TIMEOUT handler in my on_ble_central_evt() was not getting called. On investigation I found that ble_conn_state_role() is returning BLE_GAP_ROLE_INVALID on a scan timeout because there is no connection so conn_handle is not set.

The ble_app_hrs_rscs_relay example has a BLE_GAP_EVT_TIMEOUT case in its on_ble_central_evt() function, but I wonder if this can ever get called. Shouldn't the ble_evt_dispatch() function include an explicit check for role == BLE_GAP_ROLE_INVALID in which it call functions to handle connectionless events such as BLE_GAP_EVT_TIMEOUT, or have I misunderstood how to use the ble_conn_state_role() function?

[Eric Stutzenberger]

Hmm. I wonder if this is invalid operation by the SDK. BLE_GAP_EVT_TIMEOUT occurs for both Scanning timeout and Advertising timeout. However, in your case, I am not sure how the code is supposed to determine if BLE_GAP_EVT_TIMEOUT comes from a scanning timeout or from an Advertising timeout. If your peripheral advertising never times out, then you could work on the assumption that the timeout is always from scanning and never from advertising. Then you could handle it as a special case. My guess is that there is someway of determining that the timeout is from the central that doesn't depend on the role function since, as you said, this event is always a connectionless event.