Log in

Previous Entry | Next Entry


The main competitor of BLE comes from IEEE rivaling. Roughly speaking, classic Bluetooth compares to IEEE 802.12 (Wi-Fi and especially Wi-Fi Direct) standards and BLE, as native successor of classic base, compete with IEEE 802.15 (ZigBee powered with 6LoWPAN). Both players – BLE and ZigBee – fit into relatively new market segment: the low-power communication with weak demands on traffic volume, but emphasize long battery life and various network topologies. Obviously, the final cost of the standards’ implementation and its simplicity for industrial solutions is critical factor as well. Today for around $2, you can buy BLE system-on-chip (2.4 GHz radio-plus-microcontroller) solutions per chip and in low volumes, which is well below the total overall price point of similar devices for ZigBee.
From radio perspective, been low-powered simply means to sleep between short activity sessions and consequently being able to wake up as fast as possible. The implications of such sleeping to the transmission rate are very sensitive, but in the field of IoT and other low traffic domains even the rate of 5-10 Kb/s might be enough. The long battery life is more important. Official Bluetooth Core 4.1 specification declares the transmission rate for BLE device for 25 Mbps, but actually it may be may be significantly low. In reality, 10Kb/s may be the production mark for many device. Although this rate might seem slow and counterproductive, it does highlight the primary design goal of Bluetooth Low Energy: low energy. Even transmitting at these relatively modest data rates, 10 KB/s will quickly drain any small coin cell battery. The easiest way to avoid consuming precious battery power is to turn the radio off as often as possible and for as long as possible, and this is archived by using short burst of packets (during a connection event) at certain frequency. In between those, the radio is simply powered off. For example, Nordic nRF52833 SoC cay transmit up to six data packages per connection interval while each outgoing data packet can contain up to 20 bytes of user data. Now assuming the shortest connection interval of 7.5 ms, this provides a maximum 133 connection events per second and 120 bytes per connection event (6 packets * 20 user bytes per packet). Continuously transmitting at this rate gives
133 connections per second * 120 bytes = 15960 bytes/s ~ 0.12 Mbs (~12Kb/s).
TI SendorTag is advertising by 100 ms. interval.
The connection interval (usually between 7.5 – 4000 MS) is dictated by Central device, but no Android, nor do iOS applications have no control on connection parameters.
So, in practice, a typical best-case scenario should probably assume a potential maximum data throughput in the neighborhood of 5-10 Kb/s, depending on the limitation of both peers.
This gives an idea of what you can and can’t do with BLE in terms of pushing data out to the device and why other technologies such as WiFi and classic Bluetooth have their place in the world.

2. A BLE device can communicate with outside world in two ways: broadcasting and connections.  Both are based on GAP (Generic Access Profile).
Broadcasting essentially allowed for sending data out one-way to anyone that is capable of picking up the transmitted data. It is important to understand, because there is the only way for a device to transmit data to more than one peer at time.
The standard advertising packet contains 31-byte payload used to include data that describes the broadcaster and its capabilities, but it can also include any custom information you want to broadcast to other devices. If this standard payload isn’t large enough to fit all of the required data, BLE also supports an optional secondary advertising payload (called the Scan Response), which allows devices that detect a broadcasting device to request a second advertising frame with another 31-byte payload, for up to 62 bytes total. The very popular example of broadcasting is iBeacon (the format defined by Apple) or AltBeacon (the open format, aka Alternative beacon).
A major limitation of broadcasting, when compared to regular connection, is that there are no security or privacy provisions at all with it: any observer device is able to receive the data being broadcasted), so it might not be suited for sensitive data.
The widely known terms Central and Peripheral (slave) roles are applied only to BLE connection mode.
When in Central role, the device scans periodically the preset frequencies for connectable advertising packet and, when suitable, initiates the connection. Once the connection established, the central manages the timing and initiates the periodical data exchanges.
The device in Peripheral role send connectable packets periodically and accepts incoming connections. Once in active connection, the peripheral follows the central’s timing and data its data exchange regulations.
The most important mark of a BLE version 4.0 connection mode is that once the connection is established, the peripheral stops advertising and thus, becomes invisible to other device. On other hand, the two connected devices can begin a secure data exchange between them in both directions.
Starting from BLE version 4.1 it is possible, although, to connect one central to more than one peripheral device. (In addition, even a peripheral can be connected to multiple centrals).
Obviously, connections have an advantage of organizing the data with much finer-grained control over each field or property through the use of additional protocol layers and, more specially, the Generic Attribute Profile (GATT). Data is organized around units called services and characteristics, each characteristic with its own level of access rights and descriptive metadata.

To make the interoperability between various BLE devices, the profiles play significant role by organizing the use of protocols (which deal with formats, routing, encoding etc.) in order to achieve a particular goal. In this extent, they similar to 802.11 instructions for Wi-Fi.
Two profiles are very important: GAP and GATT
Generic Access Profile (GAP) defines low-level interactions with devices, roles (Central, Peripheral etc)
Generic Attribute Profile (GATT) establishes in details how to exchange all profile and user data over BLE connection, including roles (Client, Server).
It is worth mentioning that GATT roles are both completely independent of GAP roles and also compatible with each other. That means that both a GAP central and a GAP peripheral can act as a GATT client or server, or even act as both at the same time.
These profiles are often used as a foundation for APIs as the entry point for the application to interact with protocol stack.
Use-case-profiles are limited to GATT-based profiles. However, the introduction of L2CAP connected-oriented channels in BLE specification 4.1 might mean that GATT-less profiles can might start to appear in near future.
For a meanwhile, Bluetooth SIG defined the set of use-case profiles, based on GATT, covering a wide range of use case. The full list is here.

As was predicted (“Getting Started with Bluetooth Low Energy” by Akiba; Robert Dacidson, Carle Cufi and Kevin Townsend. Chapter 5. Hardware Platforms.) “One big weakness of CC2541 is the relatively dated 8051 core driving its SoC, which not only requires an expensive commercial compiler and IDE to use (IAR Embedded Workbench), but also feels quite long in the tooth compared to more modern ARM Cortex-M cores making their way into many other SoC. This will likely change in the near future, as SoC vendors feel greater pressure to move to newer cores, and IT is no doubt well aware of the trend.”
The TI’s answer was amazing: not only the modified version of SensorTag – the SimpleLink - based on modern ARM Cotex-M3 core, nor it is include more sensors like light and microphone – with a help of AOD it may be loaded not only for BLE but also for 6LoWPAN and ZigBee.
Aside well-known Android and iOS frameworks for BLE, its worth mention the intriguing JavaScript approach and new (but a lame bit) framework for WP 8.1.