Bluetooth Technology for Wearable Devices

中文版 Chinese Version: 面向可穿戴设备的蓝牙技术

Wearable technology certainly made a splash at CES 2014 in Las Vegas. Several industries such as healthcare, sport and fitness, gaming, and even fashion were demonstrating next-generation concepts to see what could shape into “real” products. This market is estimated to explode over the next several years and potentially be worth $50 billion USD.

“The wearable technology area is ripe for exploration. I think there will be tons of companies playing in this space.” Tim Cook, Apple CEO

To get an insider’s view of the wearable trend, one could look at the various Bluetooth software stack vendors that are enabling the connectivity for many of these products to the smartphone. I reached out to one vendor that I found on the The specified item was not found., SEARAN and spoke to their CEO arkadypittel.

Will Tu (WT): Bluetooth first gain popularity with the mobile phone pairing with wireless ear pieces and the automotive hands-free systems. It has evolved quite a bit – what makes Bluetooth relevant today and where do you see the future trend of Bluetooth technology?

Arkady Pittel (AP): Originally Bluetooth technology was designed to work in scatternet and mesh network. To the most part it turned out to be not very practical if not possible in real world. Bluetooth applications turned out to be more simplistic, requiring in majority of use cases communication between a host (smartphone) working as a server, and several (up to seven) slave devices (clients). Although high data rates, up to 1Mbps and higher were desired for some applications, i.e. audio streaming, other apps required only occasional few bytes sent every second. Such applications were used in all sorts of sensors requiring months long operation from a single coin cell battery. This demands brought out the Bluetooth Low Energy with some different architectural characteristics. The main differences are:

  • BLE uses a wider channel - 2MHz with 40 channels (vs. 1MHz with 79 channels for Bluetooth) and has lower throughput (1Mbit/sec vs. 2/3Mbit/sec for BR/EDR)
  • BLE has three dedicated advertisement channels (less power to create connection)
  • BLE in connection behavior is close to always in sniff BR/EDR (original Bluetooth) connection, with minimum latency of 7.5msec vs. 0.625msec for BR/EDR
  • BLE has worse security, it is susceptible to passive eavesdrop attack

I tried to find a comprehensive table to demonstrate the main characteristics between BLE and BR/EDR and came across such a table on Wikipedia. I certainly have some comments (see below) and I am sure other Bluetooth developers will have also issues with this table, but at least it demonstrates some key points.

Technical Specification Classic Bluetooth Technology Bluetooth Low Energy Technology


(theoretical max.)

100 m (330 ft)** 50 m (160 ft)**
Over-The-Air Data Rate 1-3 Mbit/s 1 Mbit/s
Application Throughput 0.7-2.1 Mbit/s** 0.27 Mbit/s**
Active Slaves 7 Not defined; implementation dependent
Security 56/128-bit and application layer user defined 128-bit AES with Counter Mode CBC-MAC and application layer user defined
Robustness Adaptive fast frequency hopping, FEC, fast ACK Adaptive fast frequency hopping, Lazy Acknoledgement, 24-bit CRC, 32-bit Message Integrity Check


(from a non-connected state)

Typically 100 ms 6 ms

Total Time to Send Data

(det. battery life)

100 ms 3 ms, <3 ms[22]
Voice Capable Yes No
Network Topolgy Scatternet Star-bus**
Power Consumption 1 as the reference 0.01 to 0.5 (depending on use case)
Peak Current Consumption <30 mA <15 mA
Service Discovery Yes Yes
Profile Concept Yes Yes
Primary Use Cases Mobile phones, gaming, headsets, stereo audio streaming, automotive, PCs, security, proximity, healthcare, sports and fitness, etc. Mobile phones, gaming, PCs, watches, sports and fitness, healthcare, security and proximity, automotive, home electronics, automoation, Industrial, etc.

** Comments by SEARAN

  • In our experience, practical data throughput using embedded platforms and Bluetooth radio controller reaches 1.5Mbps for Bluetooth and about 100kbps for BLE. iOS significantly limits the throughput even further, i.e. with BLE it is about 34kbps.
  • Data range for BR/EDR class 2 is 10meters in open space and for class 1 - 100 meters; for BLE – practical is 30 meters in open space.
  • Scatternet is now allowed on BLE but not supported yet by most controllers available on the market

As you can see the major differences between BR/EDR and BLE from the product developer’s stand point are that data rates and ranges, not to mention the life battery of course.

When looking at his/her application one needs to consider all major parameters, data throughput, distance limitations and power. Anything you want to connect within 10 to 30 meters with the data throughput of up to 1.5Mbps will be a perfect application for classic Bluetooth. BLE is a different story, the data rates are much lower.

The power consumption can be a real advantage even 100 times better with BLE. However, please keep in mind that using a sniff mode with proper duty cycle and lower processor frequency leads to lower power consumption that you can run on a coin cell battery on some processors.

From the software developer’s standpoint using BLE has many other advantages, unless security is of great importance. A single mode BLE stack (without classic Bluetooth) and some specific profiles are available from chip manufacturers. However, when developers need to mix both technologies, BLE and classic Bluetooth, what is called “dual mode”, engineers need to use software stack from third party developers like SEARAN. Customers need to be also aware that in attempt to make a single BLE chip very inexpensive and low power some manufacturers chose very small controllers with very little RAM and therefore limited data throughput, for example, to 1.5KB/sec for CC254X by Texas Instruments.

The bottom line is developers need to clearly understand what user cases they want to implement. They need to choose carefully either Bluetooth or BLE, or both, to fit a great number of applications including the wearable devices.

Another consideration is connectivity with Apple devices. If your data rates of just over 30kbps over BLE is not sufficient and you need to connect over RFCOMM to speed things up then you need to use Apple specific iAP protocol and authentication chip. You also need to be an MFI member and pay royalty to Apple. From the technical standpoint, you need to consider that data throughput is somewhat lower over iAP with iOS devices than when using SPP.

Both technologies are quite mature, and unequivocally, Bluetooth and recently the Bluetooth Low Energy (BLE) became a standard feature for close proximity and modest data throughput in wireless communication on literally all smartphones and tablets. Proliferation of Bluetooth on smart-phones is the largest and most important driver behind the new wireless applications, including wearable devices.

One of the key trends in Bluetooth is its ability to “cut the wire”.  This is one of the driving forces among both consumers and many different industries, including healthcare and medical. Cutting the wire on any peripheral devices like sensors, and replacing it with a direct wireless link to a host device, connected to the internet. Here you can see that Bluetooth can enable the “Internet of Things” through a host device.

The wireless audio is another example of “cut the wire”. Bluetooth brought to market not only a single Bluetooth speaker, or multiple wireless speakers, but also control of audio streaming from many handset devices (phones and tablets) connected and working concurrently with the same speaker system.

As you pointed out there is a large variety of new wearable devices that include smart watches that notify users of voice, messages and other signals and provide a feedback to the phones; health bracelets helping calculate activity and burnt calories, smart jewelry, wireless credit cards and badges, clothes; smart glasses with cameras and the whole computers on the glasses’ frame, and many other wearable sensors and devices.

Although, Bluetooth and BLE are the only close-mid range wireless technology available on smart phones and other consumer devices, other technologies like ZigBee and ANT are trying to compete. Their low power capabilities and no limit of a seven devices per picanet are attractive. However, they mostly find applications where the host device is proprietary specialized equipment, like a health training machine, or an industrial sensor network. So far, the penetration attempts of ZigBee and ANT technologies into mobile phones had failed.

WT: Where is your company finding the most success with Bluetooth, can you share some of your successes?

AP: There are two questions here, one about SEARAN as a company and product, and the other on how our embedded stack as a technology fits in wireless product development.

If you are asking regarding our product and company, then the highest success we find with customers who need to implement BR/EDR or a dual mode (BR/EDR+BLE) on the smallest most inexpensive processor with very little resources left for wireless connectivity. The same applies when customers are trying to outfit their existing product with Bluetooth capabilities. Customers find our stack is the smallest on the market, with the memory footprint of only 3KB RAM and 40KB Flash for SPP profile. They also find that our stack’s API is easy and straightforward. Our pricing is also very affordable, and we have a very responsive support.

If you are referring to the technology, I probably should draw the line along the technological divide between a classic Bluetooth and the dual-mode, on one hand, and a single mode BLE, on the other. While we find customers interested in all applications that relate to the former, the BLE only applications have been using mostly single BLE chips that come with their own stack. Some of those wearable devices, particularly that don’t need to transmit a lot of data, and send data only (no voice or messaging), use BLE stack that comes with the BLE chip. In those cases where a single BLE stack is enough, customers don’t need an embedded stack. In most cases they are satisfied with the stack provided by the chip manufacturer. However, if the wearable device needs higher data rate, send or receive voice, audio, or other signals that BLE is not capable of, the customers need a dual mode stack. Also if the wearable device communicates with legacy devices that don’t have BLE yet, or like Android have BLE but did not yet open it up for development, then they require an embedded dual mode stack.

Another area where we excel is when customer needs to optimize processor utilization for the maximum performance. To reach maximum efficiency we help customers fine tune their application. Here’s a diagram showing different performance with different RFCOMM buffer sizes and numbers of buffers, for Cortex-M3 by STMicroelectronics, STM32F103ZE with The specified item was not found.'s CSR8811 dual mode Bluetooth controller.

WT: Maybe a better way to ask this is what is your favorite Bluetooth enabled wearable product?

AP: My favorite wearable product is the one we developed a few years back, a wireless Bluetooth pen that can write on any surface and via Bluetooth, instantaneously communicate handwriting or drawing to a mobile phone and internet. Unfortunately, that product did not see the market – that is a whole separate story. However, as a result, our truly embedded Bluetooth stack, with the smallest memory footprint was developed. dotstack is very attractive to many product designers who need to make their device smaller and less expensive.

There are some applications that I believe have a lot of future. Wearing a health wireless bracelet or a smart watch is very natural, and finds a lot of users who are desperate to cut calories and lose weight. Having LEDs in your clothes can be a very interesting application, and you have to wear clothing anyways. I can share with you that Erogear, one of SEARAN customers, has a very interesting implementation of this idea.

WT: Why does one chose to buy a Bluetooth Stack from a third-party versus writing it themselves?

AP: There are several things to consider. Certainly, a strong group of software engineers can write a Bluetooth stack. The question is how much time and resources they are willing to dedicate. Here are some steps through the process:

  1. Creating the Bluetooth stack itself, with variety of profiles.
  2. Integrating those profiles into various embedded platforms, writing embedded code examples, conducting stress and other tests on the whole system.
  3. Before a product can be called as supporting Bluetooth, it must satisfy all Bluetooth SIG specification requirements, be tested against Bluetooth SIG using for example their PTS test suite, and the Bluetooth SIG QDID fees have to be paid for.
  4. BR/EDR and BLE are constantly evolving. Specifications change requires constant upgrades to the latest version and functionality.
  5. Interoperability and stress testing has to be repeated.

Here’s how development and support of embedded stack looks like, in a nutshell.

If you consider all that and the fact that even a basic profile like SPP would require tens of thousands of lines of code to be written, tested and constantly supported, including many variations of parameters and Bluetooth features to be used, then the obvious decision for many is to choose a good stack that is supported by a team of dedicated Bluetooth developers.

WT: How does one go about evaluating a Bluetooth stack vendor?  What are the main reasons customers ask to see before they buy?

AP: First, the customer needs to know what they really want and can achieve from Bluetooth. We spend a lot of time understanding customer needs and advising them on their architecture. We urge customers to start working on integrating Bluetooth into their product architecture as soon as possible. Here is just one table by SEARAN with a set of profiles to demonstrate memory parameters and MIPS requirements. Certainly, there are many other details of the design to be taken into consideration.

As you can see from this table our RAM and Flash footprint allows fit the Bluetooth solution into very small, inexpensive processors freeing valuable space and resources for the application code. We help our customers at each step of the way, and those who work with us, listen to our advice have successful projects at least as far as Bluetooth is concerned. Unfortunately, many a times we run into companies that already developed their hardware based on some cursory advice and then start shopping around for Bluetooth stack with a set of profiles and features that their hardware would not support.

Once customers know which profiles and features they need, they want to learn the basic differentiators between embedded stack Bluetooth vendor: memory footprint on processor of their choice, specifics of different Bluetooth controllers, whether to use an RTOS or a proprietary scheduler (no RTOS), MIPS requirements for different profiles and applications. We start by asking our customers very specific questions, i.e. their product data throughput, low-power modes requirements, needs for specific audio codecs and architectures, need for multi-connect and multi-channel modes. During evaluation process, our customers would like to see a working demo, and we have quite a few!

WT: It seems that, the Bluetooth and BLE, both very well established technologies, are still evolving and changing to address new markets. On the embedded front, like wearables, memory resources are limited and working with a company like SEARAN gives customer the ability to get a stack that serves their specific needs instead of putting it all in and pay for unnecessary memory costs. Certainly a company like SEARAN not only offers software but their expertise in how to optimize it for an application, and chose the right hardware as well. SEARAN seems to have a considerable portfolio of off-the-shelf solutions, many on ARM Processors, which is particularly appealing to us. That allows for quick validation of Bluetooth solution and even more in-depth development using available development kits before committing to your own hardware.

  • Great write-up Will. I certainly know more about Bluetooth now! As you are currently at Embedded World, I am sure you are seeing all sorts of applications there, with the common threat being Bluetooth connectivity. In-vehicle connectivity, wearbles etc..