final docu paged

132
Design of a Vehicular Collision Automatic Advisory and Data Management System A Thesis Project Presented to the Faculty of The Electrical/Electronics Engineering Department of the University of San Carlos Cebu City, Philippines In Partial Fulfillment Of the Requirements for the Degree Bachelor of Science in Electronics Engineering By Gerard O. Campomayor Jelley Gay P. Ceniza Donna Bel R. Flores Dexter E. Nuevo

Upload: papepipopu07

Post on 02-Nov-2014

110 views

Category:

Documents


2 download

TRANSCRIPT

Design of a Vehicular Collision Automatic Advisory

and Data Management System

A Thesis Project

Presented to the

Faculty of

The Electrical/Electronics

Engineering Department of the

University of San Carlos

Cebu City, Philippines

In Partial Fulfillment

Of the Requirements for the Degree

Bachelor of Science in Electronics Engineering

By

Gerard O. Campomayor

Jelley Gay P. Ceniza

Donna Bel R. Flores

Dexter E. Nuevo

Engr. Jerome M. Puza

Engr. Adrian D. Villarin

Advisers

February 2013

Acknowledgement

Abstract

Approval Sheet

Table of Contents

Title Page

Acknowledgement i

Abstract ii

Approval Sheet iii

Table of Contents iv

List of Figures and Tables vi

Chapter 1 The Problem and Its Settings 1

1.1 Introduction 11.2 Statement of the Problem 21.3 Significance of the Study 31.4 Scope and Limitations

41.5 Definition of Terms 5

Chapter 2 Review of Related Literature 8

1.6 ECall 81.7 Portable Systems 91.8 Single-board Embedded System 111.9 Data logger and Google Maps 12

Chapter 3 Methodology 13

1.10 Project Flow 131.11 System Overview 14

1.12 Client Module 15

1.13 Server Module 211.14 Software Support 251.15 Calibration of ADXL345 291.16 Testing

31

Chapter 4 Results and Discussions 33

1.17 Small-scale In-vehicle Sensor System 131.18 Communication Device Using GPS and GSM/GPRS Module 38

1.19 Receipt and Storage of Data into the Database 41

1.20 Display of Information from Database to Website 421.21 Testing

44

Chapter 5 Summary, Conclusions, and Recommendations 81

1.22 Summary 811.23 Conclusions 811.24 Recommendations 82

Bibliography 84

Appendices

Appendix A – Gantt Chart

Appendix B – Bill of Materials

Appendix C – Client Module Hardware Connections

Appendix D – Module Schematics

Appendix E – Datasheets

Appendix F – Microcontroller Unit Code

Appendix G – ‘Default.php’ Page Code

Appendix H – ‘Acceleration.php’ Page Code

Appendix I – ‘Details.php’ Page Code

Appendix J – ‘Receive.php’ Page Code

Appendix K – ‘Greys.css’ Page Code

Appendix L – Photo Documentation

Curriculum Vitae

List of Tables and Figures

Tables

Table No. Title of Table Page

1.1 Percentage of Vehicular Accidents in 2011 and 2012 1

1.2Records of Road Accident Fatalities and Injuries in

ASEAN Countries 2

4.1Summary of Acceleration of Gravity Measurements before

and after Calibration36

4.2Accelerometer and GPS Information (Latitude and Longitude) at Paseo Arcenas, Banawa, Cebu City

46

4.3Error of Location Information Acquired at Paseo Arcenas,

Banawa, Cebu City47

4.4Time Information Acquired at Paseo Arcenas, Banawa,

Cebu City48

4.5Time Delay of Information Sending through GPRS at

Paseo Arcenas, Banawa, Cebu City49

4.6Time Delay of Information Sending through SMS at Paseo

Arcenas, Banawa, Cebu City49

4.7Accelerometer and GPS Information (Latitude and

Longitude) at Shell Station - Basak, Pardo51

4.8Error of Location Information Acquired at Shell Station -

Basak, Pardo52

4.9 Time Information Acquired at Shell Station - Basak, Pardo 53

4.10Time Delay of Information Sending through GPRS at

Shell Station - Basak, Pardo54

4.11Time Delay of Information Sending through SMS at Shell

Station - Basak, Pardo54

4.12Accelerometer and GPS Information (Latitude and Longitude) at Jollibee - North Reclamation Area

56

4.13 Error of Location Information Acquired at Jollibee -

North Reclamation Area57

4.14Time Information Acquired at Jollibee - North

Reclamation Area58

4.15Time Delay of Information Sending through GPRS at

Jollibee - North Reclamation Area59

4.16Time Delay of Information Sending through SMS at

Jollibee - North Reclamation Area59

4.17Accelerometer and GPS Information (Latitude and

Longitude) at McDonalds - Lapu-Lapu61

4.18 Error of Location Information Acquired at McDonalds -

Lapu-Lapu62

4.19 Time Information Acquired at McDonalds - Lapu-Lapu 63

4.20Time Delay of Information Sending through GPRS at

McDonalds - Lapu-Lapu64

4.21Time Delay of Information Sending through SMS at

McDonalds - Lapu-Lapu64

4.22Accelerometer and GPS Information (Latitude and

Longitude) at Yati, Liloan66

4.23 Error of Location Information Acquired at Yati, Liloan 674.24 Time Information Acquired at Yati, Liloan 68

4.25Time Delay of Information Sending through GPRS at Yati,

Liloan69

4.26Time Delay of Information Sending through SMS at Yati,

Liloan69

4.27Accelerometer and GPS Information (Latitude and

Longitude) at Busay, Top's Entrance, Lahug71

4.28 Error of Location Information Acquired at Busay, Top's

Entrance, Lahug72

4.29Time Information Acquired at Busay, Top's Entrance,

Lahug73

4.30Time Delay of Information Sending through GPRS at

Busay, Top's Entrance, Lahug74

4.31Time Delay of Information Sending through SMS at

Busay, Top's Entrance, Lahug74

4.32Accelerometer and GPS Information (Latitude and

Longitude) at Nice Day Car Wash, Escario76

4.33 Error of Location Information Acquired at Nice Day Car

Wash, Escario77

4.34Time Information Acquired at Nice Day Car Wash,

Escario78

4.35Time Delay of Information Sending through GPRS at Nice

Day Car Wash, Escario79

4.36Time Delay of Information Sending through SMS at Nice

Day Car Wash, Escario79

4.37 Summary of the Performance of the System 80

Figures

Figure Name of Figure Page

No.

1.1Number of Road Fatalities as reported by the Police vs. the

Health Sector 3

1.2Records of Road Accident Fatalities and Injuries in ASEAN

Countries4

2.1 E-Call System Overview 92.2 GPS Based Road Management Architecture 102.3 Smart Phone Based Accident Detection System 102.4 Block Diagram of GPS-GSM Based Tracking System 113.1 Project Flow Chart 133.2 System Block Diagram 143.3 ATMega644 Pin Configuration 153.4 Gizduino+ Board 163.5 ADXL 345 Pin Configurations 163.6 GPS and GPRS/GSM Shields from E-Gizmo 183.7 Microcontroller Unit Program Flow 193.8 Server Code Flow 213.9 Hierarchies of the Website Content and Features 223.1 Process Flow Chart of 'Receive.php' Page Scripts and Codes 233.11 Process Flow Chart of 'Default.php' Page Scripts and Codes 24

3.12cPanel and its supported features: Used in managing the

website25

3.13 phpMyAdmin: Used in managing the Database 263.14 Notepad ++ Used in coding the PHP Pages of the website 27

3.15Arduino Integrated Development Environment used in

Coding the program for the Microcontroller Unit28

3.16FileZilla FTP Used in uploading and downloading files from

and to the website29

3.17 Accelerometer Output Response Vs. Orientation Gravitiy 303.18 Device Prototype for Testing 313.19 Prototype with its LED Indicators 32

4.1Acceleration of Gravity Measurements viewed on the

Arduino Serial Monitor34

4.2Acceleration of Gravity Measurements viewed on the

Arduino Serial Monitor after Calibration36

4.3Dynamic Resultant Acceleration Values viewed on the

Arduino Serial Monitor37

4.4Graph of Dynamic Resultant Acceleration (G) with respect to

Time(ms)37

4.5 GPS Information Viewed on the Arduino Serial Monitor 38

4.6GPS Location Information and Actual Testing Location

plotted on Google Maps39

4.7Communication between Gizduino+ and GSM/GPRS Module

viewed on the Arduino Serial Monitor40

4.8 Text Message Received by the Mobile Phone 41

4.9 Information Logged into the Database 424.1 Information Displayed in the 'default.php' page of the website 434.11 Information Displayed in the 'details.php' page of the website 43

Chapter 1

The Problem and Its Settings

Vehicular collision is one of the major causes of traffic accidents, road fatalities

and external injuries – it is a problem that continues to contribute to the declining

campaign on road safety [1][2][3]. An automatic advisory and data management system

for vehicular collisions has been proposed by the researchers to solve this problem. The

design and implementation of this study will contribute to the improvement of emergency

response and coordination of the relevant agencies. This chapter will give a background

on vehicular collision, present the proposed research problem, and outline the importance

of conducting the proposed study.

1.1 Introduction

Vehicular collision is a conflict between a vehicle and a moving or a stationary

object in such a manner as to exert a relatively strong force on each other for a relatively

short time. It is one of the major causes of external injuries, death and property damage.

In the Philippines, vehicular collision tops the list of external causes of reported injuries.

According to the recent data from the Department of Health, the average percentage of

vehicular collisions that happen in the Philippines is more than fifty-percent of vehicular

accidents[1][2][3].

Table 1.1 Percentage of Vehicular Accidents in 2011 and 2012 [1][2][3]

Period 3rd Quarter of 2011 4th Quarter of 2011 1st Quarter of 2012No. of Reported

Vehicular Accidents

(Percentage)

1,860 (28.5%) 2,589 (31.5%) 3,904(27.7%)

Percentage of Collision Vehicular

Accidents53% 58.1% 63.3%

There are many existing and proposed solutions in order to decrease the

occurrence or fatalities of vehicular collisions – implementation of laws and rules,

development of vehicular safety systems, automatic advisory to authorities, and gathering

of vehicular collision data.

One approach is to use automatic crash notification systems. These systems use

wireless telecommunication technologies, most often GSM or 3G, and Global Positioning

System (GPS) to instantly alert appropriate public safety agencies when a collision occurs

and inform them of the location of the incident. It reduces road fatalities by enabling

faster emergency medical services notification times, and therefore, the earlier provision

of treatment.

Data management systems are also very useful in vehicular collisions solutions by

keeping track of collision events and collecting relevant and accurate data for future

reference and analysis. The stored data could be used to design better safety systems.

1.2 Statement of the Problem

The researchers have recognized the need for an efficient and centralized road

accident data system in the Philippines. The lack of such system in concerned agencies

and companies has been a major hindrance to the improvement of road accident

management. Crash data is gathered and recorded separately resulting to limited and

inconsistent information and underreporting of vehicular collision cases.

The researchers have also recognized the need for an improvement in emergency

response to decrease fatalities in vehicular accidents. Response time of emergency units

and hospitals is known to be crucial in increasing the survival rate of the involved parties

in road accidents.

Thus, this study aimed to provide an automatic advisory to the authorities and

concerned personnel if there is a vehicular collision. The objectives of this study were:

i) To design a small-scale in-vehicle sensor system that will detect collision.

ii) To design a communication device using a GPS module, GSM module and

microcontroller that will send location and time stamp data.

2

iii) To develop a system that will receive data and store it into a database.

iv) To develop a website that will display data from the database.

1.3 Significance of the Study

The time-dependence of trauma from road crashes is well accepted within the

medical literature. A number of studies have also investigated the link between road

trauma fatalities and emergency services response times [4]. The faster the response time,

the less the number of fatalities is. In the Philippines, emergency response is slow

especially in rural areas due to delays in the reporting of the accident and the lack of

advanced communications equipment of the concerned agencies in monitoring the road

situation [5].

Automatic notification of vehicular accidents will improve the response time of

emergency units since it will be able to save crucial time spent on manually trying to

contact the authorities concerned. The automatic transmission of location and other

relevant data will help the emergency units to instantly plan routes, estimate the severity

of the accident and bring the needed equipment. It will also make possible emergency

response in remote areas especially during nighttime where it is unlikely for a witness to

be present.

Another persistent problem in road accident management in the Philippines is that

data gathering of the police and health sectors are not done in a centralized manner.

Because of this, there are inconsistencies and inadequacies in crash data for analysis. This

has also resulted to an underreporting of vehicular accidents to the police authorities as

shown in Figure 1.1 and Table 1.2.

Figure 1.1 Number of Road Fatalities as reported by the Police vs. the Health Sector [6]

3

Table 1.2 Records of Road Accident Fatalities and Injuries in ASEAN Countries [6]

Data on vehicular collisions—location and time of vehicular collision and severity

of collision—should be logged for precaution and for a more organized system of

gathering data by the police and concerned agencies. The detection and systematic

collection of vehicular collision data is essential for all the concerned agencies such as

the Philippine National Police – Traffic Management Group (PNP – TMG), Department

of Public Works and Highways (DPWH) and Department of Health (DOH) because it

can serve as a basis for regulation of new traffic laws, improvement of public roads and a

more convenient data gathering method. This will also help car companies to improve the

safety systems of their vehicles and reduce financial costs by making informed decisions

about the most effective measures to implement to manage risk.

1.4 Scope and Limitations

The study focused on the design of a small-scale prototype that detects collision

and has automatic advisory and data management system. The project was divided into

two major modules: the Client Module and the Server Module. The Client Module

hardware consisted of a microcontroller module with sensor, GSM and GPS shields. The

software consisted of an Arduino program for the microcontroller. The Server Module

4

consisted of a database wherein the location, timestamp and sensor data are stored and a

website to display the data from the database.

The type of sensor that was used in this project is the most common and readily

available in the Philippines. Sensors designed to specifically detect car crash are mostly

manufactured, sold and tested in other countries, therefore the main function of the sensor

module was limited to just triggering the microcontroller to gather data from the sensor

and logging it into the database. The standard threshold used by car security systems in

designing car crash sensors was not used because of the limited range of the sensor that

was used and limited means of testing. Instead, a lower threshold was set in order to

trigger the data gathering function of the microcontroller.

The prototype was designed such that vehicle design and construction, including

the placement of the device inside the vehicle, was hardly considered. The term

“collision” used in this study referred only to impacts beyond the set threshold of the

accelerometer, other factors such as rollover, impact force, and accident setting were

neglected.

The study did not cover crash testing involving actual vehicles because it is highly

expensive and there is no vehicular collision testing facility available in the Philippines.

The study also did not include further cyberspace security of the website other than the

security provided by the web host.

Strength of the device casing was assumed to be significantly high so as to

survive a crash impact. GSM/GPRS signal was assumed to be at an adequate level and

GPS position estimation was assumed to be adequately accurate.

5

1.5 Definition of Terms

Vehicular collision – occurs when a vehicle collides with another vehicle, pedestrian,

animal, road debris, or other stationary obstruction, such as a tree or utility pole. In this

study, it refers to an acceleration value that is beyond the threshold set by the sensor

system.

Sensor system – measures a physical quantity and converts it into a signal which can be

displayed on an instrument and read by a user, and can be programmed to detect changes

in parameters measured.

Global System for Mobile communication (GSM) – a digital mobile telephony system

that uses a variation of time division multiple access (TDMA) and operates at either the

900 MHz or 1800 MHz frequency band.

General Packet Radio Services (GPRS) – a packet-based wireless communication

service based on GSM communication with data rates from 56 up to 114 Kbps.

AT commands – allow giving instructions to GSM devices for operations like calling a

number, sending, reading, or deleting an SMS, setting the SMSC number, looking for a

GPRS access point, reading and deleting phonebook data, reading the battery status,

reading the signal strength, and so on. Different device manufacturers provide an AT

command set guide, where the basic command syntax and the response of the commands

are specified.

Global Positioning System (GPS) – a space-based satellite navigation system that

provides location and time information in all weather, anywhere on or near the Earth,

where there is an unobstructed line of sight to four or more GPS satellites.

6

NMEA – a combined electrical and data specification for communication between

marine electronic devices defined by the U.S.-based National Marine Electronics

Association. It uses a simple ASCII, serial communications protocol that defines how

data is transmitted in a "sentence". The standard also defines the contents of each

sentence type so that the message can be parsed accurately.

Data Management - is an administrative process by which the required data is acquired,

validated, stored, protected, and processed, and by which its accessibility, reliability, and

timeliness is ensured to satisfy the needs of the data users.

Web server – software that delivers Web content that can be accessed through the

Internet and is able to host websites and data storage. Using the Hypertext Transfer

Protocol (HTTP). HTML documents and any additional content that may be included by

a document, such as images, style sheets and scripts are delivered on the request to

clients.

Database – is a systematically organized or structured storage of information that allows

easy retrieval, updating, analysis, and output of data.

PHP – a widely-used general-purpose scripting language that is especially suited for Web

development and can be embedded into HTML.

7

Chapter 2

Review of Related Literature

In-vehicle emergency and security systems have become a necessity and an

advantage to car manufacturing companies ever since its development in early 2000s.

Most of these systems are equipped with communication services that aimed to provide

the automatic notification of a road traffic accident through GSM and GPS-based

positioning. This chapter will present different studies that are related to the proposed

research study and the methods they used in order to achieve their objectives. The

different advantages and disadvantages of the studies presented will also be discussed in

this chapter.

2.1ECall

Filjar, Vidovic, Britvic, and Rimac [7] presented the architecture and technical

solution of the modem-based eCall. ECall refers to an in-vehicle telecom service

expected to be introduced and operated across Europe on 2015. The introduction and use

of in-vehicle eCall for deployment of emergency assistance is expected to save lives and

reduce social burden by improving the notification of road accidents and speeding up

emergency service response [7]. The eCall device consists of in-vehicle control unit with

a GPS receiver and GSM connected to the car sensors. It triggers an emergency call upon

the detection of an accident or by manual interaction of the user and sends Minimum Set

of Data (MSD) containing the timestamp and geographical position of the accident,

activation indicator (manual or automatic), and vehicle type and identification number,

number of passengers.

8

Figure 2.1 eCall System Overview [7]

A disadvantage of this system is that the device is installed upon manufacture,

making the device (1) proprietary of the carmakers, which renders it difficult to use the

technology for the public’s optimum benefit; and, (2) unavailable in all vehicles,

especially those that was manufactured before the technology was developed. Moreover,

the system utilizes one of the vehicle’s pyrotechnic systems like the airbag or seatbelt

tensioning system, making the system expensive.

2.2 Portable Systems

A study by Pinart, Calvo, Nicholson, and Villaverde [8] presented an early crash

notification system that was dedicated to two-wheeled and secondhand vehicles. The

system has two major modules in its system, the accelerometer which was chosen as the

crash sensor and the eCall box – a communications enabled device which encompasses

GSM and Short-Range Communications (SRC). The connection between the crash sensor

and eCall box can be wired or wireless and its wireless connection was tested to be viable

in a worst-case scenario in terms of Bluetooth link quality and reliable in case of long

duration and crash detection. This service, however, requires a vehicle’s on-board or

portable computer for sending the crash data to emergency services, which is absent in

older vehicles and expensive to install.

Goh, Ng, Jusoff, Chen, and Tan [9] conducted a study on a GPS-based approach

for reporting thoroughfare problems such as malfunctioning traffic lights, potholes and

roads in bad condition via GSM. They used a GPS-supported GSM phone and Python

script to retrieve GPS signals and send SMS to server.

9

Figure 2.2 GPS - Based Road Management System Architecture [9]

A study by White, Thompson, Turner, Dougherty, and Schmidt [10] describes

how smartphones, such as the iPhone and phones that have Google Android platforms,

can automatically detect traffic accidents with their built-in sensors, immediately notify a

central emergency dispatch server after an accident, and provide situational awareness

through photographs, GPS coordinates, Voice over Internet Protocol (VOIP),

communication channels, and accident data recording.

Figure 2.3 SmartPhone-Based Accident Detection System [10]

10

Smartphone-based accident detection applications have both advantages and

disadvantages relative to conventional in-vehicle accident detection systems, e.g., they

are vehicle-independent, increasingly pervasive, and provide rich data for accident

analysis, including pictures and videos. Building a smartphone-based accident detection

system is hard, however, because phones can be dropped and generate false positives and

the phone is not directly connected to the vehicle so their motions do not directly mirror

the forces the vehicle experiences. In-vehicle accelerometers, on the other hand, are

physically mounted to the car, making them more reliable in detecting traffic accidents.

2.3 Single-board Embedded System

A study by Khan and Mishra [11] used a single-board embedded system that is

equipped with GPS and GSM modems along with ARM processor that is installed in the

vehicle, making the device portable, more compact, less costly, and specifically designed

for its function. The basic function of in-vehicle unit is to acquire, monitor and transmit

the position latitude, longitude, time to management center either at fixed interval or on

demand. Microcontroller unit serves as the heart of tracking unit, which acquires and

process the position data from the GPS module and sends the data to the management

center through the GSM Modem.

Figure 2.4 Block Diagram of GPS-GSM Based Tracking System [11]

11

2.4 Data logger and Google Maps

In the study by Goh, Ng, Jusoff, Chen, and Tan [9], the SMS server at receiver’s

side transfers data to local computer database. The system optimizes location, date and

time data by mapping the site onto Google maps using PHP scripts.

The study by White, Thompson, Turner, Dougherty, and Schmidt [10] is an

internet-based service that depends entirely on freely-available Application Program

Interfaces (APIs) and open-source software. The program for retrieving in storing data

information coded using Java language. It utilizes a MySQL database to store accident

information. The server communicates with the clients using custom Extensible Mark Up

Language (XML) for the Android application and JavaScript Object Nation (JSON) for

the web-based application. When an accident occurs, it is geo-tagged on the server with

its location and entered into a searchable database of accidents. The accident locations are

shown in a map through a Google Maps interface.

12

Chapter 3

Methodology

This study is a design-demonstration research of an automatic advisory and data

management system for vehicular collisions. Project construction consisted of: (1)

hardware design and implementation of a microcontroller unit equipped with sensor,

GPS, and GSM shields, (2) coding of the program for the microcontroller unit for alarm

sensing, location and time data gathering, and data sending, (3) coding of the program for

an online database and website for data storage and display. This chapter will present the

materials and methods that were used in the construction, testing, and evaluation of the

system in study.

3.1 Project Flow

The following flow chart maps out the entire process to finish the project within

the allotted time.

Figure 3.1 Project Flowchart

13

3.2 System Overview

The automatic detection of a collision is achieved by constantly monitoring the

output of the sensor, which in this study is the acceleration data from an accelerometer.

The microcontroller checks x-axis, y-axis and z-axis output data for sharp spikes in the

resultant acceleration values. If a peak above a certain threshold is found, the alarm

becomes active. The microcontroller extracts this peak acceleration data by accessing the

appropriate registers on the accelerometer.

The GPS module constantly outputs NMEA sentences containing location,

altitude, and other data. At the instant the alarm becomes active; the microcontroller

extracts time and location data from the GPS module. The microcontroller uses AT

commands to establish wireless communication and send the acceleration and GPS data

to a server through General Packet Radio Service (GPRS), a packet oriented mobile data

service on the 2G and 3G networks, and to mobile phones through Global System for

Mobile Communications (GSM). The server stores the received data on a database and

displays it on a webpage.

14

Server Module

Client Module

Figure 3.2 System Block Diagram

The system is composed mainly of the Client Module and the Server Module. The

Client Module consists of the in-vehicle device and was implemented using E-Gizmo’s

ADXL345 3-Axis Digital Accelerometer board, ATmega644 GizDuino+, SIM900D

GSM/GPRS Module and GPS Module. The Server Module is made up of a website

hosted by an online server that supports MySQL, PHP and is accessible in the domain,

sirena1234.vacau.com

3.3 Client Module

3.3.1 Hardware of Client Module

3.3.1.1 Gizduino +

The ATmega644 GizDuino+ was used as the main microcontroller for the system.

GizDuino+ is an Arduino compatible board that features 32 I/Os. It also has 2 hardware

UART ports which are ideal for the study because both the GSM/GPRS and GPS shields

were connected to UART ports. The ATmega644 variant features a 64K program

memory.

Figure 3.3 ATmega644 Pin Configurations [13]

15

The ATmega644 is a low-power CMOS 8-bit microcontroller based on the AVR

enhanced Reduced Instruction Set Computer (RISC) architecture. The ATmega series of

microcontrollers are created by Atmel and are currently used by the Arduino platform.

They feature general-purpose I/O ports, internal self-programmable instruction flash

memory, and a variety of serial interfaces.

Fig 3.4 Gizduino+ Board

3.3.1.2 ADXL345: A 3-Axis, ±2 g/±4 g/±8 g/±16 g Digital Accelerometer

Accelerometers measure the rapid deceleration of a vehicle on hitting an object.

They are the most widely used sensors in the automotive sector, especially in airbag

deployment.

Figure 3.5 ADXL345 Pin Configurations [12]

16

The ADXL345 was used as the sensor for the system. It is a small, thin, low

power, 3-axis accelerometer with high resolution (13-bit) measurement at up to ±16 g.

Digital output data is formatted as 16-bit twos complement and is accessible through

either a SPI (3- or 4-wire) or I2C digital interface [12].

An ADXL345 breakout board designed by E-Gizmo was used in this study. The

ADXL345 breakout board was connected to the Gizduino using SPI communication

protocol.

3.3.1.3 GPS and GSM Shield

The SIM900D GSM/GPRS module was used for the transmission of data.

SIM900D is a quad-band GSM/GPRS engine that works on frequencies GSM 850MHz,

EGSM 900MHz and PCS 1900MHz. It features GPRS multi-slot class 10/class 8 and

supports the GPRS coding schemes Coding Scheme-1, Coding Scheme-2, Coding

Scheme-3 and Coding Scheme-4.

A Smart Buddy SIM card from Smart Communications, Inc., with its data

services activated, was used for the GSM/GPRS module.

The SkyNav EG25A1 GPS module was used for the gathering of time and

location information. The GPS signal is applied to the antenna input of module, and a

complete serial data message with position, velocity and time information is presented at

the serial interface with NMEA protocol.

E-Gizmo’s GSM/GPRS Module and GPS Module are specially designed to

function as GizDuino shields. They were mounted directly on the GizDuino board.

17

(a) GSM/GPRS shield

(b) GPS shield

Figure 3.6 GPS and GSM/GPRS Shields from e-Gizmo

3.3.1.4 Power Supply

The modules used in this study had a single power supply which is two (2) 4V

lead-acid batteries in series. The supply voltage is regulated by regulators within each

module.

3.3.1.5 LED Indicators

Six (6) light-emitting diodes (LEDs) were used to display the functions of the

client module as they are being executed. They were connected to the digital output pins

18

of the modules. LED1 and LED2 indicate the initialization of the GPRS function of the

GSM/GPRS module. LED1 lights up when the module is attached to GPRS service.

LED2 lights up when wireless connection with GPRS is established. LED3 and LED4

indicate the sensing function of the client module using the ADXL345. LED3 lights up

when the microcontroller starts reading and processing acceleration values from the

sensor. LED4 lights up when the threshold acceleration value has been exceeded and the

collision alarm becomes active. LED5 and LED6 indicate the transmission of data. LED5

lights up when all the necessary information, specifically, peak acceleration, time, and

location, has been gathered and the data has been sent to the remote server. LED6 lights

up when the same information has been sent to the mobile phone through SMS.

3.3.2 Coding of Program for the Microcontroller Unit of Client Module

Figure 3.7 Microcontroller Unit Program Flow

19

The microcontroller unit was developed using Arduino. Arduino is an open source

physical computing platform based on a simple input/output (I/O) board and a

development environment that implements the processing language.

The program for the ATmega644 microcontroller was coded using the Arduino

language and Arduino IDE. The program executes as follows:

Communication with the GSM/GPRS module is established at a baud rate of

57600, utilizing the primary hardware UART port of the Gizduino. GPRS function is

initialized by using AT commands, followed by carriage return and newline, to attach

GPRS service, set GPRS as wireless connection mode, set TCP local port, set single IP

connection, start task and set APN for Smart Buddy (“internet”), bring up wireless

connection, get local IP address, disable IP header, and configure primary

(“208.67.222.222”) and secondary (“208.67.220.220”) domain name servers. LED1 and

LED2 light up.

SPI Communication with ADXL345 is established. LED3 lights up. The

ADXL345 is put into +/- 4G range and into measurement mode by writing to the

appropriate registers. x, y and z acceleration values are retrieved by reading data from the

appropriate registers and converting them to units of G. The resultant acceleration is then

calculated.

The said registers are continued to be read until the specified resultant

acceleration threshold is exceeded. In this case, the sensor alarm is considered to be

active. LED4 lights up.

Communication with the GPS module is then established at a baud rate of 9600,

utilizing the secondary hardware UART port of the Gizduino. The GPGGA sentence was

chosen as the source for the time and position information. This sentence refers to the

Global Positioning System Fixed Data. The Arduino code searches for the GPGGA

string: $GPGGA, hhmmss.sss (UTC time), ddmm.mmmm (latitude), N (S),

dddmm.mmmm (longitude), E (W)… The time, latitude, and longitude were extracted

from the GPGGA string. UTC time is converted to Philippine local time by adding 8

hours.

The time, position, and acceleration information is then prepared for sending

through GPRS and SMS. To send through GPRS, TCP connection is started using AT

20

commands. Domain name and port are set, in this case “sirena1234.vacau.com” and “80”

respectively, and data is sent via URL. LED5 lights up when the Arduino receives a reply

from the GSM/GPRS module indicating that the data was sent successfully. To send

through SMS, the SMS system is set to text mode, the mobile phone number of the

recipient is set, and text message containing the time, position, and acceleration is sent.

LED6 lights up when the Arduino receives a reply from the GSM/GPRS module

indicating that the text message was sent successfully.

The code was uploaded to the microcontroller by connecting the GizDuino board

to the computer via USB cable.

3.4 Server Module

Figure 3.8 Server Module Program Flow

The server module is made up of a website hosted by a server which supports

PHP Scripts and MYSQL Database. This website is acquired through free webhosting

service – a type of internet hosting service which makes websites accessible in the World

Wide Web through its free available domains. A website from 000webhost was acquired

with the domain http://sirena1234.vacau.com, equipped with 1500 MB disk space,

cPanel, PHP and MySQL support, and File Transfer Protocol Support. The control panel

provided by 000webhost also utilizes the use of phpMyAdmin in administrating MySQL

databases.

21

Figure 3.9 Hierarchies of the Website Contents and Features

Upon the acquisition of website, a database was created using phpMyAdmin. The

database name was set to ‘a6705968_oink’ and the table name was set to ‘arduino’.

MySQL makes use of tables which contain rows and columns for storing or logging

information from the data transmitted by the client module. Five columns in the ‘arduino’

table was created – the date column, which contains the date and timestamp upon receipt

of the transmitted data of the client module; the acceleration column, which contains the

values of acceleration transmitted by the client module; the time column, which contains

the timestamp of the collision – this timestamp is acquired from the GPS shield unlike the

22

000Webhost

Domain: sirena1234.vacau.com

Cascading Style Sheet

Support

Contains all HTML the

customizations of the page

PHP Scripts Support

Contains all the basic scripts needed for

connecting to the database, creating and customizing

pages

phpMyAdmin

Used for manipulating the database using

the browser

MYSQL Database

Database Name: 'a6705968_oink'

Table Name: 'arduino'

Arduino Columns: Acceleration, Time, Date, X-coordinates, Y-Coordinates,

Plate Number

other timestamp in the time column, wherein it is acquired from the database’s server; the

plate column, which contains the plate numbers or any identification of the client module;

the coorX and coorY columns , which contains the x-coordinates and y-coordinates

gathered from the GPS shield of the client module.

3.4.1 Receipt, Parsing and Writing of Data into the Database

Figure 3.10 Process Flow Chart of ‘receive.php’ Page Scripts and Codes

After the database and its important columns have been set, several samples of

data were inserted into the table via url method. This was done by coding and uploading a

‘receive.php’ page into the website’s server. The ‘receive.php’ page containing a PHP

script utilizes the ‘mysql_connect()function’ – a PHP function that establishes a

connection with the database and the page. Another script is coded into the page – the

PHP Get Method script which strips out the data transmitted by the client module URL

and logs it into the database. In summary, the ‘receive.php’ page executes the first three

blocks of the Server Module’s program flow.

23

Load/Access 'receive.php' page

Load all PHP Scripts within the page

Fetch the data entered via the URL

Establish connection into the 'a6705968_oink' database

Establish connection with 'a670968_oink' database's

'arduino table'

Log the fetched data into the 'arduino'

table

Return an "OK" message to confirm the logging of data

3.4.2 Display of Data into Webpage

Figure 3.11 Process Flow Chart of ‘default.php’ Page Scripts and Codes

Subsequently, another php page named ‘default.php’ was created to display the

data acquired from the ‘arduino’ table of the ‘ac670968_oink’ database. The

‘default.php’ page serves as the home page and links all other pages within the website.

There are two major scripts coded in the ‘default.php’ page – the Google Maps java script

and the PHP script which establishes the connection to the database and displays the table

with all the values logged into the database.

The Google Maps java script employs the web mapping service application

provided by Google. The java script embeds the Google Map in the page and displays a

marker on an exact location, specified by the coordinates entered in the ‘arduino’ table.

The PHP script in the ‘default.php’ makes use of the ‘mysql_connect()’ function

to connect into the database, ‘mysql_query()’ function to fetch data from the database and

the ‘echo()’ syntax in displaying the data. A checkbox is utilized in order to display the

markers which serve as the indicators of the location of the accident. Checking the

checkbox prompts markers to appear in the embedded map. The table displayed in the

website is customized in a way that it displays the most recent data logged and each

accident is classified according to its severity. There are three severities of accident

24

Load or access the 'default.php' Page

Load all the Java Script, PHP Script and CSS

Load and run the Google Maps Javascript

Establish connection to the database

Display the data from the database into the

page

Run the pagination and autorefresh scripts

classified in the page – Light (for accidents with peak accelerations less than 3g),

Moderate (for accidents with peak accelerations greater than or equal to 3g but less than

8g) and Very Severe (for accidents with peak accelerations greater than or equal to 8g).

A pagination script was also embedded in the page – this was done to prevent the

overflow of table rows in the page. An auto refresh script was also included so that the

page is always updated in case new data is logged into the database. And in order to

improve the appearance and order of the website, it was customized with the use of

HTML tags and cascaded style sheets. The ‘details.php’ page was also coded and

uploaded so that the viewers can opt to see the specific details and larger scale of the map

if a specific accident is viewed. Another page named ‘acceleration.php’ is also coded and

added, and accessing this page gives the option to sort the accidents logged according to

its severity.

3.5 Software Support

Various open-source and free software were utilized in coding and managing the

programs for both the client and server modules.

Figure 3.12 cPanel and its Supported Features: Used in Managing the Website

25

Cpanel is one of the features included in 000webhost’s free hosting service – it is

a web hosting control panel that provides the user a graphical interface in managing the

process of hosting a website.

Figure 3.13 phpMyAdmin: Used in Managing the Database including Creating Tables,

Columns and Managing Stored Information

PhpMyAdmin is a free and open source-tool written in PHP and also

automatically installed in 000webhost’s websites. It provides convenience to users by

using the web browser instead of MySQL commands in managing the database.

26

Figure 3.14 Notepad ++: Used in Coding the PHP pages of the Website

Notepad ++ was used in editing the PHP pages because it is very convenient and

helpful in linking PHP functions and java scripts. It also supports tabbed editing – a

feature where you can edit multiple pages at once. It was also used in coding the style

sheet of the website.

27

Figure 3.15 Arduino Integrated Development Environment – Used in Coding the

Program for the MCU

Arduino IDE is the most commonly used application in coding Arduino programs.

It was used in compiling and uploading the programs to the microcontroller unit and also

in monitoring the serial ports of the microcontroller.

28

Figure 3.16 Filezilla FTP Client is used in uploading and downloading files from and to

the website

Filezilla was used as the file transfer protocol software because it is available in

the internet and can be downloaded for free.

3.6 Calibration of ADXL345

Accelerometers are mechanical structures which contain elements that move

freely and these elements can be sensitive to mechanical stress. The 0g bias or offset of

an accelerometer defines the baseline for measuring the acceleration. The offset error of

an accelerometer is constant value in g that cancels out the error caused by different

factors – environment, application, soldering and mounting.

29

Figure 3.17 Accelerometer Output Response vs. Orientation to Gravity [12]

Calibration was done by measuring two points per axis, +1g field and -1g field

and by calculating the AOFF using two points per axis [15]. Each axis was oriented into

+1g and – 1g field and their actual measured value were as follows when broken down

into an equation:

A+1g = AOFF + (1g × Gain) (Equation 3.1)

A−1g = AOFF – (1g × Gain) (Equation 3.2)

where:

AOFF is the offset error, in g.

A+1g is the actual measured value of the axis in g if it is oriented at +1g field.

A−1g is the actual measured value of the axis in g if it is oriented at -1g field.

After both values were obtained, AOFF and Gain were calculated using the

following equations:

AOFF = 0.5 × (A+1g + A−1g) (Equation 3.3)

Gain = 0.5 x (A+1g−A−1 g

1 g) (Equation 3.4)

Once the accelerometer’s offset error were obtained, the actual acceleration

became obtainable using the equation:

AACTUAL(x,y,z) = (AOUT−AOFF

Gain) (Equation 3.5)

30

where:

AACTUAL(x,y,z) is the actual acceleration acting on the accelerometer and the desired

value in g.

AOUT is the acceleration read by the accelerometer.

AOFF is the accelerometer’s offset error.

After calibration, the program for the microcontroller unit was modified so that

the acceleration information that is processed by the microcontroller for sensing and

sending is AACTUAL(x,y,z).

3.7 Testing

Since the device cannot be tested using an actual crash, another method in testing

was used. The device was mounted on a model car and was subjected to different crash

tests to record and analyze the performance of the device in terms of: failure in sending

through GPRS and/or SMS, time elapsed between sending and receiving, and errors in

time and position information received.

Figure 3.18 Device Prototype for Testing

The device was tested in seven different locations in Cebu namely, Paseo Arcenas

in Banawa, Shell Gas Station in Basak, Pardo, Jollibee North Reclamation, McDonald’s

Lapu-lapu, Yati, Liloan, Nice Day Car Wash in Escario, and Busay, Cebu. Certain

environmental factors and physical obstructions such as the existence of large

infrastructures surrounding the area were considered. The signal level and the type of

31

connection (EDGE/3G) of the service provider in the locations were checked using a

mobile phone of the same provider. The weather and atmospheric conditions and time of

testing were considered as well.

Figure 3.19 Prototype with its LED Indicators

At the instant the device is turned on, LED1 and LED2 automatically lights up,

indicating the initialization of the GPRS function of the GSM/GPRS module. LED3

lights up when the microcontroller starts reading and processing acceleration values from

the sensor. The car model where the device is installed was subjected to a force enough to

make LED4 light up. When LED4 lights up, signaling the detection of a crash by the

microcontroller, the device is expected to send through GPRS and SMS the information

of the crash: the location of the crash, the timestamp data, and the magnitude of

acceleration. LED5 and LED6 are expected to light up in sequence. Failure of LED5 to

light up indicates failure in sending of the GPRS data. Failure of LED6 to light up

indicates failure in sending of the SMS text message.

The information sent through GPRS will be received by the server and will be

displayed on the website. The information sent as text message through SMS will be

received by a mobile phone. The time of receipt of the data by the database and the text

message by the recipient mobile station were recorded.

Since Google Maps is the most popular choice among developers as web mapping

service for websites, Google Maps coordinates for the said locations were acquired and

compared to the position coordinates displayed on the website.

32

Chapter 4

Results and Discussions

This study aimed to provide an automatic advisory to the authorities and

concerned personnel if there is a vehicular collision. An in-vehicle device was

constructed to perform sensing, processing and communication functions. The device was

tested for performance based on different factors. This chapter presents the findings and

our analysis of the findings. Table of the important results are shown and observed trends

are discussed. The percentage error is calculated to determine the accuracy and reliability

of the device. The possible sources of error are explained.

4.1 Small-scale In-vehicle Sensor System

This study used the 3-axis digital accelerometer ADXL345 as sensor. To test the

basic function of the sensor, the static acceleration of gravity was measured and the

measurements were displayed to the Arduino serial monitor. The results are shown on

Figure 4.1.

(a) X-Axis Oriented into -1G and +1G Fields

33

(b) Y-Axis Oriented into -1G and +1G Field

(c) Z-Axis Oriented into -1G and +1G Fields

Figure 4.1 Acceleration of Gravity Measurements viewed on the Arduino Serial Monitor

Figure 4.1 shows that the measured value of the x-axis in units of G when

oriented at the -1G field is 0.43 and when oriented at the +G field is 0.52. The measured

value of the y-axis when oriented at the –G field is 0.41 and at the +G field is 0.5. The

measured value of the z-axis when oriented at the –G field is 0.51 and at the +G field is

0.48. Using Equations 3.3 and 3.4, the offset acceleration and gain were calculated for

each axis.

34

The accelerometer’s offset acceleration at the x-axis was computed to be 0.475G,

at the y-axis 0.455G, and at the z-axis 0.495G. The gain was computed to be 0.045 at the

x-axis, 0.045 at the y-axis, and 0.015 at the z-axis. By using Equation 3.5 and the

computed offset error and gain, the actual acceleration acting on the accelerometer can be

determined.

The code of the program for extracting accelerometer data was modified in such a

way that the computed offset error, gain and equation 3.5 was embedded to the program

and used in obtaining the actual resultant acceleration of the accelerometer. Figure 4.2

shows the reading of the different axes of the accelerometer after calibration.

(a) X-Axis Oriented into -1G and +1G Fields

(b) Y-Axis Oriented into -1G and +1G Fields

35

(c) Z-Axis Oriented into -1G and +1G Fields

Figure 4.2 Acceleration of Gravity Measurements viewed on the Arduino Serial Monitor

after Calibration

Table 4.1 Summary of Acceleration of Gravity Measurements before and after Calibration

Axis Before Calibration After Calibration+1G Field -1G Field +1G Field -1G Field

X-Axis 0.43 0.52 0.94 0.97Y-Axis 0.41 0.51 1.1 1.07Z-Axis 0.51 0.48 1.02 1.06

As seen on Table 1.1, the values of acceleration of each axis are now closer to its

ideal acceleration, 1G and -1G when projected to +1G and -1G fields, respectively.

An ideal value of 1G in each axis could not be obtained due to external factors

which cannot be controlled, such as the testing environment and vibrations surrounding

the accelerometer – these factors are already out of the scope of the study.

To test the sensing function of the sensor, the model car where the device was

mounted was subjected to a crash test to record and plot the resultant acceleration with

respect to discrete time. An Arduino code was uploaded to the microcontroller that

measures the acceleration of the 3 axes and calculates the resultant acceleration every

approximately 150 milliseconds. Figure 4.3 shows the resultant acceleration

measurements in units of G as shown on the Arduino serial monitor. Figure 4.4 displays

the graph of acceleration versus time.

36

Figure 4.3 Dynamic Resultant Acceleration Values viewed on the Arduino Serial Monitor

0 500 1000 1500 2000 2500 3000 35000

0.20.40.60.8

11.21.41.61.8

0

0.470.470.470.470.480.560.55

1.65

0.130.26

0.390000000000001

0.480.490.450.460.470.470.470.470.47

Graph of Resultant Acceleration vs Time

Time (in mS)

Res

ulta

nt A

ccel

erat

ion

(in

G)

Figure 4.4 Graph of Dynamic Resultant Acceleration (G) with respect to Time (150ms)

37

Figure 4.3 and 4.4 shows that there is a sudden spike in the resultant acceleration

from the accelerometer measured values. This indicates the sudden impact or deceleration

(+/- signs are ignored by the Arduino code) experienced by the model car. The sensor

was able to measure a constant acceleration of 0.47G prior to and after the impact. The

peak acceleration due to the sudden collision was measured to be 1.65G.

4.2 Communication Device using GPS and GSM/GPRS module

A code was uploaded to the microcontroller to extract location and time

information from the GPS module. The Arduino serial monitor was used to view the

GPGGA sentence outputted by the GPS module, and the latitude and longitude and time

information extracted from the GPGGA sentence.

Figure 4.5 GPS Information viewed on the Arduino Serial Monitor

38

Figure 4.5 shows that the GPGGA sentence contained the UTC time 061800.000

in the format hhmmss.sss, the latitude 1021.3075 in the format ddmm.mmmm, the N/S

indicator N, the longitude 12354.8291 in the format dddmm.mmmm, and the E/W

indicator E. The Arduino code was able to process the information so as to obtain the

location coordinates 10.3551N 123.9138E and the local time in 24-hour format 14:18:00

from the GPS module. The geographic coordinates of the actual location of the device

was obtained from Google Maps. This resulted to the actual location having the

coordinates 10.35507N 123.914073E.

The location information obtained from the GPS module and the actual location

were plotted on Google Maps (using green markers) as shown on Figure 4.6. The

distance between the coordinates obtained from the GPS module and the actual

coordinates was calculated to be 30.05 meters. The time information obtained from the

GPS module, however were exactly the same as that of the computer time synchronized

with ‘time.windows.com’.

Figure 4.6 GPS Location Information and Actual Testing Location plotted on Google

Maps

39

The GSM/GPRS module function of sending information from the Client Module

through SMS and GPRS was tested by uploading a code to the microcontroller that sends

pre-defined acceleration, longitude, latitude, and time values. Figure 4.6 shows the

communication between the microcontroller and the GSM/GPRS module using AT

commands. Also shown are the pre-defined values for acceleration, longitude, latitude,

and time.

Figure 4.7 Communication between Gizduino+ and GSM/GPRS Module viewed on the

Arduino Serial Monitor

40

As shown on Figure 4.7, the GSM/GPRS module replied OK to the series of AT

commands sent by the microcontroller. The AT+CIPSEND command sends the data to

the TCP connection and was given the reply SEND OK indicating that the data was sent

successfully. The AT+CMGS command sends the SMS message and was given the reply

OK indicating that the text message was sent successfully.

A mobile number was set in the Arduino code, directing to the mobile phone to

which the text message will be sent. Figure 4.8 displays the mobile phone’s screen

containing the text message received from the GSM/GPRS module.

Figure 4.8 Text Message Received by Mobile Phone

Figure 4.8 shows that the mobile phone received the acceleration value 3G,

longitude 123.5555E, latitude 10.1010N, and UTC time 091521. This is the exact same

information pre-defined and sent by the Client Module (see Figure 4.7).

4.3 Receipt and Storage of Data into the Database

To verify whether the transmitted data by the Client Module is the same as the

received and stored data into the database, these values were pre-defined and sent from

the Client Module (see Figure 4.7):

Acceleration: 3G

Longitude: 123.5555E

Latitude: 10.1010N

Time (in UTC): 091521

41

The information sent by the microcontroller was received by the server through a

PHP page entitled ‘receive.php’. This page acquires data from the microcontroller with

the use of PHP functions. Some of the PHP functions employed are the exclusion of letter

characters to be logged in the ‘acceleration’ field of the database; it was already assumed

that all information logged in this field is in the unit of G and the conversion of the GMT

time to GMT+8 time; all logged information in the ‘time2’ field is already in GMT+8

settings. The expected information logged into the database is seen below while the

actual information logged in the database is seen on Figure 4.9.

Acceleration: 3

Longitude: 123.5555E

Latitude: 10.1010N

Time (in GMT+8): 171521

Figure 4.9 Information Logged into the Database

The same information sent by the microcontroller as viewed in the serial monitor

is logged into the database. The ‘Date’ field of the database is a timestamp of the

information logged – it specifies the date and time the information was logged. It is

extracted from the timestamp of the server and is at GMT-5 time zone.

4.4 Display of Information from Database to Website

The information logged into the database was displayed on the website –

http://sirena1234.vacau.com. The information was displayed through ‘default.php’ page

and ‘details.php’. To verify whether the same information logged on the database is also

the same information displayed on the website, Figures 4.10 and 4.11 are compared.

42

Figure 4.10 Information Displayed in the ‘default.php’ Page of the Website

Figure 4.11 Information Displayed in the ‘details.php’ Page of the Website

The information logged in the database as seen on Figure 4.7 is the same as the

data displayed on the ‘default.php’ (see Figure 4.10) and ‘details.php’ (see Figure 4.11)

page of the website. The time of collision was also set in a 24-hour format and the

logging date & time of the information was already set to GMT+8 time zones.

43

4.5 Testing

The device was subjected to 10 trials each of crash tests in 7 different locations

around Metro Cebu. The information sent through GPRS was displayed on the

http://sirena1234.vacau.com website. The information sent as text message through SMS

were received by the mobile phone of one of the researchers.

Tables 4.2, 4.3, 4.4, 4.5 and 4.6 show the crash test information displayed on the

website and received by the mobile phone at Paseo Arcenas, Banawa, Cebu City. On 9

out of the 10 trials (90%), the device was able to send the GPRS data successfully. On 10

out of the 10 trials (100%), the device was able to send the SMS text message

successfully. Out of the 9 data successfully sent, none (0%) included erroneous

information. Out of the 10 text messages successfully sent, none (0%) included erroneous

information.

Table 4.2 shows the information which includes the plate number, the magnitude

of acceleration, and the acquired and exact coordinates of the location of testing. The

acceleration values varied from 0.418g to 0.624g. These acceleration values are above the

set threshold of 0.4g. In each of the ten trials, the location error, which is the distance

between the received coordinates and the exact coordinates of testing, is 4.382 meters.

Table 4.3 shows the average location error which is equal to 4.382 meters.

Table 4.4 shows the timestamp in every trial. The data presented include the time

of collision, the time the data was logged on the database, the data time delay, the time

the SMS was received, and the SMS time delay. The data from Trial No. 4 was not

successfully logged onto the website however, the SMS was successfully sent. The SMS

time delay, which is the interval between the time of collision and the time the SMS was

received on the mobile phone, ranges from 0:00:15 to 0:00:46. The data time delay which

is the interval between the time of collision and the time the data was logged on the

database ranges from 0:00:06 to 0:00:37.

44

Table 4.5 shows the average data time delay which is equal to 0:00:19. The data

used in computing for the average only includes nine trials since no data was acquired

from Trial No. 4.

Table 4.6 shows the SMS time delay which is equal to 0:00:26.

45

Table 4.2 Accelerometer and GPS Information (Latitude and Longitude) at Paseo Arcenas, Banawa, Cebu City

Trial No. Plate Number AccelerationReceived Coordinates Exact Coordinates of Testing

Location Location Error (in m)Latitude Longitude Latitude Longitude

1 TDB-916 0.488g 10.3095N 123.8751E

10.309491N 123.875061E 4.382

2 TDB-916 0.481g 10.3095N 123.8751E

10.309491N 123.875061E 4.382

3 TDB-916 0.418g 10.3095N 123.8751E

10.309491N 123.875061E 4.382

4 TDB-916 0.485g 10.3095N 123.8751E

10.309491N 123.875061E 4.382

5 TDB-916 0.474g 10.3095N 123.8751E

10.309491N 123.875061E 4.382

6 TDB-916 0.624g 10.3095N 123.8751E

10.309491N 123.875061E 4.382

7 TDB-916 0.488g 10.3095N 123.8751E

10.309491N 123.875061E 4.382

8 TDB-916 0.488g 10.3095N 123.8751E

10.309491N 123.875061E 4.382

9 TDB-916 0.474g 10.3095N 123.8751E

10.309491N 123.875061E 4.382

10 TDB-916 0.521g 10.3095N 123.8751E

10.309491N 123.875061E 4.382

46

Table 4.3 Error of Location Information Acquired at Paseo Arcenas, Banawa, Cebu City.

Trial No. Location Error (in m)

1 4.3822 4.3823 4.3824 4.3825 4.3826 4.3827 4.3828 4.3829 4.38210 4.382

Average Location Error (in m) 4.382

47

Table 4.4 Time Information Acquired at Paseo Arcenas, Banawa, Cebu City

Trial No. Received Time of Collision

Time of SMS Received

SMS Time Delay Time Logged on Website Data Time Delay

1 11:18:10 PM 11:18:27 PM 0:00:17 11:18:21 PM 0:00:112 11:21:00 PM 11:21:15 PM 0:00:15 11:21:12 PM 0:00:123 11:23:07 PM 11:23:23 PM 0:00:16 11:23:13 PM 0:00:064 11:24:43 PM 11:25:00 PM 0:00:17 NOT LOGGED NOT LOGGED5 11:26:19 PM 11:27:05 PM 0:00:46 11:26:54 PM 0:00:356 11:28:23 PM 11:28:54 PM 0:00:31 11:29:00 PM 0:00:377 11:31:41 PM 11:32:04 PM 0:00:26 11:31:58 PM 0:00:178 11:33:33 PM 11:34:00 PM 0:00:27 11:33:50 PM 0:00:179 11:35:15 PM 11:35:50 PM 0:00:35 11:35:30 PM 0:00:1510 11:38:00 PM 11:38:27 PM 0:00:27 11:38:17 PM 0:00:17

48

Table 4.5 Time Delay of Information Sending through GPRS at Paseo Arcenas, Banawa, Cebu City.

Trial No. Data Time Delay

1 0:00:112 0:00:123 0:00:065 0:00:356 0:00:377 0:00:178 0:00:179 0:00:1510 0:00:17

Average Data Time Delay 0:00:19

Table 4.6 Time Delay of Information Sending through SMS at Paseo Arcenas, Banawa, Cebu City.

Trial No. SMS Time Delay

1 0:00:172 0:00:153 0:00:164 0:00:175 0:00:466 0:00:317 0:00:268 0:00:279 0:00:3510 0:00:27

Average SMS Time Delay 0:00:26

49

Tables 4.7, 4.8, 4.9, 4.10 and 4.11 show the crash test information displayed on the

website and received by the mobile phone at Shell Station - Basak, Pardo, Cebu City. On 9 out of

the 10 trials (90%), the device was able to send the GPRS data successfully. On 10 out of the 10

trials (100%), the device was able to send the SMS text message successfully. Out of the 9 data

successfully sent, 1 (10%) included erroneous information. Out of the 10 text messages

successfully sent, 2 (20%) included erroneous information.

Table 4.7 shows the acceleration values which varied from 0.471g to1.1195g. Two trials,

Trial Nos. 1 and 6, returned error in coordinates. In each of the other eight trials, the location

error, which is the distance between the received coordinates and the exact coordinates of testing,

is 2.478 meters.

Table 4.8 shows the average location error which is equal to 2.478 meters.

Table 4.9 shows the timestamp data in every trial. The data from Trial No. 1 was not

successfully logged onto the website however, the SMS was successfully sent. The data time

delay ranges from 0:00:05 to 0:01:42. The SMS time delay ranges from 0:00:14 to 0:01:55.

Table 4.10 shows the average data time delay which is equal to 0:00:54. The data used in

computing for the average only includes nine trials since no data was acquired from Trial No. 1.

Table 4.11 shows the SMS time delay which is equal to 0:00:59.

50

Table 4.7 Accelerometer and GPS Information (Latitude and Longitude) at Shell Station – Basak, Pardo

Trial No.Plate

Number Acceleration

Received Coordinates Exact Coordinates of Testing Location Location Error (in m)

Latitude Longitude Latitude Longitude1 TDB-916 0.5g 6.8833G 123.0000A 10.28802N 123.86381N ERROR2 TDB-916 0.544g 10.2880N 123.8638E 10.28802N 123.86381N 2.4783 TDB-916 0.475g 10.2880N 123.8638E 10.28802N 123.86381N 2.4784 TDB-916 0.503g 10.2880N 123.8638E 10.28802N 123.86381N 2.4785 TDB-916 0.550g 10.2880N 123.8638E 10.28802N 123.86381N 2.4786 TDB-916 0.581g 215.8663 25.5 10.28802N 123.86381N ERROR7 TDB-916 1.1195g 10.2880N 123.8638E 10.28802N 123.86381N 2.4788 TDB-916 0.471 10.2880N 123.8638E 10.28802N 123.86381N 2.4789 TDB-916 0.544 10.2880N 123.8638E 10.28802N 123.86381N 2.47810 TDB-916 0.521 10.2880N 123.8638E 10.28802N 123.86381N 2.478

51

Table 4.8 Error of Location Information Acquired at Shell Station – Basak, Pardo

Trial No. Location Error (in m)

2 2.4783 2.4784 2.4785 2.4787 2.4788 2.4789 2.47810 2.478

Average Location Error (in m) 2.478

52

Table 4.9 Time Information Acquired at Shell Station – Basak, Pardo

Trial No. Received Time Info

Time of SMS Received

SMS Time Delay Time Logged on Website

Data Time Delay

1 12:59:22 AM 1:00:00 AM 0:00:38 NOT LOGGED NOT LOGGED2 1:02:05 AM 1:04:00 AM 0:01:55 1:03:47 AM 0:01:423 1:05:07 AM 1:05:21 AM 0:00:14 1:05:12 AM 0:00:054 1:06:41 AM 1:08:02 AM 0:01:21 1:07:48 AM 0:01:075 1:13:11 AM 1:14:02 AM 0:00:51 1:13:44 AM 0:00:336 1:15:05 AM 1:16:03 AM 0:00:58 1:16:00 AM 0:00:557 1:15:55 AM 1:17:34 AM 0:01:39 1:17:15 AM 0:01:208 1:18:00 AM 1:19:02 AM 0:01:02 1:18:58 AM 0:00:589 1:20:04 AM 1:21:03 AM 0:00:59 1:21:00 AM 0:00:5610 1:21:10 AM 1:21:40 AM 0:00:30 1:21:22 AM 0:00:12

53

Table 4.10 Time Delay of Information Sending through GPRS at Shell Station – Basak, Pardo.

Table 4.11 Time Delay of Information Sending through SMS at Shell Station – Basak, Pardo.

Trial No. Data Time Delay

2 0:01:423 0:00:054 0:01:075 0:00:336 0:00:557 0:01:208 0:00:58

9 0:00:5610 0:00:30

Average Data Time Delay 0:0:54

54

Trial No. SMS Time Delay

1 0:00:382 0:01:553 0:00:144 0:01:215 0:00:516 0:00:587 0:01:398 0:01:029 0:00:5910 0:00:12

Average SMS Time Delay 0:00:59

Tables 4.12, 4.13, 4.14, 4.15 and 4.16 show the crash test information displayed

on the website and received by the mobile phone at Jollibee North Reclamation, Mandaue

City. On 10 out of the 10 trials (100%), the device was able to send the GPRS data

successfully. On 10 out of the 10 trials (100%), the device was able to send the SMS text

message successfully. Out of the 10 data successfully sent, none (0%) included erroneous

information. Out of the 10 text messages successfully sent, none (0%) included erroneous

information.

Table 4.12 shows the acceleration values which varied from 0.47g to1.888g. In

each of the ten trials, the location error, which is the distance between the received

coordinates and the exact coordinates of testing, is 3.56 meters.

Table 4.13 shows the average location error which is equal to 3.56 meters.

Table 4.14 shows the timestamp data in every trial. The data time delay ranges

from 0:00:03 to 0:00:36. The SMS time delay ranges from 0:00:05 to 0:00:58.

Table 4.15 shows the average data time delay which is equal to 0:00:19.

Table 4.16 shows the SMS time delay which is equal to 0:01:07.

55

Table 4.12 Accelerometer and GPS Information (Latitude and Longitude) at Jollibee North Reclamation Area

Trial No.Plate

Number AccelerationReceived Coordinates Exact Coordinates of Testing

Location Location Error(in m)Latitude Longitude Latitude Longitude

1 TDB-916 1.443g 10.3168N 123.9292E 10.316768N 123.929201E 3.562 TDB-916 0.473g 10.3168N 123.9292E 10.316768N 123.929201E 3.563 TDB-916 0.47g 10.3168N 123.9292E 10.316768N 123.929201E 3.564 TDB-916 0.474g 10.3168N 123.9292E 10.316768N 123.929201E 3.565 TDB-916 1.888g 10.3168N 123.9292E 10.316768N 123.929201E 3.566 TDB-916 0.515g 10.3168N 123.9292E 10.316768N 123.929201E 3.567 TDB-916 0.512g 10.3168N 123.9292E 10.316768N 123.929201E 3.568 TDB-916 0.511g 10.3168N 123.9292E 10.316768N 123.929201E 3.569 TDB-916 0.515g 10.3168N 123.9292E 10.316768N 123.929201E 3.5610 TDB-916 0.515g 10.3168N 123.9292E 10.316768N 123.929201E 3.56

56

Table 4.13 Error of Location Data Acquired at Jollibee North Reclamation Area

Trial No. Location Error(in m)

1 3.562 3.563 3.564 3.565 3.566 3.567 3.568 3.569 3.5610 3.56

Average Location Error (in m) 3.56

57

Table 4.14 Time Information Acquired at Jollibee North Reclamation Area

Trial No. Received Time Info

Time Logged on Website

Data Time Delay

Time of SMS Received SMS Time Delay

1 1:39:44 AM 1:40:20 AM 0:00:36 1:40:36 AM 0:00:522 1:42:15 AM 1:42:45 AM 0:00:30 1:43:06 AM 0:00:513 1:44:37 AM 1:44:40 AM 0:00:03 1:44:42 AM 0:00:054 1:48:46 AM 1:49:03 AM 0:00:17 1:49:30 AM 0:00:445 1:50:47 AM 1:51:03 AM 0:00:16 1:51:09 AM 0:00:226 1:51:43 AM 1:52:04 AM 0:00:21 1:52:10 AM 0:00:277 1:53:10 AM 1:53:28 AM 0:00:18 1:58:38 AM 0:05:288 1:55:13 AM 1:55:31 AM 0:00:18 1:56:00 AM 0:00:479 1:57:09 AM 1:57:27 AM 0:00:18 1:57:49 AM 0:00:4010 1:58:02 AM 1:58:15 AM 0:00:13 1:59:00 AM 0:00:58

58

Table 4.15 Time Delay of Information Sending through GPRS at Jollibee North Reclamation Area

Trial No. Data Time Delay

1 0:00:362 0:00:303 0:00:034 0:00:175 0:00:166 0:00:217 0:00:188 0:00:189 0:00:1810 0:00:13

Average Data Time Delay 0:00:19

Table 4.16 Time Delay of Information Sending through SMS at Jollibee North Reclamation Area

Trial No. SMS Time Delay

1 0:00:522 0:00:513 0:00:054 0:00:445 0:00:226 0:00:277 0:05:288 0:00:479 0:00:4010 0:00:58

Average SMS Time Delay 0:01:07

59

Tables 4.17, 4.18, 4.19, 4.20 and 4.21 show the crash test information displayed

on the website and received by the mobile phone at McDonald’s Lapu-lapu. On 10 out of

the 10 trials (100%), the device was able to send the GPRS data successfully. On 10 out

of the 10 trials (100%), the device was able to send the SMS text message successfully.

Out of the 10 data successfully sent, 1 (10%) included erroneous information. Out of the

10 text messages successfully sent, 1 (10%) included erroneous information.

Table 4.17 shows the acceleration values which were equal to 0.581g. Trial No. 1,

returned error in coordinates. In each of the other eight trials, the location error, which is

the distance between the received coordinates and the exact coordinates of testing, is

61.05 meters and the error in the other one trial is 139.1 meters.

Table 4.18 shows the average location error which is equal to 69.722 meters.

Table 4.19 shows the timestamp data in every trial. The data time delay ranges

from 0:00:02 to 0:00:30. The SMS time delay ranges from 0:00:05 to 0:01:24.

Table 4.20 shows the average data time delay which is equal to 0:00:18.

Table 4.21 shows the SMS time delay which is equal to 0:00:36.

60

Table 4.17 Accelerometer and GPS Information (Latitude and Longitude) at McDonald’s Lapu – Lapu

Trial No.Plate

Number Acceleration

Received Coordinates Exact Coordinates of Testing Location Location Error (in m)

Latitude Longitude Latitude Longitude1 TDB-916 0.581g 0.00001N 123.9612E 10.316889N 123.96201E ERROR2 TDB-916 0.581g 10.3175N 123.9609E 10.316889N 123.96201E 139.13 TDB-916 0.581g 10.3173N 123.96238E 10.316889N 123.96201E 61.054 TDB-916 0.581g 10.3173N 123.96238E 10.316889N 123.96201E 61.055 TDB-916 0.581g 10.3173N 123.96238E 10.316889N 123.96201E 61.056 TDB-916 0.581g 10.3173N 123.96238E 10.316889N 123.96201E 61.057 TDB-916 0.581g 10.3173N 123.96238E 10.316889N 123.96201E 61.058 TDB-916 0.581g 10.3173N 123.96238E 10.316889N 123.96201E 61.059 TDB-916 0.581g 10.3173N 123.96238E 10.316889N 123.96201E 61.0510 TDB-916 0.581g 10.3173N 123.96238E 10.316889N 123.96201E 61.05

61

Table 4.18 Error of Location Information Acquired at McDonald’s Lapu – Lapu

Trial No. Location Error (in m)

2 139.13 61.054 61.055 61.056 61.057 61.058 61.059 61.0510 61.05

Average Location Error (in m) 69.722

62

Table 4.19 Time Information Acquired at McDonald’s Lapu – Lapu

Trial No. Received Time Info

Time Logged on Website

Data Time Delay

Time of SMS Received SMS Time Delay

1 1:13:54 AM 1:13:56 AM 0:00:02 1:13:59 AM 0:00:052 1:15:12 AM 1:15:42 AM 0:00:30 1:16:36 AM 0:01:243 1:20:28 AM 1:20:55 AM 0:00:27 1:21:00 AM 0:00:324 1:22:28 AM 1:22:53 AM 0:00:25 1:23:02 AM 0:00:345 1:23:59 AM 1:24:19 AM 0:00:20 1:24:37 AM 0:00:386 1:25:00 AM 1:25:18 AM 0:00:18 1:25:36 AM 0:00:367 1:27:00 AM 1:27:13 AM 0:00:13 1:27:36 AM 0:00:368 1:28:34 AM 1:28:51 AM 0:00:17 1:29:00 AM 0:00:269 1:30:12 AM 1:30:30 AM 0:00:18 1:30:53 AM 0:00:4110 1:31:44 AM 1:31:57 AM 0:00:13 1:32:08 AM 0:00:24

63

Table 4.20 Time Delay of Information Sending through GPRS at McDonald’s Lapu – Lapu

Trial No. Data Time Delay

1 0:00:022 0:00:303 0:00:274 0:00:255 0:00:206 0:00:187 0:00:138 0:00:179 0:00:1810 0:00:13

Average Data Time Delay 0:00:18

Table 4.21 Time Delay of Information Sending through SMS at McDonald’s Lapu – Lapu

64

Trial No. SMS Time Delay

1 0:00:052 0:01:243 0:00:324 0:00:345 0:00:386 0:00:367 0:00:368 0:00:269 0:00:4110 0:00:24

Average SMS Time Delay 0:00:36

65

Tables 4.22, 4.23, 4.24, 4.25 and 4.26 show the crash test information displayed on the website and received by the mobile phone at Yati, Liloan, Cebu. On 10 out of the 10 trials (100%), the device was able to send the GPRS data successfully. On 10 out of the 10 trials (100%), the device was able to send the SMS text message successfully. Out of the 10 data successfully sent, 1 (10%) included erroneous information. Out of the 10 text messages successfully sent, 1 (10%) included erroneous information.

Table 4.22 shows the acceleration values which varied from 0.472g to 0.488g. Trial No. 2 returned error in coordinates. In each of the other nine trials, the location error, which is the distance between the received coordinates and the exact coordinates of testing, is 3.68 meters.

Table 4.23 shows the average location error which is equal to 3.68 meters.

Table 4.24 shows the timestamp data in every trial. The data time delay ranges from 0:00:02 to 0:00:31. The SMS time delay ranges from 0:00:05 to 0:01:20.

Table 4.25 shows the average data time delay which is equal to 0:00:21.

Table 4.26 shows the SMS time delay which is equal to 0:00:46.

66

Table 4.22 Accelerometer and GPS Information (Latitude and Longitude) at Yati, Liloan

Trial No.Plate

Number AccelerationReceived Coordinates Exact Coordinates of Testing

Location Location Error (in m)Latitude Longitude Latitude Longitude

1 TDB-916 0.472g 10.3895N 123.9807E 10.389479N 123.980726E 3.682 TDB-916 0.488g 10.3895N 123.0003E 10.389479N 123.980726E ERROR3 TDB-916 0.488g 10.3895N 123.9807E 10.389479N 123.980726E 3.684 TDB-916 0.488g 10.3895N 123.9807E 10.389479N 123.980726E 3.685 TDB-916 0.486g 10.3895N 123.9807E 10.389479N 123.980726E 3.686 TDB-916 0.478g 10.3895N 123.9807E 10.389479N 123.980726E 3.687 TDB-916 0.488g 10.3895N 123.9807E 10.389479N 123.980726E 3.688 TDB-916 0.488g 10.3895N 123.9807E 10.389479N 123.980726E 3.689 TDB-916 0.488g 10.3895N 123.9807E 10.389479N 123.980726E 3.6810 TDB-916 0.488g 10.3895N 123.9807E 10.389479N 123.980726E 3.68

67

Table 4.23 Error of Location Data Acquired at Yati, Liloan

Trial No. Location Error (in m)

1 3.683 3.684 3.685 3.686 3.687 3.688 3.689 3.6810 3.68

Average Location Error (in m) 3.68

68

Table 4.24 Time Information Acquired at Yati, Liloan

Trial No. Received Time Info

Time Logged on Website

Data Time Delay

Time of SMS Received SMS Time Delay

1 2:49:44 AM 2:49:54 AM 0:00:10 2:50:00 AM 0:00:162 3:00:28 AM 3:00:30 AM 0:00:02 3:00:33 AM 0:00:053 3:02:40 AM 3:02:58 AM 0:00:18 3:03:30 AM 0:00:504 3:04:15 AM 3:04:45 AM 0:00:30 3:05:00 AM 0:00:455 3:07:00 AM 3:07:22 AM 0:00:22 3:08:02 AM 0:01:026 3:08:40 AM 3:09:11 AM 0:00:31 3:10:00 AM 0:01:207 3:12:32 AM 3:13:01 AM 0:00:29 3:13:25 AM 0:00:538 3:15:14 AM 3:15:30 AM 0:00:16 3:15:56 AM 0:00:429 3:18:02 AM 3:18:21 AM 0:00:19 3:18:40 AM 0:00:3810 3:20:12 AM 3:20:43 AM 0:00:31 3:21:17 AM 0:01:05

69

Table 4.25 Time Delay of Information Sending through GPRS at Yati, Liloan

Table 4.26 Time Delay of Information Sending through SMS at Yati, Liloan

Trial No. Data Time Delay

1 0:00:102 0:00:023 0:00:184 0:00:305 0:00:226 0:00:317 0:00:298 0:00:169 0:00:1910 0:00:31

Average Data Time Delay 0:00:21

Trial No. SMS Time Delay

1 0:00:162 0:00:053 0:00:504 0:00:455 0:01:026 0:01:207 0:00:538 0:00:429 0:00:3810 0:01:05

Average SMS Time Delay 0:00:46

70

Tables 4.27, 4.28, 4.29, 4.30 and 4.31 show the crash test information displayed on the website and received by the mobile phone at Busay, Lahug, Cebu City. On 10 out of the 10 trials (100%), the device was able to send the GPRS data successfully. On 10 out of the 10 trials (100%), the device was able to send the SMS text message successfully. Out of the 10 data successfully sent, none (0%) included erroneous information. Out of the 10 text messages successfully sent, none (0%) included erroneous information.

Table 4.27 shows the acceleration values which varied from 0.47g to 0.89g. In six trials, the location error, which is the distance between the received coordinates and the exact coordinates of testing, is 2.846 meters. In the remaining four trials, the location error is 13.84 meters.

Table 4.28 shows the average location error which is equal to 7.2436 meters.

Table 4.29 shows the timestamp data in every trial. The data time delay ranges from 0:00:04 to 0:00:37. The SMS time delay ranges from 0:00:08 to 0:00:51.

Table 4.30 shows the average data time delay which is equal to 0:00:12.

Table 4.31 shows the SMS time delay which is equal to 0:00:24.

71

Table 4.27 Accelerometer and GPS iNFORMATION (Latitude and Longitude) at Busay, Top’s Entrance Lahug

Trial No.Plate

Number AccelerationReceived Coordinates Exact Coordinates of Testing

Location Location Error (in m)Latitude Longitude Latitude Longitude

1 TDB-916 0.47g 10.3792N 123.8736E 10.379201N 123.873626E 2.8462 TDB-916 0.474g 10.3792N 123.8736E 10.379201N 123.873626E 2.8463 TDB-916 0.473g 10.3792N 123.8736E 10.379201N 123.873626E 2.8464 TDB-916 0.476g 10.3792N 123.8736E 10.379201N 123.873626E 2.8465 TDB-916 0.471g 10.3792N 123.8736E 10.379201N 123.873626E 2.8466 TDB-916 0.473g 10.3792N 123.8736E 10.379201N 123.873626E 2.8467 TDB-916 0.489g 10.3791N 121.8737E 10.379201N 123.873626E 13.848 TDB-916 0.489g 10.3791N 121.8737E 10.379201N 123.873626E 13.849 TDB-916 0.48g 10.3791N 123.8737E 10.379201N 123.873626E 13.8410 TDB-916 0.491g 10.3791N 123.8737E 10.379201N 123.873626E 13.84

72

Table 4.28 Error of Location Information Acquired at Busay, Top’s Entrance Lahug.

Trial No. Location Error (in m)

1 2.8462 2.8463 2.8464 2.8465 2.8466 2.8467 13.848 13.849 13.8410 13.84

Average Location Error (in m) 7.2436

73

Table 4.29 Time Information Acquired at Busay, Top’s Entrance Lahug

Trial No. Received Time Info

Time Logged on Website

Data Time Delay

Time of SMS Received SMS Time Delay

1 6:28:16 PM 6:28:21 PM 0:00:05 6:28:49 PM 0:00:332 6:30:39 PM 6:30:43 PM 0:00:04 6:30:47 PM 0:00:083 6:31:40 PM 6:31:45 PM 0:00:05 6:31:59 PM 0:00:194 6:32:29 PM 6:32:34 PM 0:00:05 6:32:54 PM 0:00:255 6:33:18 PM 6:33:24 PM 0:00:06 6:33:30 PM 0:00:126 6:38:41 PM 6:39:02 PM 0:00:21 6:39:10 PM 0:00:297 6:46:00 PM 6:46:37 PM 0:00:37 6:46:51 PM 0:00:518 6:48:00 PM 6:48:25 PM 0:00:25 6:48:41 PM 0:00:419 7:02:19 PM 7:02:23 PM 0:00:04 7:02:27 PM 0:00:0810 7:06:10 PM 7:06:16 PM 0:00:06 7:06:21 PM 0:00:11

74

Table 4.30 Time Delay of Information Sending through GPRS at Busay, Top’s Entrance Lahug

Trial No. Data Time Delay

1 0:00:052 0:00:043 0:00:054 0:00:055 0:00:066 0:00:217 0:00:378 0:00:259 0:00:0410 0:00:06

Average Data Time Delay

0:00:12

Table 4.31 Time Delay of Information Sending through GPRS at Busay, Top’s Entrance Lahug

Trial No. SMS Time Delay

1 0:00:332 0:00:083 0:00:194 0:00:255 0:00:126 0:00:297 0:00:518 0:00:419 0:00:0810 0:00:11

Average SMS Time Delay 0:00:24

75

Tables 4.32, 4.33, 4.34, 4.35 and 4.36 show the crash test information displayed on the website and received by the mobile phone at Nice Day Carwash - Escario, Cebu City. On 10 out of the 10 trials (100%), the device was able to send the GPRS data successfully. On 10 out of the 10 trials (100%), the device was able to send the SMS text message successfully. Out of the 10 data successfully sent, none (0%) included erroneous information. Out of the 10 text messages successfully sent, none (0%) included erroneous information.

Table 4.32 shows the acceleration values which varied from 0.442g to 0.478g. Trial No. 10 returned error in coordinates. In each of the other nine trials, the location error, which is the distance between the received coordinates and the exact coordinates of testing, is 2.083 meters.

Table 4.33 shows the average location error which is equal to 2.083 meters.

Table 4.34 shows the timestamp data in every trial. The data from Trial No. 10 was logged onto the website and received via SMS was erroneous. The data time delay ranges from 0:00:03 to 0:00:42. The SMS time delay ranges from 0:00:06 to 0:00:47.

Table 4.35 shows the average data time delay which is equal to 0:00:18. The data used in computing for the average only include nine trials since erroneous data was acquired from Trial No. 10.

Table 4.36 shows the SMS time delay which is equal to 0:00:32. The data used in computing for the average only include nine trials since erroneous data was acquired from Trial No. 10.

76

Table 4.32 Accelerometer and GPS Information (Latitude and Longitude) at Nice Day Carwash - Escario

Trial No.Plate

Number AccelerationReceived Coordinates Exact Coordinates of Testing

Location Location Error (in m)Latitude Longitude Latitude Longitude

1 TDB-916 0.466g 10.3181N 123.894E 10.318083N 123.894122E 2.0832 TDB-916 0.461g 10.3181N 123.894E 10.318083N 123.894122E 2.0833 TDB-916 0.475g 10.3181N 123.894E 10.318083N 123.894122E 2.0834 TDB-916 0.461g 10.3181N 123.894E 10.318083N 123.894122E 2.0835 TDB-916 0.442g 10.3181N 123.894E 10.318083N 123.894122E 2.0836 TDB-916 0.471g 10.3181N 123.894E 10.318083N 123.894122E 2.0837 TDB-916 0.461g 10.3181N 123.894E 10.318083N 123.894122E 2.0838 TDB-916 0.478g 10.3181N 123.894E 10.318083N 123.894122E 2.0839 TDB-916 0.477g 10.3181N 123.894E 10.318083N 123.894122E 2.08310 TDB-916 0.474g 89.7333N 19.0014E 10.318083N 123.894122E ERROR

77

Table 4.33 Location Error of Location Data Acquired at Nice Day Carwash - Escario

Trial No. Location Error (in m)

1 2.0832 2.0833 2.0834 2.0835 2.0836 2.0837 2.0838 2.0839 2.083

Average Location Error (in m) 2.083

78

Table 4.34 Time Information Acquired at Nice Day Carwash - Escario

Trial No. Received Time Info

Time Logged on Website

Data Time Delay Time of SMS Received

SMS Time Delay

1 7:24:43 PM 7:24:58 PM 0:00:15 7:25:30 PM 0:00:472 7:26:11 PM 7:26:35 PM 0:00:24 7:26:40 PM 0:00:293 7:28:12 PM 7:28:20 PM 0:00:08 7:28:39 PM 0:00:274 7:35:05 PM 7:35:47 PM 0:00:42 7:35:36 PM 0:00:315 7:36:11 PM 7:36:52 PM 0:00:41 7:36:54 PM 0:00:436 7:37:24 PM 7:37:39 PM 0:00:15 7:38:06 PM 0:00:427 7:39:12 PM 7:39:20 PM 0:00:08 7:39:56 PM 0:00:448 7:40:53 PM 7:40:59 PM 0:00:06 7:41:09 PM 0:00:169 7:42:25 PM 7:42:28 PM 0:00:03 7:42:31 PM 0:00:0610 8:11:47 AM 7:46:22 PM ERROR 7:48:31 PM ERROR

79

Table 4.35 Time Delay of Information Sending through GPRS at Nice Day Carwash – Escario

Trial No. Data Time Delay

1 0:00:152 0:00:243 0:00:084 0:00:425 0:00:416 0:00:157 0:00:088 0:00:069 0:00:03

Average Data Time Delay 0:00:18

Table 4.36 Time Delay of Information Sending through GPRS Acquired at Nice Day Carwash – Escario

Trial No. SMS Time Delay

1 0:00:472 0:00:293 0:00:274 0:00:315 0:00:436 0:00:427 0:00:448 0:00:169 0:00:06

Average SMS Time Delay 0:00:32

80

Table 4.37 Summary of the Performance of the System

Place GPRS Sent SMS Sent Erroneous GPRS Data

Erroneous SMS Data

Location Error Data Time Delay

SMS Time Delay

Banawa, Cebu City

90% 100% 0% 0% 4.382m 19sec 26sec

Basak, Cebu City

90% 100% 10% 20% 2.478m 54sec 59sec

North Reclamation

100% 100% 0% 0% 3.56m 19sec 1.07sec

Lapu-lapu City 100% 100% 10% 10% 69.722m 18sec 36sec

Yati, Liloan 100% 100% 10% 10% 3.68m 21sec 46sec

Busay, Lahug 100% 100% 0% 0% 7.2436m 12sec 24sec

Escario, Cebu City

100% 100% 0% 0% 2.083m 18sec 32sec

Table 4.37 shows the summary of the performance of the system in terms of failure in sending through GPRS and/or SMS, time elapsed between sending and receiving, errors in time and position information received, and errors in sending. Failures in GPRS sending occurred due to the limited connection of the device to the service provider. In Banawa and Basak, Cebu City, the mobile phone signal ranges from 3-5 out of 5 bars. The inconsistency of the strength of connection to the service from time to time opens the possibility of failure in sending via GPRS. However, the sending of data via SMS works properly in all of the trials made. Occurrence of erroneous GPRS and SMS data were also listed. There were few instances that the data gathered by the GPS module such as the coordinates of the location and the time stamp data are different from the ideal values. This may be caused by the physical obstructions surrounding the area like large infrastructures and the bad weather conditions during testing. The data and SMS time delays in the successful transmissions are considerably small.

81

Chapter 5

Summary, Conclusions and Recommendations

5.1 Summary

In this study, a system was designed which detects collision and has automatic

advisory and data management system for vehicular collisions. The accelerometer used in

the device was calibrated and tested to ensure the reliability of its sensing function. A

code was also uploaded to the microcontroller to extract location and time stamp

information from the GPS module and transmit this information using the GSM/GPRS

module. The system’s performance is analyzed in terms of failure in sending through

GPRS and/or SMS, time elapsed between sending and receiving, errors in time and

position information received, and errors in sending. The testing results showed that the

device is capable of executing processes to detect collision and sending the acquired

collision information to the database via GPRS and mobile phones via SMS at an

efficient time. However, certain conditions affect the device which caused it to return

erroneous data – conditions or factors which cannot be controlled and out of the scope of

the study. The limited access the service provider gives in specific areas caused the delay

in sending of the collision information. The physical environment and weather and

atmospheric conditions at a particular time also affected the accuracy of the GPS data.

5.2 Conclusions

A small-scale in-vehicle sensor system that detects collision was designed using

ADXL345 3-Axis Digital Accelerometer as the crash sensor and the ATmega644

GizDuino+ as the microcontroller. Although the system was not tested in an actual crash;

it detects acceleration values beyond the set threshold of the accelerometer and classifies

82

it as a “collision”. Using the GPS and GSM/GPRS modules mounted on the

microcontroller, the device acquires location of the collision and time stamp data and

sends it to the defined mobile phones as a text message and logs it into the database. The

delay, failure and success of transmission of text message varies accordingly to the GSM

signal obtained from a certain location while the delay, failure and success of

transmission of data to the database varies accordingly to the EDGE signal obtained from

that location. The erroneous data obtained from the GPS shield were due to factors which

are out of scope of the study – obstructions or infrastructures surrounding the prototype,

terrain of the location and the location’s satellite reception. The data logged and stored in

the database is then displayed on the webpage with the domain, sirena1234.vacau.com

with the use of PHP coded pages. The objectives stated in this thesis project were met.

5.3 Recommendations

After a thorough analysis of the data, the following recommendations have been

made:

The antenna of the GSM/GPRS module should be modified and improved to

acquire wider coverage and higher signal strength.

The GPS module should be replaced with one which produces a more accurate

and consistent coordinates to gather more reliable location and time information.

The power supply used for the client module should be specified to operate on a

daily basis and should be able to provide the needed power for a longer span of

time to the Client Module to prevent interruption in the system operation.

A back-up power supply for the Client Module in order to ensure the continuous

operation of the system.

Different network providers that provide service within the Philippines should be

tested and acquired data from the testing should be compared, in order to improve

the efficiency and delay of transmission of data and text message.

83

A new method of testing – one that is closer to actual crash testing should be

employed in triggering the extraction of data from accelerometer, and GPS

Shield.

A high-range accelerometer, specifically designed to detect impacts or crash

should be used as the sensor in the Client Module.

Crash sensors other than accelerometers such as pressure and vibration sensors

should also be incorporated to the system, for a better and sensitive crash sensing.

A casing specifically designed for the Client Module should be used, in order to

protect the modules and to ensure the fixation of the wired connections between

the microcontroller unit and its compatible shields.

A host with a server that operates on the GMT+8 time zone should be utilized, in

order to lessen the need of converting timestamps into its designated time zones

for the convenience of displaying it to the website users or viewers.

84

Bibliography

[1] DOH National Electronic Injury Surveillance System (NEISS) Factsheet Volume 3, Issue 3, December 2011.

[2] DOH National Electronic Injury Surveillance System (NEISS) Factsheet Volume 3, Issue 4, February 2012.

[3] DOH National Electronic Injury Surveillance System (NEISS) Factsheet Volume 4, Issue 1, May 2012.

[4] Feero S., Hedges JR., Simmons E., Irwin L., “Does out-of-hospital EMS time affect trauma survival?,” in The American Journal of Emergency Medicine: 133-135, 1995.

[5] Patrol 117 “failure”: DILG blames lack of budget for equipment maintenance. The Freeman, November 2009.

[6] ASEAN Region Road Safety Strategy and Action Plan, May 2006.

[7] R. Filjar, K. Vidovic, P. Britvic, M. Rimac, "eCall: Automatic Notification of a Road Traffic Accident," in MIPRO: 600-605, 2011.

[8] C. Pinart, J. C. Calvo, L. Nicholson, J. Villaverde, "Ecall-compliant early crash notification service for portable and nomadic devices," in Vehicular Technology Conference: 1-5, 2009.

[9] Goh, Ng, Jusoff, Chen, Tan, "Architecture of a GPS-Based Road Management System," in World Applied Sciences Journal: 26-31, 2011.

[10] White, Thompson, Turner, Dougherty, Schmidt, "WreckWatch: Automatic Traffic Accident Detection and Notification with Smartphones," in Mobile Networks and Applications - Volume 16 Issue 3: 285-303, 2011.

[11] A. Khan, R. Mishra, "GPS-GSM Based Tracking System," in International Journal of Engineering Trends and Technology - Vol. 31 Issue 2: 161-164, 2012.

[12] Analog Devices, “ADXL345: A 3-Axis, ±2 g/±4 g/±8 g/±16 g Digital Accelerometer,” 2011.

[13] ATMEL, “ATmega644/V: 8-bit Atmel Microcontroller with 64K Bytes In-System Programmable Flash,” 2012.

[14] SIMCOM, “SIM900D GSM/GPRS Module,” 2010.

[15] Analog Devices, “Using Accelerometer for Inclination Sensing,” 2010.

85

86