BLE_GATTC_EVT_TIMEOUT is caused in master(client) during communicate randomly.

[Taoo]

In my situation, I want to use ble to designed a piconet which has 1 master and up to 4 slave.(upload(Slave->Master) rate is 2.2KB/s,download(Master->Slave) rate is 500+B/s).

Master :designed by myself,use:nrf52832+SDK16.0.0.

Slave: module bought from other company,use:52810.

more info of my situation,https://devzone.nordicsemi.com/f/nordic-q-a/60872/ble_nus_c-how-to-send-pkt-from-client-to-service-with-efficient-and-reliable

In the master,I will send several packets to each slave used WRITE_REQ and WRITE_CMD,per second.It could work.But in the master,it detected  BLE_GATTC_EVT_TIMEOUT randomly(maybe per tens of minutes or longer),further caught calling sd_ble_gap_disconnect,and slave will reconnected quickly.Obviously,when it happened,it caught some packets lost.

I confuse:why there appear  BLE_GATTC_EVT_TIMEOUT randomly?how to fix it out?I had search in devzone,and know BLE_GATTC_EVT_TIMEOUT is appered when no response from peer,Is that mean it caught by slave bug?

some param i set in master:

MIN_CONNECTION_INTERVAL:30;

MAX_CONNECTION_INTERVAL:50

SLAVE_LATENCY:2

SUPERVISION_TIMEOUT:4000;

BLE_GAP_PHYS:BLE_GAP_PHY_2MBPS;

NRF_SDH_BLE_GATT_MAX_MTU_SIZE:247;

NRF_SDH_BLE_GAP_EVENT_LENGTH:40;

Hope for yours replies!

 

[haakonsh]

A BLE_GATTC_EVT_TIMEOUT means that the peer did not respond to a request in time. Usually, this is a read/write request or similar. 

I suggest you get some logs from each device.

[Taoo]

Thanks for your reply. 

As i say above, slave is not designed by me.It not easily for me to get log.But this slave module had used in another product,connected with mobile phone,upload data to mobile phone point to point,receive serveral pkt from phone.

So i guess wheather the params for GAP cause this bug.The params i set is try to make larger throughput,longer distance,with 4 slave piconet.

 Here is the rtt log in master,when peer going to disconnect.

reason:0x16

00> 
<00> debug> app: 2 rssi change -62 dbm, ch_index:34
00> 
00> 
<00> debug> nrf_ble_gq: Adding item to the request queue of conn:2
00> 
<00> debug> nrf_ble_gq: request_process GATTC Write cmd 11 bytes to conn:2
00> 
<00> debug> nrf_ble_gq: SD GATT procedure (1) succeeded on connection handle: 2.
00> 
<00> debug> nrf_ble_gq: Adding item to the request queue of conn:2
00> 
<00> debug> nrf_ble_gq: request_process GATTC Write cmd 21 bytes to conn:2
00> 
<00> debug> nrf_ble_gq: SD GATT procedure (1) succeeded on connection handle: 2.
00> 
<00> debug> nrf_ble_gq: Adding item to the request queue of conn:2
00> 
<00> debug> nrf_ble_gq: request_process GATTC Write cmd 21 bytes to conn:2
00> 
<00> debug> nrf_ble_gq: SD GATT procedure (1) succeeded on connection handle: 2.
00> 
<00> debug> app: GATT client 2 timeout.

<00> debug> app: 2 rssi change -48 dbm, ch_index:20
00> 
00> 
<00> debug> ble_db_disc: ble_db_discovery_on_ble_evt conn 2 disconnect.
00> 
<00> debug> ble_db_disc: ble_db_discovery_on_ble_evt conn 2 disconnect.
00> 
<00> debug> ble_db_disc: ble_db_discovery_on_ble_evt conn 2 disconnect.
00> 
<00> debug> ble_db_disc: ble_db_discovery_on_ble_evt conn 2 disconnect.
00> 
<00> debug> ble_db_disc: ble_db_discovery_on_ble_evt conn 2 disconnect.
00> 
<00> debug> ble_nus_c: ble_nus_c_on_ble_evt conn 2 disconnect.
00> 
<00> info> app: NUS central link 0x2 disconnected (reason: 0x16)

[haakonsh]

This is a GATT Client timeout, it is not a GAP issue. The 52810 should have enough processing power to handle any BLE activity, so I doubt that changing the GAP parameters will do anything, but it might. 

I suggest you get in touch with whoever makes the peripheral and ask them what their application is doing, or why they would not be able to service a write request.