BLE Central connect to same device mulitple times, and client service reacts to events twice.

[shn]

I've made a project that scans and advertises. 

The first problem:
When i have one central link, I get the problem that the client service gets events twice. 

<debug> ble_db_disc: Starting discovery of service with UUID 0x180F on connection handle 0x0.
<debug> nrf_ble_gatt: ATT MTU updated to 247 bytes on connection 0x0 (response).
<debug> ble_db_disc: Found service UUID 0x180F.
<debug> ble_scan: Connecting
<debug> ble_scan: Connection status: 0
<debug> app: Filter match:
<debug> app: 143:117:224:141:81:108
<debug> ble_db_disc: Discovery of service with UUID 0x180F completed with success on connection handle 0x0.
<debug> app: Db discovery Handler
<debug> ble_bas_c: Battery Service discovered at peer.
<debug> app: Battery Service discovered. Reading battery level.
<debug> ble_bas_c: SD Read/Write API returns Success..
<debug> app: Enabling Battery Level Notification.
<debug> ble_bas_c: Configuring CCCD. CCCD Handle = 43, Connection Handle = 0
<debug> ble_bas_c: SD Read/Write API returns error. This message sending will be attempted again..
<info> app: Battery Level Read as 99 %.
<debug> ble_bas_c: SD Read/Write API returns Success..
<info> app: Battery Level Read as 99 %.

The second problem:
When i have more central links it established a connection to the same device twice.

<debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.
...
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x1.
...
etc.

I've made a filter that triggers on a certain service UUID, and a name. That works fine.

The second problem i can't seem to figure out - I thought i should be in the Peer Manager's domain, but i'm not certain.

So at what module can I make some logic to ensure that the central(device 1) doesn't connect to the same device twice.

[Vidar Berg]

Hi,

In the first problem, It looks like the read request is being sent twice. I suggest to add more logging in ble_bas_c.c::tx_buffer_process() to confirm if the read request is duplicated. Also, do you always get the "SD Read/Write API returns error. This message sending will be attempted again.." message when reading the battery characteristic? Please check the returned error code from sd_ble_gattc_read() in that case.

The scanner module will connect to anything matching the filter settings when it's initialized with ".connect_if_match" enabled. So I suggest to disable this option and instead make the decision to connect in your scanner callback. One way to do it could be to manage a RAM table with the addresses of all connected peers, then when you get the  NRF_BLE_SCAN_EVT_FILTER_MATCH you can check if the discovered device is already in the address list or not. 

[shn]

Hey,

.connect_if_match is enabled. So a good idea to do the address table - is there any example of how to implement that?

The "SD READ/WRITE API returns error." happens the very first time, on connection... The error code is 17 - So I think it's just because the central device makes requests a READ twice

[Vidar Berg]

Hi,

We don't have any examples of this that I know of, unfortunately. One of the sides (Central or peripheral) is usually limited to one connection so it's normally not a problem. The peer address is included in the adv. report event and the GAP connect event. I would maybe add the address to the table on the connect event, and remove it when it disconnects. You can use the connection handle as an index for your table. 

[shn]

Hey,

Okay - I will look into why the db_discovery handler get's called twice.
It seems to a duplication of events or calls... I will update on when i find the error. 

Then I will start creating the address table - Does the SDK have anything i should use to create this?

[shn]

Hey,

I solved the problem, my application was reacting to the event twice.

This happened by, using both:

ble_bas_c_on_ble_evt(p_ble_evt, &m_bas_c);

void event_dispatcher(ble_evt_t const* p_ble_evt, void* p_context) {
    uint16_t conn_handle = p_ble_evt->evt.gap_evt.conn_handle;  // connection handle
    uint16_t role        = ble_conn_state_role(conn_handle);    // fetch role
        
   if(role == BLE_GAP_ROLE_PERIPH || ble_evt_is_advertising_timeout(p_ble_evt)) {

        on_ble_peripheral_event(p_ble_evt);

    } else if((role == BLE_GAP_ROLE_CENTRAL) || (p_ble_evt->header.evt_id == BLE_GAP_EVT_ADV_REPORT)) {

        on_ble_central_event(p_ble_evt);
        ble_bas_c_on_ble_evt(p_ble_evt, &m_bas_c);
  
}

and

ble_bas_on_db_disc_evt(&m_bas_c, p_scan_evt);

in the db_discovery_handler.

This made the event happen simultaneously, in retrospect this makes sense. I've revmoved the first occurance.