SRM INSTITUTE OF SCIENCE AND TECHNOLOGY

(Deemed to be University u/s 3 of UGC act, 1956)

Office of Controller of Examination
REPORT FOR PLAGIARISM CHECK ON THE DISSERTATION/PROJECT REPORTS FOR UG/PG PROGRAMMES
(To be attached in the Dissertation / Project report)
NANDURI NAGA SOWRI
1 Name of the Candidate
(IN BLOCK LETTERS)

2 Address of the Candidate 1-64, BESIDE GRAM PANCHAYAT

E.G dt., PAMARRU
533305

Mobile Number :7013816469

3 Registration Number RA1711004040047

4 Date of Birth 09-08-2000

5 Department E.C.E

6 Faculty Engineering And Technology

7 Title of the Dissertation / Project A SMART IoT SYSTEM FOR PUBLIC

TRANSPORT
Individual or group
(Strike whichever is not applicable)
Whether the above project/ dissertation
8 is done by a) If the project/ dissertation is done in
group, then how many students together
completed the project :

b) Mention the Name & Register Number

of other candidates :

9 Name and address of the Supervisor / Guide Mrs. S. INDUMATHI

Mail ID: [email protected]

Mobile Number: 9840999956
 10 Name and address of the Co-Supervisor / Co-
Guide Mail ID :
Mobile Number :
11 Software Used Node-Red, Pg admin, Django
12 Date of Verification 21-05-21
13 Plagiarism Details : (to attach the final report from the software)
Chapter Title of the Chapter Percentage Percentage % of
of similarity of similarity plagiarism
index index after
(including (excluding excluding
self self citation) Quotes,
citation) Bibliography
, etc.,
1 INTRODUCTION 3% 2% 2%
2 SYSTEM ARCHITECTURE 2% 2% 2%
3 SYSTEM IMPLEMENTATION 4% 4% 4%
4 WORKING OF SYSTEM 4% 3% 3%
5 REVIEW AND RESULT 3% 3% 3%
6 CONCLUSION 2% 1% 1%
7 FUTURE WORK 1% 1% 1%
8
9
10
Appendices
I / We declare that the above information has been verified and found true to the best of my / out
knowledge

Name & Signature of the Staff

(Who uses the plagiarism check software)

Signature of the Candidate

Name & Signature of the Co-Supervisor / Co-

Name & Signature of the Supervisor / Guide Guide

Name & Signature of the HOD

 PROJECT REPORT

On

A SMART IoT SYSTEM FOR PUBLIC TRANSPORT

Submitted for partial fulfilment for the award of the degree

BACHELOR OF TECHNOLOGY

In

ELECTRONICS AND COMMUNICATION ENGINEERING

By

NANDURI NAGA SOWRI (RA1711004040047)

Under the guidance of

Mrs. INDUMATHI

(Assistant Professor, Department of Electronics and Communication Engineering)

DEPARTMENT OF ELECTRONICS & COMMUNICATION ENGINEERING

FACULTY OF ENGINEERING AND TECHNOLOGY

SRM INSTITUTE OF SCIENCE AND TECHNOLOGY,

VADAPALANI CAMPUS, CHENNAI-26

MAY 2021
 BONAFIDE CERTIFICATE
Certified that this project report titled “A SMART IoT SYSTEM FOR

PUBLIC TRANSPORT” is the Bonafide work of Mr. NANDURI NAGA

SOWRI (Reg. No. RA1711004040047) who carried out the project work under my
supervision as a batch. Certified further, that to the best of my knowledge the work
reported herein does not form any other project report on the basis of which a degree or
award was conferred on an earlier occasion for this or any other candidate.

Project guide Head of the Department

Mrs. S. Indumathi Dr. SHIRLY EDWARD A

Asst. Prof. (O.G) H. O. D

Department of ECE, Department Of ECE,

SRM IST. SRM IST

Date:

Submitted for University Examination held in May 2021 at SRM Institute of

Science and Technology,
Vada Palani Campus, Chennai -600026

Date: Internal Examiner-I Internal Examiner-II

 ACKNOWLEDGEMENT

It has been an enjoyable journey over our cherished years at the SRM IST. This work would
not have been completed without motivation and help from our SRM INSTITUTE OF
SCIENCE AND TECHNOLOGY MANAGEMENT.

We would like to express our sincere gratitude to Founder and Chancellor -

Dr. T. R Pachamuthu, Chairman - Mr. Ravi Pachamoothoo Director of Engineering and
Technology - Dr. C.Muthamizhchelvan, Dean - Dr. K.Duraivelu and Head of the
Department,0Electronics0and0Communication0Engineering--Dr.0Shirly0Edward0A
for0her0support0and0constant0encouragement throughout the project.

We are also grateful to the faculty members Dr. D. Vaishali, Mr. Glaret Subin and
Mr. A.Dinesh Babu for reviewing our project and providing valuable feedbacks and
suggestions amidst their busy schedule. We would like to have a special mention of our
guide Mrs. S.Indumathi for her guidance.

We could not have finished this work without support from our family. They are dearest in
heart and great source of motivation. Our hearty appreciation and thanks to our friends
whose support and encouragement made all this possible.
 SYNOPSIS
City transportation is an important pillar for quality of life of citizens in a city.
Making transport network of a city smart is one of the major tasks when it comes
to making smart city. In most of the cities, public and private road transportation
are the key modes of commuting. Now a days the cities are developing in all the
means of living irrespective of the economic class of the families. The people in
the villages are moving to their nearest cities for better opportunities and to change
their way of living resulting in increase of the population. As the Population is
raising day by day, rapid explode in rate of vehicles has resulting in an overload of
traffic and increase in the cost of fuel. So, public transportation, being a pivotal
role, is the most affordable means of transportation for major type of economic
classes in the city. But, the major impediment of traveling with bus is the
inconsistent arrival time which may be due to unforeseen circumstances. Even
though bus schedule is known, there are a number of reasons that bus may not
arrive as expected. Traffic congestion, heavy downpour, bus breakdown, accident
and day-to-day problems faced by bus company can delay or completely interrupt
bus service. All these reasons leading the citizens in averting the Public Bus
transport system.
 LIST OF FIGURES

Figure Figure Name Page

No. No.
1.3.1 Methodology 9

2.1.1 Algorithm of system 12

2.2.1 Block Diagram 14

3.1.1 Installing Bluez Library 17

3.1.2 Java Script program 18

3.2.1 Data Flow in Node-Red 20

3.2.2 Node-Red connection with 21

POSTGRE Server
3.2.3 MVT Architecture 23

3.2.4 Django ORM 24

5.1.1 Graph For Real-Time Data 31

5.2.1 Log-in Page 32

5.2.2 Find Bus Page 33

5.2.3 Result Page 34

 LIST OF ABBREVIATION
S.no ACRONYM ABBREVIATION

1 UWB ULTRA WIDE BAND

2 BLE BLUETOOTH LOW ENERGY

3 ETA ESTIMATED TIME OF ARRIVAL

4 GPS GLOBAL POSITIONING SYSTEM

5 RFID RADIO FREQUENCY IDENTIFICATION

6 RSSI RECIEVED SIGNAL STRENGTH INDEX

7 SSID SERVICE SET IDENTIFIER

8 GATT GENERAL ATTRIBUTES

9 SQL STRUCTURED QUERY LANGUAGE

10 MVT MODEL VIEW TEMPLATE

11 ORM OBJECT RELATED MAPPING

12 API APPLICATION INTERFACE

TABLE OF CONTENTS
ACKNOWLEDGEMENT 3

ABSTRACT
 TABLE OF CONTENTS

Chapter Chapter Name Page

No. No.

1 INTRODUCTION 10-13

1.1. TRANSPORTATION IN A CITY 10

1.2. WHY BLE 11

1.3. METHODOLOGY 11-12

1.4 OVERVIEW 12-13

2 SYSTEM ARCHITECTURE 14-18

2.1. BLOCK DIAGRAM 14

2.2. BACK-END 14-17

A. BLUETOOTH DETECTION 15
B.RUN TIME ENVIRONMENT 16
C. IoT GATEWAY 16-17
2.3. FRONT-END 18

3 SYSTEM IMPLEMENTATION 18-28

3.1 HARDWARE USED 18-22

A. BLE Beacon 18-19

B. Raspberry-pi 20-22
3.2 SOFTWARE USED 23-28

A. NODE-RED 23-24
B. POSTGRE SQL 24
C. DJANGO 25-28
 Chapter
Chapter Name Page
No. No.

4 WORKING OF SYSTEM 28-32

4.1 BUS LOCATION TRACKING USING BLE 28-31

A. DETETCTION AT DEPARTING BUS 29-30

TERMINAL
B. DETECTION AT ARRIVING STATION 30-31
4.2 ESTIMATION OF BUS ARRIVAL TIME 31-32

4.3 AVERAGE HISTORICAL TIME 32-33

5 REVIEW AND RESULTS 33-37

5.1 DETECTION OF BLE BEACON 33-34

5.2 COMMUTER WEB APPLICATION 35-37

6 CONCLUSION 38

7 FUTURE WORK 39

8 REFERENCES 40
 ABSTRACT
Stage Bus is the most commonly used mode of public transportation in the world.
In many developing countries, people rely on public bus to commute between
home and work place. However, public buses often suffer from over-crowding, and
the current transportation infrastructure is not adequately supported by the
government to deal with the overwhelming number of commuters. In addition, the
public bus network in developing cities is mostly unreliable, and the service
frequency is unpredictable most of the time. Although a human time-keeper is
employed at the bus terminal to enforce the schedule of the bus, it falls short due to
human errors and non-compliance by the bus drivers.

With the advent of IoT and tracking technologies bus fleets can now be tracked in
real-time. This has provided great certainty to the commuters, allowing them to
plan their journey more efficiently and hence reduce their waiting time at the bus
stop. Many Public bus operators in developing countries do not have such a
solution in place to provide an accurate estimation of bus arrival time (ETA).
Without ETA information, it is very difficult for the general public to plan their
journey effectively. This paper proposes an innovative IoT solution to track the
location of buses without requiring the deployment of a GPS device. It uses
Bluetooth Low Energy (BLE) proximity beacon to track the journey of a bus by
deploying an Estimote location beacon on the bus. BLE detection devices
(Raspberry Pi 4) are installed at selected bus stops along the bus route to detect the
arrival of buses. Once detected, the location of the bus is submitted to a cloud
server to compute the bus ETA.
 1.INTRODUCTION

1.1- TRANSPORTAION IN A CITY

City transportation is an important pillar for quality of life of citizens in a city.
Making transport network of a city smart is one of the major tasks when it comes
to making smart city. In most of the city's public and private road transportation are
the key modes of commuting. As the population is increasing rapidly, traffic
congestion is prevalent. Primitive traffic systems are unable to cater the demands
of present-day traffic regulation. Thus, a smart traffic system is requisite. A system
that would provide user with real-time information about traffic congestion at
various places. All these features make tracking location of public transport like
buses crucial as it contributes to a major chunk of traffic.

The major impediment of traveling with bus is the inconsistent arrival time. Even
though bus schedule is known, there are a number of reasons like traffic
congestion, heavy downpour, bus breakdown, accident and day-to-day problems
faced by bus company owing to which bus may not arrive as expected. Another
drawback of the primitive bus system is that the safety of passengers has never
been considered. Also, the system has been ignorant towards specially-abled
people. This shortcoming has given the notion of developing an IoT enabled
system that would inform the commuters prior about the upcoming bus at the bus
stop. This will facilitate in passengers to plan trips with minimum wait-time.
1.2- WHY BLUETOOTH LOW ENERGY(BLE)

Various systems are developed to track the location of bus like GPS, RFID,
computer vision etc. GPS based bus tracking incurs from location error and high
data consumption and cannot be used effectively for the short distances.

RFID based systems can be used to provide a solution to this problem. But low-
cost RFID systems have low range and as the range increases the cost increases
exponentially. Computer vision-based approach to detect the arrival of bus has also
been proposed, but is an expensive alternate as the installation and maintenance is
costly. Also is affected by weather conditions such as rain, fog etc. So, we will
focus on Bluetooth Low Energy (BLE) Ultra-Wide band (UWB) beacons
technology for estimating the bus arrival time at the bus-stop.

1.3- METHODOLOGY

Fig-1.3.1
The transit web service will be provided by the server hosted by the Raspberry-Pi,
will continuously streams the data to be viewed, edited and to be transferred, in
order to proper functioning of the whole system. It is responsible to the whole
management of the data which plays the crucial role in calculating the Estimation
Arrival Time of the Bus.

From the initial point of the system where a bus is needed to be identified using its
beacon-id will gives the information response to the request made by the server
and updates the Database with the Real-Time Data that has been carved out from
the sensed information and the calculated ETA can be viewed in the Webpage
using the particular Application Interface program which has been carefully
developed to get display the personalized data considering every type of the user.
The methodology will be detailed in the subsequent chapters.

1.4- OVERVIEW

The system aims at enhancing the overall traveling experience of commuter. The
proposed system consists of UWB BLE beacons that are attached to each bus and
are operating in broadcasting mode. On the other hand, bus stops would have a
Raspberry-Pi module installed. This raspberry Pi module will receive notification
about the arriving bus which would be uploaded on cloud. Also, the system would
keep the users informed about the status of bus in real-time by broadcasting a
precise notification on their smart phone about the arriving bus or any updates in
schedule. It would facilitate in passengers to plan trips with minimum wait-time.
The commuter and bus driver will be provided with a mobile application.
The commuter's mobile application will have features that will consist of bus
schedule details, prior seat reservation and booking of bus pass. This would require
the mobile application with Internet connectivity. Along with it an additional
support for payment wallets is integrated for easy payment of bus fare.

This app gives a view of seats booked at each bus stop and whether a specially-
abled person will be boarding the bus. For upcoming bus notification, the bus-stops
have raspberry Pi installed with its Bluetooth enabled.

As beacons come in range of the raspberry Pi, it would broadcast the notification.
The Raspberry Pi is programmed in a such a way that it will upload Realtime bus
arrival time on cloud to enable commuters fetch the details. This notification would
also be broadcast in audio format at the bus-stop which would address person with
visual disability.

The data gathered using raspberry Pi provides valuable insights to manage arrival
delays and traffic congestion. The advantage of UWB BLE based solution is its
simplicity, high customization and low-latency support. Also, UWB BLE beacons
consume very less power and no pairing is needed for communication which
allows the system to handle as many buses at a given time, increasing the
robustness of the system. High UWB BLE range facilitates in rapid detection and
its effectiveness is not deterred in different experiment conditions unlike GPS
which may not provide precise location details.
 2.SYSTEM ARCHITECHTURE

2.1- BLOCK DIAGRAM

Fig.2.1.1
2.2-BACK-END
A. BLUETOOTH DETECTION
Bus arrival detection constitutes of UWB BLE beacons attached to each bus to
be considered in the system. These beacons have range up to 200 meters and
consume low power. This drawback of feasibility range of beacon is resolved by
uploading the data on cloud using Raspberry Pi installed on each bus stop.
This will facilitate commuters in knowing the bus arrival details before hand and
plan their journey. This will also help in providing estimated delays in bus arrival.

B. RUN TIME ENIVORNMENT

Each beacon is given a unique SSID. A database consisting of SSID mapped with
its corresponding MAC address for each beacon is maintained on cloud platform
for each bus stop. It also consists of the route which the bus would be traveling
from along with the estimated time to reach each bus-stop on its way. Each bus
stop has a raspberry Pi and speaker installed.

C. IoT GATEWAY

The IoT gateway is programmed in such a way that it continuously scans for
beacon. Once the beacon is detected, the SSID of the beacon is fetched and
validated in the cloud database. This information can be used to perform analytic
support and present insights about traffic congestion and delays in bus arrival.

Raspberry Pi installed at the bus stop continuously runs a program to scan for
UWB BLE beacons. The algorithm used to program raspberry Pi is described with
the help of a flow chart.

The algorithm described in the Figure is explained below:

1. Raspberry Pi is programmed such that it continuously scans for BLE Devices

2. If device is found, the corresponding SSID of beacon is fetched.

 Fig.2.2.1

3. The SSID obtained is then matched with the database stored on cloud. This
database consists of all information related to bus route, arrival timings at
respective stops, bus route etc.

4. After validation from database a notification is generated which is broadcast to

the Commuter application for the Visualization of ETA and etc. and is advertised
at the bus stop through speakers.
2.3- FRONT END

A. FRAMEWORK

The entire functionality of the back end is to proper serve the information required
for the different set of users in different modes by using the FRAMEWORK. It is
the bridge to visualize the data that has being processed by the backend model.

B. API

The API is used to pull out the personalized information required to any user from
the cloud which the data has been transmitted to it and stored using the back-end
servers.

3. SYSTEM IMPLEMEMTATION
The accurate usage of the concepts involved in the system will be reflected as the
important and key features of the whole functioning system. The concepts required
to implement the smart transportation system should be both the Hardware and
Software related to overcome the possible issues that can be arise in the working of
the system. The Hardware problems such as the Power supply, battery-life,
overheat of the processor and all the other connections of the components.

Now, coming to the Software related issues that can be arise takes the important
role as the problem cannot be identified directly till the troubleshoot of the whole
process that has been implemented. So, the smooth transition of the data should be
happened in the whole Software flow of the data starting from the sensing of the
information to get the personalized data to the front-end visualization.
Whole process should be carefully managed from end to end in order to give the
exact information to the end-user. The trick with the Software is it would be very
easy to manage the Data-Flow and to troubleshoot any issues once it has been
perfectly established.

3.1- HARDWARE USED

A. BLE BEACON

The word Beacon was given to it as it is very durable, simple and carriable very
easily as it is simple light weight and small size.

The Usage of the beacons continuously transmitting the Bluetooth low energy
signals was not much complicated as there is no need to install any power supply
until the charge in the battery drains out completely and can be rechargeable
immediately when it happened.

The advantage of UWB BLE based solution is its simplicity, high customization
and low-latency support. Also, UWB BLE beacons consume very less power and
no pairing is needed for communication which allows the system to handle as
many buses at a given time, increasing the robustness of the system. High UWB
BLE range facilitates in rapid detection and its effectiveness is not deterred in
different experiment conditions.

The Ultra-Wide Band BLE beacons are placed at the front side of the bus. The
Bluetooth module operates at a frequency of 2.4GHz ISM band. The size of the
module is very compact and has a broadcasting range up to 200 meters. Beacon
featuring with built-in Bluetooth 5.0 Module which helps it operating in high
frequency with long distance range by supporting the UWB signals transmission
with low power consumption.
 B. RASPBERRY-PI

Raspberry Pi is a 64bit ARMv7 Quad Core Processor powered Single Board

Computer running at 1.2GHz. It has a built-in Bluetooth 5.0 module which
continuously scans for Bluetooth devices. It also has a BCM43143 Wi Fi module.
This Wi Fi module connects raspberry Pi with the database hosted on cloud.
Raspberry Pi installed at the bus stop continuously runs a program to scan for
UWB BLE beacons. Raspberry Pi is programmed in such a way that it periodically
scans for the BLE signals every 5-7 seconds. As, the processor runs every minute
vigorously the heat produced while running the programs installed may cause
effects while it runs for the entire process. So, the cooling system must be affixed
with the Raspberry-Pi to exhaust the overheat outside to the environment by using
cooling fans to cool down the temperature of the processor and maintain the
perfect temperature conditions to run the processor successfully for a very long
period of time. The Power Supply should also be taken care of as it should not be
interrupted for the very minute reasons, and giving the exact amount of voltage
without any fluctuations and provide the required power supply, giving the high-
power supply than the required may cause over-heat again and the low-power
supply than the required amount resulting in frequent loss of supply and make the
processor runs slow than the normal speed it process the programs given to it.

The Bluetooth packages must be installed for scanning the signals and for make the
scanning periodic without being prompted every time, node java script must be
installed in the Raspberry-pi. The General Attribute gives the profile of it to be
used as commands in the node terminal to read and write the information to
convert it into the Data required, that should have been upload to the Database.
 Fig.3.1.1

Starting with the installation of the Node Java Script (NODE.JS) in the Raspberry-
Pi to define the node function to operate periodically over a certain amount of time.

Fig.3.1.2
Here, the node manager manages everything mainly the indentation of the
program, when should it be start scanning for the BLE beacon for how much long
it should scan for it and do the iteration of the same after every same amount of
time.

The displaying of the scanned information will be displayed on the Node terminal
after the node manager successfully stops after finding the BLE devices nearby.
After displaying the information that has been provided by the beacon consists of
SSID, RSSI level, Mac Address, Distance from the scanner. Now to assign the data
transmitting function to the Raspberry Pi GATT tool commands will come in to the
action for reading and writing the information and carve out the required data from
the sensed information.

The GATT commands will assign the attributes for reading which means each
piece of the displayed information will be mapped to the respective attribute
assigned. This process is inbuilt by the Bluetooth packages that have been
downloaded and installed, coming to the writing attributes the manual commands
can be given to the previously assigned attributes to change the identification in the
means of name which is very much required for initiating the Data-Flow process.
The Attribute ID should be matched as in the Node-Red cloud server to further
transmitting this real time data into a Database server running by POSTGRE SQL.
3.2- SOFTWARE USED

A. NODE-RED

The Software which used to connect the hardware to transmitting its data to a
visualization end using a cloud server to view as per requirements to the further
proceedings. It is a Flow connector maintained under a cloud server to connect
with the Database running on another server. The connection flow can be done
using the nodes which are already preinstalled with the node red software.

The Java Script program written in the Node manager of the Raspberry-pi can be
installed in this Software cloud server as a Node using Function Profile further
connected to the Attribute ID nodes which are defined here are mapped with the
respective information.

Fig.3.2.1
The main process was detailed and to function in whole perspective, the data
should be further passed to the Database. This connection was further made to the
Database server using all the previous flow of the data and the required nodes of all
the credentials like Port Number, Database Name, Table name which will be used
for the visualization containing all the fields to store the real-time Data that has
been flowing in the entire connection for only this perspective.

Fig.3.2.2

B. POSTGRE SQL

The Database is maintained in the postgre admin server and can be accessed by
any computer by providing the correct credentials and it will be help to process the
real-time data stored in the table using for the visualization layer where the
calculation of ETA will be takes place. The Tables can be created in the Database
server using the Models layer of the Django by defining the objects using python a
machine language.

The Data from the Node-Red comes and settles under these Objects as the Row
fileds in the table, where the defined objects act as the Column fileds with the
appropriate templates which are the Attribute Ids from the nodes of the Bluetooth
Packages.

C. DJANGO

The Django is a certain Framework that binds the front-end visualization layer and
the back-end servers together in a very coherent way that a task can be performed
in an efficient manner and obtain the required information in the front-end using all
the data that has been streaming in the back-end servers as user-friendly
considering all the personalization's that a user can do in front-end webpage where
he/she can see the information of the Route, Bus, Calculated ETA, etc.

In addition to the Live-Tracking the implementation of the seat booking system has
been done, that means the user can book a seat in the bus before the bus arriving to
the boarding station of the user.

Django uses very powerful and useful technology for the database to get uploaded
itself using the Django Administration server. Generally, there is an urge to use the
SQL commands to make changes to the database irrespective of the front-end
framework, if one has to alter the Visualization according to the database.

In, Django, the administration layer provides a cool feature that we can alter the
stored records of the data in the tables of a database server without using the SQL
commands.
Django framework can be very useful and developer convenient as it provides
Model View Template (MVT) and Object Related Mapping (ORM) as well as its
base for the front-end visualization.

MVT:

The Model View Template method is widely used in Django as it is an inbuilt

feature of it, made it more developer friendly. The main theme of it is that
grouping the different types of machine language programs together which makes
everything easy for the visualization and troubleshooting the entire Django system
can be done in a sequential manner. The creation of the Project and starting an
application in Django, by default gives the three types of files Model, View and
Template. The Model file is to making the table consisting the required objects that
are used to create the API and View and Template together will be used to write
the API. The sequential system programming of the files is what the main scheme
here to make feel the developer can handle things in a constructed way and
much more organized.
 Fig.3.2.3

ORM:

ORM – Object Related Mapping is the feature servicing by Django Frame Work
which is very useful for mapping the fields/columns into the Database (any Query
supported servers such as PostgreSQL) as Class by defining the function. We can
implement as many Objects into the CLASS function which automatically get
updated as rows into the database. ORM can create the table very easily by simply
following some type of python commands of the Django. There will not be any
disturbances meanwhile creating the table unlike SQL commands as they can
interrupt in the middle if the indentation breaks the flow of the commands. And
ORM also be very helpful in managing the data inside the table and while writing
the API one can use those fields directly in their program with very few lines of
python commands by using the mapping list of the objects.
 Fig.3.2.4

4.WORKING OF THE SYSTEM

4.1- BUS LOCATION TRACKING USING BLE

BLE is a power-conserving sub-technology of Bluetooth, designed for devices and
machines that are connected to the Internet. Due to the low maintenance cost and
long-lasting battery life, it is a popular technology that is being widely used for
pervasive computing and IoT applications in recent years. BLE devices when set at
0 dBm (decibels/milliwatts) output power could produce a detection range of up to
50 meters. Any Bluetooth device, such as a Raspberry Pi 4 will be able to
determine within the set range of the BLE, whether there are devices within the
proximity.
Our proposed system uses BLE proximity detection in order to detect whether a
bus is (1) stationary at the starting point at the bus terminal

(2) passing through a bus stop along its bus route.

When the location of the bus is detected, the location information together with a
timestamp are sent to the cloud service, to trigger real-time estimation of bus
arrival time for all subsequent bus stops. When there is insufficient bus location
data, the cloud service will use the averaged historical travelling time between bus
stops to compute the ETAs. The Estimote proximity beacon is placed inside the
dashboard of the bus, broadcasting itself using iBeacon protocol. The Estimote
beacon can be configured to adjust the broadcasting power, maximum range of
broadcast and the advertising interval. The maximum range of ≈ 200m is used, to
ensure that that the BLE beacon can be picked up by the BLE detection device. A
standard Raspberry Pi Model 4 (RP4) device is used as the BLE detection device
mounted at selected bus stops and bus terminals.

It is programmed to periodically scan and discover BLE devices in the proximity.

There is a white list that contains the MAC addresses of all the Estimote proximity
beacons deployed on the buses, and the RP4 updates the list daily from the cloud
server. This allows for the RP4 to filter out non-relevant BLE devices, and only
discovers buses plying the route which pass by the bus stops

A. DETECTION AT DEPARTING BUSTERMINALS

A Raspberry Pi device must be mounted at the bus terminal to detect the
departure of the bus. The Raspberry Pi maintains a list of detected beacons (also
the buses) If it detects that the beacon is no longer in the vicinity, this implies that
the bus has left the bus terminal.
As the BLE detection can be inconsistent due to the interference, a single non-
detection does not necessary mean that the bus has departed. Therefore, when there
are three consecutive non-detection of the beacon, Raspberry Pi concludes that the
bus had left the bus terminal. Subsequently, the Raspberry Pi submits the location
of the bus (i.e., the coordinates of the bus terminal) to the cloud-based analytics
server, as the last known location of the bus. This would in turn trigger the
prediction of bus ETA based on the bus’s departure time. when the bus is entering
the bus terminal, the Raspberry Pi is able to detect that the bus is already in the
vicinity as the moving speed of the bus is slow. As the Raspberry Pi scans for the
presence of beacons every 30 seconds, it continuously monitors and detects
whether the beacon is still present at the bus terminal. When the bus is parked at
the parking bay, the bus will be at its closest point to the Raspberry Pi and hence it
will be easily detected. Finally, when the bus departs from the terminal, the beacon
will no longer be detected.

B. DETECTION AT ARRIVING BUS STOP

The proposed system assumes that the bus usually stops at the bus stops to allow
for passengers to alight, as well as to pick up new passengers. As the bus is
stationary for about one to two minutes at the bus stop.

It allows for the RP4 to accurately discover the Estimote beacon in the bus, and
upon successful detection, sends the location of the bus stop (pre-set in the RP4) to
the cloud-based analytics service for processing. In the case that the bus stays at
the bus stop for a longer period of time, as the RP4 scans for the beacons every 30
seconds, it will keep on sending the bus location to the cloud service.
In this way, the system is aware that the bus is still at the bus stop, and the ETA to
the next stops will be updated accordingly and accurately until the bus leaves the
bus stop.

It is possible that RP4 detects buses on the opposite direction and this would have
an adverse effect on the estimation of bus arrival time if the bus is mistakenly
classified as plying the opposite service route. When a bus location is detected and
then submitted to the cloud-based analytics server, it first checks the travel
direction of the detected bus, i.e.., by checking whether the ETA of the last stop for
that particular service route is known. If the ETA for the destination is not known,
this implies that the bus is travelling on the opposite direction. In addition, the
placement of RP4 and also the number of RP4 deployed would significantly
determine the accuracy of the ETA. Having a RP4 mounted at every bus stop
means that more location data of the bus can be collected. This will improve the
accuracy of the ETA, however there will also be an increase in the operating cost.
Hence, placing the RP4 at a strategically located bus stop could help in terms of
cutting down the number of RP4 being deployed, while maintaining a certain level
of accuracy.
4.2 ESTIMATION OF BUS ARRIVAL TIME (ETA of BUS)
The bus service route is pre-defined prior to the deployment of the system. The
route information is converted into a polyline, i.e., a set of GPS coordinates
(latitude, longitude), so that the distance between a bus stop on the route with the
last reported bus location can be calculated, and subsequently deriving the ETA. In
addition, all the bus stops along the route are identified and then mapped to the
closest point on the polyline for the route. Using Haversine Formula, the distance
between two GPS points (obtained from the route polyline) can be accurately
calculated, hence the distance between consecutive bus stops can be calculated
based on the route and then stored in the database.

As each bus stop is mounted with an RP4 to detect the bus, essentially the
proposed system is able to track the journey of the bus effectively when the bus
passes by the bus stop. When detected, the location of the bus is sent to the cloud-
based analytics server. An ETA computation process is executed every 30 seconds
in order to update the time of arrival of all bus services at every bus stop, based on
the reported bus location collected from the RP4.

For each bus service route, the ETA computation process determines the latest bus
location, Tn, which is usually a bus stop. The distance between bus stops, such as
d0 and d1, is fixed and pre-computed when defining the bus service route. In order
to accurately estimate the bus arrival time at the next few stops, the average speed
of the bus in the past 5-10 minutes, v is used.

The distance between two points in the past five minutes are determined, and using
the total travelling time between the two points (Tn to Tn−3), the system is able to
determine the average travelling speed.
As a result, the ETA for the next few bus stops can be calculated. In the case that
there was no reported bus location in the past five minutes, the historical averaged
travelling time.

4.3- AVERAGE HISTORICAL TIME

In our previous work, there was a batch processing job that is executed once a day
to analyze the bus location data in order to compute the average journey time
between bus stops for all routes. The algorithm simply iterates through the location
data collected and find the closest point to the two consecutive bus stops and
calculate the velocity, v of the bus. Using the pre-computed distance between the
bus stops, the journey time between two bus stops, T can be derived.

Currently, the computed T is averaged with the historical data, and organized
according to the day, and time of the journey. With the historical average journey
time, when the bus departs from the Terminal, as there is only one location data
reported, our system first uses the historical journey time to estimate the ETA for
all bus stops along the route, until sufficient location data have been collected, only
then the real-time prediction of ETA is triggered.
 5. REVIEW AND RESULTS
This section describes a set of tests to determine the accuracy of Estimote location
beacon detection.

5.1- DETECTION OF BLE BEACON

Table I shows the result of a range test for detecting a BLE beacon. The test
measured the furthest distance the beacon could achieve based on its broadcasting
power level, while still being detected by the RP4. The test was conducted by
changing the broadcasting power level of the Estimote location beacon. The
evaluation was performed in a void deck in a housing area, where there was
interference from the building walls and also Bluetooth devices.

Transmission power (in dBm) Maximum Range (in meters)

-60 0.2
-50 0.4
-40 1.2
-30 2.0
-20 3.8
-10 5.0
-4 12.2
4 20
12 33.7
TABLE-5.1.1
The venue of where the test was conducted is a good gauge of how the actual
usage of the system is being used, as the place where the RP4 is deployed would
also have interference such as Bluetooth devices coming from the passengers’
smart phones.

Fig.5.1.1

Based on the result shown in Table I, the application of using the Bluetooth
beacons to track the bus is feasible as it is possible to detect a Estimote beacon
which is 33.7 m away, with interference inclusive. We note that the distance
between the bus stop and the furthest lane on the opposite direction is typically be
less than 40 m.
5.2- COMMUTER WEB APPLICATION
A Web App has been created to let the passengers check the bus’s ETA on their
smart phones. The Web App is build based on the Django Framework using the
implementation concepts discussed earlier and uses API to obtain the necessary
data from the cloud server.

A. LANDING PAGE

If the users are newly accessing the Web Application, one should register oneself
into the database and then sign-in with the credentials entered by them to register
in the database. Then the users can able to access all the webpages in the
Application to view and able to get the data required by them. After the process
has been done by the users, The Landing page provides the user to Sign with their
credentials redirecting to another webpage of FIND BUS.

Fig.5.2.1
 B. FIND BUS

The users can fill out the required fields upon their interests and where they need to
travel. The required fields contain the SOURCE and DESTINATION which any
users were boarding from the Source point and to specify their Destination. After
they can able to search for the Bus number, Route Id, stations in the whole route of
the Route Id, Number of stations covered till the latest iteration of updating the
database with the real-time data using Node-Red as previously discussed in the
Implementation of the System.

Fig.5.2.2

C. RESULT PAGE

In this page the users can find their results according to the information they
provided in the required fields of the Find Bus page.
They can have a quick view of the buses that have been rotating in the Route and
can come to know about the ETA of the Bus. User thus can know all the details of
the bus they want to boarded in, and the stations that have been covered till the
latest update of the database. And they can able to view the number of stations of
that has to be covered. The Booking of a seat in the preferred bus as per the user
can also be done which will add another strong feature for the proposed system.

Fig.5.2.3
 6.CONCLUSION
We have proposed a new way of tracking the location of public buses using BLE
beacon, in order to provide an estimation of bus arrival time. With sufficient
location and bus arrival data collected, the proposed system predicts the bus arrival
time. The ultimate aim of this research is to design an accurate bus location
tracking and ETA system that does not rely on the availability of real-time GPS
data. With such a solution, it can be deployed in many developing countries to
improve people’s mobility and journey experience.

This paper can be concluded as all the problems that have been discussed in the
Abstract were addressed and can help in reducing the impact of those problems can
meet the main objective of the Smart City which is to better facilitate, assist,
simplify, comforting, the way of living of the people in that city and help them to
think, act, live smart using the technology. The efficient working system
implementation of this project in a large scale with in the city can help the
environment as well by reduce the number of vehicle users who can get benefited
and meet the requirements of their travelling with in the city by using this project
for their daily commuting further helps in reducing the emission of the carbon
mono oxide gases from the vehicles, and make one step forward towards Smart
Green City requirements.
 7. FUTURE WORK
This project can be further developed by integrating sufficient location and bus
arrival data collected, with a deep-learning model with linear regression to learn
about the journey duration between two points during peak and non-peak period,
taking into account the weather condition that might affect the journey time. The
bus location data collected from this research will then be fed into the machine
learning model to refine the prediction engine, thus increasing the accuracy of the
estimation of bus arrival time.

As part of the predictive analysis of ETA, the proposed system can make use of
Google Traffic API to determine the traffic condition of the road that the bus will
be traveling on. The current system could only detect delay based on the reported
location of the bus by the RP3. Thus, there might be a slight miscalculation of ETA
in the case where the bus was delayed for a long period of time and the distance
between the previous RP3 and the next one is a long distance. Hence, by making
use of the traffic data obtained by Google API, the calculation of ETA can be
optimized by adding the amount of extra time the bus will spend on due to heavy
traffic.
REFERENCES
1) Overview and evaluation of Bluetooth low energy: An emerging low-power
wireless Technology. By ‘Joaquim Oller and Josep Paradells’.

2) Towards an IoT-based system for Smart City, “In Consumer Electronics

(ISCE)”, 2016 IEEE.

3) Towards the development of intelligent transportation systems. “In Intelligent

transportation systems”, vol. 88,

4) IoT based of RFID Bus Tracking System to Support Green City Initiatives, 2019
IEEE International Conference on Sensors and Nanotechnology, Penang, Malaysia.

5)A Prediction Model for Bus Arrival Time at Bus Stop Considering Signal
Control and Surrounding Traffic Flow, 2020. By ‘Hu Zhang, Shidong Liang’.

6) A Study of a Bus Stop that Displays the Current Location of the Bus to Increase
User Convenience, 2020 IEEE 9th Global Conference on Consumer Electronics
(GCCE), Kobe, Japan.

7) Smart Passenger Information System Based on IoT, 2019 TRON Symposium

(TRONSHOW), Minato, Japan, 2019.