A Low-cost Intelligent Car Break-in Alert System

Using Smartphone Accelerometers for Detecting Vehicle Break-ins

Reinhold Behringer, Muthu Ramachandran and Victor Chang

School of Computing, Creative Technologies and Engineering, Faculty of Arts, Environment and Technology,

Leeds Beckett University, Leeds, LS6 3QS, U.K.

Keywords: Alert System, Smartphone, Car Alert, Status Detection, Remote Notification.

Abstract: Smartphones provide sensors and online data connectivity which makes them suitable for individual alert

systems. A prototype for a car break-in alert system has been developed which can detect activity through

smartphone accelerometers. The main goal of this system is to provide a low-cost alternative to expensive

embedded systems with similar functionality. It can be controlled remotely solely through text messages

from another mobile phone, which provides the option to use SMS instead of internet data access, in case of

high cost of internet data connection (international roaming charges). In case of a detected break-in the

system will send a text message to the user’s second phone. The user also can query information and request

the location of the vehicle. The prototype has been tested in various situations, and data have been collected

to distinguish different scenarios. The system has been programmed with MIT App Inventor and will be

made available for free on the Google Play Store.

1 INTRODUCTION

The rapid progress of smartphone technology often

leads to users purchasing a new phone, even if the

old phone is still working fine. A study by Entner

(2011) has shown that in several countries users

change their phone every two years on average. This

raises the question what to do with the old phone,

which may still be very capable for certain tasks,

while the new phone would be the user’s main

phone for regular use.

One possibility is to find use of the old phone for

a particular dedicated application, for example using

the phone in a road vehicle, with the purpose of

adding intelligent functionality to the car. In

particular, if the old smartphone has a reasonable

sensor suite (accelerometers, GPS), it can be used to

detect motion and disturbance in the car, indicating a

possible break-in into the vehicle by a burglar.

Furthermore, the smartphone location system can be

used to track and trace the vehicle when it is being

stolen, and this allows a rapid response to such an

incident. This opens the possiblilty for a very low-

cost system which brings machine intelligence into a

vehicle as a retro-fitted component: there is no

additional hardware cost, and the cost for the

software would be not more than for a typical

smartphone app.

In this paper the prototype of such a system is

described: Intelligent Car Break-In Alert System

(ICaBrAS) consists of an “obsolete” smartphone that

can be left in a vehicle and which can communicate

with the user’s main phone. The software for this in-

vehicle phone has facilities to detect break-ins into

the vehicle and removal of the vehicle from its

parked location. The main communication link to

the user is via text messaging, so no internet

connection is required. If a mobile internet

connection is available, it can be used for additional

services such as using map services for determining

location name.

Since Android is by far the most popular

operating system with a market share of 82% in

2015 Q2 (IDC, 2015), it was chosen for the

development of the ICaBrAS prototype. In order to

include a wide range of Android versions and to

simplify the development process, the MIT App

Inventor prototyping tool (MIT, 2015) was used.

This removed the hurdles of native Android

programming and did allow quick concept testing

without having to solve fundamental software

development problems related to system interface or

device/version compatibility.

The “old” spare smartphone with the ICaBrAs

Behringer, R., Ramachandran, M. and Chang, V.

A Low-cost Intelligent Car Break-in Alert System - Using Smartphone Accelerometers for Detecting Vehicle Break-ins.

DOI: 10.5220/0005914001790184

In Proceedings of the International Conference on Internet of Things and Big Data (IoTBD 2016), pages 179-184

ISBN: 978-989-758-183-0

179

sytem installed would need to be placed in the

vehicle at a hidden location, but still with reasonable

mobile and GPS satellite reception. The software for

this alert system monitors the acceleration sensors

and sends an alert message via SMS to the users

“new” phone. The user then can remotely query the

vehicle phone to obtain further information.

This provides a low-cost vehicle alert system

without any fixed installation, wiring or other

integration work at the vehicle itself. The prototype

is self-contained and does not need any mechanical

or electrical interface to the vehicle, except a

connection to a power source, which in most cases

would be the vehicle battery.

The alert system ICaBrAS will be made

available on the Google Play Store for individual

evaluation and testing.

2 RELATED WORK

2.1 Vehicle Alert Systems

There are numerous solutions for devices which set

off a car alerts. High-end vehicles often have

systems built-in which are directly linked with the

vehicle data management systems. One example of

such a system is the OnStar® system which can

report vehicle diagnostics data to a repair centre or a

mobile app (OnStar, 2015). There are subscription

costs associated with this service.

There are also after-market systems available

which can be retro-fitted into vehicles, for example

from Maplin the Nikkai EasyFit Car Alarm (Maplin,

2015). This device sounds an alarm (120 dB) as

soon as an electric consumer is switched on or a

mechanical shock is “felt” by the sensor. This kind

of alert is completely stand-alone and does not

provide any link to the user’s remote phone.

Recently there have been GPS trackers on the

market, with GSM functionality for control through

SMS messages. Most of these devices are embedded

GPS receivers which only rely on location

measurement to determine if the vehicle is being

moved. These devices cost from £50-£120. There

are, however, newer devices made in China for

specifically addressing vehicle alerts, based on GPS

and accelerometers. These devices are also linked to

GSM with a SIM card and provide a functionality

that is similar to ICaBrAS. They are, however not

further configurable and lack the possibilities which

a smartphone offers, for example automated call-

back or customised audio responses. These devices

are, however, very inexpensive at £21 (TomTop

2016).

2.2 Sensing Acceleration

The use of inexpensive smartphone sensors for in-

vehicle application has been explored already since

several years. Johnson and Trivedi (2011) have used

accelerometers to determine the driving style. In

general, such low-cost sensors are suitable for a

wide variety of activity recognition applications, as

shown by Saedi and El-Sheimy (2015).

Smartphone accelerometers have also been used

in differentiating the transport medium in which the

user is travelling (Bedogni, 2012), based on the

characteristics of the acceleration data. Also, the

sensors could detect a vehicle collision (Thompson

et al., 2010).

The novelty in our current time in the year 2016

is that such a system can now be run on a low-cost

“spare” smartphone. In this paper, there is also a

new way of processing the smartphone data and

detecting the specific characteristics by not

examining the raw acceleration data, but by using

the change of acceleration and acceleration

oscillations (noise) to determine the kind of event

that is being detected and classified.

3 SYSTEM ARCHITECTURE

The architecture of the alert system ICaBrAS is

simple: once started, the app continuously captures

data from the accelerometers and processes these

data so that resulting values can be used to classify

the detected motion activity. The data capture works

as fast as the phone can capture and process the

acceleration data. This means it draws significant

battery current; therefore it is advisable to connect

the power to the vehicle 12V supply.

Figure 1: GUI of the application. Left: main operation

screen (dark for stealthyness). Right: configuration screen.

IoTBD 2016 - International Conference on Internet of Things and Big Data

180

3.1 GUI on Smartphone

The OS on this phone needs to be set to disable

screen saver or going into sleep mode, because

otherwise the acceleration data capture would stop.

For a more advanced version other than the current

prototype one would make the system run in the

background as a continuous service and keep

capturing the data and performing the processing.

ICaBrAS can be controlled either through a GUI

on the phone screen (see

Figure 1) or through SMS

messages. The GUI shows status information and

provides access to a configuration menu. Access to

this configuration screen and also exit button are

password-protected, so that no unauthorised user can

configure or terminate the application while it is

running. The background of the GUI is set to black,

to preserve energy and to keep the phone screen dark

while the application is running and the display is

on, so that it cannot easily be seen by a possible

intruder.

In the configuration menu the user can set the

phone number of the corresponding second user

phone from which ICaBrAS can be controlled. This

allows only one single phone to control this app via

SMS. Also the password can be set and changed in

this configuration menu.

3.2 Control through SMS

The user can control the operation of ICaBrAS

solely via SMS from a phone which has been

“registered” with the software in the configuration

screen. The configuration menu allows to either

enter the phone number or select it from the address

book on the phone. Incoming SMS messages from

other phone numbers are ignored.

This method of using SMS for remote cotnrol

has been chosen as a cost-effective method and also

one that is widely compatible with all types of

mobile phones. It works abroad and also in areas

where the signal reception is not sufficient for

mobile data access. Since only SMS messages are

used, no data traffic is created. Such data traffic

abroad could cost a significant amount of money,

therefore the SMS control method is a way of

keeping the operational costs down, as SMS

messages are inexpensive even abroad.

If an SMS with a specific keyword is received,

then ICaBrAS will respond with an SMS reporting

the status and the activity classification of the

system. Once remotely activated, ICaBrAS will keep

sending SMS everytime a new (higher) activity level

is detected. The user can then also stop this SMS

reporting by sending a specific SMS.

The position of the vehicle can be requested

through SMS: the returned SMS contains a link

which will open Google Maps showing a map with

the vehicle location.

The user can remotely request that ICaBrAS

initiates a phone call back to the remote phone. In

conjunction with a Bluetooth hands-free mic/speaker

unit this allows to communicate with whoever is in

the vehicle without them accessing or handling the

phone.

3.3 Development Environment

For the development of this prototype, the cloud-

based framework MIT App Inventor (MIT, 2015)

has been chosen. The reason is the robust and

suitable functionality provided by this framework.

The event-driven nature of the ICaBrAS prototype

could easily be implemented with this framework,

and there was no need to further consider

compatibility issues between various versions of

Android. This means that this prototype should be

able to run on all mobile android phones from

version 2.3 onwards which have a set of 3-axis

accelerometer sensors and GPS for location

reporting.

The development is done simply through drag-

and-drop in a graphical web-based programming

environment. MIT App Inventor is intended to learn

principles of mobile programming, but it extends

very well to more demanding real-world

applications like this.

4 ACTIVITY CLASSIFICATION

The main sensor for the activity detection on which

the alert system is based is the set of accelerometers.

Most smartphones that have been on the market in

recent years have built-in 3-axis accelerometers.

These sensors measure acceleration in the three

orthogonal Cartesian coordinate axes. The

acceleration data are used by applications to

determine motion of the phone, for example to

detect activity for sports and health applications (e.g.

Hong et al., 2010), and to qualitatively determine

key parameters of the motion. Hong et al., (2010)

hereby use FFT to determine the motion

characteristics to link and correlate it to calorie

consumption. This method does not require bias

removal, as only the changes of the acceleration

values are taken into account.

For the purposes of this alert system, it is

A Low-cost Intelligent Car Break-in Alert System - Using Smartphone Accelerometers for Detecting Vehicle Break-ins

181

important to look not only at the temporal changes

but also at the intensity of these changes, because

they will lead to the classification of the detected

activity. This triggers the need for dealing with one

problem that all algorithms relying on accelerometer

data face: the removal of the earth’s gravity bias

from the accelerometer data.

4.1 Gravity Bias Removal

Due to their nature, accelerometer data always do

have a bias when being used in the presence of

gravity: the gravity vector exerts a force which

points directly to the centre of the Earth and which

has the acceleration value of 1g = 9.81 m/s

. This

acceleration bias is present during all measurements

of the overall acceleration  which is calculated by

the Euclidean Norm from the three Cartesian

components:























(1)

If the sensor is kept at a steady orientation, the bias

removal is easy: the average value can be computed

for each of the three components and is subtracted

from each of the components in order to obtain the

true acceleration. Since in this application the

smartphone and its accelerometer sensors are placed

in the vehicle at a steady location, this simple bias

removal process can be implemented. It is to note,

however, that this bias removal is not valid once the

phone changes its orientation towards the earth,

because then the gravity vector components change

and the average value of the acceleration

components will change. Such a situation can be

mitigated by calculating a weighted or windowed

average which only takes into account the most

recent acceleration measurements.

In the ICaBrAS app the mean acceleration value

of each of the three components is calculated

through a low-pass filter with a time constant of 1

second. Each measurement 



leads to a low-pass

filtered value 



 which represents the average over

1 second. This value is subtracted from the

measurement 



to provide the true acceleration

without the gravity bias.





⋅









1



⋅

























(2)

This processing is triggered by the event when new

accelerator data arrive. In the specific setup this was

done at 50Hz, therefore the time period for the

measurements was:   0.02. It is explicitly

measured every time the event is raised, therefore

always the true value of the time period is taken into

account in the computation of the true acceleration.

4.2 Acceleration Processing

In order to have a more convenient measure of the

acceleration than the raw value which can range

over several order of magnitudes, the logarithm of

the overall acceleration is calculated and processed

through another low-pass filter with the same time

constant 1 second. This now provides two

suitable values which can be used for describing

motion and acceleration changes: the long-term

filtered average baseline log 





value which

describes the changes based on a time constant of 1

second and therefore can be used to detect general

vehicle motion modes, and the immediate

acceleration change value log 



which describes

sudden changes in acceleration and can therefore be

used to detect sudden events which only last very

short.

4.3 Activity Classification

The activity detection is based on these two values:

log 



and log 





. The first value indicates

peaks of activity, while the second value indicates a

longer lasting commotion.

Table 1: Activity classification based on acceleration

values.

maximum:

 



average:

 





activity

level

< -3.3 < -3.3 No activity. 0

-3.3 < x < -2.4 < -3.3 Slight jerks. 1

-1.4 < x < -1.0 < -3.3 Some jerks. 2

-1.0 < x < 0.25 < -3.3

Significant

jerks.

> 0.25 < -3.3 Hard jerks. 4

any -3.3 < x < -2.4

Some

commotion.

any -1.4 < x < -1.0

Motor is

on.

any -1.0 < x < 0.25

Vehicle is

driving

any > 0.25

Phone in

user’s hand.

Through heuristic evaluation the classification

based on the acceleration values in Table 1 have been

determined. These were obtained by observing the

processed acceleration values in different situation.

The mobile phone with its sensors was hereby

IoTBD 2016 - International Conference on Internet of Things and Big Data

182

placed on a flat surface in the vehicle while it

recorded the acceleration data.

For determining the activity the log-acceleration

values were observed during 2-second intervals, and

the peak (Column 1) and the average value (Column

2) of these log-acceleration values were recorded.

They form the base for detecting a change in the

activity level to which the phone is exposed. This

activity is classified into one of 9 levels (0-8, in

Column 4). For classifying a certain level, the

conditions in both Column 1 and Column 2 need to

be satisfied.

5 EXPERIMENTAL SETUP

The prototype of ICaBrAS was installed on a

Google Nexus 4 mobile phone, running Android 5.0.

The remote user phone which did receive SMS

messages and was used to remotely control ICaBrAS

is a Motorola Moto E with Android 5.0.2.

The ICaBrAS phone was placed in the rear of a

2005 Fiat Doblo 1.9 TD. It was continuously

powered from the vehicle battery, and the OS was

set to not go to sleep while connected to external

power. The ICaBrAS software was started and kept

running continuously for several days. The current

that is drawn by the phone from the vehicle battery

is around 300 mA. Since the vehicle battery is a

usual 12V lead-acid with 90 Ah capacity, the

theoretical operation duration can be 300 hours until

the battery would be fully depleated. In typical

realistic situations the usable battery capacity is only

half the nominal value, which is 45Ah. This leads to

a real-world operation of around 150 hours. It is to

note that when the vehicle is driven, the vehicle

battery is being recharged again. To avoid draining

the vehicle battery an auxiliary batterz (leisure

batterz) as it is custom for camper vans can be used

and can be connected to a solar panel. Provided the

solar panel is rated at a sufficiently high power

(150W is a realistic value for this), it then can

generate continuous uninterrupted power to recharge

the battery during the day even in winter.

The accelerometers of the Nexus 4 phone can run

at 50Hz, therefore they provide 50 data sets per

second. For debugging the ICaBrAS could be set

into data recording mode, which provided sets of

CSV files stored on an SDRAM card. This data

recording was controlled remotely through SMS: a

specific messages could switch on the data recording

and turn it off, allowing to record the acceleration

data in specific scenarios.

The phone was placed out of plain sight and was

situated behind a fabric screen. This was done in

order to avoid to attract attention by a possible

intruder. The GPS reception still was good neough

to provide location updates.

6 RESULTS

The Nexus 4 phone with the ICaBrAS software was

run in a variety situations. The following graphical

plots show the resulting log-acceleration data

(maximum) in these sutiations.

In Figure 2 the log acc data are shown during no

activity. This was recorded during idle time, and the

data plot gives an impression of how the basic noise

of the accelerometer data manifests itself in the case

of absence of any motion or externally triggered

jerk.

Figure 2: Acceleration during 9 minutes of no external

activity. Peak (dotted) and average (solid) values are

shown.

In Figure 3 the data plot shows the log-

acceleration values when the door is opened with a

key. The peak value indicates the moment when the

opening of the door occurs. This peak is detected

and gives rise to a SMS being sent, indicating that an

intruder has entered the vehicle.

Figure 3: Raw log acceleration data with peak when

opening the vehicle door.

A Low-cost Intelligent Car Break-in Alert System - Using Smartphone Accelerometers for Detecting Vehicle Break-ins

183

In Figure 4 the log acceleration is shown during

several phases of driving. The first peak is when opening

the door, then shutting it. At time 176,000 the motor is

started, and then a constant acc noise level between -1 and

-3 is recorded, which is clearly above the acc noise level

for no motion. At time 191,000 the motor is switched off

again, followed by some commotion which includes

opening the door then shutting the door at 213,000. The

time units are milliseconds.

Figure 4: Log acceleration values during different phases

of vehicle operation.

These data plots illustrate how the log acc data

changed during different situation. The

accelerometers in the smartphone are able to pick up

differences in acceleration which can be used for

determining and classifying the activity level which

the phone and hereby the vehicle are undergoing.

The acceleration data which are being collected

and processed while the vehicle is driving can also

be used to identify road roughness. This can be used

to highlight trouble spots with potholes and rough

road surfaces, in particular if many vehicles are

using this app and report back such data via crowd-

sourcing.

7 CONCLUSIONS

The experiments with this prototype app have

indicated that it is possible to re-use an obsolete

smartphone and use it as a low-cost vehicle alert

system. Simple data processing is employed which

can be run in real-time on a typical smartphone

without exceeding its capabilities. This can provide

a low-cost alternative to expensive on-board vehicle

systems. With such a smartphone, any vehicle can

be “upgraded” to become an intelligent device which

can communicate its status and captured data. This

can be used in the context of detecting a break-in,

but also an actual theft of the vehicle, as this can

report its current and changing location back to the

user’s “main” phone.

There is much further potential for using such an

app for data harvesting: the app could collect data

about road roughness and share it with other users

through a web app / web portal. Also, in conjunction

with the location tracking, the app could be used to

estimate the mechanical stress under which the

vehicle is, from its accelerations and vibrations

which are recorded on the phone.

REFERENCES

Bedogni, L., Di Felice, M., Bononi, L. 2012. By train or

by car? Detecting the user’s motion type through

smartphone sensors data. Wireless Days, 2012 IFIP,

21-23 Nov 2012, Dublin.

Entner, R, 2011. International Comparisons: The Handset

Replacement Cycle. Recon Analysis. 23 June 2011.

http://mobilefuture.org/wp-content/uploads/2013/02/

mobile-future.publications.handset-replacement-cycle.

pdf.

Hong, Y.-J. and Kim, I.-J., 2010. Mobile health

monitoring system based on activity recognition using

accelerometer. In Simulation Modelling Practise and

Theory, v.8, no.4, 4 April 2010, pp. 446-455.

IDC, 2015. Smartphone OS Market Share, 2015 Q2.

http://www.idc.com/prodserv/smartphone-os-market-

share.jsp

Johnson, D.A. and Trivedi, M.M. 2011. Driving style

recognition using a smartphone as a sensor platform.

Proc of ITSC 2011, 14

Int. IEEE Conference on

Intelligent Transportation Systems (ITSC).

Washington DC, 5-7 Oct 2011, pp. 1609-1615.

Maplin, 2015. http://www.maplin.co.uk/p/nikkai-easy-fit-

car-alarm-120db-siren-a78jq

MIT, 2015. MIT App Inventor. http://

appinventor.mit.edu/explore/

OnStar, 2015. https://www.onstar.com

Saedi, S. and El-Sheimy, N. 2015. Activity Recognition

Using Fusion of Low-Cost Sensors on a Smartphone

for Mobile Navigation Application. Micromachines,

vol 6, no.8, pp. 1100-1134.

Thompson, C.. White, J., Dougherty, B., Albright, A., and

Schmidt, D.C. 2010. Using Smartphones to Detect Car

Accidents and Provide Situational Awareness to

Emergency Responders. In Mobile Wireless

Middleware, Operating Systems and Applications. 3

Ing. Conf. Mobileware 2010, Chicago. Pp. 29-42.

TomTop, 2016. Vehicle Tracker Anti Theft Alert System,

http://www.tomtop.com/various-function-gsm-gps-

car-vehicle-tracker-anti-theft-alert-system-sos-voice-

talking-communicating-iosandriod-app-positioning-

alarm-tracker-k2463.html.

IoTBD 2016 - International Conference on Internet of Things and Big Data

184