Still trouble with BLE_GATTC_EVT_TIMEOUT

[Marius Heil]

Hello,

I was having a lot of trouble with BLE_GATTC_EVT_TIMEOUT on the nRF51 and softdevice v2. But now I continue to have the same problems on an nRF52 with Softdevice v5.1.0. Below is a short description of what I am doing:

- Forming a scatternet of multiple nodes as a spanning tree using https://github.com/mwaylabs/fruitymesh/

- Sending data through this network with both WRITE_REQ and WRITE_CMD

- All network participants are the same nRF52 chipset with S132 5.1.0

=> When I send a larger numbe rof WRITE_REQ, some of my nodes will randomly run into the BLE_GATTC_EVT_TIMEOUT. This does not happen when I only send WRITE_CMD.

This seems to be a Softdevice Bug and I now reverted and went back to using WRITE_CMD, but this is not a solution. I have used WRITE_CMD for a long time now to mitigate the issue, but I thought this would have been fixed in the latest Softdevice.

See here my old questions about the same issue:

https://devzone.nordicsemi.com/f/nordic-q-a/19878/ble_gattc_evt_timeout-possible-causes/77361#77361

https://devzone.nordicsemi.com/f/nordic-q-a/11142/connection-stability-with-s130/41760#41760

[Hung Bui]

Hi Marius, 

I'm sorry that this old issue is remained after a long time. Could you please make a fresh sniffer trace with the new softdevice ? 

It would be the best if we can find a way to reproduce the issue here with the minimal code. 

[Marius Heil]

Hello, I will be on parental leave for some time, so I might need to do that at a later time. i was hoping that this was a known issue or that it was reproducable with the old traces. As this happens very infrequently and in my case in a network with around 70 nodes, it is very hard for me to track down. I think it should happen when setting up a device with a peripheral and 3 central connections and then sending a mixture of write_cmd and write_req from all nodes to flood the small network of 4 nodes. But I don't currently have the time to set this up.

[Michal]

Hi Hung, thank you for sharing results. Right now we cannot switch to newer softdevice. We have plans to do that in future, but I am not sure when that could be. Is there a way to avoid this situation from happening ?

[Hung Bui]

Hi Michal,

If you plan to use S132v5 we would need to make sure not all 6 buffers for write command (and/or notification) being used.

Could you analyze a worst case scenario of your fruity mesh on how many bytes and how many package need to be queued at the same time ? 

[Michal]

In worst case we have can a lot of data (> 512 bytes) that needs to be send immediately. In that case we are always trying keep all of 6 buffers full. If we decide to queue only 5 buffers then probably the throughput of our mesh will drop. Right now we are struggling to get highest possible throughput so this solution is hard to accept. Is there any other solution ?

[Hung Bui]

Hi Michal, 

In order to calculate the buffer needed, could you let me know the ATT_MTU using in your mesh ? Is it 23 or larger? 

I assume your mesh only uses WRITE_CMD, WRITE_REQ and doesn't use notification/indication ? 

[Michal]

ATT_MTU is 23 bytes. In some situations we are using notifiactions as well but mostly writes.

[Hung Bui]

Could you try to test with the following: 

- Set the NRF_SDH_BLE_GATT_MAX_MTU_SIZE to 300 (you still can use 23 byte as the preferred MTU)

- Set the configuration with sd_ble_cfg_set() with  ble_cfg.conn_cfg.params.gattc_conn_cfg.write_cmd_tx_queue_size = 1 (BLE_CONN_CFG_GATTC)

- Set the configuration with sd_ble_cfg_set() with  ble_cfg.conn_cfg.params.gatts_conn_cfg.hvn_tx_queue_size   = 1 (BLE_CONN_CFG_GATTS)

- Use a buffer counter to avoid queuing more than 6 packets at anytime. This means you keep track of the number of buffer you are using by counting the number of success queue of write command (and notification) and the number of packet sent (count)  in BLE_GATTC_EVT_WRITE_CMD_TX_COMPLETE and BLE_GATTS_EVT_HVN_TX_COMPLETE if you use notification. Delay sending if you have used all 6 packets. 

I had a quick test overnight here and it seems to work.