BLE_GATTC_EVT_TIMEOUT - Holding up Scan

RE: BLE_GATTC_EVT_TIMEOUT - Holding up Scan

bjorn-spockeli — Wed, 16 Jan 2019 10:18:57 GMT

Hi Mia, I apologize for the late reply.

Yes, a BLE_GAP_EVT_TIMEOUT event with the source set to BLE_GAP_TIMEOUT_SRC_SCAN will be generated when scanning times out, see the event structure for the timeout event below.

/**@brief Event structure for @ref BLE_GAP_EVT_TIMEOUT. */
typedef struct
{
  uint8_t src;                                  /**< Source of timeout event, see @ref BLE_GAP_TIMEOUT_SOURCES. */
  union
  {
    ble_data_t adv_report_buffer;               /**< If source is set to @ref BLE_GAP_TIMEOUT_SRC_SCAN, the released
                                                     scan buffer is contained in this field. */
  } params;                                     /**< Event Parameters. */
} ble_gap_evt_timeout_t;

/**@defgroup BLE_GAP_TIMEOUT_SOURCES GAP Timeout sources
 * @{ */
#define BLE_GAP_TIMEOUT_SRC_SCAN                       0x01 /**< Scanning timeout. */
#define BLE_GAP_TIMEOUT_SRC_CONN                       0x02 /**< Connection timeout. */
#define BLE_GAP_TIMEOUT_SRC_AUTH_PAYLOAD               0x03 /**< Authenticated payload timeout. */
/**@} */

RE: BLE_GATTC_EVT_TIMEOUT - Holding up Scan

Mia — Thu, 27 Dec 2018 21:44:18 GMT

Hi Bjorn,

I found that the timeout happened each time the scanning of the whitelist timed out. Changing the parameter SCAN_DURATION_WHITELIST changed how often this timeout occurred.

Do you know how these are linked?

Thanks,

Mia

RE: BLE_GATTC_EVT_TIMEOUT - Holding up Scan

bjorn-spockeli — Mon, 26 Nov 2018 09:58:19 GMT

I am afraid that I do not know of any mobile apps that can capture BLE sniffer traces.

OK, good to know that you have a viable workaround.

Its hard to say what the cause for the BLE_GAP_EVT_TIMEOUT is without the sniffer trace.

Best regards

Bjørn

RE: BLE_GATTC_EVT_TIMEOUT - Holding up Scan

bjorn-spockeli — Mon, 26 Nov 2018 09:58:18 GMT

I am afraid that I do not know of any mobile apps that can capture BLE sniffer traces.

OK, good to know that you have a viable workaround.

Its hard to say what the cause for the BLE_GAP_EVT_TIMEOUT is without the sniffer trace.

Best regards

Bjørn

RE: BLE_GATTC_EVT_TIMEOUT - Holding up Scan

Mia — Mon, 26 Nov 2018 04:23:41 GMT

I wanted to add that adding int he scan_start after the BLE_GAP_EVT_TIMEOUT event is seen solved my issue for allowing the phone connect again. However, I'm still not sure why the BLE_GAP_EVT_TIMEOUT event is happening in the first place.

RE: BLE_GATTC_EVT_TIMEOUT - Holding up Scan

Mia — Mon, 26 Nov 2018 04:20:14 GMT

Let me see what I can do. My only issue is I would need a 3rd controller to build that sniffer as I am currently using the two that I have, one as the client and one to spoof the UUID.

Any suggestions on apps that can achieve the same goal?

RE: BLE_GATTC_EVT_TIMEOUT - Holding up Scan

bjorn-spockeli — Mon, 19 Nov 2018 14:47:48 GMT

I cant think of any reason for not sending scan requests to devices should lead to the SoftDevice locking up.
Could you capture a trace of the on air packets using the nRF Sniffer v2 ? It would make it easier to debug the issue.

RE: BLE_GATTC_EVT_TIMEOUT - Holding up Scan

Mia — Fri, 16 Nov 2018 16:56:39 GMT

I'm sorry. I highlighted the wrong event to copy over. It is BLE_GAP_EVT_TIMEOUT that is issued.

I am not sure what I would be missing in my whitelist set up. I have my scanner set up as inactive, for reasons that I dont want the device sending scan requests to all devices. Would this have an effect possibly?

RE: BLE_GATTC_EVT_TIMEOUT - Holding up Scan

bjorn-spockeli — Fri, 16 Nov 2018 12:34:27 GMT

Hi Mia,

the BLE_GATTC_EVT_TIMEOUT is issued when a GATT procedure, i.e. writing or reading an Attribute times out, see GATTC Timeout. Its not related to the connection timing out which will be signaled with a BLE_GAP_EVT_TIMEOUT event. Hence, you need to look at the peripheral you're communicating with as it is not responding to the ATT packet sent by your central.

Yes, scanning must be restarted as it is stopped when you call sd_ble_gap_connect(), so you should restart scanning when you get the BLE_GAP_EVT_TIMEOUT event.

If the whitelist is set up correctly then you should only get BLE_GAP_EVT_ADV_REPORT events from devices that are in the whitelist. Advertisment packets from Non- whitelisted devices are ignored at the Link layer.

Best regards

Bjørn