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

[Michal]

Great to hear you were able to reproduce it ! Marius is on a vacation right now but I will be able to speak in his name. Would be nice if this can be fixed, right now we hade to remove all WRITE_REQ from code.

[Hung Bui]

Hi Michal, 

Further investigation showed that it's one of the bug that we had found and fixed in S132 v6.0.0

It's described in the release note of S132 v6.0.0 as: 

Fixed an issue where the SoftDevice could drop a write request if it was received at the same time as a write command (DRGN-9709).

Is it possible for you to upgrade the softdevice to v6.0.0 or newer ? I think it's the best option, otherwise we would need to look into how we can avoid the corner case when the softdevice drop the write request on the server side. 

[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 ?