BLE_GATTC_EVT_TIMEOUT: Possible causes?

[Marius Heil]

Hello,

I am still having troubles with the BLE_GATTC_EVT_TIMEOUT. The problem is that the error is not happening frequently and is hard to reproduce. It is also hard to attach a sniffer to each connection (and the nRF sniffer doesn't even work reliably) Here is what I have:

• Scatternet of 8 Beacons running as concurrent central and peripheral
• I send Write Requests but after a while the communication stalls for 30 seconds
• I receive a GATTC timeout

I do have one beacon that will produce a similar fault very realiable. All Beacons are nRF51 Dongles of newer age with the S130 v2. It will connect to other beacons, the exchange a few packets, but then the link only sends empty PDUs. (THIS MIGHT NOT BE THE SAME FAULT)

Is this a fault that I could potentially have made in my code? It looks like the Acknowledgement is never sent, but how could I possible interfer in this process with my code? Isn't this the SoftDevice's fault? Is it possible that I can decide to not acknowledge a write or to block it? Why is packet 155 an empty PDU, why is it not acknowledged directly?

Marius

[Marius Heil]

Hi, i uploaded it here:

www112.zippyshare.com/.../file.html

The slave did not crash, there was no hardfault or anything. I had my UART logger open. The slave ran into a handshake timeout (the packets you are seeing are my custom handshake) and then it continued to connect to other devices with the same result.

Interesting, why are 154 and 155 in the same event if only an empty PDU is sent? I use one handle for communication purpose. Whatever is written to this handle is used as a kind of serial-data transfer. It will trigger a handler on the node that will process the message.