At the time of writing, Google have just announced Android Wear, and Motorola announced the Moto 360 smart watch. The Wear APIs are still fairly basic, are quite well documented, and there are more to come, so I’m not going to write a tutorial on them (not yet, at least!). One interesting thing about the Moto 360 is that is supported on Android 4.3 and later. The most obvious reason for this is that Bluetooth LE is only supported in Android 4.3 and later, which would imply that the Moto 360 will support Bluetooth LE. Bluetooth LE is a technology that is going to be central to not only wearable technology, but to many IoT devices. In this series we’ll take a look at using Bluetooth LE on Android.
Bluetooth has been around since the mid-to-late 1990’s and has become the standard for peer-to-peer networking of devices over short distances. One disadvantage is that it can draw a bit of power, and this becomes something of an issue on mobile devices, and even more so on wearable technology where the batteries need to be smaller still. Also two Bluetooth devices must be paired before they can communicate with each other. The pairing process need only be performed once, but can be a painful experience for the user.
Bluetooth Low Energy, or Bluetooth LE for short, or BLE for even shorter still, was introduced as part of the Bluetooth 4.0 (sometimes called Bluetooth Smart) specification, and addresses these specific issues. As far as improved battery life is concerned, many manufacturers are claiming months or even years for some sensors (I must admit to being a little sceptical of this as manufacturers estimates are usually based upon best-case scenarios that do not involve actual usage). As has already been mentioned, Google added BLE support to Android 4.3 (API 18).
For those already familiar with Bluetooth development, BLE presents something of a learning curve because it is a rather different beast, so let’s take a brief look at the main differences.
The first major difference is in the pairing process. For traditional Bluetooth development, the task of pairing two devices was largely the responsibility of the user, but with BLE that responsibility lies much more with the developer. That is a good thing because it makes the whole pairing process much more straightforward from our users’ perspective.
The other major difference is the actual communication itself. In traditional Bluetooth development there were a number of options. Fundamentally these were based on a socket architecture very similar to standard network sockets. Essentially our data is streamed over sockets, and it is a case of both devices knowing the format of that stream. BLE takes a different approach, and centres around attributes. An attribute is essentially an atomic piece of data (i.e. an integer or string) which is shared between both devices. Attributes may be used to either represent data or control how the sensor behaves. For example, in a heart rate monitor one attribute may hold the current heart rate value (data) and another may contain a setting for how often the heart rate value should be updated (behaviour).
It is worth defining some roles before we go much further. Typically we will be connecting sensors (heart rate monitor, temperature sensor, etc.) to a host (smart phone, tablet, etc.). In our example, the host could control the behaviour of the sensor by writing a new value to one attribute, while reading data from another. There is actually a little more to it than that because a host can also register to be notified when an attribute changes, but we’ll cover that in due course.
The device that I’m going to be using during these articles is a Texas Instruments SensorTag which is a BLE-enabled multi-sensor development kit. It’s fairly cheap at under £20 ($25 US) and has ambient temperature, infrared temperature, relative humidity, barometer, magnetometer, accelerometer, gyroscope, and manual switches – all accessible over BLE. In this series we’ll build an app to show ambient temperature and humidity with values obtained from the SensorTag.
Apologies for the lack of code in this article, but I felt it important to establish a bit of background before diving in to the nitty gritty. They will definitely be some code in the next article – I promise!
© 2014, Mark Allison. All rights reserved.
Copyright © 2014 Styling Android. All Rights Reserved.
Information about how to reuse or republish this work may be available at http://blog.stylingandroid.com/license-information.
