Service discovery and connection delay

[Guillaume76]

Hello,

I'm trying to connect as fast as possible two devices (central : 52832 S132v5 and peripheral : 51422 S130v2), for a given advertisement interval. The central will always be connected to the same kind of peripherals, all identicals.

Regarding this, I have two questions :

• about service discovery : given that the central knows the device he is connected too (always the same kind, with the same service), can I without expecting problems, store in advance in the central the characteristics handles I will use and hence skipping service discovery? Bonding allows to skip service discovery after the first connection for a given device but if I store the handles in advance, I won't ever need discovery for any of the devices.

• about connection delay : the central scans for peripherals to connect to (recognised using adv data). Once the central receives an advertisement a connection request is sent (sd_ble_gap_connect) but the connection is established on the next peripheral advertisement. I guess the central waits for the receive window of the peripheral on the next advertisement. So if the advertisement period is 2s, the min delay to establish a connexion is 2s. Is there any way we can establish a connection on the first advertisement the central receives?

Thanks for your help,

Guillaume

[bloobird0]

First point: yes you can store the handles if you are sure that the profile is never likely to change (I did it in a project, works OK).

2nd point: I don't know, we miss information about how the peripheral is implemented.

[endnode]

There is mechanism defined in BT SIG Core specification for caching of static GATT Server handles, it depends on presence of Service Changed Characteristic under GATT Primary Service.

Regarding connection request and advertising/scanning detection: it's logical because once scanner receives broadcast on lower layers it must propagate it up to APP layer to decide what to do with it. So it needs to go out of lower stack through APIs up and then you are way out of 150us window you have for SCAN_REQ or CONNECT_REQ packets after each ADV packet is finished. So GAP Central device will wait for another ADV packet to issue CONNECT_REQ (if you decide to do it on APP layer) and therefore GAP Peripheral devices with long adv. interval provide such bad user experience (= you need to have at least 2 adv. intervals to really connect). And that's why for good (fast) user experience vendors recommend to advertise as frequently as possible (e.g. old Apple BT guidelines recommend 20ms adv. interval for certain period of time).

Theoretically you could implement some light-way parsing of ADV packet directly in lower stack but a) it will break all the logic of BLE stack architecture and b) it will be possible only with small logic and open source stack, not Nordic Soft Device.

[Petter Myhre]

If the central knows the address of the device it wants to connect to it can call sd_ble_gap_connect() directly without scanning first (sd_ble_gap_scan_start()), if not it needs to receive a advertisement from the device it wants to connect to (to collect the address).

[Guillaume76]

Thanks, it works! I also use a whitelist with sd_ble_gap_connect() to connect directly to any device I already know.

[Petter Myhre]

Great :) If I answered your question I would appreciate if you accept it.