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

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.

Parents
  • 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.

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

Reply
  • 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.

Children
Related