One of the ubiquitous wireless communication methods has gotten even better. Bluetooth SIG has released Bluetooth 5 (BT5), an enhancement to the current Bluetooth Low Energy v4.2. The key updates to Bluetooth 5 are 8x data, 4x range, and 2x speed, as well as improved interoperability and coexistence with other wireless technologies. For a designer and consumer, here’s what you need to know about the new BT5.
1. Eight times the data
BT5 sports a larger broadcasting capacity. The size of the message has increased from 31 to 255 octets. To be more specific, the broadcasting capacity affects only the advertising message. This is particularly useful for a beacon-like application, whereby longer sensor data can be transmitted without pairing a device.
On top of a larger broadcasting capacity, BT5 also introduced a new feature called “Advertising extensions”. This is to alleviate the possibility of the three advertising channels being over-congested, as there might exist beacon-like devices with a large broadcasting message and slow on-air transmission rate such as 125kb/s. The new feature mitigates this by keeping the shorter advertising message on the three advertising channels and offloading the longer data broadcast message to a pre-selected non-advertising channel (out of the 37 broadcasting channels). Another function of “Advertising extensions” is the ability to chain advertising packets to create a longer payload (>255 octets). This is akin to a long write, whereby a longer payload is broken down and sent via multiple max octet messages.
2. Four times the range
BLE 4.2 has a typical range of 10 to 20m and the new BT5 specification quadruples the range over which devices can transmit and receive data. In one of the demo videos from Nordic Semiconductor, a BT5 device was tested in a clear line-of-sight outdoor environment and it covered well over 770m (link)! However, there’s one caveat: the longer range the lower your data throughput.
With a longer-range coverage, this opens BT5 to a new set of potential applications and use cases. Product designers could now potentially design wireless home appliances to cover an entire house, e.g. a wireless sound bar system connected tightly to your phone regardless of the phone location within the home while keeping crisp and clear sounds wirelessly transmitting to the soundbar.
3. Twice the speed
The next major enhancement for BT5 is doubling the transmission speed from 1 to 2Mb/s while still using the same Gaussian frequency shift keying (GFSK) modulation. Coupled with advancements introduced in BLE 4.2 which allowed for Data Length Extensions (DLE), the overall throughput is 5x higher than BLE 4.0. The improved data rate means a decrease in the transmission time for data, giving designers the ability to design new applications that simply need more data throughput than was possible previously such as enabling much faster Over the Air Device Firmware Upgrades (OTA-DFU). Nordic Semiconductor has written a blog on this with a demo video to showcase the enhancement transmission speed of BT5 (link).
4. Improved operability
With the 2.4GHz ISM band getting increasingly congested, there’s always a possibility that our other 2.4GHz devices, e.g. LTE-enabled devices, get interfered or interfere with our Bluetooth device. Bluetooth SIG has introduced slot availability masks detection to prevent such interference. This feature works with the Mobile Wireless Standard (MWS) system.
Nordic Semiconductor nRF52840 Bluetooth 5-ready SoCs
THESIS now offers BT5 project development capability based on Nordic’s new nRF52840 and nRF52832 multiprotocol SoCs which are designed to take advantage of these significant performance advancements of BT5. Nordic’s nRF52840 is based on the powerful 64MHz Cortex-M4F microcontroller that meets the needs of the most demanding complex arithmetic applications such as inertial measurement (IMU) and biosensor analogue signal processing. The chip supports DSP instructions, HW accelerated Floating Point Unit (FPU) calculations, single-cycle multiply and accumulate, and hardware divide for energy-efficient processing complex operations.
The nRF52840 also has an improved output power of 8dB on top of the long-range features in BT5 and development on the nRF52840 is supported by KEIL, IAR and GCC. The chip also has a host of other power-saving features for extended battery life, a powerful on-chip cryptographic coprocessor that incorporates a true random number generator (TRNG) and support for a wide range of asymmetric, symmetric and hashing cryptographic services for secure applications and on-chip NFC.
And BT 5 is backwards-compatible with the 4.x versions. With these key improvements, BT5 is set for greater adoption in the Internet of Things (IoT) arena. New applications in the consumer home-automation space, such as controlled lighting, are possible. This is especially true for industrial IoT, where the new BT5 features are a good fit for low-data-rate sensor reading with greater range, security, and reliability.
If you’re looking for wireless technology for your IoT/smart-device project, have a chat with us to discuss the future possibilities of incorporating BT5 to speed up and simplify new product designs for your business.
During the height of iBeacon, google released a similar and more powerful proximity beacon protocol called EddystoneTM in July 2015. The protocol was designed to be platform agnostic and more flexible in the data that can be broadcast. The key features were designed to make it a better platform than the iBeacon protocol. App developers can find more information on the available API here.
However flexible google wishes to design the EddystoneTM to be, they have to keep in mind the space limit of a BLE broadcasting data. Instead of trying to cram all sort of data within the data limit, google overcame the problem by introducing “frames”. A total of 3 different data frames was designed into the EddystoneTM protocol- namely UID, ULR and TLM. Each frame was designed to carry different set of information to fulfill the broadcasting need of most proximity beacon.
UID
The most basic of the EddystoneTM protocol with frame specification that is very similar to the iBeacon’s. In this frame, user will have to indicate the unique ID of the device, the instance ID and the transmission power. The unique ID is also known as namespace, which is a 10bytes data. User can generate it using an online UUID generator. The instance ID works the same as the Major and Minor ID from iBeacon. Finally, the transmission power, aka ranging data. To calibrate this – “Tx power is the received power at 0 meters measured in dBm. The value may range from -100 dBm to +20 dBm at a resolution of 1 dBm (source)
Note to developers: the best way to determine the precise value to put into this field is to measure the actual output of your beacon from 1 meter away and then add 41 dBm to that. 41dBm is the signal loss that occurs over 1 meter.”
Unlike the iBeacon’s transmission power which was supposed to be measured at 1m range, EddystoneTM requires the transmission power to be measured at 0m instead. However, noting from the calibration information provided by google, the transmission is supposed to be measured at 1m range and you add 41dBm to account for the signal loss over 1 meter. The result is the transmission power at 0m.
URL
This frame is designed to house an URL for your proximity beacon to broadcast. Do make sure to indicate “0x10” in the Frame Type byte, else the EddystoneTM APP API will not recognize the frame properly. Following that is the transmission power, which can be calibrated with the same procedure provided in the above section. The URL scheme indicate which html prefix to be appended to the decoded URL and currently, there are 4 options to choose from:
Finally, it’s the encoded URL. For example, if I wish to broadcast “onethesis.com”, my encoded URL will looks like “0x6f6e6574686573697300” (with padding: onethesis = 6f 6e 65 74 68 65 73 69 73), note that the data is entirely in hexidecimal). The string is ended with the URL with “0x00” which will be decoded as “.com/”. A full list of the ending character is listed below:
TLM
This frame is also known as the telemetry frame. It holds device specific information which could be useful for debugging or data-logging purpose. To start with, user must indicates “0x20” in the Frame type and followed by the TLM version. The subsequent data are device specific information like battery voltage, Beacon temperature, Advertising PDU count (ADV_CNT) and Time since power-on or reboot (SEC_CNT).
Battery voltage is in 1mV per bit resolution. Beacon temperature is in degrees Celsius expressed in 8.8 fixed point representation. ADV_CNT counts the number of advertising frame that has been sent since power-on or reboot. SEC_CNT is a 0.1 second resolution counter. It is not necessary to provide all of the data. User can choose to obscure certain data by simply not updating the values.
One important note about this frame is that it cannot be a standalone frame in the EddystoneTM protocol. It should always be used in conjunction with the UID or URL frame.
Resources
As usual, for firmware developer, Cypress Ez-BLE pioneer kit provides easy access to learning this protocol and Cypress has provided some examples for their users as well (source).
What are the differences between Notify and Indicate?
The short answer is that they both basically do the same thing, except Indicate requires acknowledgement, while Notify does not. For the longer answer, please read the rest of my post.
By default, you cannot push data to your remote client whenever your Bluetooth low energy (BLE) device has new data to publish. If you read my previous post, you will know that you need to enable the proper permission and include a “Client Characteristic Configuration Descriptor” (CCCD) for that to happen. Not forgetting, your remote client must subscribe to the attribute via the CCCD to receive the pushed data.
Typically, people push data when they want their remote client to asynchronously receive updates whenever their BLE device has new data. While you can perform a periodic polling, the method wouldn’t be very energy efficient and you will not get the quickest update (this depends on your polling rate). Also your BLE device might get updates in an aperiodic fashion, so periodic polling is an utter waste of energy. Furthermore, polling requires two-way communication and Notify is one way, so you will save on radio airtime which would lead to further energy reduction. However, because Notify is unacknowledged, it is unreliable since you will not know whether your remote client has received the data.
To rectify that, let me introduce the Indicate feature. It is almost the same as Notify, except it supports acknowledgment. Your remote client will have to send an acknowledgement if it has received the data. However, such reliability comes at the expense of speed since your BLE device will wait for the acknowledgement until it has timed out.
Conclusion
For most use cases, I would recommend you start with Notify until you find out in your test environment that data is dropping out, then you move into Indicate. In any case, Indicate might take up additional airtime, but it shouldn’t drastically affect your use case. If the communication speed of Indicate is bordering your requirement, then perhaps you should be looking at alternative wireless technologies because BLE is not meant for high-speed communication.
Hey folks, I am back with another article on Bluetooth Low Energy (BLE). In my previous article, I addressed some common misconceptions between classic Bluetooth and BLE. This time, I will be talking about one of the most commonly used profiles for a BLE device – the GATT, also known as the Generic Attribute Profile. Before I begin, let’s start with a good ol’ history lesson. You may ask why. Simply because I love history, and I promise it’s a short one. BLE was not always known as Bluetooth Low Energy. It was first conceived by Nokia in 2006 as Wibree. Then, it was touted to be a competitor to Bluetooth and there were articles on how Wibree might replace Bluetooth in some use cases. However, as we all know by now, that didn’t happen because Bluetooth SIG absorbed Wibree in 2010 into its current Bluetooth v4.0 specifications and BLE was born. As always, we have to thank Nokia for laying the foundation of many good wireless technologies that we have come to enjoy today. Nokia 3210, I will always love you for being my first… mobile phone. With the history lesson behind us, let’s move on with the introduction of BLE profiles and protocols. For BLE, you will use one of the following profiles or protocols:
GATT-based profiles
BR/EDR profiles
BR/EDR protocols
I will focus on GATT-based profiles as they are the most commonly used profiles in data-transfer applications.
GATT Profiles
When one looks deeper into the GATT-based profiles, one will quickly discover that Bluetooth SIG has defined many profiles for generic IoT usage. Of course, you can also design a custom profile if none of them suits your use case. However, there are reasons that Bluetooth SIG has a predefined profile. First, a predefined profile is kind of like a “plug and play” element in your design. Most BLE-chip software development kits (SDKs) would support some of such profiles and all you have to do is to enable them. This saves a lot of time for developers. Second, the predefined profile uses the 16-bit universally unique identifier (UUID) because it has been approved by Bluetooth SIG. A custom profile needs to use a 128-bit UUID to prevent collision with an existing UUID (if any) and for future-proofing the design. Having said so, a predefined profile will not be flexible when you need to transmit information that is not in the predefined list. When that happens, you will need a custom profile. At this junction, I know that some of you guys may have the tendency to “retrofit” a predefined profile for your use case, but I will not recommend that. It is better to define a custom one from scratch.
Pros-and-cons summary table
GATT Structure
As much I wish to go into great detail on the deep, deep abyss of BLE, I will give only an overview to get you chaps started. Ok, maybe it’s not that deep of an abyss and maybe it’s a shiny piece of heaven to some of you chaps. I will give only an overview. For those who wish to learn more about BLE, do read this. The best way to get started is to have a graphical representation of the GATT profile.
When it comes to designing a profile, there are three attributes that must be taken care of – namely service, characteristic and descriptor. Each attribute is demarcated by a handler number which is usually enumerated automatically by your Bluetooth chip SDK. If your SDK does not take care of that, I will just say “have fun enumerating”. So to prevent making a mess out of your code, it’s better to design and reiterate before you jump into your code, you code monkeys. One good note when it comes to designing a profile is that it’s not necessary for a characteristic to hold a descriptor, but it’s mandatory for a service to hold at least one characteristic.
Service
There are two types of services – primary and secondary. Usually, developers will use only the primary service because the secondary service can exist only under the primary service, which makes it a little tricky to use. Within a profile, you may find multiple primary services. For example, a standard heart-rate tracker will have the following services:
Device information service
Battery information service
Heart-rate service
Note that all of them are predefined services. You are encouraged to create your own service if none of the standard services fits your usage, modification to the service may yield unexpected results and it’s recommended that you write your own service characteristics. So if you look at the above graphic, you can think of service as a container for all your characteristics. During device advertising, you would usually include the UUID of the key primary services so your remote client will discover the right device.
Characteristic
A characteristic is a data container for the information that your device wishes to transmit to your remote client. For example, a heart-rate service will have a Heart-Rate Measurement characteristic to hold the heart rate that your device has detected. When declaring a characteristic, you will also determine the permission level for the characteristic:
Read
Write
Write with response
Signed write
Notify
Indicate
Writable Auxiliaries
Broadcast
The most common permissions would be read and write. One a side note, if you wish to push your data to your remote client, you will need to enable the notify permission. However, enabling the notify permission is not enough, you will also need to include the notify switch descriptor, also known as Client Characteristic Configuration Descriptor or CCCD.
Descriptor
As mentioned previously, it is not entirely necessary for a characteristic to be accompanied by a descriptor. A question that a reader might ask is, under what circumstance would you include a descriptor? That would be when you wish to describe a characteristic (like its name or function) or to include a notify switch. For the former, you would include a “Characteristic User Description” and for the latter, you would include a “Client Characteristic Configuration Descriptor”.
In Summary
In a nutshell, you use a predefined profile if the standard profile is good enough for you, and a custom one if you know what you are doing. For a firmware designer, you have to take note that the BLE GATT profile is by no mean persistent. You will need some form of non-volatile memory to hold your default values or previously captured data and instantiate your GATT profile during each device restart or power up. Now go forth and code away! Build the future.
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.
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)
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.
You’re likely to own a Bluetooth-enabled device by now – your phone is one. Bluetooth-enabled connectivity exists in a variety of consumer electronics and has become a socially understood means of convenient wireless communications.
Bluetooth capability can be found in almost every decent smartphone, tablet, wireless mp3 speaker and in-vehicle entertainment system to even household appliances like a rice cooker or refrigerator.
However, did you know that there are many versions of Bluetooth? Since its inception, Bluetooth has been a wireless technology standard for exchanging data over short distances via small Personal Area Networks (PANs) and it has evolved over the years with newer functionality and capabilities that consumers know little about.
Bluetooth has now evolved to Bluetooth 4.0 standards and beyond – also known as Bluetooth Low Energy (BLE4.0), Bluetooth® Smart or simply “BLE” or BLE4.0.
Bluetooth Smart Technology: Powering the Internet of Things
As consumers demand longer battery life from their mobile devices and the power efficiency of communication modules has come under scrutiny, a device with Bluetooth connected all day will undoubtedly lead to a decrease in battery life. Bluetooth® Smart is the intelligent, power-friendly version of Bluetooth wireless technology.
Bluetooth® Smart is a new generation of Bluetooth connectivity with enhanced power efficiencies targeted at mobile battery-powered applications, yet retaining its ability to be backwards-compatible with all other versions of legacy Bluetooth. You can pair existing Bluetooth headsets with a new smartphone or tablet you already own or new Bluetooth headsets with older mobile devices.
Now, because of BLE, consumers are seeing everyday objects featuring Bluetooth connectivity. Developers are attempting to make devices “smart” by incorporating Bluetooth, and today we start to see smart locks such as SKYLOCK and Noke lock marketed with BLE-enabled features.
New applications have also been made possible with BLE. Ever forgotten where you placed your keys at home? Tile is one such product targeted at short-distance location-tracking. Consumer reaction has been somewhat lukewarm, but that hasn’t stopped similar products from popping up, such as Lupo, Pebblebee, Hipkey and XYfindit just to name a few.
With BLE’s ability to connect to smartphone apps seamlessly; developers and sports and fitness companies are empowered to integrate this new technology. The market is now seeing a wide range of devices such as Bluetooth-connected heart-rate monitors, clothing and even running footwear.
What does this mean?
The world is exploding with an incredible array of devices connected via BLE. Everyday appliances and devices can now be seamlessly connected to a control device – the most ubiquitous is your smartphone and this development is accelerating the growth of the Internet of things (IoT).
Research companies Cisco, Texas instruments and ABI Research project that some 30 billion to 50 billion devices will enter into the IoT ecosystem by 2020. What this means is that IoT will have a tremendous impact on businesses, consumers and everyday life.
These newly connected devices will produce new types of data that will, in turn, produce new information and knowledge that enable a gain in business efficiencies and enhance customer and consumer satisfaction. IoT will also have a profound impact on people’s lives. It will improve public safety, transport, and healthcare with better information and faster access to this information.
Imagine waking up for a run listening to music with headphones that monitor your heart rate and pace. Your smart-toothbrush will have sensors and algorithms that monitor the state of your dental health. These Bluetooth-connected devices are targeted at reducing wire clutter while allowing you to benefit from the convenience, empowerment, and freedom of BLE technology.
Developing with Bluetooth Smart
As a developer, Bluetooth® Smart is a powerful technology enabler limited only by your imagination and creativity. What are the advantages of BLE over legacy Bluetooth 2.0?
Reduced power consumption – BLE4.0’s Ultra-low peak, average and idle mode power consumption consumes half as much energy when active and transmitting, and 1/100th the energy when in sleep mode. This means longer battery life for mobile devices with an ability to operate for months or years on standard coin-cell batteries. In many cases, it makes it possible to operate these devices for more than a year without recharging.
Enhanced range – The majority of Bluetooth devices on the market today include the basic – 10m range of the Classic Bluetooth radio, but there is no limit imposed with BLE. Manufacturers may choose to optimize a range of 50m and beyond, particularly for in-home sensor applications where a longer range is a necessity. Increased modulation index provides a possible range for BLE of over 100m.
Simplified pairing process – Pairing is now quicker (down to 0.1s instead of 2.0s) and can be done from within an iOS app (instead of having to go through Settings). No complicated handshaking. Just press a button within the app – you’re paired!
Background operation – Once paired, the Bluetooth device can wake up the mobile device with a pop-up notification or an interrupt, even when the app is in the background.
Convenient data retrieval – Obtaining data is no longer constrained by the Classic Bluetooth profiles or Apple’s proprietary 32-pin connector and its expensive MFi Program, which in turn results in a shorter, simpler and cheaper development cycle.
Backward compatibility – BLE allows two types of implementation, dual-mode and single-mode and the resulting architecture shares much of Classic Bluetooth technology’s existing radio and functionality resulting in a minimal cost increase compared to Classic Bluetooth technology. Manufacturers can also use current Classic Bluetooth technology (Bluetooth v2.1 + EDR or Bluetooth v3.0 + HS) chips with the new low-energy stack, enhancing the development of Classic Bluetooth-enabled devices with new capabilities.
Frequency hopping – BLE uses the adaptive frequency hopping common to all versions of Bluetooth technology to minimize interference from other technologies in the 2.4 GHz ISM Band. Efficient multi-path benefits increase the link budgets and range.
Host control – BLE also places a significant amount of intelligence in the controller, which allows the host to sleep for longer periods of time and be woken up by the controller only when the host needs to perform some action. This allows for the greatest current savings since the host is assumed to consume more power than the controller.
Low latency – BLE can support connection setup and data transfer as low as 3 milliseconds, allowing an application to form a connection and then transfer authenticated data in a few milliseconds for a short communication burst before quickly tearing down the connection.
Robustness – BLE uses a strong 24-bit CRC on all packets ensuring the maximum robustness against interference.
Strong security – Full AES-128 encryption using CCM to provide strong encryption and authentication of data packets.
Common terms discussed amongst developers dabbling in BLE:
Universally unique identifier (UUID) – UUID is typically a 128-bit identifier standard used in software construction, however, Bluetooth Special Interest Group (SIG) has a set of defined services and descriptors in a 16-bit address specific to Bluetooth. Any value with a UUID can be listed as an attribute which refers to specific Bluetooth services and characteristics.
Generic Access Profile (GAP) – Controls connections and advertising in Bluetooth. GAP is what makes a device visible to the outside world, and determines how two devices interact with each other. GAP typically defines various roles for devices and identifies which device is ‘central’ and which is peripheral. Peripheral devices are small, low-power, resource-constrained devices that can connect to a much more powerful central device. Examples of peripheral devices are devices like a smartwatch, heart-rate monitor or smart proximity tracking tag. A central device will refer to a smartphone or tablet with more processing power and memory size. More information here.
Generic Attribute Profile (GATT) – A GATT is a collection of services of the characteristics and relationships to other services that encapsulate the behaviour of part of a device. GATT tables describe how data is exchanged once the device is connected; more information here.
Services – this refers to what kind of information is being transmitted; is its battery life or heart rate?
Characteristic/descriptors – this refers to a specific value type, a string value or an integer, or a character, and characteristically contains read/write/notify properties; more information here.
In other words, a GATT holds several services, where the services, in turn, hold several characteristics or descriptors.
What is the difference between Bluetooth, Bluetooth Smart Ready and Bluetooth Smart?
The terminology might seem confusing; let’s simplify it.
Bluetooth Smart Ready: Connects with both Bluetooth Classic & Bluetooth Smart devices and is sometimes called dual-mode. This represents devices with both BLE4.0 and legacy protocols; most new tablets and smartphones are as such. BLE smart ready has the advantage of utilizing classic Bluetooth profiles which have a higher data bandwidth when compared to BLE4.0.
Bluetooth Classic: Used for streaming audio or video to a device (For example a Bluetooth headset), this typically represents older legacy Bluetooth peripherals that are not compatible with BLE4.0-only devices.
Bluetooth Smart: Used for low-energy devices that communicate to smartphones (for Example Apple iBeacon, proximity marketing, and heart rate monitors), these are the new generation of BLE4.0 devices that do not have legacy protocol support.
BLE all around us
Because of this newfound power efficiency and lower cost, the viability of new use cases and applications for Bluetooth that were previously limited have reopened new possibilities.
The battery drain concerns are now largely gone; no longer will Bluetooth be an undermined connection on a mobile device. It will likely become one of the driving forces that will continue to push smartphone innovation along at its current, breakneck pace. Technology manufacturers have embraced the new technology eagerly with Apple first introducing the iPhone4S in 2013 to feature BLE-ready capabilities, and BLE is now standard on most new smartphone entrants to the market.
Because of the major improvements in power consumption, it’s easy to see BLE making a big impact on the Bluetooth accessory market and one very prominent wave is in the personal fitness and health market.
Tens of dozens of fitness trackers now available on the market are mostly empowered by a BLE chip. Xiaomi’s MiBand low-cost fitness tracker sold a sensational 6 million units worldwide and is powered by the Dialog Semiconductor DA14580. The DA14580 boasts ultra-low power consumption giving the Mi Band a previously unheard-of battery life of up to 30 days!
Not to be outdone, electronic giant Texas Instruments has a broad portfolio of BLE chip solutions for various applications such as the Microcontroller-BLE CC2541 found in the Misfit Shine, and a newer generation stand-alone Bluetooth controller, the CC2564 is found in Fitbit Surge fitness watch and Pebble Time smartwatches.
Add BLE to your projects today!
In the next few years, the fight for dominance within embedded BLE will continue apace and is, understandably, a concern for developers and manufacturers. As silicon vendors continue to compete for market share, this then brings into question what level of Bluetooth support customers and engineers can expect. 2015 seems to be just the beginning of a battle for market share among vendors like Silicon Laboratories, which recently purchased BLE module manufacturer, Bluegiga Technologies Inc. Not to be outdone, mobile chip-maker Qualcomm giant has acquired UK-based Bluetooth audio solutions provider Cambridge Silicon Radio (CSR), for $2.5 billion!
Today, incorporating BLE connectivity into your device or project is a painless process when using ready-made third-party modules allowing a designer to reduce development time and accelerate time-to-market cycles considerably. In selecting a chip for your project, developers are now spoilt for choice; it is comforting to know that there is an extensive portfolio of BLE solution providers on the market. The type of BLE chipset required depends on your intended application. We’ve tested several modules, and have selected a few prominent ones for your consideration.
The major time-saving feature of these BLE modules is that the BLE protocol stack has been designed by the manufacturer and the modules are mostly certified under various regulations in different countries required of Bluetooth devices. Furthermore, to aid development, manufacturers of these modules often provide a list of application program interfaces (API) to get your application up and running quickly.
Texas Instruments
The electronics giant’s pioneering efforts in the adoption of BLE paid off with their CC2540/CC2541 chipset seeing a large adoption in the wearable market, notably with their presence in devices like Fitbit Flex, and Fitbit Surge and the Misfit Shine.
TI’s CC254X series uses a legacy 8051 core if you’re into Embedded C and Embedded Systems Development. With such versatility, third-party companies like Bluegiga have adopted the CC2541 chipset into their BLE113 module, which serves a large community of DIY enthusiasts as well as professionals. Both Texas Instruments and Bluegiga offer development/evaluation kits to aid development. You can purchase Bluegiga’s BLE113 module by itself and fairly inexpensively.
The extensive library of APIs that is provided usually suffices to develop the services you require unless you intend to develop your own proprietary 2.4GHz protocol stack. Bluegiga allows you can create custom BT4.0 profiles using their simple XML language referred to as BGScript.
As previously mentioned, TI now offers a newer CC2564 chipset that is now featured on the Pebble Time watch. The CC2564 is a Bluetooth and Dual-Mode Controller that supports legacy A2DP for audio transmissions (this is what enables your wireless Bluetooth speaker to receive music from your smartphone), as well as Serial Port Profile (SPP) for high throughput serial data communication (notably for the voice recording feature on the Pebble Time sports).
Texas Instruments SensorTag is a reference design kit that quickly enables beginners to overcome their BLE learning curve with a host of development resources available. The SensorTag boasts a plethora of sensors (temperature, humidity, pressure sensors, an accelerometer, gyroscope and a magnetometer), and the data is easily retrievable with its accompanying app.
It also passes federal certification FCC (US) / ETSI (Europe) / IC (Canada) for Radio Frequencies (RF). There is a section detailing the certifications the SensorTag has received and the steps that you can take to certify your own product.
Nordic Semiconductor
Nordic specializes in ultra-low-power performance wireless Systems on Chip (SoC) and connectivity devices for the 2.4GHz ISM band, with power consumption and cost being the main focus areas. With these core focus areas, it’s no wonder Nordic’s BLE solutions have one of the best value-for-money and power efficiencies in their class.
Nordic’s nRF8001 solution is present in Fitbit Flex activity trackers, and key features of the µBlue nRF8001 include:
· Highly integrated single-mode slave solution; · 32-pin 5x5mm QFN package; · Fully embedded radio, link controller, and host subsystem; · Profiles and application examples included within the µBlue SDK™; · Sub 15mA peak current consumption; · Microampere range average current consumption; years of battery operating life for coin cell battery-powered applications (depending on duty cycle).
Fitbit chose to adopt an SoC design. This approach effectively reduces the physical footprint required to allow a smaller device size, which is justified by a sufficient sales volume of more than 900,000 units in just the latter half of 2013.
However, this approach will be more expensive for small-volume developers and Nordic has licensed its technology to dozens of third-party vendors with a large selection of BLE modules utilizing Nordic chipsets that you can consider for your product. The external links provide valuable information on specific features, Minimum Order Quantity (MoQ), sales channels and pricing of respective third-party vendors.
Nordic has also unveiled party Japanese ODM vendors producing BLE modules based on its newer more power-efficient nRF51822 chipset. One module that we’ve used is Fujitsu’s latest MBH7BLZ07 module which is a drop-in solution with an embedded antenna and a footprint size of only 11.5×7.9×1.7mm.
Cambridge Silicon Radio (CSR)
CSR has been a world leader in Classic Bluetooth for audio transmission. Your Bluetooth headset is likely powered by a low-cost CSR bluecore chipset.
CSR developed its proprietary aptX advanced audio codec BLE profile that is superior and yet compatible with legacy A2DP for profiles for audio transmission. CSR’s AptX compression algorithm boasts low latency transfer rates suitable for audio applications with the added advantages of superior battery life. However, you will need to license these technologies and they often come with a hefty initial investment if developers choose to adopt the SoC approach.
For other BLE data transfer applications, CSR now offers a broad range of BLE kits, notably the CSR8510 which is a dual-mode BLE that supports both the Classic Bluetooth and new BLE profiles. Some designers prefer to have a Bluetooth® Smart Ready dual mode built into their product for backward compatibility.
With its acquisition by Qualcomm, stand-alone product offerings by CSR might become more B2B focused; however, third-party manufacturers such as Bluegiga’s BT111 module still feature the CSR8510 chipset and in another development in the intense battle for market share dominance, Bluegiga has now been acquired by Silicon Laboratories.
Dialog Semiconductor
Dialog Semiconductor is a UK-based company with customers that include Bosch, Sharp, and Samsung, is a smaller less-known underdog in the market of BLE solution providers.
The company recently gained prominence with the successful adoption by Chinese consumer manufacturing giant Xiaomi. Dialog’s DA14580 powers Xiaomi’s Mi Band activity tracker and by far leads the industry in terms of the lowest current consumption and also sports a very decent Flash and RAM capacity size.
If you’re looking for a certified module option, Murata’s LBCA2HNZYZ module is based on the DA14580 – a tiny 7.4×7.0x1.0mm (requires external crystal though) in size and a great selection for any low-power applications.
Murata’s LBCA2HNZYZ is a Bluetooth® Smart module that supports Bluetooth v4.1 BLE standards. All protocol stacks required for Bluetooth low-energy communication are built in, including various healthcare profiles.
Cypress is an American semiconductor design company and it has been making waves in the area of semiconductor innovation with several big-name company acquisitions and versatile product offerings. They offer memory chips, peripheral controllers, touch sensors and proprietary microcontroller architectures.
Their PSoC 4 BLE and PRoC BLE product portfolio has a very short learning curve for any designers new to BLE and offers a plethora of built-in analogue and digital functionality and features capitalizing on their PSoC’s built-in components (Capacitive sensing, ADC, DAC, Op-amps, RTC, I2C, SPI, UART, USB, etc).
Cypress’s PRoC BLE Module is a tiny 10x10x1.8mm module that has already been certified in the US, Canada, Europe, Japan and South Korea, which is great news for developers and expediting a faster time to market.
These truly “plug-and-play” systems come with high reliability and customizability, and you can easily expand beyond these countries to the other markets which recognize some of these certifications.
Certifications
Consumer safety is of paramount importance and should always be an active consideration for any developer. Devices with communications capabilities could pose potential RF interferences or electromagnetic incompatibilities. Certifications ensure that the product is safe and that the RF energy emitted is harmless to the human body. As such, communications devices are regulated by the Federal Communications Commission (FCC) for consumer consumption within the United States and by European Commission (CE) for usage within the European region.
To get a Bluetooth or other wireless product on the market, there is a range of qualifications and approvals you will need to meet to prove that the products meet wireless standards. This qualification involves both testing and paperwork, which can be a relatively complex and costly process for those unfamiliar with the process. Approvals under wireless and teleregulatory standards cannot be obtained on chips alone; they can only be acquired for complete products or sub-systems/modules.
Today, many of the world’s best-known module manufacturers offer modules. These modules are available with the necessary external circuitry and are either partially or fully qualified (with/without integrated antenna) towards relevant wireless standards.
If it is expected that your product will gain significant market share, it is worthwhile for the company to focus on increasing profit margins and move away from procuring BLE modules to adopt an SoC solution instead and acquire its own certifications.
However, the process of doing so requires dedicated R&D effort, Bluetooth SIG membership registration, a declaration to list its products, and certification of the product with regulatory bodies like FCC and/or CE clearance. Let’s explore the options:
CE marking is mandatory for certain product groups within the European Economic Area (EEA), Switzerland and Turkey. The manufacturer of products made within the EEA and the importer of goods made in other countries must ensure that CE-marked goods conform to standards. CE in that sense is similar to the FCC’s Declaration of Conformity which is used on certain electronic devices sold in the United States. Most countries recognize these qualifications and thus permit sales of the product in their respective domestic markets (such as Singapore).
Manufacturers and companies typically strive to achieve such FCC or CE (and a less common UL or CSA) certifications on their products prior to global distribution to expedite entry into the target market by conformance to the country’s economic regulations.
More information on certification processes can be found from certifying agencies such as TÜV Rheinland, and from certifying agencies in Singapore including TÜV SÜD PSB, BSI, and SGS.
Summary
As a developer, there’s no shortage of resources and tools to aid you with your BLE development for your next project. Depending on your level of expertise, there are many development kits and modules from various manufacturers to choose from, and should you choose to use a module, beyond the skills already mentioned, you’ll likely need surface mount soldering tools and abilities to build a prototype board. Not sure how to go about it? Give us a buzz and let our experienced team assist you!
When you intend to incorporate BLE into your existing or future designs, decide whether to use an SoC approach or purchase an existing module after weighing the pros and cons ( mode of application, projected volume, target markets, required certifications, etc). Most designers find it easy to define the “what” about their project, but it is always the “how” which is more difficult.
At the highest level, you can go straight to the chips themselves and design your own custom board. As pointed out above, OEM manufacturers offer a variety of cores and features to fit your full custom product design. With the onset of BLE v4.2, faster and higher transfer throughput with security upgrades and lower current consumption are available for future designs.
