Bluetooth Low Energy

Undergone at
Samsung Research Institute, Bangalore














Submitted by
Harvinder Singh
11114018









SUMMARY
Samsung R&D Institute India - Bangalore is one of Samsungs Research & Development
centres among other global R&D hubs. It develop software for Samsung's technology
solutions across different products and the engineers are involved in many of Samsungs
strategic and important projects. I worked in Printer Solutions Group.
Problem
Bluetooth low energy or Bluetooth Smart is a wireless personal area network technology
designed and marketed by the Bluetooth Special Interest Group.
This Project is aimed at enabling Bluetooth Low Energy communication between a Bluetooth
Low energy peripheral chip and handheld mobile devices. This Bluetooth Low Energy
peripheral device was then connected to mother board of a computer.
Solutions
To achieve the above mentioned aims, a CSR uenergy microcontroller device was used as
Bluetooth Low Energy device. Using CSR uenergy SDK, an application was to be created to
transmit required data through CSR uenergy microcontroller. An app was to be created on an
android phone to receive the data from BLE devices. Then, middleware and drivers were to
be created for connecting the microcontroller to the motherboard of computer.
Achievements
First, an android was created to scan nearby bluetooth devices and connect to them. Then
using CSR uenergy SDK an app was created to transmit company specific data to nearby
BLE enabled devices. Then I worked on the middleware to connect the CSR uenergy
microcontroller to the motherboard.













INTRODUCTION
Wireless is no longer a luxury, it is a necessity. Bluetooth has been one of the most well
known of the wireless technologies over a considerable period of time. Bluetooth technology
is a short-range communications technology whose robustness, low power, and low cost
make it ideal for a wide range of devices ranging from mobile phones and computers to
medical devices and home entertainment products. The base technology is defined and
maintained by the Bluetooth Special Interest Group (SIG) in the Core Specification, which
serves a uniform structure for devices to interoperate.
Bluetooth Low Energy (BLE) is the distinguishing feature (subset) of the latest Core Version,
Bluetooth v4.0. With the release of BLE, the Bluetooth SIG has built upon the original key
features of Bluetooth and set the stage for a variety of new markets, industries, and
applications based on devices that must operate with ultra low power wireless connectivity,
and be very low cost. The revolution brought forth by BLE is such that the name Classic
Bluetooth has become popular for Bluetooth v2.1 + EDR and Bluetooth v3.0 + HS, to
distinguish these technologies from Bluetooth v4.

Bluetooth Low Energy
BLE is characterized by an entirely new protocol stack, for rapid build-up of very simple
links. In this chapter, we explore the motivations that led to its definition, as well as its key
features and implementations.
Motivations
BLE is Bluetooth SIGs response to the convergence of several key trends in wireless
connectivity:
1. Wireless everywhere: connectivity is being added to an increasing number of devices,
which have been traditionally connected via cables or not connected at all.
2. Portability: while all wireless markets have been growing steadily in the past years,
those for portable wireless-enabled devices have witnessed some of the highest rates
of growth. The market for smartphones is a classic example; others include watches,
proximity tags, remote controls, or personal devices for entertainment and fitness.
Portability usually implies that the device is powered by a small battery, such as a
coin cell, or more in general that the energy available for the wireless link is limited.
3. Low-cost: as wireless becomes pervasive, and competition to penetrate new market
opportunities becomes more fierce, pressures for minimizing the cost of adding the
wireless capability to our everyday devices continue to increase.
BLE responds to the need for a simple communication link between devices that must operate
with very low power consumption, and be very low cost. It is not, obviously, a one-for-all
technology; instead, it is particularly suited for those devices that need to transfer very small
quantity of data, and do so within relatively short ranges.
What Makes Bluetooth Low Energy Unique
BLE substantially reduces classic Bluetooths peak, average, and idle mode power
consumption, with energy efficiencies that can be 20 times higher 1 than Classic Bluetooth.
The extremely low peak, average, and idle currents of BLE chipsets, shown in Table 1,
enable BLE radios to work with very small battery power sources for a year and more.
BLEs incredibly low power consumption is enabled by its very simple link layer, designed
for quick connections. BLE chips spend most of their time asleep, only waking up to send
data - a process that takes only few ms, compared to 100 ms with Classic Bluetooth.
In particular, BLE features:
1. Smart Host Control. BLE technology 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 generally consumes more power than the
controller.
2. Adjustable, ultra-low duty cycle. While BLE still uses a synchronous protocol, its
duty cycle can be adjusted down to just 0.1% (compared to Bluetooths 1% duty
cycle).
3. Adjustable message length. BLEs message length is also adjustable, to take
advantage of the fact that packing large quantities of data into a long packet is more
energy efficient than sending multiple packets.
In addition to all of the above, Bluetooth Low Energy also implements a number of other
energy-conserving strategies pioneered by proprietary ultra-low power (ULP) technologies,
such as maximized standby time, faster connections, and reduced peak transmit/ receive
power.
Summary of key BLE terms and concepts
Generic Attribute Profile (GATT)The GATT profile is a general specification for
sending and receiving short pieces of data known as "attributes" over a BLE link. All
current Low Energy application profiles are based on GATT. The Bluetooth SIG
defines many profiles for Low Energy devices. A profile is a specification for how a
device works in a particular application. Note that a device can implement more than
one profile. For example, a device could contain a heart rate monitor and a battery
level detector.
Attribute Protocol (ATT)GATT is built on top of the Attribute Protocol (ATT).
This is also referred to as GATT/ATT. ATT is optimized to run on BLE devices. To
this end, it uses as few bytes as possible. Each attribute is uniquely identified by a
Universally Unique Identifier (UUID), which is a standardized 128-bit format for a
string ID used to uniquely identify information. The attributes transported by ATT are
formatted as characteristics and services.
CharacteristicA characteristic contains a single value and 0-n descriptors that
describe the characteristic's value. A characteristic can be thought of as a type,
analogous to a class.
DescriptorDescriptors are defined attributes that describe a characteristic value. For
example, a descriptor might specify a human-readable description, an acceptable
range for a characteristic's value, or a unit of measure that is specific to a
characteristic's value.
ServiceA service is a collection of characteristics. For example, you could have a
service called "Heart Rate Monitor" that includes characteristics such as "heart rate
measurement." You can find a list of existing GATT-based profiles and services on
bluetooth.org.

Roles and Responsibilities
Here are the roles and responsibilities that apply when two BLE devices interact with each
other:
Central vs. peripheral. This applies to the BLE connection itself. The device in the
central role scans, looking for advertisement, and the device in the peripheral role
makes the advertisement.
GATT server vs. GATT client. This determines how two devices talk to each other
once they've established the connection.
To understand the distinction, imagine that you have an Android phone and an activity
tracker that is a BLE device. The phone supports the central role; the activity tracker supports
the peripheral role (to establish a BLE connection you need one of eachtwo things that
only support peripheral couldn't talk to each other, nor could two things that only support
central).
Once the phone and the activity tracker have established a connection, they start transferring
GATT metadata to one another. Depending on the kind of data they transfer, one or the other
might act as the server. For example, if the activity tracker wants to report sensor data to the
phone, it might make sense for the activity tracker to act as the server. If the activity tracker
wants to receive updates from the phone, then it might make sense for the phone to act as the
server.
In the example used in this document, the Android app (running on an Android device) is the
GATT client. The app gets data from the GATT server, which is a BLE heart rate monitor
that supports the Heart Rate Profile. But you could alternatively design your Android app to
play the GATT server role. See BluetoothGattServer for more information.







Details of Bluetooth Low Energy

GAP
GAP is an acronym for the Generic Access Pro file, and it controls connections and
advertising in Bluetooth. GAP is what makes your device visible to the outside world,
anddetermines how two devices can (or can't) interact with each other.
Device Roles
GAP defines various roles for devices, but the two key concepts to keep in mind are
Centraldevices and Peripheral devices.
Peripheral devices are small, low power, resource contrained devices that can connect
to a much more powerful central device.Peripheral devices are things like a heart rate
monitor, a BLE enabled proximity tag, etc.
Central devices are usually the mobile phone or tablet that you connect to with far
more processing power and memory.
Advertising and Scan Response Data
There are two ways to send advertising out with GAP. The Advertising Data payload and the
Scan Response payload. Both payloads are identical and can contain up to 31 bytes of data,
but only the advertising data payload is mandatory, since this is the payload that will be
constantly transmitted out from the device to let central devices in range know that it exists.
The scan response payload is an optional secondary payload that central devices can request,
and allows device designers to fit a bit more information in the advertising payload such a
strings for a device name, etc.
Advertising Process
The following illustration should explain the advertising process and how the
advertisingpayloads and scan response payloads work.
A peripheral will set a specific advertising interval, and every time this interval passes, it
willretransmit it's main advertising packet. A longer delays saves power but feels less
responsiveif the device only advertises itself once every 2 seconds instead of every 20ms. If a
listening device is interested in the scan response payload (and it is available on the
peripheral) it can optionally request the scan response payload, and the peripheral will
respond with the additional data.

Broadcast Network Topology
While most peripherals advertise themselves so that a connection can be established
andGATT services and characteristics can be used (which allows for much more data to
beexchanged and in both directions), there are situations where you only want to advertise
data.The main use case here is where you want a peripheral to send data to more than one
deviceat a time. This is only possible using the advertising packet since data sent and
received inconnected mode can only be seen by those two connected devices.
By including a small amount of custom data in the 31 byte advertising or scan response
payloads, you can use a low cost Bluetooth Low Energy peripheral to sent data one-way to
any devices in listening range, as shown in the illustration below. This is known as Bro
adcasting in Bluetooth Low Energy.
This is the approach use by Apple's iBeacon, for example, which inserts a custom payload
inthe main advertising packet, using the Manufacturer Specific Data field.

GATT
GATT is an acronym for the Generic Attribute Profile, and it defines the way that two
Bluetooth Low Energy devices transfer data back and forth using concepts called Services
and Characteristics. It makes use of a generic data protocol called the Attribute Protocol
(ATT), which is used to store Services, Characteristics and related data in a simple lookup
table using 16-bit IDs for each entry in the table.
GATT comes into play once a dedicated connection is established between two devices,
meaning that you have already gone through the advertising process governed by GAP. The
most important thing to keep in mind with GATT and connections is that connections are
exclusive. What is meant by that is that a BLE peripheral can only be connected to one
central device (a mobile phone, etc.) at a time! As soon as a peripheral connects to a central
device, it will stop advertising itself and other devices will no longer be able to see it or
connect to it until the existing connection is broken. Establishing a connection is also the only
way to allow two way communication, where thecentral device can send meaningful data to
the peripheral and vice versa.
Connected Network Topology
The following diagram should explain the way that Bluetooth Low Energy devices work in
aconnected environment. A peripheral can only be connected to one central device (such as
amobile phone) at a time, but the central device can be connected to multiple peripherals.If
data needs to be exchanged between two peripherals, a custom mailbox system will need to
be implemented where all messages pass through the central device. Once a connection is
established between a peripherals and central device, however, communication can take place
in both directions, which is different than the one-way broadcasting approach using only
advertising data and GAP.
GATT Transactions
An important concept to understand with GATT is the server/client relationship. The
peripheral is known as the GATT Server, which holds the ATT lookup data and service and
characteristic definitions, and the GATT Client (the phone/tablet), which sends requests to
this server.
All transactions are started by the master device, the GATT Client, which receives response
from the slave device, the GATT Server.
When establishing a connection, the peripheral will suggest a 'Connection Interval' to the
central device, and the central device will try to reconnect every connection interval to see if
any new data is available, etc. It's important to keep in mind that this connection interval is
really just a suggestion, though! Your central device may not be able to honour the request
because it's busy talking to another peripheral or the required system resources just aren't
available.

The following diagram should illustrate to data exchange process between a peripheral (the
GATT Server) and a central device (the GATT Client), with the master device initiating
every transaction:

Services and Characteristics
GATT transactions in BLE are based on high-level, nested objects called Profiles, Services
and Characteristics, which can be seen in the
illustration below:













Profiles
A Profile doesn't actually exist on the BLE peripheral itself, it's simple a pre-defined
collection of Services that has been compiled by either the Bluetooth SIG or by the peripheral
designers. The Heart Rate Profile, for example, combines the Heart Rate Service and the
Device Information Service.


Services
Services are used to break data up into logic entities, and contain specific chunks of data
called characteristics. A service can have one or more characteristics, and each service
distinguishes itself from other services by means of a unique numeric ID called a UUID,
which can be either 16-bit (for officially adopted BLE Services) or 128-bit (for custom
services).
If you look at the Heart Rate Service, for example,you can see that this officially adopted
service has a 16-bit UUID of 0x180D, and contains up to 3 characteristic, though only the
first one is mandatory: Heart Rate Measurement, Body Sensor Location and Heart Rate
Control Point.
Characteristics
The lowest level concept in GATT transactions is the Characteristic, which encapsulates a
single data point (though it may contain an array of related data, such as X/Y/Z values from a
3-axis accelerometer, etc.).
Similarly to Services, each Characteristic distinguishes itself via a pre-defined 16-bit or 128-
bit UUID, and you're free to use the standard characteristics defined by the Bluetooth SIG
(which ensures interoperability across and BLE-enabled HW/SW) or define your own custom
characteristics which only your peripheral and SW understands.
As an example, the Heart Rate Measurement characteristic is mandatory for the Heart Rate
Service, and uses a UUID of 0x2A37. It starts with a single 8-bit value describing the HRM
data format (whether the data is UINT8 or UINT16, etc.), and the goes on to include the heart
rate measurement data that matches this config byte.
Characteristics are the main point that you will interact with your BLE peripheral, so it's
important to understand the concept. They are also used to send data back to the BLE
peripheral, since you are also able to write to characteristic. You could implement a simple
UART-type interface with a custom 'UART Service' and two characteristics, one for the TX
channel and one for the RX channel, where one characteristic might be configured as read
only and the other would have write privileges.









Problem Statement

Bluetooth low energy or Bluetooth Smart is a wireless personal area network technology
designed and marketed by the Bluetooth Special Interest Group.
This Project is aimed at enabling Bluetooth Low Energy communication between a Bluetooth
Low energy peripheral chip and handheld mobile devices. This Bluetooth Low Energy
peripheral device was then connected to mother board of a computer.
To achieve the above mentioned aims, a CSR uenergy microcontroller device was used as
Bluetooth Low Energy device. Using CSR uenergy SDK, an application was to be created to
transmit required data through CSR uenergy microcontroller. An app was to be created on an
android phone to receive the data from BLE devices. Then, middleware and drivers were to
be created for connecting the microcontroller to the motherboard of computer.





















Solution
The implementation invlolved:
creation of android app on mobile side to discover advertisement
creation of application on CSR uenergy software development kit to make the
bluetooth peripheral

Android Application
Android 4.3 (API Level 18) introduces built-in platform support for Bluetooth Low Energy in
the central role and provides APIs that apps can use to discover devices, query for services,
and read/write characteristics. In contrast to Classic Bluetooth, Bluetooth Low Energy (BLE)
is designed to provide significantly lower power consumption. This allows Android apps to
communicate with BLE devices that have low power requirements, such as proximity
sensors, heart rate monitors, fitness devices, and so on. Following are various methods from
Android BLE API that are used to accomplish the making of the mobile app.
BLE Permissions
In order to use Bluetooth features in your application, you must declare the Bluetooth
permission BLUETOOTH. You need this permission to perform any Bluetooth
communication, such as requesting a connection, accepting a connection, and transferring
data.
Setting Up BLE
Before your application can communicate over BLE, you need to verify that BLE is
supported on the device, and if so, ensure that it is enabled. If BLE is not supported, then you
should gracefully disable any BLE features. If BLE is supported, but disabled, then you can
request that the user enable Bluetooth without leaving your application. This setup is
accomplished in two steps, using the BluetoothAdapter.
Get the BluetoothAdapter
The BluetoothAdapter is required for any and all Bluetooth activity. The BluetoothAdapter
represents the device's own Bluetooth adapter (the Bluetooth radio). There's one Bluetooth
adapter for the entire system, and your application can interact with it using this object. The
snippet below shows how to get the adapter. Note that this approach uses getSystemService()
to return an instance of BluetoothManager, which is then used to get the adapter. Android 4.3
(API Level 18) introduces BluetoothManager.
Enable Bluetooth
Next, you need to ensure that Bluetooth is enabled. Call isEnabled() to check whether
Bluetooth is currently enabled. If this method returns false, then Bluetooth is disabled. The
following snippet checks whether Bluetooth is enabled. If it isn't, an error prompting the user
to go to Settings to enable Bluetooth will occur.
Finding BLE Devices
To find BLE devices, you use the startLeScan() method. This method takes a
BluetoothAdapter.LeScanCallback as a parameter. You must implement this callback,
because that is how scan results are returned. Because scanning is battery-intensive, you
should observe the following guidelines:
As soon as you find the desired device, stop scanning.
Never scan on a loop, and set a time limit on your scan. A device that was previously
available may have moved out of range, and continuing to scan drains the battery.
If you want to scan for only specific types of peripherals, you can instead call
startLeScan(UUID[], BluetoothAdapter.LeScanCallback), providing an array of
UUID objects that specify the GATT services your app supports.
Connecting to a GATT Server
The first step in interacting with a BLE device is connecting to it more specifically,
connecting to the GATT server on the device. To connect to a GATT server on a BLE device,
you use the connectGatt() method. This method takes three parameters: a Context object,
autoConnect (boolean indicating whether to automatically connect to the BLE device as soon
as it becomes available), and a reference to a BluetoothGattCallback:
mBluetoothGatt = device.connectGatt(this, false, mGattCallback);
This connects to the GATT server hosted by the BLE device, and returns a BluetoothGatt
instance, which you can then use to conduct GATT client operations. The caller (the Android
app) is the GATT client. The BluetoothGattCallback is used to deliver results to the client,
such as connection status, as well as any further GATT client operations.
When a particular callback is triggered, it calls the appropriate broadcastUpdate() helper
method and passes it an action. Back in DeviceControlActivity, these events are handled by a
BroadcastReceiver.
Reading BLE Attributes
Once your Android app has connected to a GATT server and discovered services, it can read
and write attributes, where supported.
Receiving GATT Notifications
It's common for BLE apps to ask to be notified when a particular characteristic changes on
the device. This snippet shows how to set a notification for a characteristic, using the
setCharacteristicNotification() method.
Once notifications are enabled for a characteristic, an onCharacteristicChanged() callback is
triggered if the characteristic changes on the remote device.
Closing the Client App
Once your app has finished using a BLE device, it should call close() so the system can
release resources.

CSR Uenergy Application
The CSR uenergy SDK consisted of a target board and an IDE to develop applications for the
chip. The microcontroller will act as a BLE peripheral device. The user application created
will interact with the firmware of the microcontroller using following methods:
1. AppPowerOnReset: This method is called on the cold boot and before any other
application callbacks.
2. AppInit: Called on every boot and should contain application initialisation
Hardware setup
Upper stack initialisation (e.g. setting up GATT Server database)
3. AppProcessSystemEvent: Called by firmware to process system-level events
Low battery
Input PIO level change (e.g. to handle buttons, external signals etc.)
WAKE pin level change
Interrupt from PIO controller
4. AppProcessLmEvent: Handles communication link-related events from firmware
GAP and (G)ATT messages
Security Manager messages
Low-level link layer messages
Radio events
5. Ti
mers: Run
on top of
the
hardwareti
mer with
microseco
nd
accuracy









Typical lifecycle of the GAP peripheral application
Connection making

Conclusion
Bluetooth Low Energy is an upcoming technology that can be used on a wide scale to reduce
the power consumption of battery operated devices. The project has helped Samsung take a
step forwaerd in that direction by enabling with BLE therefore reducing the power that has to
be consumed by a mobile device to perform a print.
The outcome of the project was :
An android application capable of displaying all the BLE enabled devices in the
vicinity and can connect to the nearest one based on the RSSI.
After connection establishment, the application could be used to peripheral specific
operations.
An application for CSR uenergy microcontroller was created using CSR uenergy
SDK.
CSR uenergy microcontroller was connected to the mother board of a computer to
send company specific data through it.



















References
https://developer.android.com/guide/topics/connectivity/bluetooth-le.html
http://www.bluez.org
http://www.developer.bluetooth.com
specifications of Bluetooth systems (version 4.2)