Future Prospects

The are a few improvements which can be made in the project some of which are listed:

1. Use of sleep mechanism in the transmitter to improve the battery life and reduce power consumption.

2. Daisy chain the LED matrices to improve the display at each bus stop.

3. Make the android application more intuitive for the user.

4. Replace the laptop at the bus stop by a Ethernet shield on the arduino which can be used to send the data to the pseudo server.

5. Provide assistance to the operator as well by showing bus timings as a separate application.

6. Do traffic analysis to deploy more buses in case of heavy traffic.

Difficulties faced

We faced a few issues as we moved on in the project:

Problem:  The LED matrix and the MP3 shield would not work on the same hardware SPI even if we correctly altered the chip select pin.
Solution: We implemented software SPI for the LED matrix as we had a few extra pins on the arduino.

Problem: The Bus stop reading the serial port read trash values and incorrectly updated the database.
Solution: We adjusted the minimum number of bytes read to make sure that no trash value is read. Also we set conditions in the database to avoid incorrect updation.

Problem: Developing a server that could handle multiple requests from users
Solution: We spawned a new process each time a request is made to the server by a user. We kill it after it processes the request.

Problem: Android application would crash sometimes when sending and receiving data from the android server.
Solution: We created a new thread to handle the socket connections. Only after the thread finished did we move to the next screen to display the results. This significantly reduced the untimely crashes.

Problem: Network problems would not allow connection to a remote socket and crash the application.
Solution: Implement a catch mechanism in the JAVA code to go back to the previous screen in case of network problems.

Android Front End - Google Maps

Google maps was an integral and important part of the project. We used the maps feature for the following purposes:
Show user position
Show the closest bus stop
Plot bus routes
Show bus position
Navigate to a bus stop

We used the google maps API v2 for the project. It was more complex than the original API v1 but the maps were more interactive and feature rich as compared to the original version.
In this version, since maps are now encapsulated in the map fragment class ,we could show a map by itself on smaller screens such as mobile phones or tablets. 

Google provides many tutorials and API support online which makes implementing maps a smooth process. We did need to make a few modifications to suit our project and implement a few extra features but otherwise there is plenty of support available online.

Steps to get started (For a first time user):

1. Download and configure the Google Play services SDK. The Google Maps Android API is distributed as part of this SDK.
2. Obtain an API key. To do this, you will need to register a project in the Google APIs Console, and get a signing certificate for your app.
3. Specify settings in the Application Manifest.
4. Add a map to a new or existing Android project.
5. Publish your application!

To get detailed information, go to:

Google Maps Tutorial

Android Front End - Design

The android front end was the most important part of out project. It was extremely important for us to design a user friendly UI since without an intuitive front end, the work done in the backend would be of no use. We made sure that the user would have no difficulty in finding the bus timings he/she required by making the design as simple and descriptive as possible. We also made sure that the user would have no difficulty in understanding the navigation features of the application.

We were successful in hiding the details involved and made the user experience as simple as possible. Making different people try our application helped us understand and make changes depending on the feedback received.

We have a number of screens which show different information as requested by the user. Our application also has the Google map feature using which the user can find bus positions, the closest bus stop, the bus routes, and directions to the closest bus stop.


The application starts with a welcome screen that has a picture of a bus and the name of the
application. As soon as the application is started a picture is displayed on the screen and a thread is
created which sleeps for 4 seconds . At the end of 4 seconds, the ‘LOADING’ intent is started.

The intent MENUSCREEN has three radio buttons and a submit button that allows the user to
decide if he wants information according to the buses, according to the bus stops or if he wants to
get information using the maps. Based on the selection made by the user a new intent is started
(BUSSTOPINFO or BUSINFO or MAINACTIVITY).

If the user selects Bus Stop Information then the intent BUSSTOPINFO starts. This intent has two radio
buttons that allow the user to select the bus stop number for which they want to get information.

If the user selects Bus Information then the intent BUSINFO starts. This intent has two radio buttons that
allow the user to select the bus number for which they want to get information. On making a selection
and submitting it via the button ‘GO’ an intent ‘BUSDISPLAY’ starts. The screenshot is shown below.

Google Maps screenshots:
                                                              Displays the 3 bus stops

                                                            Displays the bus position

Display the Bus route

Provide navigation assistance

Embedded Front End Integration

The architecture of the entire integrated system can be viewed in the project architecture section of the blog.

The bus stop transmits a string of data continuously to the bus stop every second. The data structure used here is String. The string consists of two parts the first part denotes the bus number, and the next part of the string consists of the bus stop that it is heading to. For example the bus number 21 transmits “2133” before reaching the bus stop 33. The first part of the sting “21” is the bus number and the next part of the string “33” is the bus stop that it is heading to.

The code which is running at the bus stop continuously checks if it is receiving any data from the bus and when this happens, it parses this data to obtain the bus number and the bus stop and functions to display visual information on the LED Matrix and play audio information using the MP3 Shield are called.  It then re transmitted to the bus the bus number and the address of the next bus stop it has to go to.

We tested the system using 2 buses and 2 bus stops. The bus stops were around 200 meters apart. 

We had the pseudo server and the android server running at one bus stop to which the other bus stop communicated using TCP/IP.

Each bus stop looked like this:

The video for the actual demonstration was also recorded.

Embedded Front end video

The Backend - Pseudo Server

The pseudo server is a remote server with which each bus stop communicates. This server is meant for data logging purposes based on the data received from each bus stop. Initially this server is also intended to create the database and appropriate tables in the database.
The data  received by the server from the bus stop is in the form (bus stop, bus no). Based on the data it received it updates the tables after time stamping the arrival of the information. This is done so that data retrieval at a later stage is accurate and the user gets to see the correct timing which is updated by once central server.


Database :

The server creates a SQLite3  database with a table for each bus and bus stop. Doing this the retrieval of data is much more simplified since memory is not really an issue for a central server.
The tables are updates using prepared statements in C.

For the purpose of simplicity, we have set the ETA for a bus on the bus stop as 1 hour from the current time and  the ETA for the next bus stop as 10 minutes from the current time.

The Backend - Android Server

This is a multi-process server whose primary purpose is to respond to queries sent by the user from an android application. It send the bus or the bus stop information to the user based on the request. It also sends data regarding the position of the bus .

This server has access to the database which is created and updates by the pseudo server. This server is ideally hosted on the same computer as the pseudo server. It spawns a new process to respond to the request from the user since multiple users might want to access the database at the same time. As soon as the request is processed, the process is killed.

The server is listening continuously on a port dedicated for this purpose.

The user application sends a code using the TCP/IP protocol because data loss cannot be tolerated. Each request is sent as a code which are shown below:

Code Purpose
21 Get bus 21 information
22 Get bus 22 information
33 Get bus stop 33 information
34 Get bus stop 34 information
100 Get bus 21 current position
101 Get bus 22 current position

The server sends a response by collecting data from the appropriate table and appending the strings to form 1 38 byte string with a ' $ 'as a last character to indicate end of string to the receiving android application.

Advantage of having 2 servers:

The data logging part is separated from the data retrieval part and hence the backend is more modular and reliable. One central server can be complex to manage as it might be difficult to handle data sent bus stops and user applications all on one port.