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]

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 ?

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