This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Slow connect in a SDK15 previously bonded peripherial device.

Hi!

I have SDK15 central (nRF52832) with previously bonded peripherial device also SDK15 (nRF52810).

All works. But sometime when power on on the peripherial device, connect establish up to 5 seconds. 

In a LOG central i see next:

0> <info> app: Starting scan.
0> <info> app: Connected ble_advertising.
0> <info> app: Connected to a previously bonded device.

In the debugging of central I have also debug in a BLE_GAP_EVT_ADV_REPORT case.

Switch on peripherial device and see above logs on the central device:

up to 5 seconds pause, when I get BLE_GAP_EVT_ADV_REPORT event, right next 

0> <info> app: Connected ble_advertising.
0> <info> app: Connected to a previously bonded device.

Why I have this delay for connect? Scan windows is:

#define SCAN_INTERVAL   0x00A0 
#define SCAN_WINDOW    0x0096
#define SCAN_DURATION 0x0000
#define SCAN_DURATION_WITELIST 0x0000

Also I have same project on a SDK13, and there is no same behavior- connect establish right after power on peripherial device.

Parents
  • Hi Mikhail, 

    What advertisement interval is the peripheral device using?

    The central will actually send the connection request upon receiving the second advertisment packet from the peripheral. This is to ensure that the peripheral device is still in range and avoid sending conn requests on spurious advertisment packets. Hence, the delay between theBLE_GAP_EVT_ADV_REPORT and the connected event will be atleast 2 x the advertisement interval. 

    It could also be the deffered logging, i.e. log statments are queued and processed when the CPU is idleing, is contributing to the delay as well.  

    Best regards

    Bjørn

Reply
  • Hi Mikhail, 

    What advertisement interval is the peripheral device using?

    The central will actually send the connection request upon receiving the second advertisment packet from the peripheral. This is to ensure that the peripheral device is still in range and avoid sending conn requests on spurious advertisment packets. Hence, the delay between theBLE_GAP_EVT_ADV_REPORT and the connected event will be atleast 2 x the advertisement interval. 

    It could also be the deffered logging, i.e. log statments are queued and processed when the CPU is idleing, is contributing to the delay as well.  

    Best regards

    Bjørn

Children
Related