Bluetooth Smart for Wearables and IoT

What is the latest in bluetooth smart?

Bluetooth Smart has had an explosive growth in a number of applications and devices over the past five years. In my opinion, it really started in 2011/2012 with the introduction of the iPhone 4S as the first phone to support Bluetooth Smart with the 4.0 specification. Penetration of the standard in smartphones has soared since then, and today most new smartphones support Bluetooth Smart. So what does the Bluetooth Smart landscape look like for 2016?

The latest version of Bluetooth (4.2)

The latest version of Bluetooth (4.2) added a couple of notable improvements over previous releases. First is a packet length extension of the Bluetooth Smart packets, which potentially increases the effective data rate by around 2x to around 300 Kbit/sec. One benefit of this is that the Over-the-Air download of new firmware to a Bluetooth Smart product can be done much quicker. A second benefit is the new security and privacy features, which reduces the risk of eavesdropping but also gives a new level of control to the user. An example is that the user can grant or deny a Bluetooth Smart beacon permission to engage with the smartphone, and thus decide if the smartphone can be tracked or not. We can expect these features to be utilized further with new products and apps deployed in 2016.

The Bluetooth SIG recently announced some standard improvements for Bluetooth Smart in 2016 which includes both updates to the Bluetooth Smart physical layer and software enhancements. The three new components to be introduced include a higher data rate option, a longer-range mode and finally mesh networking. The first will enable more data from sensors or lower power consumption for wearables, while longer range and mesh could drive wider adoption of Bluetooth Smart in building and industrial automation.

Adapting bluetooth smart connections to Android and Ios

If you are designing a wearable Bluetooth Smart product, most likely you will be looking at making an app for both Android and iOS devices. A key parameter for the Bluetooth Smart wireless link is the connection interval – the time between two Bluetooth Smart connection events. This is a tradeoff between latency and responsiveness of your product versus power consumption. As an example, a product that tracks your movement with an accelerometer and gyro will most likely require a shorter connection interval, while a battery operated weather station can benefit from the lower power consumption of a longer connection interval.

If solely looking at the Bluetooth specification, a connection interval can be between 7.5 milliseconds and 4.0 seconds. In addition, a Bluetooth Smart peripheral is allowed to skip a number N of connection events, so it can potentially sleep for longer than 4.0 seconds. This is called slave latency and is a number from 0 to 499 – which theoretically lets a device sleep for minutes without breaking the connection. However, when designing for use with Android and iOS we don’t have that wide range of options and need to pick a common denominator between the two. In Android 5.0 and up, the central device (the smartphone) can ask for low, medium or high connection intervals, depending on the need for data. The shortest available connection interval is 7.5 ms. I haven’t found explicitly documented what the medium and high intervals are, but from actual measurements it seems like medium = ~100ms and high = ~1 sec. This could also be smartphone dependent. In iOS (at least from version 5.0 to 9.2), connection interval is governed by the iOS device. The default is 37.5 ms and the Bluetooth Smart peripheral device must request a change (the app cannot decide this on its own). The minimum connection interval is 30 ms and maximum is 2.0 sec. There is an exception for Human Interface Devices (HID) devices (e.g. keyboard) where the interval can be as low as 11.25 ms. On the TI SimpleLink Bluetooth Smart SensorTag kit, we are able to control the connection interval by implementing a proprietary connection interval service on the device which in turn lets us update the connection interval from the SensorTag app. Hence, it is possible to control the connection interval both from a smartphone running either iOS or Android.

Signal processing on the device or in the cloud?

When designing a Bluetooth Smart wearable application, the developer will have to make some choices regarding where signal processing occurs.

Let’s look at the Bluetooth SIG specified services of heart rate and cycling speed and cadence. For the heart rate service, the key characteristic is “heart rate measurement”, which indicates the actual heart rate measured on the device. Hence, we can conclude that any signal processing or calculations need to happen on the embedded device (the heart rate monitor product). The cycling speed and cadence service is different. Here the key characteristic is “CSC Measurement”, which represents either wheel revolution data, crank revolution data or both. Useful data such as average speed, distance travelled etc. needs to be calculated on the host side which is usually the phone, but could potentially also be calculated in the cloud. A word of advice is to consider if you need to do very complex calculations – then you might want to move your data processing to a more powerful processor to save power and improve execution speed.

Adopted bluetooth smart profiles for wearables?

As you might know, there are a number of adopted services in Bluetooth Smart. For wearables, I put them in two buckets.

There are the “health monitoring” related ones, such as blood pressure, continuous glucose meter, body composition, health thermometer and weight scale. Then you have more “activity tracking” devices with heart rate monitoring and running speed / cadence. Adopted profiles are convenient to use if you want a straight forward and clean interface between your Bluetooth Smart product and a category of smartphone apps. As an example, let’s say you are designing a heart rate monitor. By implementing the Bluetooth Smart heart rate profile, your product will be compatible with popular fitness apps supporting this profile. It is still possible to make a heart rate belt which doesn’t follow the adopted profile using a custom service, but then a dedicated app is needed to make use of this product. A better solution is to combine an adopted profile with an extra custom service. If you want extra differentiation and display body temperature in addition to heart rate data from your product, you could add that as an extra service and supply an app which utilizes this data. Your product would still work with the common fitness apps mentioned earlier, but also provide extra information when used with your custom app.

A simple cloud interface with bluetooth smart

Many Bluetooth Smart products in the market today include a cloud interface. To help developers get started with this, TI provides a development kit in the form of a SensorTag which shows how to get data from sensors via Bluetooth Smart to the cloud.

The sensortag kit is a small PCB with a SimpleLink multi-standard CC2650 wireless MCU, connected to 10 different sensors (mostly via I²C). There is also a multi-purpose SensorTag app which enables Bluetooth Smart and cloud connectivity on iOS and Android. When the app is running and SensorTag is turned on, the app does a device discovery using Bluetooth Smart and finds the SensorTag. The user then selects to connect and the app does a service discovery to read all available services (one for each sensor) and starts displaying sensor data. Each service in the app has a cloud interface, and we have the option of exporting each service to dweet or via mqtt. Dweet.io is like “the Twitter of devices”, and MQTT is an open standard initiated by IBM. Exporting to dweet.io, under dweet.for/device_name/ this data can then be used by any app or website subscribing to the dweet. A nice example is the freeboard service, which lets anyone design visual elements to create “freeboards” visualizing sensor data. In this simple setup there is no aggregation of data, but this could be implemented by exporting data to a website with a datastore backend.

FURTHER INFORMATION

Texas Instruments SensorTag

The SimpleLink SensorTag allows quick and easy prototyping of IoT devices. It just works – connect your sensor solution to the cloud in three minutes with Bluetooth Smart, 6LoWPAN or ZigBee.

In this article we looked at the latest Bluetooth Smart standard, Bluetooth Smart connections, Bluetooth Smart apps, Bluetooth Smart profiles and methods for connecting Bluetooth Smart products to the cloud. Try it yourself today and order the TI SensorTag kit, find out more about the SensorTag.

Download our Tech Journal on Bluetooth Smart for Wearables and IoT here.