December 13, 2016
What is Bluetooth LE?
Bluetooth Low Energy (BLE or Bluetooth Smart) is an iteration on Bluetooth technology that was built for the Internet of Things. It is power-friendly and implemented on all major operating systems, making it a great option for close-range communication with “smart” objects.
BLE’s role in IOT
Much of the appeal of BLE as a technology lies in it’s ability to efficiently offer direct wireless communication between two devices in range of each other. While this makes BLE a natural and obvious fit for offline scenarios, BLE also plays a crucial role in many Internet of Things applications.
One scenario common to many wearable devices is the use of BLE to communicate back to an internet connected smartphone or tablet. In these scenarios the smartphone is essentially acting as an internet connected hub between the wearable and the cloud services it relies upon.
BLE is also commonly used to streamline the setup of WIFI connected smart devices. Google’s Chromecast setup process was one of the first to use BLE in this way. Instead of relying entirely on wifi communications, the Chromecast setup mobile app uses BLE communications to pass wireless access credentials to the Chromecast device. From there the Chromecast connects directly to wifi to steam video, but BLE plays a key role in solving the “last-mile” problem of getting the credentials onto the internet connected device to begin with.
BLE’s role in local positioning
BLE is also commonly used for local positioning applications such as Apple’s iBeacon technology, and other BLE based beacon solutions. BLE beacons placed at known locations can communicate with BLE enabled phones and tablets to position users within spaces where GPS might not be available (shopping malls, convention centers, theme parks ect).
When range becomes an issue
One of the most limiting factors in many applications of BLE communications often centers around the physical range of the technology. This is especially true in certain smart home scenarios that involve controlling multiple BLE devices individually and in groups. Range limitations can lead to poor user experience and juggling direct connections between a smartphone and many BLE devices can become cumbersome and impractical.
Other competing wireless technologies such as Zigbee have solved this problem by integrating a mesh networking layer into the wireless specification. This allows communication with any device on the mesh via connectivity to any single node on the network. Devices on the mesh network relay wireless communications to each other, effectively extending range and robustness of wireless communication to multiple devices. The limitation with Zigbee is that most of the phones, tablets, and computers we use on a daily basis do not have compatible radios in them and therefore require specific hardware hubs to communicate with connected devices.
Does BLE mesh?
Fairly well thanks. And it should be getting better. While support for BLE mesh networking is not part of the core Bluetooth Smart specification, a number of companies have produced BLE chips and SDKs to add a mesh networking layer to the core BLE functionality. Furthermore, the Bluetooth Special Interest Group (https://www.bluetooth.com/) announced that it has formed a “Mesh Networking Working Group” to work on integrating mesh networking into the official Bluetooth Smart specification. At this point the release of that specification is targeted for early 2017. In the meantime technologies like Qualcomm’s CSR Mesh are robust and relatively widely adopted. OST has particular experience implementing CSR Mesh SDKs for the development of native mobile applications to control BLE connected lighting products.
As a developer, what do I need to know about Bluetooth LE?
Every BLE device has a set of endpoints that allow other BLE devices to interact with it. The endpoints are included in the Generic Attribute Profile (GATT) of the device.
A device has a single GATT profile that makes up its interface. At the top level, each device has a set of services. Each service is made up of a set of characteristics. These characteristics are the actual endpoints that allow interaction with the device. Each characteristic has a set of properties that determine how other devices are allowed to interact with it. Characteristics can allow a combination of the following common interactions:
- Read: read a value from the characteristic
- Write: write a value to the characteristic
- Notify/Indicate: receive notifications when the characteristic’s value changes
There are reserved services and characteristics for specific types of devices and information. For example, a heart rate monitor will always have a service with identifier 0x180D that has characteristics 0x2A37, 0x2A38, and 0x2A39. Before beginning development, be sure to fully document the GATT profile for the device to understand its full interface and capabilities.
Bluetooth LE in iOS
The BLE implementation for iOS is all included in the Core Bluetooth framework. Apple has provided very helpful documentation detailing the data structure and use of this framework.
Basically, the data structure follows its physical representation. Using a CBCentralManager, you can scan for and connect to devices (CBPeripheral). The central manager’s functionality is limited to device discovery, connection, and disconnection. Once connected to a device, the CBPeripheral object is the main interface for interacting with the device. You can discover the device’s services (CBService), discover a service’s characteristics (CBCharacteristic), and interact directly with the characteristics.
Bluetooth LE in Android
BLE in Android is a little less straight-forward. The main interface is the BluetoothAdapter, which is required for any and all Bluetooth activity. Once a device (BluetoothGatt) is discovered, you can connect to that object by calling a method (.connectGatt()) on it. The returned object is the connected device, with which you can interact the same as above.
One interesting difference between the BLE API on Android and iOS is the way that each platform handles asynchronous communication. Callbacks (LeScanCallback & BluetoothGattCallback) are passed to the discovery and connection to handle errors/success. These classes need to be extended and implemented to properly discover devices, connect to them, and receive updates from them.
Cross-Platform Bluetooth LE
Sharing code in a cross-platform app means that the implementation details for each platform can be abstracted away. This gives us a blank canvas on which to build a new interface for BLE.
For ease of re-use, I have created a nuget package (Xamarin.BluetoothLE) with the iOS and Android Bluetooth LE implementation abstracted away. You can view/contribute to the source on Github. The framework is largely based on the Monkey.Robotics project, but with some updates and changes. Because of the confusion introduced by the callbacks in Android, the framework is modeled more closely to the iOS implementation of BLE. With C#, we can raise events when asynchronous communication events occur.
The documentation for the Xamarin.BluetoothLE package can be found here.
With the incredibly fast growth of the IoT world, Bluetooth (specifically BLE) is a valid option for communication with smart objects. My hope is that this cross-platform library will help app developers to be able to look past the nitty gritty details of BLE implementation and to instead focus on using this technology to create great things.