We have recently been working on a project harnessing the iOS ANCS (Apple Notification Service Center). The product is not yet launched and still under wraps. But suffice to say it is a battery powered device that remains connected to your iPhone and displays to you whether your phone has any notifications pending (WhatsApp, Facebook, missed call etc etc).

In the process we discovered quite a few subtleties with the implementation in iOS. Our main one being discovery of what looks like a ‘3 strikes and you’re out’ algorithm within iOS. The symptom is the device stays connected nicely most of the time, but once every ~2 days the user has to delve back into Settings-> Bluetooth and re-connect to the device. This happens automatically most of the time, but after a ‘3 strikes’ issue it appears to get grey listed, requiring a manual re-connect instead.

We took some logs – see below. These show the device connecting/disconnecting in marginal signal conditions:

Mar 18 16:38:05 afes-iPhone BTLEServer[107] : (Note ) Central “xxx” is now subscribed to characteristic “ANCS Data Source”
Mar 18 16:38:07 afes-iPhone BTServer[68] : Core Connection timed out to device “xxxxxxx”
Mar 18 16:38:07 afes-iPhone BTLEServer[107] : (Note ) Peripheral “xxx” is now disconnected: Error Domain=CBErrorDomain Code=6 “The connection has timed out unexpectedly.” UserInfo=0x14528470 {NSLocalizedDescription=The connection has timed out unexpectedly.}
Mar 18 16:38:07 afes-iPhone BTLEServer[107] : (Note ) Connecting peripheral “xxx”…
Mar 18 16:38:07 afes-iPhone BTLEServer[107] : (Note ) Central “xxx” is now unsubscribed from characteristic “ANCS Notification Source”
Mar 18 16:38:07 afes-iPhone BTLEServer[107] : (Note ) Central “xxx” is now unsubscribed from characteristic “ANCS Data Source”
Mar 18 16:38:08 afes-iPhone BTLEServer[107] : (Note ) Peripheral “xxx” is now connected
Mar 18 16:38:08 afes-iPhone Preferences[164] : (Warn ) CoreBluetooth: API MISUSE: can only accept commands while in the connected state
….
Mar 18 16:38:09 afes-iPhone BTServer[68] : Core Connection timed out to device “xxxxxxxxx”
Mar 18 16:38:09 afes-iPhone BTLEServer[107] : (Note ) Peripheral “xxx” is now disconnected: Error Domain=CBErrorDomain Code=6 “The connection has timed out unexpectedly.” UserInfo=0x1453daf0 {NSLocalizedDescription=The connection has timed out unexpectedly.}
Mar 18 16:38:09 afes-iPhone BTLEServer[107] : (Note ) Connecting peripheral “xxx”…
Mar 18 16:38:09 afes-iPhone BTLEServer[107] : (Note ) Peripheral “xxx” did not use any built-in service, strike #1
…

Now if we go in and out of range with the right frequency (hint: a biscuit tin comes in handy), we get ‘API MISUSE’ three times in a row.

Resulting in the following messages:

Mar 18 16:38:12 afes-iPhone BTLEServer[107] : (Note ) Peripheral “xxx” did not use any built-in service, strike #2
…
Mar 18 16:38:16 afes-iPhone BTLEServer[107] : (Note ) Peripheral “xxx” did not use any built-in service, strike #3
…

It seems this is a ‘three strikes and you’re out’ algo that then places the peripheral into some kind of ‘grey-list’. The elapsed time has to be within the 11 or so seconds range. We can’t slow down our interrogations or we go up against the 30 second key exchange with pairing time outs.

We started a thread on the Apple developer forum and find a few others in the same boat. And today were asked to submit a potential bug report to Apple, which we have done.

iOS 8.3 has since added another 2 strikes, we we’re up to ‘5 strikes’ now.

We have tweaked the firmware which has made the issue a lot less prevalent. Interestingly, we looked at other ANCS devices (that have been in the market for a while now) and found similar issues.

If you want to find out more about the Internet of Things in general, Nick Thorne will be giving a short presentation at the Eastleigh Tech Hub ‘Internet of Things’ evening event on 27th May 6pm – 8:30pm.

Hint – here’s another really interesting $5 postage stamp WiFi device with a 32 bit micro running GCC, the ESP8266. “…one of the leading platforms for the Internet of Things”.