Bluetooth LE: iOS vs. Android

Bluetooth Low Energy enables devices to have great battery life. However, designers and developers need to learn how to deal with lower data transmissions volumes and the completely new architecture.

The advent of Bluetooth Low Energy has made it possible to create devices and accessories with great battery life. In practice what this means for designers and software engineers is having to plan for faster data exchange, lower volume of data sent and received, and coming up with a completely new architecture (classic Bluetooth and Bluetooth LE are not compatible).

Let’s make a comparison across several technical characteristics of Classic Bluetooth vs. Bluetooth Low Energy. BLE requires 3.8 μJ of energy to send an 8-byte data packet versus 21.1 μJ for Classic – a huge advantage. However, as far as data transmission rates are concerned, we quickly see the trade-off: the fastest theoretical transmission rate for Classic is 2,178 kb/sec, almost an order of magnitude faster than BLE (303 kb/sec). In practice, the fastest Bluetooth Classic can send data is at the rate of 1,200 kb/sec, handily beating the measly 50 kb/sec achieved with Low Energy.    

Exciting applications of BLE

Despite a slower rate of transmission, BLE makes all sort of cool things possible or easier. Let’s take a look at just a few:

• Healthcare: Bluetooth LE is already widely used in healthcare. Most of today’s medical devices, such as blood pressure or heart rate monitors, use Bluetooth LE for data transmission. These devices have battery lives of months and even years.
• Fitness: Today the market is being almost flooded with fitness gear and accessories featuring BLE such as heart rate monitors, pedometers, and even running shoes. Manufacturers of sports apparel, footwear, and exercise gear are extremely interested in BLE and will likely continue to expand their ranges of BLE-enabled products.
• Security: While this may not be intuitive, Bluetooth LE makes it possible and even practical to use your smartphone as your car key or even house key. BLE uses the AES-128 encrypted data transfer channel and provides for key management across multiple devices. This makes it realistic to rely on ubiquitous BLE-enabled consumer devices, such as smartphones, for various security applications.
• Smart home: Manufacturers of various smart home automation and devices use a number of different technologies in their products. However, Bluetooth LE has the same advantage of being present on perhaps the most ubiquitous consumer device: the smartphone, which is almost always on your person. Technically, BLE-enabled devices can sense the strength of the signal between the sender and the receiver. In practice, this means that BLE can be used for implementing proximity sensors. Just as you could unlock your car by simply walking up to it, when you walk into a room in your house, the room can sense you’re there and adjust things like temperature and lighting to your preferences. The potential for this kind of proximity-based smart automation is limitless.
• Entertainment: This is another thing that’s kind of obvious but still very interesting. Your smartphone can use BLE to talk to various devices in your home, such as your blu-ray DVD player, smart speakers, and could act as the universal remote for all of your home media devices.
• Toys: Another area where the only limit is your imagination. A BLE-enabled toy could work with a tablet or a larger computer. Imagine a toy robot that you can program on your iPad, or an interactive board game that has a physical and a tablet-based interface.
• Payments: Obviously, other technologies are already being used for payments, NFC being the most prominent. However, Bluetooth LE is also a great fit: it is secure, works over short distances, and is simple to use.
• Clock synchronization: Every day we are surrounded with devices and machines that display time and rely on time in their operation: there is clock in the microwave, a clock in your car, a clock in your oven, a clock in the media player, plus your bedside alarm clock, etc. Well, if there is one clock that we rely on for exact time, it’s the clock in your phone. And it’s a huge drag to have to adjust the time on all these different clocks when they switch to daylight savings, or when you experience a power outage. Wouldn’t it be cool if we could force synchronize our other household clocks to the correct time by just walking into our home? This is hardly rocket science, but it’s small things like this that make life more enjoyable.

The Android Wrinkle

Let’s take a separate look at the implementation of BLE on Anroid. As you will see, not everything is perfect in the BLE universe.

BLE is supported by Android 4.3 (API level 18) and higher. The main characteristics are as follows:

• Distance: 50-150 ft
• Energy consumption: extremely low. For example, a Lenmar WC357 battery (1.55v, 180mAh), if used only for BLE transactions, would last 15 years.

To implement the device interaction, BLE uses the peripheral–central model. The center is a device that scans for other available BLE devices and looks for potential connections. The peripheral is the device that is on the other end of those connections, its job is to generate and send data packages to the central.

So, on to the glaring issue:

As of right now, Android 4.3 and 4.4 (KitKat) devices do NOT support the peripheral mode.

Here is the link to the open issue in the Android Issue Tracker. For an example of someone trying to find a workaround by using a third party module (Samsung BLE SDK), click here. And here is what StackOverflow has to say on the issue.

Previously, Google had not included the support for peripheral mode in the 4.3 version. There were hopes of the support being added in 4.4 (KitKat), but alas. Here is what the source says: An Android app still can assume the central role according to the documentation. In building such an application, the developer needs to cover the following:

1. Declaring the app’s permissions, setting up BLE
2. Searching for BLE devices
3. Establishing the connection
4. Reading BLE attributes
5. Receiving GATT notifications
6. Closing the app and releasing the system resources

The official documentation contains several small examples of writing methods for BLE interactions. Here’s also a github project that is in full compliance with the documentation: it scans for BLE devices, establishes connections and reads the attributes.

Contact First Line Software to see how we can help create a Bluetooth solution for your business needs.