AUTOMATIC ATTENDANCE MANAGEMENT

SYSTEM USING BLE TECHNOLOGY

A Project report submitted in partial fulfillment of the requirements for the award of the

Degree of

BACHELOR OF TECHNOLOGY
IN

ELECTRONICS AND COMMUNICATION ENGINEERING

Submitted by

V. Rajesh (315126512170) K. Harshitha (315126512209)

Ch. V Sai Teja (315126512187) N. Ramu (31512651286)

Under the guidance of

Mr. B.Chandra Mouli

Assistant Professor, Department of ECE

DEPARTMENT OF ELECTRONICS AND COMMUNICATION ENGINEERING

ANIL NEERUKONDA INSTITUTE OF TECHNOLOGY AND SCIENCES

(UGC AUTONOMOUS)

(Permanently Affiliated to AU, Approved by AICTE and Accredited by NBA & NAAC with „A‟ Grade)
Sangivalasa, Bheemili Mandal, Visakhapatnam dist. (A.P) 2018-2019
 ACKNOWLEDGEMENT
We would like to express our deep gratitude to our project guide
Mr. B.Chandra Mouli, Assistant Professor, Department of Electronics and
Communication Engineering, ANITS, for his/her guidance with unsurpassed knowledge
and immense encouragement. We are grateful to Dr. V. Rajyalakshmi, Head of the
Department, Electronics and Communication Engineering, for providing us with the
required facilities for the completion of the project work.

We are very much thankful to the Principal and Management, ANITS, Sangivalasa, for
their encouragement and cooperation to carry out this work.

We express our thanks to all teaching faculty of Department of ECE, whose suggestions
during reviews helped us in accomplishment of our project. We would like to thank all
non-teaching staff of the Department of ECE, ANITS for providing great assistance in
accomplishment of our project.

We would like to thank our parents, friends, and classmates for their encouragement
throughout our project period. At last but not the least, we thank everyone for supporting
us directly or indirectly in completing this project successfully.

PROJECT STUDENTS
V. Rajesh (315126512170)

K. Harshitha (315126512209)

Ch. V Sai Teja (315126512187)

N. Ramu (315126512186)
DEPARTMENT OF ELECTRONICS AND COMMUNICATION ENGINEERING

ANIL NEERUKONDA INSTITUTE OF TECHNOLOGY AND SCIENCES

(UGC AUTONOMOUS)
(Permanently Affiliated to AU, Approved by AICTE and Accredited by NBA & NAAC with ‘A’
Grade)
Sangivalasa, Bheemili Mandal, Visakhapatnam dist. (A.P)

CERTIFICATE

This is to certify that the project report entitled “Automatic Attendance Management System
using BLE technology” submitted by V. Rajesh (315126512170), K. Harshitha (315126512209),
Ch. V Sai Teja (315126512187) , N. Ramu (315126512186). In partial fulfillment of the
requirements for the award of the degree of Bachelor of Technology in Electronics &
Communication Engineering of Andhra University, Visakhapatnam is a record of bonafide work
carried out under my guidance and supervision.

Project Guide Head of the Department

Mr. B.Chandra Mouli Dr. V.Rajyalakshm

Assistant professor Professor

Department of E.C.E Department of ECE

ANITS ANITS
 CONTENTS
ABSTRACT i

LIST OF SYMBOLS ii

LIST OF FIGURES iii

LIST OF TABLES iv

LIST OF ABBREVATIONS v

CHAPTER 1 INTRODUCTION 1-2

1.1 Project Objective 1
1.2 Project Outline 2
CHAPTER 2 BLUETOOTH TECHNOLOGY 3 - 19
2.1 Introduction 3
2.2 Bluetooth Radio System Architecture 4
2.3 Bluetooth Protocol Stack 6
2.3.1 Bluetooth Module 7
2.3.1.1 Link Controller 9
2.3.1.2 Link Manager 11
2.3.2 Bluetooth Host 12
2.4 Conclusion 19
CHAPTER 3 BLUETOOTH LOW ENERGY TECHNOLOGY 20 - 29
3.1 Introduction 20
3.2 BLE Protocols 23
3.3 BLE Beacons 24
3.4 How BLE Works? 26
3.5 Comparison Of Classic Bluetooth and BLE 26
3.6 Benefits Of BLE 28
3.7 RFID Versus BLE 29
3.8 Applications 29
CHAPTER 4 HARDWARE COMPONENTS 30 -
31
 4.1 Power Supply 30
4.1.1 CR2032 Coin Cell 30
4.2 NRF51822(BLE beacon) 31
CHAPTER 5 SOFTWARE TOOLS 34 - 60
5.1 Android Studio 34
5.1.1 How to Install? 36
5.2 Java JDK 51
5.3 SQLite Database 60
CHAPTER 6 METHODOLOGY OF PROJECT 64 - 66
6.1 Project Description 64
6.2 Algorithm 64
6.3 Flowchart 66
CHAPTER 7 RESULTS AND DISCUSSIONS 67-76

CONCLUSIONS 77

REFERENCE 78

ABSTRACT
This work presents a design and framework for taking attendance in college at the end
of every period within the classroom, for making troublesome process of taking and
compiling of attendance simple and efficient, so that the teacher can concentrate on the
class and doesn‘t invest time on classroom attendance collection. This system uses the
Bluetooth Low Energy (BLE) 4.0 technology of beacons which communicate with an
android mobile using an application. The android application designed will compare
the data of the BLE device with its background mobile database. Thus, the process
continues further. This system can also be used maintain attendance of
Employees/workers in an organization and finding books in a library. Compared to
RFID, this is more economical.
 i
LIST OF FIGURES:
Figure 1.1 Project Outline
Figure 2.1 The Bluetooth Protocol Stack
Figure 2.3 Discovering a Bluetooth device
Figure 2.4 Position of audio in the Bluetooth stack
Figure 2.5 LMP PDU payload body
Figure 2.6 Structure of an SDP PDU
Figure 2.7 Stages in setting up an SDP session
Figure 2.8 Bluetooth profiles
Figure 3.2 Bluetooth low energy Protocol Stack Basics
Figure 6.3 Flow chart
 1. INTRODUCTION

1.1 Project Objective:

In present days, Educational institutions are concerned mostly about the irregularity
of the student attendance. The conventional attendance system which is taking attendance
by calling names is, time consuming and inaccurate. Hence, this work automates the
conventional attendance system in an efficient manner.

1.2 Project Outline:

This work presents a design and framework for taking attendance in college at the
end of every period within the classroom, for making troublesome process of taking and
compiling of attendance simple and efficient, so that the teacher can concentrate on the
class and doesn‘t invest time on classroom attendance collection.
This system uses the Bluetooth Low Energy (BLE) 4.0 technology of beacons
which communicate with an android mobile using an application. Each student is provided
with the BLE beacon which resembles as an ID Card. Each BLE beacon has an unique 6
byte MAC address. The android application designed will compare the data of the BLE
device with its background mobile database. Thus, the process continues further. Finally
the list absentee in the class is displayed in the android application. This system can also
be used maintain attendance of Employees/workers in an organization and finding books
in a library. Compared to RFID, this is more economical.

1
 Cloud
Or
Database

BLE

BLE
ANDROID
MOBILE

BLE

Figure 1.1 Project Outline

2
 2. BLUETOOTH TECHNOLOGY

2.1 Introduction:
As one of the youngest member of the LAN family, wireless LANs were little used
until recently. The main reasons for this were high prices and low data rates, as well as
licensing requirements. However, increasing requirements for mobility, relocation and
coverage of locations difficult to wire are making wireless LANs more popular every day.

Wireless LANs can be designed in many different ways depending on their

applications, one kind is a wireless ad-hoc network. An ad-hoc network is a peer-to-peer
network set up temporarily to meet some immediate need. In contrast to the majority of
radio systems in use today, it doesn‘t have any centralized server. Ad hoc radio systems
have been in use for some time, for example walky-talky systems are broadly used by
police, military and fire departments. However, the Bluetooth system is the first
commercial ad hoc radio system envisioned to be used on a large scale and widely
available to the public.

The Bluetooth radio system began as an idea of Ericsson Mobile

Communications in 1994., but today, it is the result of the joint effort of many large
companies (Ericsson, Intel, IBM, Toshiba, Nokia, Microsoft, Lucent, etc). The Bluetooth
system is named after Harald Blatand, a tenth-century Danish Viking king, who united
Denmark and Norway. The name was adopted because Bluetooth wireless technology is
expected to unify the telecommunication and computing industry. The main aim of
Bluetooth is to be widely available, inexpensive, convenient, easy to use, reliable, small,
and low power.

3
One of the most important characteristics of the Bluetooth specification is that it should
allow devices from lots of different manufacturers to work with one another. For that
reason, Bluetooth doesn't only define a radio system, but also a software stack that enables
applications to find other Bluetooth devices in the area, discover what services they can
offer, and use that services. Bluetooth allows up to eight devices to connect together in a
group called a piconet. Different piconets can be linked into scatternets, but the data rate
between scatternets will be lower than the rate within a single piconet.

2.2 Bluetooth Radio System Architecture:

Bluetooth devices operate at 2.4GHz, in the globally available, license-free, ISM

band. That is the bandwidth reserved for general use by Industrial, Scientific and Medical
applications worldwide. Since this radio band is free to be used by any radio transmitter
as long as it satisfies the regulations, the intensity and the nature of interference can't be
predicted. Therefore, the interference immunity is very important issue for Bluetooth.
Generally, interference immunity can be obtained by interference suppression or
avoidance. Suppression can be obtained by coding or direct-sequence spreading, but the
dynamic range of interfering signals in ad hoc networks can be huge, so practically attained
coding and processing gains are usually inadequate. Avoidance in frequency is more
practical. Since ISM band provides about 80MHz of bandwidth and all radio systems are
band limited, there is a high probability that a part of the spectrum can be found without a
strong interference.

Considering all this, FH-CDMA (Frequency Hopping - Code Division Multiple

Access) technique has been chosen to implement the multiple access scheme for the
Bluetooth. It combines a number of properties, which make it the best choice for an ad hoc
radio system. It fulfills the spreading requirements set in the ISM band, i.e. on average the
signal can be spread over a large frequency range, but instantaneously only a small part of
the bandwidth is occupied, avoiding most of potential interference. It also doesn't require

4
neither strict time synchronization (like TDMA), nor coordinated power control (like DS-
CDMA). In the 2.45GHz ISM band, a set of 79 hop carriers has been defined, at 1MHz
spacing. A nominal hop dwell time is 625 us. Full-duplex communication is achieved by
applying time-division duplex (TDD), and since transmission and reception take place at
different time slots, they also take place at different hop carriers. A large number of
pseudo-random hopping sequences have been defined, and the particular sequence is
determined by the unit that controls the FH channel. That unit is usually called the master
and it also defines timing parameters during the certain session. All other devices involved
in the session, the slaves, have to adjust their spreading sequences and clocks to the
master's.

Bluetooth uses Gaussian-shaped frequency shift keying (GFSK) modulation with

a nominal modulation index of k=0.3. This binary modulation was chosen for its
robustness, and, with the accepted bandwidth restrictions, it can provide data rates to about
1Mbps. A noncoherent demodulation can be accomplished by a limiting FM discriminator.
This simple modulation scheme allows the implementation of low-cost radio units, which
is one of the main aims of the Bluetooth system.

An FH Bluetooth channel is associated with the piconet. As mentioned earlier, the

master unit defines the piconet channel by providing the hop sequence and the hop phase.
All other units participating in the piconet are slaves. However, since the Bluetooth is
based on peer communications, the master/slave role is only attributed to a unit for the
duration of the piconet. When the piconet is cancelled, the master and slaves roles are
canceled too. In addition to defining the piconet, the master also controls the traffic on the
piconet and takes care of access control. The time slots are alternatively used for master
and slaves transmission. In order to prevent collisions on the channel due to multiple slave
transmissions, the master applies a polling technique, for each slave-tomaster slot the
master decides which slave is allowed to transmit. If the master has no information to send,
it still has to poll the slave explicitly with a short poll packet. This master control

5
effectively prevents collisions between the participants in the piconet, but independent
collocated piconets may interfere with one another when they occasionally use the same
hop carrier. This can happen because units don't check for a clear carrier (no listen-before-
talk). If the collision occurs, data are retransmitted at the next transmission opportunity.
Due to the short dwell time, collision avoidance schemes are less appropriate for FH
system.

2.3 Bluetooth Protocol Stack:

The Bluetooth protocol stack is defined as a series of layers, though there are some
features which cross several layers. A Bluetooth device can be made up of two parts: a
host implementing the higher layers of the protocol stack, and a module implementing the
lower layers. This separation of the layers can be useful for several reasons. For example,
hosts such as PCs have spare capacity to handle higher layers, allowing the Bluetooth
device to have less memory and a less powerful processor, which leads to cost reduction.
Also, the host device can sleep and be awoken by an incoming Bluetooth connection. Of
course, an interface is needed between the higher and lower layers, and for that purpose
the Bluetooth defines the Host Controller Interface (HCI). But for some small and simple
systems, it is still possible to have all layers of the protocol stack run on one processor. An
example of such a system is a headset.

6
 Applications Host
Higher Layers
TCS SDP Upper
Audio L2CAP Control
Layers
HCI Driver on
Host
Physical Bus Driver
RFCOMM
HCI
Logical Link Control and Packets
Applicaton
Bluetooth Module
Physical Bus Driver
Host Controller Interface
Lower
HCI Driver Layers
Link Manager on
Link Manager
Bluetooth
Link Controller Module
Baseband/Link Controller
Radio
Radio

Figure 2.1 The Bluetooth Protocol Stack

2.3.1 Bluetooth Module:

Baseband - There are two basic types of physical links that can be established between a
master and a slave:
Synchronous Connection Oriented (SCO)
Asynchronous Connection-Less (ACL)

An SCO link provides a symmetric link between the master and the slave, with
regular periodic exchange of data in the form of reserved slots. Thus, the SCO link
provides a circuit-switched connection where data are regularly exchanged, and as such it
is intended for use with time-bounded information as audio. A master can support up to
three SCO links to the same or to different slaves. A slave can support up to three SCO
links from the same master.

7
 An ACI link is a point-to-multipoint link between the master and all the slaves on
the piconet. It can use all of the remaining slots on the channel not used for SCO links.
The ACL link provides a packet-switched connection where data are exchanged
sporadically, as they become available from higher layers of the stack. The traffic over the
ACL link is completely scheduled by the master.

Each Bluetooth device has a 48 bit IEEE MAC address that is used for the derivation
of the access code. The access code has pseudo-random properties and includes the
identity of the piconet master. All the packets exchanged on the channel are identified by
this master identity. That prevents packets sent in one piconet to be falsely accepted by
devices in another piconet that happens to use the same hopping frequency in the certain
time slot. . All packets have the same format, starting with an access code, followed by a
packet header and ending with the user payload.

Access Code Header Payload

68 or 72 bits 54 bits 0 - 2745 bits

Figure 2.2 Bluetooth packet structure

The access code is used to address the packet to a specific device. The header
contains all the control information associated with the packet and the link. The payload
contains the actual message information. The Bluetooth packets can be 1, 3, or 5 slots long,
but the multislot packets are always sent on a single-hop carrier.

2.3.1.1 Link Controller:

8
The Link Controller - The link control layer is responsible for managing device
discoverability, establishing connections and maintaining them. In Bluetooth, three
elements have been defined to support connection establishment: scan, page and inquiry.

Inquiry is a process in which a device attempts to discover all the Bluetooth enabled
devices in its local area. A unit that wants to make a connection broadcasts an inquiry
message that induces the recipients to return their addresses. Units that receive the inquiry
message return an FHS (FH-synchronization) packet which includes, among other things,
their identity and clock information. The identity of the recipient is required to determine
the page message and wake-up sequence. For the return of FHS packets, a random backoff
mechanism is used to prevent collisions.

Inquiry
o
o
o
Laptop Mobile
Inquiry
Computer Phone
FHS

Figure 2.3 Discovering a Bluetooth device

A unit in idle mode wants to sleep most of the time to save power, but, from time
to time, it also has to listen whether other units want to connect (page scan). In truly ad
hoc system, there is no common control channel a unit can lock to in order to listen for
page messages. So, every time the unit wakes up, it scans at a different hop carrier for an
extended time. A trade-off has to be made between idle mode power consumption and
response time: increasing the sleep time reduces power consumption but prolongs the time
before an access can be made. The unit that wants to connect has to solve the frequency-
time uncertainty: it doesn't know when the idle unit will wake up and on which frequency.

9
For that reason, the paging unit transmits the access code repeatedly at different
frequencies: every 1.25ms the paging unit transmits two access codes and listens twice for
a response. In 10ms period, 16 different hop carriers are visited. If the idle unit wakes up
in any of these 16 frequencies, it will receive the access code and start with a connection
setup procedure. First, it will notify the paging unit by returning a message, and then it
will transmit a FHS packet which contains all of the pager's information. This information
is then used by both units to establish the piconet. Once a baseband link is established, the
master and slave can exchange roles if they wish, so that slave becomes master and master
becomes slave.

It should be noted that the control of links rests completely with the local device.
If it doesn't make itself discoverable by page scanning it cannot be found, if it does not
make itself connectable by page scanning it cannot be linked with, and once in a
connection it is free to disconnect without warning at any time.

Audio - Audio data is carried via SCO (Synchronous Connection Oriented) channels.
These SCO channels use pre-reserved slots to maintain temporal consistency of the audio
carried on them. This allows us to build devices such as wireless headsets, microphones
and headphones using Bluetooth for many consumer products such as cellular phones, call
centre switchboards, or even personal musical playback.

There are two routes for audio to pass through a Bluetooth system: through the
HCI as data in HCI packets, and via direct PCM connection to the baseband CODECs.

10
 Higher Layers and Applications

Control
Audio L2CAP

Host Controller Interface

Link Manager
Baseband
Radio

Figure 2.4 Position of audio in the Bluetooth stack

The HCI route has some deficiencies in carrying audio data, i.e. packets crossing
the HCL are subject to flow control and therefore to variable latency due to microcontroller
executing the HCI and LM (Link Manager) tasks. The direct PCM route is not well
specified in the Bluetooth specifications, but is very common in commercial
implementations.

2.3.1.2 Link Manager:

The Link Manager - The host drives a Bluetooth device through Host Controller Interface
(HCI) commands, but it is the link manager that translates those commands into operations
at the baseband level. Its main functions are to control piconet management (establishing
and destruction of the links and role change), link configuration, and security and QoS
functions.

Link manager communicates with its peers on other devices using the Link
Management Protocol (LMP). Every LMP message begins with a flag bit which is 0 if a
master initiated the transaction and 1 if the slave initiated the transaction. That bit is
followed by a 7-bit Operation Code, and by the message's parameters.

11
 TID OpCode Parameter 1

Parameter
Parameter 2
o
o
o

Parameter N-1 Parameter N

Figure 2.5 LMP PDU payload body

When a link is first set up, it uses single-slot packets by default. Multi-slot packets
make more efficient use of the band, but there are some occasions when they can't be used,
for example on noisy links or if SCO links don't leave sufficient space between their slots
for multi-slot packets.

LMP also provides a mechanism for negotiating encryption modes and

coordinating encryption keys used by devices on both ends of the link. In addition, LMP
supports messages for configuration of the quality of service on a connection. Packet types
can automatically change according to the channel quality, so that the data can be
transferred at a higher rate when the channel quality is good, and on lower rates with more
error protection if the channel quality deteriorates.

2.3.2 Bluetooth Host:

Logical Link Control and Adaptation Protocol (L2CAP) - Logical Link Control and
Adaptation Protocol takes data from higher layers of the Bluetooth stack and from
applications and sends them over the lower layers of the stack. It passes packets either to
the HCI, or in a host-less system directly to the Link Manager. The major functions of the
L2CAP are:

12
• Multiplexing between different higher layer protocols to allow several higher layer links
to share a single ACL connection. L2CAP uses channel numbers to label packets so that,
when they are received, they can be routed to the correct place.
• Segmentation and reassembly to allow transfer of larger packets than lower layers support.
• Quality of service management for higher layer protocols.

All applications must use L2CAP to send data. It is also used by Bluetooth's higher
layers such as RFCOMM and SDP, so L2CAP is a compulsory part of every Bluetooth
system.

RFCOMM - RFCOMM is a simple, reliable transport protocol that provides emulation of

the serial cable line settings and status of an RS-232 serial port. It provides connections to
multiple devices by relying on L2CAP to handle multiplexing over single connection.
RFCOMM supports two types of devices:
• Type 1 - Internal emulated serial port. These devices usually are the end of a
communication path, for example a PC or printer.
• Type 2 - Intermediate device with physical serial port. These are devices that sit in the
middle of a communication path, for example a modem.

Up to 30 data channels can be set up, so RFCOMM can theoretically support 30

different services at once. RFCOMM is based on GSM TS 07.10 standard, which is an
asymmetric protocol used by GSM cellular phones to multiplex several streams of data
onto one physical serial cable.

The Service Discovery Protocol - One of the most important members of the Bluetooth
protocol stack is Service Discovery Protocol (SDP). It provides a means for an SDP client
to access information about services offered by SDP servers. An SDP server is any
Bluetooth device which offers services to other Bluetooth devices. Information about
services is maintained in SDP databases. There is no centralized database, so each SDP

13
server maintains its own database. The SDP database is simply a set of records describing
all the services which a Bluetooth device can offer to another Bluetooth device, and service
discovery protocol provides a means for another device to look at these records. To make
it easier to find the service you want, services are arranged in a hierarchy structure as a
tree which can be browsed. Clients begin by examining the root of the tree, then follow
the hierarchy out to the leaf nodes where individual services are described.

To browse service classes, or get information about a specific service, SDP clients
and servers exchange messages which are carried in SDP Protocol Data Units (PDUs).
The first byte of PDU is an ID, identifying the message in the PDU. Services have
Universally Unique Identifiers (UUIDs) that describe them. The services defined by the
Bluetooth profiles have UUIDs assigned by the standard, but service providers can define
their own services and assign their own UUIDs to those services.

0 8 16 24 32 40
PDU ID Transaction ID Parameter Length

Parameters

Figure 2.6 Structure of an SDP PDU

SDP relies on L2CAP links being established between SDP client and server,
before retrieving SDP information. Stages in setting up an SDP connection are shown on

14
 Inquiry
Link Controller Paging

Connection Setup
LMP_host connection_req

LMP_accepted

LMP_name_req

LMP_name_res
Link Manager

Connection Setup Authentication

LMP_Setup_complete

LMP_Setup_complete

L2CAP_connection_req
L2CAP
L2CAP_connection_res
Connection Setup

SDP_inquires
SDP Session SDP_responses

Disconnect Terminate Connection

a following figure.

Figure 2.7 Stages in setting up an SDP session

Supported Protocols - As mentioned at the beginning of this paper, one of the most
important characteristics of the Bluetooth specification is that it should allow devices from
lots of different manufacturers to work with one another. For that reason, Bluetooth is

15
designed in such a way to allow many different protocols to be run on top of it. Some of
these protocols are:

1. The Wireless Access Protocol (WAP) - WAP provides a protocol stack similar
to the IP stack, but it is tailored for the needs of mobile devices. It supports the limited
display size and resolution typically found on mobile devices by providing special formats
for Web pages which suit their capabilities. It also provides for the low bandwidth of
mobile devices by defining a method for WAP content to be compressed before it is
transmitted across a wireless link. WAP can use Bluetooth as a bearer layer in the same
way as it can use GSM, CDMA and other wireless services. The WAP stack is joined to
the Bluetooth stack using User Datagram Protocol (UDP), Internet Protocol (IP) and Point
to Point Protocol (PPP).

2. Object Exchange Protocol (OBEX) - OBEX is a protocol designed to allow a

variety of devices to exchange data simply and spontaneously. Bluetooth has adopted this
protocol from the Infrared Data Association (IrDA) specifications. OBEX has a
client/server architecture and allows a client to push data to a server or pull data from the
server. For example, a PDA might pull a file from a laptop, or a phone synchronizing an
address book might push it to a PDA. The similarities between the two communications
protocols' lower layers mean that IrDA's OBEX protocol is ideally suited to transferring
objects between Bluetooth devices.

3. The Telephony Control Protocol - Bluetooth's Telephony Control protocol

Specification (TCS) defines how telephone calls should be sent across a Bluetooth link. It
gives guidelines for the signaling needed to set up both point to point and point to
multipoint calls. By use of TCS, calls from an external network can be directed to other
Bluetooth devices. For instance, a cellular phone could receive a call and use TCS to
redirect the call to a laptop, allowing the laptop to be used as a hands-free phone. TCS is

16
driven by a telephony application which provides the user interface, and provides the
source of voice or data transferred across the connection set up by TCS.

Applications: The Bluetooth Profiles - In addition to protocols which guarantee that two
units speak the same language, Bluetooth specification defines the profiles. They are
associated with applications. The profiles specify which protocol elements are mandatory
in certain applications. This concept prevents devices with little memory and processing
power implementing the entire Bluetooth stack when they only require a small fraction of
it. Simple devices like a headset or mouse can thus be implemented with a strongly reduced
protocol stack.

The Bluetooth profiles are organized into groups, with each profile building upon
the one beneath and inheriting features from below. For developers, this means that key
features of one Bluetooth solution can be reused in other solutions, bringing down
development costs and speeding up the development cycle.

17
 Generic Access Profile Telephony Control Protocol Specification

Service Discovery Cordless Intercom

Application Profile Telephony Profile Profile

Serial Port Profile

Generic Object Exchange Profile
Dial-Up Networking
File Transfer

FAX

Object Push
Headset

Synchronization
LAN Access

Figure 2.8 Bluetooth profiles

The profiles implemented by Bluetooth version 1.0 are:

• Generic Access - It defines the basic rules for using the protocol stack.
• Serial Port - How to use RFCOMM's serial port emulation capabilities in Bluetooth
products.
• Dial-up Networking - A Bluetooth link to a modem.
• FAX - How to transfer a fax over Bluetooth.
• Headset - A duplex link to a headset, controlled by an audio gateway such as cellular
phone.
• LAN Access Point - A link to LAN via Bluetooth.
• Generic Object Exchange - A set of rules for using OBEX, which supports file transfer,
object push and synchronization profiles.
• File Transfer - Transferring files between Bluetooth devices.

18
• Object Push - Pushing objects from a Bluetooth enabled server to a client.
• Synchronization - Synchronizing objects between Bluetooth devices.
• Cordless Telephony - Forwarding telephone calls to Bluetooth devices.
• Intercom - Short range voice connections between Bluetooth devices.

2.5 Conclusion:
The Bluetooth system is a universal interface developed to enable electronic
devices to communicate wirelessly via short-range ad hoc radio connections. This project
presents general overview of the Bluetooth radio system architecture. It focuses on a
description of the Bluetooth protocol stack, which is designed to achieve better
interoperability for data communication between devices. With the restrictions set by
specification, security, power management and QOS are introduced to further improve this
new promising technology design issue.

3. BLUETOOTH LOW ENERGY TECHNOLOGY

3.1 Introduction:

19
 Bluetooth Low Energy (BLE, also marketed as Bluetooth Smart) started as part of
the Bluetooth 4.0 Core Specification. It‘s tempting to present BLE as a smaller, highly
optimized version of its bigger brother, classic Bluetooth, but in reality, BLE has an
entirely different lineage and design goals.
Originally designed by Nokia as Wibree before being adopted by the Bluetooth
Special Interest Group (SIG), the authors weren‘t trying to propose another overly broad
wireless solution that attempts to solve every possible problem. From the beginning, the
focus was to design a radio standard with the lowest possible power consumption,
specifically optimized for low cost, low bandwidth, low power, and low complexity.
These design goals are evident through the core specification, which attempts to
make BLE a genuine low-power standard, designed to actually be implemented by silicon
vendors and used in the real world on a tight energy and silicon budget. It might be the
first widely adopted standard that can realistically lay claim to running for an extended
period of time off a humble coin cell, though many other wireless technologies regularly
make that claim in their marketing.
What Makes BLE Different?
While Bluetooth Low Energy is a good technology on its own merit, what makes
BLE genuinely exciting—and what has pushed its phenomenal adoption rate so far so
quickly—is that it‘s the right technology, with the right compromises, at the right time.
For a relatively young standard (it was introduced in 2010), BLE has seen an uncommonly
rapid adoption rate, and the number of product designs that already include BLE puts it
well ahead of other wireless technologies at the same point of time in their release cycles.
Compared to other wireless standards, the rapid growth of BLE is relatively easy
to explain: BLE has gone further faster because its fate is so intimately tied to the
phenomenal growth in smartphones, tablets, and mobile computing. Early and active
adoption of BLE by mobile industry heavyweights like Apple and Samsung broke open
the doors for wider implementation of BLE.
Apple, in particular, has put significant effort into producing a reliable BLE stack
and publishing design guidelines around BLE. This, in turn, pushed silicon vendors to

20
commit their limited resources to the technology they felt was the most likely to succeed
or flourish in the long run, and the Apple stamp of approval is clearly a compelling
argument when you need to justify every research and development dollar invested.
While the mobile and tablet markets become increasingly mature and costs and
margins are decreasing, the need for connectivity with the outside world on these devices
has a huge growth potential, and it offers peripheral vendors a unique opportunity to
provide innovative solutions to problems people might not even realize that they have
today.
So many benefits have converged around BLE, and the doors have been opened
wide for small, nimble product designers to gain access to a potentially massive market
with task-specific, creative, and innovative products on a relatively modest design budget.
You can purchase all-in-one radio-plus-microcontroller (system-on-chip) solutions today
for well under $2 per chip and in low volumes, which is well below the total overall price
point of similar wireless technologies such as WiFi, GSM, Zigbee, etc. And BLE allows
you to design viable products today that can talk to any modern mobile platform using
chips, tools, and standards that are easy to access.
Perhaps one of the less visible key factors contributing to the success of BLE is that
it was designed to serve as an extensible framework to exchange data. This is a
fundamental difference with classic Bluetooth, which focused on a strict set of use cases.
BLE, on the other hand, was conceived to allow anyone with an idea and a bunch of data
points coming from an accessory to realize it without having to know a huge amount about
the underlying technology. The Smartphone vendors understood the value of this
proposition early on, and they provided flexible and relatively low-level APIs to give
mobile application developers the freedom to use the BLE framework in any way they see
fit.
Devices that talk to Smartphone‘s or tablets also offer another easy-tounderestimate
advantage for product designers: they have an unusually low barrier to adoption. Users are
already accustomed to using the handsets or tablets in their possession, which means the

21
burden of learning a new UI is limited, as long as we respect the rich visual language that
people have grown accustomed to in the platforms they use.
With a relatively easy-to-understand data model, no intrusive licensing costs, no
fees to access the core specs, and a lean overall protocol stack, it should be clear why
platform designers and mobile vendors see a winner in BLE.
The Specification
In June 2010, the Bluetooth SIG introduced Bluetooth Low Energy with version
4.0 of the Bluetooth Core Specification. The specification had been several years in the
making and most of the controversial sections and decisions were finally ironed out by the
companies involved in the development process, with a few additional concerns left to be
dealt with in subsequent updates of the specification.
The first such major update, Bluetooth 4.1, was released in December 2013 and is
the current reference for anyone looking to develop BLE products. Althought the basic
building blocks, procedures, and concepts remained intact, this release also introduced
multiple changes and improvements to smooth the experience of the user.
As with all Bluetooth specifications, 4.1 is backwards compatible with 4.0,
ensuring the correct interoperability among devices implementing different specification
versions. The specifications allow developers to release and qualify products against either
of the versions (until deprecated), although the rapid adoption of new specification
releases and the fact that the 4.1 version standardizes several common practices among
devices makes it recommendable to target the latest available one.

3.2 BLE Protocols:

The functionality of the Bluetooth low energy protocol stack and provides a list
of APIs to interface with the protocol stack. The stack project and its associated files
serve to implement the Bluetooth low energy protocol stack task. This is the highest
priority task in the system and it implements the Bluetooth low energy protocol stack as
shown in Fig

22
 Most of the Bluetooth low energy protocol stack is object code in a single library file (TI
does not provide the protocol stack source code as a matter of policy). A developer must
understand the functionality of the various protocol stack layers and how they interact
with the application and profiles. This section explains these layers.

Version 4.2 of the Bluetooth specification allows for two systems of wireless technology:
Basic Rate (BR: BR/EDR for Basic Rate/Enhanced Data Rate) and Bluetooth low energy.
The Bluetooth low energy system was created to transmit small packets of data, while
consuming significantly less power than BR/EDR devices.

Bluetooth low energy Protocol Stack Basics:

23
 Figure 3.2 Bluetooth low energy Protocol Stack Basics

3.3 BLE Beacons:

A beacon is a small Bluetooth radio transmitter, powered by batteries. Beacons are
similar to a lighthouse in functionality. These small hardware devices incessantly
transmit Bluetooth Low Energy (BLE) signals. The Bluetooth enabled smart
phones are capable of scanning and displaying these signals.

BLE: Android built-in platform to discover devices, request and transmit information from
our bluetooth device.
GATT: Generic Attribute Profile to define how to exchange data using predefined
attributes.

24
Central: the Computer/Tablet/Mobile device, also referred as GATT client. Scans,
requests and uses the data given by the peripheral.

Peripheral: the device broadcasting the data, also referred as GATT server. The data is
structured as definitions of how to interact with it‘s ‗database’.

Services: set of provided features and associated behaviors to interact with the peripheral.
Each service contains a collection of characteristics.

Characteristics: definition of the data divided into declaration and value. Using permission
properties (read, write, notify, indicate) to get a value.

Descriptor: an optional attribute nested in a characteristic that describes the specific value
and how to access it.

UUID: Universally Unique ID that are transmitted over the air so a peripheral can inform
a central what services it provides.

3.4 How BLE works?

25
 3.5 Comparisons of Classical Bluetooth and BLE:
The difference between classic Bluetooth and Bluetooth Low Energy to appreciate
BLE beacons. Classic Bluetooth consumes high power and transmits to long ranges,
which is suited for Bluetooth headsets and speakers.

However, Bluetooth Low Energy transmits less data over a long range, hence
consuming much less power. BLE beacons transfers small amounts of data at regular
intervals of time.

Technical
Classic Bluetooth Bluetooth Low Energy technology
specification

Distance/range
100 m (330 ft) >100 m (>330 ft)
(theoretical max.)

26
Over the air data
1–3 Mbit/s 125 kbit/s – 1 Mbit/s – 2 Mbit/s
rate

Application
0.7–2.1 Mbit/s 0.27-1.37 Mbit/s
throughput

Not defined; implementation

Active slaves 7
dependent

128-bit AES with Counter Mode

56/128-bit and application layer
Security CBC-MAC and application layer
user defined
user defined

Adaptive frequency hopping, Lazy

Adaptive fast frequency
Robustness Acknowledgement, 24-bit CRC,
hopping, FEC, fast ACK
32bit Message Integrity Check

Latency (from a
non-connected Typically 100 ms 6 ms
state)

Minimum total time

to send data (det. 0.625 ms 3 ms
battery life)

Voice capable Yes No

Network topology Scatternet Scatternet

27
 0.01–0.50 W (depending on use
Power consumption 1 W as the reference
case)

Peak current
<30 mA <15 mA
consumption

Service discovery Yes Yes

Profile concept Yes Yes

Mobile phones, gaming, headsets,

Mobile phones, gaming, smart
stereo audio streaming, smart
homes, wearable‘s, automotive, PCs,
Primary use cases homes, wearable‘s, automotive,
security, proximity, healthcare,
PCs, security, proximity,
sports & fitness, Industrial, etc.
healthcare, sports & fitness, etc.

3.7 Benefits of BLE:

Lower power consumption even when compared to other low power technologies. BLE
achieves the optimized and low power consumption by keeping the radio off as much
as possible and sending small amounts of data at low transfer speeds.
No cost to access the official specification documents. With most other wireless
protocols and technologies, you would have to be a member of the official group or
consortium for that technology in order to access the specification.

Lower cost of modules and chipsets, even when compared to other similar
technologies.

28
 Most importantly, its existence in most smartphones in the market.

3.7 RFID versus BLE:

Feature Passive RFID Active RFID Bluetooth low
energy

Life time use 20 Years 3-5 Years 2-5 Years

Tag cost $10 $20 $20

Reader cost $10,000 - $20,000 $500 - $2,000 $25

Sensors Enabled No Yes Yes

Memory Storage No Yes Yes

Easy integration No Yes Yes

with other
technologies and the
cloud

3.8 Applications:
• Building automation
• Smart door locks
• Beacons
• Automotive
• Remote keyless entry(RKE) key fob and Passive entry Passive start key fob
4. HARDWARE COMPONENTS

4.1 Power supply:

4.1.1 CR 2032 Coin cell:

29
Lithium button and coin cell batteries, such as the CR2032, are used to power small
portable electronics devices such as wrist watches, pocket calculators, artificial cardiac
pacemakers, implantable cardiac defibrillators, automobile key less entry transmitters, and
hearing aids

Button and coin cell batteries are typically 5-25 millimeters in diameter and 1-6
millimeters in height. Lithium sizes can be determined from their reference numbers. The
first two digits refer to the diameter of the battery in mm and the second two digits give
the height or thickness of the battery in tenths of mm. So, for example, a CR2032 is a
Lithium button cell which is 20 mm in diameter and 3.2 mm thick. A CR2430 is a lithium
battery, 24 mm in diameter and 3.0 mm thick Lithium button and coin cell batteries have
a BR or CR prefix and primarily provide 3 volts. The Renata 751 is an exception at 2
volts.

Lithium batteries cost a bit more than alkaline, but last longer, weigh less and can operate
in a much wider temperature range (extreme heat and extreme cold) compared to alkaline
batteries.

CR2032 lithium ion coin cell battery is used for NRF51822 Ble module which has been
used in this works which is durable for almost an year.

Battery Size Nominal Voltage Range Cost

capacity
Diameter x
mAh
Height

CR1220 12.5mm x 2mm 40mAh 3.0 – 2.0V $0.9

30
CR1620 16.5mm x 2mm 75mAh 3.0 – 2.0V $0.98

CR2032 20mm x3. 2mm 220mAh 3.0 – 2.0V $0.34

CR2450 24.5mm x 5.0mm 620mAh 3.0 – 2.0V $1.19

4.2 NRF51822 module(BLE Beacon):

Nordic Semiconductor nRF51822 Bluetooth Low Energy & 2.4GHz Wireless SoC offers
a multiprotocol SoC suited for Bluetooth low energy and 2.4GHz ultralow-power wireless
applications. Nordic Semiconductor nRF51822 Bluetooth Low Energy and 2.4GHz
Wireless SoC uses a 32-bit Arm Cortex M0 CPU with 256kB flash and 16kB RAM.

The embedded 2.4GHz transceiver supports Bluetooth low energy and 2.4GHz operation,
where the 2.4GHz mode is on air compatible with the nRF24L series products from Nordic
Semiconductor. A rich selection of analog and digital peripherals can interact without
CPU intervention through the Programmable Peripheral Interface (PPI) system.

A flexible 31-pin GPIO mapping scheme allows I/O like serial interfaces, PWM and
quadrature demodulator to be mapped to any device pin as dictated by PCB requirements.
This enables complete design flexibility associated with pin-out location and function. It
supports the S110 Bluetooth low energy protocol stack as well as 2.4GHz protocol stacks,
including Gazell, both available free of charge in the nRF518 Software Development Kit.

NRF51822 requires a single power supply and gives the user the option of using on-chip
linear regulators giving a supply range of 1.8V to 3.6V, a direct 1.8V mode and an onchip
DC-DC buck converter giving a supply range of 2.1V to 3.6V.

nRF51824 is an auto grade AEC-Q100 qualified Bluetooth low energy SoC ideal for
intelligent automotive applications that may include alerts, collision detection, control and
telemetry, wireless charging and infotainment.

31
Features:

• Multi-protocol 2.4GHz radio

• 32-bit Arm Cortex M0 processor
• 256kB flash/16kB RAM
• Software stacks available as downloads
• Pin compatible with other nRF51xxx series devices
• Application development independent from protocol stack
• Fully on-air compatible with nRF24L-series
• Programmable output power from +4dBm to -20dBm
• RSSI
• RAM mapped FIFOs using Easy DMA
• Dynamic on air payload length up to 256 Bytes
• Flexible and configurable 31 pin GPIO
• Programmable Peripheral Interface – PPI
• Simple ON/OFF global power modes
• Full set of digital interfaces including :SPI/2-wire/UART
• 10-bit ADC
• 128-bit AES ECB/CCM/AAR co-processor
• Quadrature demodulator
• Ultra-low-power 32kHz crystal and RC oscillators
• Low-cost external crystal 16MHz ± 40ppm
• Low power 16MHz crystal and RC oscillators
• Wide supply voltage range (1.8V to 3.6V)
• On-chip DC/DC buck converter
• Individual power management for all peripherals
• Package options: 48-pin 6x6 QFN Applications:

• Bluetooth Smart applications

32
 • Mobile phone accessories
• Computer peripherals
• Remote controls for TV, set top boxes, and media systems
• Proximity and security alert tags
• Sports and fitness sensors
• Healthcare and lifestyle sensors Game controllers for computers
• Toys and Electronic games
• Domestic/Industrial control and data-acquisition
• Smart RF tags for tracking and social interaction
• Audience response system
• Intelligent domestic appliances

5. SOFTWARE TOOLS
5.1 Android Studio:
Android is an open source and Linux-based Operating System for mobile devices
such as smartphones and tablet computers. Android was developed by the Open Handset
Alliance, led by Google, and other companies.
Android Studio is the official integrated development environment (IDE) for
Google's Android operating system, built on JetBrains' IntelliJ IDEA software and
designed specifically for Android development

t. It is available for download on Windows, mac OS and Linux based operating

systems.It is a replacement for the Eclipse Android Development Tools (ADT) as the
primary IDE for native Android application development.
The first beta version of the Android Software Development Kit (SDK) was
released by Google in 2007 where as the first commercial version, Android 1.0, was
released in September 2008.

33
 Android Studio was announced on May 16, 2013 at the Google I/O conference. It
was in early access preview stage starting from version 0.1 in May 2013, then entered beta
stage starting from version 0.8 which was released in June 2014.The first stable build was
released in December 2014, starting from version 1.0.The current stable version is 3.3,
which was released in January 2019.
Features

The following features are provided in the current stable version:

• Gradle-based build support

• Android-specific refactoring and quick fixes

• Lint tools to catch performance, usability, version compatibility and other problems

• Pro Guard integration and app-signing capabilities

• Template-based wizards to create common Android designs and components

• A rich layout editor that allows users to drag-and-drop UI components, option to

preview layouts on multiple screen configurations.

• Support for building Android Wear apps

• Built-in support for Google Cloud Platform, enabling integration with Firebase
Cloud Messaging (Earlier 'Google Cloud Messaging') and Google App Engine.

• Android Virtual Device (Emulator) to run and debug apps in the Android studio.

Windows requirements:

• Microsoft Windows 7/8/10 (32-bit or 64-bit)

• 3 GB RAM minimum, 8 GB RAM recommended (plus 1 GB for the Android

Emulator)

• 2 GB of available disk space minimum, 4 GB recommended (500 MB for IDE plus

1.5 GB for Android SDK and emulator system image)

• 1280 x 800 minimum screen resolution

Mac OS requirements

34
 • Mac OS X 10.10 (Yosemite) or higher, up to 10.13 (High Sierra)

• 3 GB RAM minimum, 8 GB RAM recommended (plus 1 GB for the Android

Emulator)

• 2 GB of available disk space minimum, 4 GB recommended (500 MB for IDE plus

1.5 GB for Android SDK and emulator system image)

• 1280 x 800 minimum screen resolution

Linux OS requirements

• GNOME or KDE desktop. Tested on Ubuntu 14.04 LTS, Trusty Tahr (64-bit
distribution capable of running 32-bit applications)

• 64-bit distribution capable of running 32-bit applications

• GNU C Library (glibc) 2.19 or later

• 3 GB RAM minimum, 8 GB RAM recommended (plus 1 GB for the Android

Emulator)

• 2 GB of available disk space minimum, 4 GB recommended (500 MB for IDE plus

1.5 GB for Android SDK and emulator system image)

• 1280 x 800 minimum screen resolution

5.1.1 How to Install?

35
 Figure 5.1 Android Studio IDE

Step 1 - System Requirements

The system should follow the requirements explained above according to the OS used.
Step 2 - Setup Android Studio
Android Studio is the official IDE for android application development.It works based on
IntelliJ IDEA, You can download the latest version of android studio from Android
Studio 2.2 Download, If you are new to installing Android Studio on windows,you will
find a file, which is named as android-studio-bundle-143.3101438-windows.exe.So just
download and run on windows machine according to android studio wizard guideline. If
you are installing Android Studio on Mac or Linux, You can download the latest version
from Android Studio Mac Download,or Android Studio Linux Download, check the
instructions provided along with the downloaded file for Mac OS and Linux. This tutorial
will consider that you are going to setup your environment on Windows machine having
Windows 8.1 operating system.
Installation
So let's launch Android Studio.exe,Make sure before launch Android Studio, Our Machine
should required installed Java JDK. To install Java JDK,take a references of Android
environment setup

36
Once you launched Android Studio, its time to mention JDK7 path or later version in
android studio installer.

37
Below the image initiating JDK to android SDK

38
Need to check the components, which are required to create applications, below the image
has selected Android Studio, Android SDK, Android Virtual
Machine and performanceIntelchipIntelchip.

39
Need to specify the location of local machine path for Android studio and Android SDK,
below the image has taken default location of windows 8.1 x64 bit architecture.

40
Need to specify the ram space for Android emulator by default it would take 512MB of
local machine RAM.

41
At final stage, it would extract SDK packages into our local machine, it would take a while
time to finish the task and would take 2626MB of Hard disk space.

42
After done all above steps perfectly, you must get finish button and it gonna be open
android studio project with Welcome to android studio message as shown below

43
You can start your application development by calling start a new android studio project.
in a new installation frame should ask Application name, package information and location
of the project.

44
After entered application name, it going to be called select the form factors your
application runs on, here need to specify Minimum SDK, in our tutorial, I have declared
as API23: Android 6.0MashmallowMashmallow

45
The next level of installation should contain selecting the activity to mobile, it specifies
the default layout for Applications

46
At the final stage it going to be open development tool to write the application code.

Step 3 - Create Android Virtual Device

To test your Android applications, you will need a virtual Android device. So before we
start writing our code, let us create an Android virtual device. Launch Android AVD

47
Manager Clicking AVD_Manager icon as shown below

After Click on a virtual device icon, it going to be shown by default virtual devices which
are present on your SDK, or else need to create a virtual device by clicking Create new
Virtual device button

If your AVD is created successfully it means your environment is ready for Android
application development. If you like, you can close this window using top-right cross
button. Better you re-start your machine and once you are done with this last step, you are

48
ready to proceed for your first Android example but before that we will see few more
important concepts related to Android Application Development.
Hello Word Example
Before Writing a Hello word code, you must know about XML tags.To write hello word
code, you should redirect to App>res>layout>Activity_main.xml

To show hello word, we need to call text view with layout ( about text view and layout,
you must take references at Relative Layout and Text View ).

49
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools" android:layout_width="match_parent"
android:layout_height="match_parent"
android:paddingLeft="@dimen/activity_horizontal_margin"
android:paddingRight="@dimen/activity_horizontal_margin"
android:paddingTop="@dimen/activity_vertical_margin"
android:paddingBottom="@dimen/activity_vertical_margin"
tools:context=".MainActivity">

<TextView android:text="@string/hello_world"
android:layout_width="550dp"
android:layout_height="wrap_content" />
</RelativeLayout>

Need to run the program by clicking Run>Run App or else need to call shift+f10key.
Finally, result should be placed at Virtual devices as shown below

50
 5.2 Java JDK

JDK Download & Install

Java is a computer programming language that is concurrent, class-based and
objectoriented. Java applications compile to byte code (class file) that can then run on a
Java Virtual Machine (JVM).
James Gosling created Java at Sun Microsystems. It is currently owned by the Oracle
Corporation.
Consult following posts if you are looking to download and install JDK 1.5, JDK
1.6, JDK 1.7, JDK 1.9 or JDK 1.10.
Java can be obtained from the Oracle Java download page. There are a number of
different Java packages available, for this tutorial we will be installing Java Standard
Edition (SE) on Windows.
In order to be able to compile Java code, we need the Java Development Kit (JDK)
package that comes with a Java compiler. The JDK package also comes with a Java
runtime environment (JRE) that is needed to run compiled Java code.
Scroll to the Java SE 8u171/ section in the middle of the Oracle Java download
page and 8u172
click on the Download button right below JDK . Then look for the Java
Development Kit SE
section.
8u172
Here is the direct link to download the jdk 8u172 installer for Windows 32
or 64 bit.
Accept the License Agreement and pick the correct download for your operating system.
In this example, we will use the Windows 64 bit version.

51
Sign in using your Oracle account (or create a new one) and the download should start.
Once the download is complete, locate the jdk-8u172-windows- file and
doubleclick to run the installer. x64.exe

52
Click Next and on the following screen optionally change the installation location by
clicking on the Change... button. In this example the default install location
of 'C:\Program was kept. From now on we will refer to this
Files\Java\jdk1.8.0_172\' [java_install_dir] directory as: .

53
We will not install the public JRE as the JDK Development tools include a private JRE
that can run developed code. Select the Public dropdown and click on This

will not be as shown below. JRE feature

available.

54
Click Next and Close to finish installing Java.
then

55
JDK Configuration
In order for Java applications to be able to run we need to setup a environment variable
'JAVA_HOME' that will point to the Java installation directory. In addition, if we
want to run Java commands from a command prompt we need to setup the environment

'PATH' variable to contain the Java bin directory.

When using Windows the above parameters can be configured on the Environment
Variables panel. Click on the Windows button and enter ―env‖ without quotes as
shown below. Start

56
Environment variables can be set at account level or at system level. For this example
click on Edit environment variables for your account and following panel should appear.

57
Click on the New button and enter ―JAVA_HOME‖ as variable name and the
as [java_install_dir] variable value. In this tutorial the installation directory is
to 'C:\Program . Click OK to save.
Files\Java\jdk1.8.0_172'

Click on the New button and enter ―PATH‖ as variable name and
―%JAVA_HOME%\bin‖ as variable value. Click OK to save.

58
Note that in case a 'PATH' variable is already present you can add
“;%JAVA_HOME%\bin” at the end of the variable value.

The result should be as shown below. Click OK to close the environment variables panel.

In order to test the above configuration, open a command prompt by clicking on the
ENTER

59
Windows Start button and typing ―cmd‖ followed by pressing . A new command prompt
should open in which the following command can be entered to verify the installed Java
version:
java -version
The result should be as shown below.

This concludes the setting up and configuring JDK 1.8 on Windows.

5.3 SQLite Database:

SQLite is a software library that provides a relational database management system. The
lite in SQLite means light weight in terms of setup, database administration, and required
resource.

SQLite has the following noticeable features: self-contained, serverless,

zeroconfiguration, transactional.

Serverless:

Normally, an RDBMS such as MySQL, PostgreSQL, etc., requires a separate server

process to operate. The applications that want to access the database server use TCP/IP
protocol to send and receive requests. This is called client/server architecture.

60
The following diagram illustrates the RDBMS client/server architecture:

SQLite does NOT work this way.

SQLite does NOT require a server to run.

SQLite database is integrated with the application that accesses the database. The
applications interact with the SQLite database read and write directly from the database
files stored on disk.

The following diagram illustrates the SQLite server-less architecture:

Self-Contained:

SQLite is self-contained means it requires minimal support from the operating system or
external library. This makes SQLite usable in any environments especially in embedded
devices like iPhones, Android phones, game consoles, handheld media players, etc.

61
SQLite is developed using ANSI-C. The source code is available as a big sqlite3.c and its
header file sqlite3.h. If you want to develop an application that uses SQLite, you just need
to drop these files into your project and compile it with your code.

Zero-configuration:

Because of the serverless architecture, you don‘t need to ―install‖ SQLite before using it.
There is no server process that needs to be configured, started, and stopped.

In addition, SQLite does not use any configuration files.

Transactional:

All transactions in SQLite are fully ACID-compliant. It means all queries and changes are
Atomic, Consistent, Isolated, and Durable.

In other words, all changes within a transaction take place completely or not at all even
when an unexpected situation like application crash, power failure, or operating system
crash occurs.

SQLite distinctive features:

SQLite uses dynamic types for tables. It means you can store any value in any column,
regardless of the data type.
SQLite allows a single database connection to access multiple database files
simultaneously. This brings many nice features like joining tables in different databases
or copying data between databases in a single command.

SQLite is capable of creating in-memory databases which are very fast to work with.

62
Creating Database:

Public DatabaseHelper (Context context) { super(context, DATABASE_NAME, null,

1);}

Creating Table:

db.execSQL(―create table‖ + TABLE_NAME+ ―(ID INTEGER PRIMARY

KEY AUTOINCREMENT, rssi INTEGER, Devicename TEXT, Macaddress

INTEGER UNIQUE)‖); db.execSQL(―DROP TABLE IF EXISTS ―+

TABLE_NAME);

6. METHODOLOGY OF PROJECT

6.1 Project Description:

Every student will be given with a unique BLE module incorporated in the Uniform using
Wearable Technology

At the Transmitting side, BLE module continuously advertise its signals using BLE
Protocols which were mentioned before. BLE module i.e, NRF51822 continuously sends
the data to the receiver like Device name, MAC Address, UUID, RSSI, Heart rate.

At the Receiving side, the Android mobile Scans for the Active BLE modules. The data
of the BLE modules which are advertising the signals is stored in the Android database
i.e, SQLite Database. In the Background, the dynamic BLE MAC Address is matched with

63
the static students data in the same Database and the Absentees list is given at the output.
So that Faculty can take down the list of Absentees in an efficient manner.

The Static Students data can be managed such as Adding the students data, View the Total
Students of the class, Updating the individual student data for correcting the changes and
Deleting the individual student data.

6.2 Algorithm:
Step 1: Install Attendance Marker Application in your Mobile.
Step 2: Open the Application.
Step 3: Press ― Scan for students ― button in the application.
Step 4: Wait for the Progress bar to fill i.e, Scan for Active BLE devices or students.
Step 5: After the Progress bar is filled, You will be taken back to Previous Activity.
Step 6: Press ― View Absentees ‖ button to view the list of Absentees of the class.
Step 7: Press ― Static Db ‖ button to manage the Static the student data of the particular
class.
Step 8: Enter the particular students name, MAC id and roll number in the fields and
Press ― Add ‖ button to add the particular student data.
Step 9: Press ― View ― button to view the total students of the particular class.
Step 10: Enter the Students data such as name, MAC id and roll number in the fields and
Press ― Update ‖ button to update the data of the Particular roll number associated
student‘s data.
Step 11: Enter the roll number and Press ― Delete ― button to delete the Particular roll
number associated student‘s data.

64
6.3 Flow chart:

65
 Scan for
Students

No If
BLE
Detected

Yes

If No View
Student
of that
Absentees

Yes

Discard

Figure 6.3 Flow chart

7. RESULTS AND DISCUSSIONS

• When the Application is entered, It asks us to enable Bluetooth if it isn‘t turned on.

66
• It also asks for location Access to be turned on.

67
• The Main Screen looks as below

68
• After clicking ― Scan for students ‖ button

69
• Adding data into Static table in the database

70
• After Pressing ― ADD ‖ button

71
72
After pressing ― View ― button

73
After pressing ― Update ‖ button

74
After pressing ― Delete ‖ button

75
76
The final result the list of Absentees after pressing ―
view
Absentees ‖ button

77
78
 CONCLUSION
This work is done with the help of NRF51822 BLE module, Android studio and
Android mobile. It‘s aim is to detect Students with in the classroom and mark their
attendance. It displays the students roll numbers who were not present in the classroom i.e,
Absentees. Thus, it automatically mark the attendance of the students with in the
classroom. It can be extended for implementation in Schools, Organization etc. It can also
be implemented to find books in Library also.

In this world of Automation, This automatic attendance management system plays

a major role in various fields.

References:

79
1. Android Development, [online] Available:
https://developer.android.com/developl-index.html
2. Bluetooth low energy, [online] Available: https://www.bluetooth.com/what-
isbluetooth-technology/bluetooth-technology-basics/low-energy.
3. Android SQLite Database [online] Available:
http://www.codebind.com/androidtutorials-and-examples/android-sqlite-tutorial-
example
4. Beacon Tech Overview, [online] Available: http://developer.estimote.com.
5. Estimote Stickers, [online] Available:
https://community.estimote.com/hc/enus/articles/203323543-What-are-Estimote-
Stickers-
6. Beacon Region, [online] Available:
https://community.estimote.com/hc/enus/articles/203776266-/What-is-a-beacon-
region-.
7. An essential for customer experience, [online]
Available: http://www.nomi.com/resources/white-papers/door-counting-
measurementmanagement/.
8. [online] Available: http://estimote.github.io/Android-SDK/JavaDocs/.
9. Ramakrishnan, "An Efficient Automatic Attendance System Using Fingerprint
Reconstruction Technique", International Journal of Computer Scienceand
Information Security, vol. 10, no. 3, 2012.
10. .R Josphineleela, M. Bluetooth low energy, [online]
Available: https://en.wikipedia.org/wiki/Bluetooth_low_energy.
11. Carles Gomez, Joaquim Ollerand Josep Paradells, "Overview and Evaluation of
Bluetooth Low Energy:", An Emerging Low-Power Wireless Technology
Sensors, vol. 12, no. 9, pp. 11734-11753, 2012.

80