Service discovery and connection delay

RE: Service discovery and connection delay

Parabit — Tue, 18 Aug 2020 14:06:59 GMT

Hi,

I hardcoded the characteristic values in iOS, but without discovering the services I couldn't read it. May I know which platform you did it (iOS or Android).

RE: Service discovery and connection delay

Petter Myhre — Wed, 19 Jul 2017 11:09:01 GMT

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

RE: Service discovery and connection delay

Guillaume76 — Wed, 19 Jul 2017 11:02:37 GMT

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

RE: Service discovery and connection delay

Petter Myhre — Wed, 19 Jul 2017 10:28:19 GMT

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

RE: Service discovery and connection delay

endnode — Tue, 18 Jul 2017 12:03:12 GMT

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.

RE: Service discovery and connection delay

bloobird0 — Tue, 18 Jul 2017 11:40:29 GMT

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.