Bluetooth today is understood by many as a convenient connectivity solution. Yet there are limitations regarding its flexibility and this entry serves to discuss some misconceptions about Bluetooth Low Energy (BLE or Bluetooth Smart) and classic Bluetooth.
We often receive projects that involve Bluetooth communication, yet many of our clients specify "BLE" without understanding the technology sufficiently. Many assume that BLE is simply classic Bluetooth or Bluetooth v2.x, but with much lower energy consumption. I don't blame them for the misconception, since our latest mobile devices, e.g. mobile phones and tablets have been touting BLE as if it is a replacement for classic Bluetooth. Furthermore, the name - Bluetooth Low Energy - isn’t much of a help in undoing the misconception. Hence, I have decided to contribute this article and, hopefully, it can be of help to some of you who are reading this.
Before I begin, I would like to say that this is not an extensive article. It will be about the top most common misconceptions that I have often encountered. For the benefit of those who aren't familiar with BLE, do read these pages for a good introduction (here and here).
Misconceptions
1. Using BLE to perform high-rate data streaming
At this junction, if you have read enough about BLE, you should have an inkling that it was chiefly designed for low-rate of data applications, e.g. Internet of Things (IoT) sensor nodes and Human Interface Devices (HID). Unlike classic Bluetooth, BLE has very low data throughput. This is because of the optimizations made to the Bluetooth profiles and Logical Link Control and Adaptation (L2CAP) to achieve low energy consumption.
(source)
To give a sense on how low is low data throughput, I will put forth a scenario. However, before that you have to understand that data in Bluetooth is split into packets and exchanged through one of 79 designated Bluetooth channels. The scenario that I will be putting forth will be based on a Generic Attribute Profile (GATT) structure that most BLE devices utilize with the following settings:
• ARM M0+ chip (operating frequency of 48MHz)
• Connection Interval of 7.5ms, which is the lowest setting (I will explain more later but typically, shorter connection interval results in higher throughput)
• Default Maximum Transmission Unit (MTU) of 23bytes per packet
Connection interval (CI) in BLE is defined as the time period before the radio jumps to another channel. A shorter CI will result in a lesser amount of packets being sent before the radio switches channel. Since swapping channels will result in downtime, you may begin to think that the CI should be as long as possible so more packets can be sent through one channel. The idea of having a longer CI to reduce downtime and hoping it will result in higher data transmission rate does sound feasible. However, life is often not that straight–forward, especially when it comes to Radio Frequencies (RF). A longer CI will also create more opportunities for RF interference to set in, and corrupt your transmission and connection event. Thus, it leads to an even lower data transmission rate.
Under the aforementioned settings, I typically get around 1 packet per connection event (7.5ms). In 1 second, I will get 133 packets transmitted and with an MTU of 23 bytes, my data throughput is 3059 bytes per second. However, take note that the L2CAP profile on BLE devices takes 3 bytes for the notification process. As a result, only the remaining 20 bytes will contain the actual data that you desire, if you spec-ed it for the notification process.
I hope that it is clear to you now that BLE is not cut out for high-rate data streaming. If you wish to perform high-rate data streaming like file transfers, please stick to classic Bluetooth.
2. BLE doesn't auto-connect like classic Bluetooth
Very often I am asked, "Why doesn't the BLE device auto-connect when I turn it on, even after pairing?” The answer is very simple. BLE devices don't auto-connect like a classic Bluetooth device because it wasn't designed to do so.
Natively, only classic Bluetooth like Bluetooth v2.x + EDR has native reconnect functions. However, all is not lost; you can simulate the reconnect feature by writing the feature into your software. The only problem is that your software must be running in the background for that to work. Therefore, if you are working on a device that requires constant connection, make sure you write a "ping-pong" feature to support "auto-connect".
Thank you for reading this article. Hope you find it useful and do remember to share our article. Feel free to comment below.
SHARE ON
