Bluetooth peripheral CTS and ANCS examples behaviour on reconnect with iOS central

RE: Bluetooth peripheral CTS and ANCS examples behaviour on reconnect with iOS central

user6207 — Wed, 01 Jun 2022 10:42:58 GMT

Alex,

I do not think CTS and ANCS client (peripheral) examples can do anything special to reconnect automatically. This has to happen from the central/IOS side (since it is the only initiator) in this case.

The two examples (CTS/ANCS) both are advertising after disconnects which is the only thing they can do and hope the peer sends an initiator request on disconnect.

[quote user="astomi"]but reconnects manually if I click on 'Nordic_CTS' device in iOS Bluetooth settings[/quote]

I am not 100% sure on the auto reconnect feature on IOS, but I think with the paired devices the IOS will automatically try to reconnect when it finds the adv packet from a known paired device.

For the paired devices, if you still feel that the behavior of the reconnect is sandom, I strongly suspect this behavior being on the IOS side. We just need a BLE trace to see what happens in air traffic to know how different the IOS side is behaving when its behavior is not consistent.

[quote user="astomi"]Is there an article somewhere on how to setup a sniffer? [/quote]

nRF Sniffer documentation should be helpful, I hope.

RE: Bluetooth peripheral CTS and ANCS examples behaviour on reconnect with iOS central

user113304 — Sun, 29 May 2022 21:41:08 GMT

Susheel,
I decided to go back to square 1 and to test CTS and ANCS behaviour in isolation. I am running a vanilla CTS example now and it is fairly consistent - it won't reconnect automatically from either side, but reconnects manually if I click on 'Nordic_CTS' device in iOS Bluetooth settings. Is it a problem with advertisement settings?

RE: Bluetooth peripheral CTS and ANCS examples behaviour on reconnect with iOS central

user113304 — Sun, 29 May 2022 21:33:52 GMT

Is there an article somewhere on how to setup a sniffer?

RE: Bluetooth peripheral CTS and ANCS examples behaviour on reconnect with iOS central

user113304 — Sun, 29 May 2022 21:30:15 GMT

To answer my own question - Characteristic Value Indication/Service Changed characteristic is included in ANCS example, I don't see any callback activity though but that is another story

RE: Bluetooth peripheral CTS and ANCS examples behaviour on reconnect with iOS central

user6207 — Mon, 09 May 2022 08:45:14 GMT

[quote user=""]Both seem to handle BT on/off in CTS case fine but never in ANCS case - discovery always fails.[/quote]

Can you provide a sniffer trace to show us what exactly in discovery fails here. There will be others also in this forum who can help us interpreting this with more info.

RE: Bluetooth peripheral CTS and ANCS examples behaviour on reconnect with iOS central

user113304 — Fri, 06 May 2022 07:31:59 GMT

Thanks Susheel,
I doubt merging has any effect as a standalone CTS example (I just call time update periodically instead of the button press) behaves in the same manner. Yes, adding a 5 second delay seems to improve the likelihood of reconnect but not solving the issue. At first, 14.8 iOS reconnected successfully but stopped working again on further attempts. As I mentioned in OP, tracking CTS availability should be a better option as Apple suggested but I would appreciate some guidance/example here.

RE: Bluetooth peripheral CTS and ANCS examples behaviour on reconnect with iOS central

user6207 — Wed, 04 May 2022 11:37:53 GMT

I have not seen this two merged into one, so the timing on when and how you can use CTS after a connection is difficult for me to answer. Probably your application can try to wait for some time (add some delay) after the connection and before the discovery happens so that after the delay we can assume that CTS is available? Not sure, just thinking out loud here.