As we found from our own experience at Stanfy, before diving too deeply into hacking with BLE enabled hardware, it is good to understand some basic concepts and have an infrastructure ready. Bluetooth Low Energy is great for connecting simple devices like sensors but can also work well for heavier applications.
(Image: don.github.io)
Below is a summary of important information about Bluetooth standard, practical limitations and tools needed to effectively develop BLE software.
If you are making a decision on which communication standard to choose, make sure to check our review of existing IoT technologies and wireless protocols.
Bluetooth Classic VS Bluetooth Low Energy – they have different stories
There are a couple of points that need to be understood about the variety of Bluetooth before proceeding to the actual implementation of software or even thinking about hardware.
A lot of confusion is caused by the fact that Bluetooth and Bluetooth Low Energy are rather different things:
- Classic Bluetooth. The wireless standard for transferring data over a short distance originally invented as a replacement for wire communications, it is widely used for a variety of tasks including raw data and file transmission, audio transmission for headsets and audio systems and controlling devices remotely.
- BLE (Bluetooth Low Energy) is also known as Bluetooth Smart and is a branch of the Bluetooth 4.0 standard. It is a much more limited version compared to Classic. Its main function is as a communication link that requires very low power and can be implemented on devices with limited power (beacons, sensors etc). Compared to the main standard it demonstrates important differences in how a radio signal is transmitted, reduced data transfer rates, limited amount of supported profiles (or how data is exposed), reduced timing intervals to minimize delays when initiating connection and transferring data.
| Bluetooth Classic | Bluetooth Low Energy | |
|---|---|---|
| Range | 100m (Class 1) | ~100m |
| Payload throughput (net) | 0.7–2.1 Mbit/s | ~120 kbit/s |
| Latency | 100ms | 6ms |
| Minimum time to send data | 100ms | 3ms |
| Voice support | Yes | No |
| Reference power consumption | 1W | 0.01 - 0.5 W |
(combined data from: Wikipedia, "Getting started with BLE" )
Unless you want to transfer large amounts of data via Bluetooth link – BLE can be an ideal solution, especially in the areas of sensors, wearable electronics, and medical devices, among others.
Choosing between Bluetooth Classic VS Bluetooth Low Energy? We have a solid expertise with using both Bluetooth Classic and BLE in mobile apps on Android and iOS platforms for our clients. Let's talk!
Bluetooth LE Communication Architecture
There are two parties involved in Bluetooth LE links: Server (has data; it is normally your sensor device) and Client (consumes data). Smartphones can play either of these roles depending on the task that you are solving.
When connecting BLE-enabled external devices to a host device like a smartphone, a common configuration would be a BLE Device as the server and iPhone/Android as the client. In the documentation of BLE those are also referred to as Peripheral (Server) and Central (Client).
Generic Attribute Profile (GATT) - How information is represented
Peripheral (Server) by its nature can be more than just a simple device that pumps data. It may have some useful functions like “unlock the door lock”. BLE standard provides a unified view for those cases.
If you are at least a little familiar with Bluetooth spec (let me know if you managed to get through the whole spec), then you know that it supports an enormous amount of different protocols on the application level. BLE adopted only one of those, called Generic Attribute Profile (GATT), based on Attribute Protocol (ATT).
GATT is a service based profile and this means that next. You can imagine Peripheral as a service provider. Those Services expose raw data or perform an activate action on a device (writing data is equal to issuing command). Each service in turn has a set of characteristics that can be read and written. This forms a tree:
Additionally, BLE standard also allows you to describe the type of information in Characteristic by specifying it via descriptor. This is especially valuable if available data is measured in standardised units like millimeters, inches, fahrenheit etc. The full list is available on Bluetooth web site.
Each Characteristic is also defined by properties which clarify how you can use it: read, write, write-confirm, subscribe etc (p 3.3.1.1 Vol 3).
Services and Characteristics have their own Identifiers (UUID), which can be used for direct access without a need to scan the whole tree.
There are a number of higher level profiles built on top of GATT for specific needs like Heart Rate Profile, Proximity profile, Device Information Service (you can read more about defined profiles on the BLE page).
Data formats and capabilities with Bluetooth LE
It’s important to mention that before defining your own service and a set of characteristics, please check the BLE standard for the list of adopted services. This will help you to integrate with existing software or system-provided functionality by keeping naming conventions in line. For example if you are building a medical device and want to measure heart rate or blood pressure, there is a set of predefined services and characteristics for that.
GATT supports a range of simple data types, starting from 1 byte values to Arrays of bytes and strings. Just keep in mind that big chunks would take time to get transferred (why? read further).
BLE Data transfer limits
By default GATT limits the size of single packet to a value defined as MTU.
Maximum Transmission Unit (MTU) by Bluetooth 4.1 standard for LE connections is 23 bytes (usually 20 bytes at top protocol levels, other bytes are used for service information). But there is a procedure called “Read/Write Long Characteristic Values” that allows you to go over the limit with a series of messages. In practice this means that you’d be able to have a transfer ratio of around 125 kbps (133 connections per second * 6 packets * 20 bytes in each packet - see “Getting started with BLE”). Some people claim to achieve up to 200 kbps ratio on certain chips. If you need higher transfer rates, you should consider protocols other than BLE.
Apple limitations when dealing with Bluetooth and Bluetooth Smart (BLE)
Out of the box you can start developing an application for iPhone or iPad without any problems if you are happy with BLE. At the same time, if you need Bluetooth Classic - you’d have to pass MFI certification and enter Apple’s MFI program. After that you’d be given access to software frameworks enabled to work with Bluetooth Classic.
Quote from Apple docs: The Core Bluetooth framework provides the classes needed for your iOS and Mac apps to communicate with devices that are equipped with Bluetooth low energy wireless technology.
When designing peripherals to work with Apple devices or selecting Bluetooth chips for your hardware product, please make sure it complies with Apple requirements (starting from physical level to security and supported profiles). This one has a lot of different restrictions like:
- The accessory should not require special permissions, such as pairing, authentication, or encryption to discover services and characteristics.
- To incorporate authentication in an accessory design, the accessory should support the Authentication Specification of MFi program.
In our experience, BLE did its job pretty well on a number of projects.
Essential Bluetooth LE tools for software developers
If you are a Mac user, you should definitely start with a set of tools provided by Apple in Hardware IO tools for Xcode (you need to be a registered Apple developer). They contain probably everything that you might need when dealing with Bluetooth devices: Bluetooth Explorer, Packet Logger, Bluetooth validation Guidelines, and more.
Bluetooth Explorer will give you all possible information that you might need starting from the physical level and radio signal parameters to the ability to work with GATT services. For BLE inspection you can use the Low Energy Devices tool to quickly sniff out advertised services and their characteristics and also update data there. This is especially useful when you want to validate what your device is broadcasting.
Light Blue. Nice and simple tool to work with BLE devices that allows you to see what is being broadcasted and to manipulate its characteristics. It does not have a pile of other functions like Bluetooth Explorer. MacApp, application for iOS.
Also if you prefer command line tools then check BlueZ package for different tools available there. Among them gatttool. As you might have figured out by its name, it lets you work with services and characteristics of GATT-based Peripheral.
While editing this article, I got a suggestion from @VitaliyMal to mention another useful tool for Mac users: Bluetooth Logs. This one can help figure out what is going on underneath the hood when building for Mac or iOS devices.
Setting Up a Bluetooth LE Virtual Peripheral - an Emulator
An important question when building software for BLE device is “how to test it”. It has to be answered before jumping into the volcano of problem solving. Of course we can stub multiple layers on the client application to test separate units but for integration testing that won’t be enough. When that moment comes having a real device is great. Even more - you have to have the latest version of the device to test at some point. But lets face reality: when was that last moment when you had everything you needed when writing that app? Having something instead of a real device is essential in the early stage.
Here are several ways to do that from our experience:
- One way is to allocate some mobile device and use it as a BLE host emulator. For example an Android phone or an iPhone. Create an app that would emulate the host device and you are ready to run the tests.
- Set up a service on a desktop/laptop machine. This would be ideal in case you want to keep all integration and test environments running from a single place.
- Use one of the prototyping boards with a bluetooth module. The big advantage in this case is that you can use exactly the same Bluetooth module as you have on your product. Plus you can set it once and put it somewhere nearby in the office running 24/7. And you can select one with the Operating system of your choice.
The big advantage of iOS and Android platforms in this case is their well done foundation for BLE, so there is no need to bother about low level stuff like managing connections, security, etc (unless that is a crucial part of your solution). The same applies for Mac apps.
If you’d like to run your Emulator equally on a Mac laptop (when developing) and Linux-based board (when running integration tests) there is also a quick solution. Check out Bleno – Node JS app which you can extend to match your own needs. It is based on a BlueZ library and is probably the quickest solution to setup.
Choosing between Bluetooth Classic VS Bluetooth Low Energy? We have a solid expertise with using both Bluetooth Classic and BLE in mobile apps on Android and iOS platforms for our clients. Let's talk!
Other useful links
- Bluetooth Core specifications - huge documents but generally well organised
- BLE overview at Bluetooth.org
- “Getting started with Bluetooth Low Energy” book
- BLE physical capabilities and comparison to Bluetooth Classic
- Bleno peripheral simulator library
- Apple Core Bluetooth programming Guide
- BLE in Android
If you find the article valuable – please share it with your network and help to spread the word. If you have something to add, post a comment. Thank you!
