BLE_GATTC_EVT_TIMEOUT - Holding up Scan

[Mia]

I am trying to test out the whitelist that I have created for the nrf52832 client. I have edited the whitelist so it will only allow one device to be bonded and added to the whitelist. I also have a scanning filter added which filters based off the Nordic UART UUID. I have an android bonded with the Rigado and added to that one slot in the whitelist.

I programmed a second nrf52832 with the Nordic UART example for a peripheral device to see if that device will be able to be added to the whitelist since it would pass the scanning filter (has same UUID). I imagined not, and while I believe this is true from the testing I'm doing, after the device starts advertising (Android not advertising itself) for about 10 seconds, a BLE event occurs. The event is registered as a BLE_GATTC_EVT_TIMEOUT. I think I understand this as the connection attempt between the nrf52832 peripheral and client timed out, however, afterwards I start advertising on the smartphone, and no connection or even Bluetooth event occurs. Somewhere along the line, something is getting hung up after the connection timeout between the two nrf52832s, but when I run the debugger on the client, there is no error occurring. On the other hand, when I start advertising both devices from the start the smartphone will connect right away and continue on with normal business.

So long story, short, my questions are, what happens after a BLE connection attempt timeout? Should scanning continue or does it need to be restarted? if scanning is supposed to continue, why would things be getting hung up? Lastly, should there even be a BLE connection attempt if the device isn't in the whitelist?

Thanks!

[bjorn-spockeli]

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 

[bjorn-spockeli]

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 

[Mia]

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

[bjorn-spockeli]

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. */
/**@} */