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

[astomi]

Hi,

I am testing NRF CTS and ANCS examples using iOS 14.7 (iPhone 6s) and 14.8(iPhone 10) and Zephyr 1.9.1. The peripheral  (target) is a custom wearable running on nrf52840

Both examples work fine on first run after pairing and bonding. However, they behave differently in respond to target powercycling or turing Bluetooth on/off on iOS devices. Both seem to handle BT on/off in CTS case fine but never in ANCS case - discovery always fails. Target powercycling is even worse - 14.7 and 14.8 handle it differently. 

Long story short - I feel that overall behaviour on reconnect is more or less random.

Apple accessory guidline suggests: " The Current Time Service...not guaranteed to be available immediately after connection and the accessory shall support Characteristic Value Indication of the Service Changed characteristic (see Bluetooth 4.0 specification, Volume 3, Part G, Section 7.1) to be notified when the services become available"

Can somebody point me into the right direction how to add handling CTS and ANCS services availability to existing CTS or ANCS examples? Or maybe there is a better example(s) somewhere for iOS devices that I could take as a starting point? 

I have searched the knowledge base but relevant posts are typically 5 or more years old which is a good indicator of this issue being solved already?

Thanks.

[astomi]

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?

[Susheel Nuguru]

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.

astomi said:

but reconnects manually if I click on 'Nordic_CTS' device in iOS Bluetooth settings

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.

astomi said:

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

nRF Sniffer documentation should be helpful, I hope.

[astomi]

You can close the ticket as I moved back from zephyr to soft device