Slow connect in a SDK15 previously bonded peripherial device.

RE: Slow connect in a SDK15 previously bonded peripherial device.

bjorn-spockeli — Wed, 11 Sep 2019 06:12:46 GMT

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.

RE: Slow connect in a SDK15 previously bonded peripherial device.

Mikhail — Tue, 10 Sep 2019 14:22:45 GMT

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?

RE: Slow connect in a SDK15 previously bonded peripherial device.

bjorn-spockeli — Tue, 10 Sep 2019 13:39:05 GMT

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

RE: Slow connect in a SDK15 previously bonded peripherial device.

Mikhail — Mon, 09 Sep 2019 14:21:35 GMT

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

RE: Slow connect in a SDK15 previously bonded peripherial device.

bjorn-spockeli — Mon, 09 Sep 2019 13:58:39 GMT

Yes, you can try that.

RE: Slow connect in a SDK15 previously bonded peripherial device.

Mikhail — Mon, 09 Sep 2019 13:51:33 GMT

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?

RE: Slow connect in a SDK15 previously bonded peripherial device.

bjorn-spockeli — Mon, 09 Sep 2019 13:19:47 GMT

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).

RE: Slow connect in a SDK15 previously bonded peripherial device.

Mikhail — Mon, 09 Sep 2019 12:14:02 GMT

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?

RE: Slow connect in a SDK15 previously bonded peripherial device.

bjorn-spockeli — Mon, 09 Sep 2019 11:33:22 GMT

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