Slow connect in a SDK15 previously bonded peripherial device.

[Mikhail]

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.

[bjorn-spockeli]

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

[Mikhail]

Advertising interval on the peripherial side is 1 Sec, like in the SDK13. Ofcourse, the peripheral device is still in range.

May be should change the window scan?

[bjorn-spockeli]

Yes, im just stating that the Central will always wait for a second advertisement packet before sending the actual connection request. 

Scan Interval: (0x00A0) 160 * 0.625ms = 0.10seconds

Scan window: (0x0096) 150 * 0.625ms = 93.75 milliseconds.

Try setting the Scan Window = Scan Interval, then you should be scanning "continously"( takes some time to switch between the advertisment channels). 

[Mikhail]

I very fear to make continously scanning becouse once I did it. And nRF can't works fine. Your collegias told me that shouldn't make continously scanning due to nRF should handle requests beetwen scan interval. For this reason I rest small window beetwen scanning.

May be should increase both parameters? For ex. 320 and 300?

[bjorn-spockeli]

Yes, you can try that. 

[Mikhail]

320 and 300 -no effect, but change to 0xA0 0x9E - more faster. Any else idea how to increase connection speed ?

[bjorn-spockeli]

The Scanner interval and window you are using 

Scan interval: 100ms (160 * 0.625ms)

Scan window: 98.75ms (158 * 0.625ms) 

means that you are effectivly scanning for 98,75% of the time, there is a 1,25ms gap between the end of one scan event and the start of the next. In addition there is also some time that the SD needs to reconfigure the RADIO frequency when swiching channels.  So if you want to increase the time it take to connect you will have to decrease the advertisement interval on the peripheral side. 

Best regards

Bjørn

[Mikhail]

Thanks, therefore, next step to increase connect time- more fast advertise on peripherial side? For ex. rfom 1 s to 500 ms? Is there all possibility to increase connect time of central?

[bjorn-spockeli]

Yes, reducing the advertisement interval to 500ms should result in a faster connection establishment. The timing on the central side is fixed, as stated before, a central will wait for the second adv. packet before sending the actual conn.request. After that the central and will exchange packets to exchange link layer features, agree on connection interval, etc. You can try to lower the connection interval and then increase after the connection and service discovery phase is complete.