Since iPhone 4S, iPad3 and iPod 5th Generation, iOS devices have shipped with Bluetooth Low energy (also called Bluetooth Smart or Bluetooth 4.0). This is supported from iOS 5 by the CoreBluetooth framework. Support for BLE has quickly created an eco system of BLE tracker ‘keyfob’ devices and associated Bluetooth smartphone apps. Examples are HipKey, Proximo, Cookoo, Pally Smart and StickNFind.
These generally support:
• a distance alarm (alarm sounds if they are too far apart)
• a find me function (alarm sounds when a button on one or the other is pressed)

CoreBluetooth provides the programming interface to the underlying BLE hardware (e.g. the Broadcom BCM4330 for iPad3) which supports two main modes of communication.
• advertising mode
• connected mode

In advertising mode, the keyfob ‘chirps’ a message at regular intervals (e.g. every two seconds) which the phone uses to detect keyfob presence and, through signal strength distance.

In connected mode, the phone detects the chirps, then initiates a connection to the keyfob. Messages are then passed instead of chirps. Again, signal strength is used to gauge distance. Connected mode is slightly less desirable as it uses more power at both ends of the connection.

We have developed an iOS app to implement this functionality in both modes. iOS apps, however also have two modes of operation:
• foreground (app on the screen)
• background (app somewhere in the background, e.g. user is taking a phone call)

It turns out that there is significant difference in behaviour between foreground and background. But before we go into this, consider the important aspects of ‘keyfob’ tracker apps.
•latency
•battery life
•reliability

Latency is the time it takes from a device going out of range to an alarm being sounded. Battery life is how much drain the app puts on the phone battery and how long the keyfob lasts on a charge. Reliability is whether the app will set off alarms reliably.

So how are foreground / background modes, latency, battery life and reliability linked in iOS ?
This is best described pictorially. The figure shows four modes of operation, A,B,C and D. Modes A,C and D use variations of advertising mode, connected mode, foreground and background. B is a variant of connected mode that may save some battery life.

Summary of Bluetooth performance

Summary of Bluetooth performance

As we can see, reliable, low latency keyfob tracking is supported by modes A and C. In other words, connected mode works well in foreground or background, but drains batteries more (but is still useable). Advertising mode works well with minimal battery drain, but only if the app is in the foreground (which will actually drain the phone battery too).

The real area for improvement is in mode D: advertising mode with the app in the background. Our experimentation (together with consensus on CoreBluetooth forums) finds that when an app is in the background, the keyfob ‘chirps’ don’t get through to the app quickly and reliably enough. In fact, the first advertisement is detected as per foreground mode (about two seconds). The next about 15 minutes later, then often one more 15 minutes after that. After this the app process is unloaded by the operating system so no more chirps are seen until the app is foregrounded again by the user. Which means in practice mode D can’t be used …. as yet. However with iOS 7 due in a matter of days, we have the highest of hopes.

The experiences of current users of the various keyfob devices and their apps appear to bare this out. We are closely watching iOS for updates that will change the situation.

A note on Android: Whilst many Android devices are now sporting BLE hardware (e.g. Galaxy S3, S4, Nexus 4), there is considerable fragmentation of the APIs. This is keeping developer numbers down because apps have to be device specific to support BLE. Google has announced that Android will have generic BLE support ‘later this year’.

Our embedded background has helped us to go deep into the performance and application of bluetooth in smartphone apps.