Error 8 (0x8): GATT CONN TIMEOUT

RE: Error 8 (0x8): GATT CONN TIMEOUT

Einar Thorsrud — Mon, 06 May 2019 06:32:46 GMT

Hi,

You can find the disconnect reason when you get the BLE_GAP_EVT_DISCONNECTED event. For instance, it is done like this in the ble_app_hrs example in SDK 15.3:

        case BLE_GAP_EVT_DISCONNECTED:
            NRF_LOG_INFO("Disconnected, reason %d.",
                          p_ble_evt->evt.gap_evt.params.disconnected.reason);

RE: Error 8 (0x8): GATT CONN TIMEOUT

mbards — Fri, 03 May 2019 16:45:35 GMT

So I dropped the interval really low following your advice and that seemed to work. Thank you.

#define MIN_CONN_INTERVAL MSEC_TO_UNITS(50, UNIT_1_25_MS)  /**< Minimum acceptable connection interval (0.5 seconds) */
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(100, UNIT_1_25_MS) /**< Maximum acceptable connection interval (1 second). */
#define SLAVE_LATENCY 0                                     /**< Slave latency. */
#define CONN_SUP_TIMEOUT MSEC_TO_UNITS(4000, UNIT_10_MS)    /**< Connection supervisory timeout (4 seconds). */

I'm very curious, what's the best way to go about finding the disconnect reason on the nRF? Is there some sort of useful context information I could pass on through

NRF_SDH_BLE_OBSERVER(m_ble_observer, APP_BLE_OBSERVER_PRIO, ble_evt_handler, **useful context struct here**)

when I initialise the ble event handler?

RE: Error 8 (0x8): GATT CONN TIMEOUT

Einar Thorsrud — Fri, 03 May 2019 09:27:44 GMT

Hi,

Would it be possible to add a bit more logging on the nRF side? It would be interesting to know the disconnect reason on the nRF, though I assume it is timeout there as well (8). It would also be interesting to know why the nRF seemingly start to advertise before the disconnected event, or if there is something odd with the logging.

If we assume that there is a timeout on both sides, this is typically caused by a few things:

Packet loss on air due to low RSSI or much noise or interference.
- This can be handled by increasing the number of retransmissions, which is achieved by increasing the supervision timeout (making it larger relative to the connection interval).
- You should also avoid slave latency, or at least ensure that you still have a good margin if it is used.
- Note that the central decides the connection parameters, so what you have configured may not be what is actually used. Do you have a sniffer trace that shows the actual connection parameters of the link?
Clock drift between the peers, making the event windows non-overlapping. This should not happen as the clock accuracy is exchanged when the connection is established, and it is accounted for. However, you sometimes see connections issues if the nRF has a bad clock source.
- This could typically be a crystal with wrong load capacitor values,
- or using the internal RC oscillator but configuring the SoftDevice to indicate a high accuracy.