"Designing onboard vehicle diagnosis fault monitoring system ...

VISVESWARAYA TECHNOLOGICAL UNIVERSITY, BELAGAVI

PROJECT REPORT ON

"Designing onboard vehicle diagnosis

fault monitoring system using IOT "

Submitted in partial fulfillment as a requirement for the award of degree of

BACHELOR OF ENGINEERING

IN

ELECTRONICS AND COMMUNICATION

UNDER THE GUIDANCE OF

Prof. Lipsa Dash

Dept. of Electronics and Communication Engineering

SUBMITTED BY

AFZAL HUSSAIN 1NH16EC004

ASHOK CHOUDHARY 1NH16EC129

BHARATH MVK 1NH16EC130

ASHISH KUMAR S 1NH16EC138

NEW HORIZON COLLEGE OF ENGINEERING, BENGALURU

Autonomous College Permanently Affiliated to VTU Approved by AICTE

Accredited by NAAC with ‘A’ grade

Dept. of ECE, NHCE 2019-20 Page 1

NEW HORIZON COLLEGE OF ENGINEERING, BENGALURU

Autonomous College Permanently Affiliated to VTU Approved by AICTE

Accredited by NAAC with ‘A’ grade

Department of Electronics and Communication Engineering

CERTIFICATE

This is to certify that the project work entitled “DESIGNING ONBOARD VEHICLE

DIAGNOSIS FAULT MONITORING SYSTEM USING IOT” is a Bonafide work carried out by

AFZAL HUSSAIN (1NH16EC004), ASHOK CHOUDHARY (1NH16EC129), BHARATH

MVK(1NH16EC130) & ASHISH KUMAR S(1NH16EC138) submitted in partial Fulfilment

for the award of Bachelor of Engineering degree in VIII semester of the Visvesvaraya

Technological University, Belagavi during the academic year 2019-20. It is certified that

all the corrections and suggestions indicated for Internal Assessment have been

incorporated in the report deposited in the Department library.

The project work has been approved as it satisfies the academic requirement in

respect of Project Work prescribed for BACHELOR OF ENGINEERING DEGREE IN

ELECTRONICS AND COMMUNICATION ENGINEERING.

GUIDE HOD PRINCIPAL

Prof. LIPSA DASH Dr. SANJEEV SHARMA Dr. MANJUNATHA

NAME OF THE EXAMINERS SIGN WITH DATE

1.

2.


ACKNOWLEDGEMENT

We wish to express our profound gratitude to our respected Chairman Dr. Mohan

Manghnani, for providing all the facilities in the college and our respected Principal Dr.

Manjunatha for his constant support. We would like to express our sincere thanks to Dr.

Sanjeev Sharma, Head of the department of Electronics and Communication

Engineering for his continuous support and encouragement. We feel deeply indebted to

our esteemed Project Coordinator Mrs. Reema Sharma and our Guide Ms. Lipsa Dash

for their guidance, right from the conception and visualization to the very presentation

of the project. They have been our guiding light throughout. We are greatly indebted to

our faculties, both teaching and supporting staff, Department of Electronics and

Communication Engineering, who took great interest in our project work. They

motivated and guided us throughout the accomplishment of this goal. We express our

profound thanks for their meticulous guidance. Finally, we would like to express our

heartfelt thanks to our beloved parents for their blessings, our friends for their help and

wishes for the successful completion of this project work.


ABSTRACT

OBD system or the On-board diagnostic systems play an important role in the current

generation of automobiles and will definitely play an equally important role in the

upcoming future. This report presents the growth of the On-board diagnostic system for

vehicles using Internet of Things(IoT) as it is going to play a revolutionary role in the

automobile industry. This OBD system consists of an ARM controller which is part of the

LPC2148 family that acts as the processing unit where the program is written using Keil

micro vision software, sensors and LCD as user interface. The vehicle specifications such

as gas concentration, brake condition and vehicle detection are sensed and those results

are viewed on the LCD display and also can be viewed on an app in a smartphone. The

sensors are first installed at different parts of the vehicle to sense various vehicle

parameters. We use a wi-fi module called nodeMCU for the wireless transmission of

data.


TABLE OF CONTENTS

CHAPTER 1 : INTRODUCTION 7

CHAPTER 2: LITERATURE SURVEY 9

CHAPTER 3: MOTIVATION AND PROPOSED SYSTEM 10

3.1 MOTIVATION 10

3.2 PROPOSED SYSTEM 10

CHAPTER 4: SYSTEM REQUIREMENT 12

4.1 SOFTWARE REQUIREMENT 12

4.2 HARDWARE REQUIREMENT 12

CHAPTER 5: HARDWARE REQUIREMENT 13

5.1 ARCHITECTURE OVERVIEW 13

5.2 ACCELEROMETER 20

5.3 SPEED CONTROLLING DC MOTOR 22

5.4 LCD 22

5.5 WIFI ESP 8266 25

5.6 GAS SENSOR MODULE 26

5.7 H-BRIDGE 28

5.8 L293D MOTOR DRIVER IC 30

5.9 DC MOTOR 33

5.10 PROXIMITY METAL SENSOR 34

CHAPTER 6 : SOFTWARE REQUIREMENT 35

6.1 INTRODUCTION TO KEIL µVision3 35

6.2 EMBEDDED C 41

CHAPTER 7: ADVANTAGES AND APPLICATIONS 43

CHAPTER 8 : RESULTS 44

CHAPTER 8 : CONCLUSION AND FUTURE SCOPE 48

8.1 CONCLUSION 48

8.2 FUTURE SCOPE 48

CHAPTER 9 : REFERENCES 49


TABLE OF FIGURES

Figure 1: Proposed system 11

Figure 2: Pin diagram of ARM7 15

Figure 3 : ADC convertor (successive approximation method) 16

Figure 4: 3 bit example of ADC convertor 17

Figure 5: Schematic of an accelerometer 21

Figure 6: Connections for clockwise rotation of motor 22

Figure 7: LCD pin diagram 23

Figure 8: Address bit of LCD 25

Figure 9: Gas sensor 26

Figure 10: Wiring of the gas sensor 27

Figure 11: H-Bridge switch connection 29

Figure 12: H-Bridge Pin configuration 30

Figure 13: Pin connection with motor 32

Figure 14: DC Motor 33

Figure 15: Metal Detector 34

Figure 16: Keil 37

Figure 17: Software Development Cycle using Keil µVision3 39

Figure 18: Overview of the model 44

Figure 19: Detection of Carbon Monoxide 45

Figure 20: Detection of Brake Failure 46

Figure 21: Messages sent to the app 47


CHAPTER 1: INTRODUCTION

Our project demonstrates the use of the architecture of an IOT based prototype

platform for an On-Board Diagnostic System (OBD) and also for an IOT based application.

Driver is also provided with a user interface through which the user can read any of the

sensor values by selecting on the list. The diagnosis of the faults in terms of parameters,

the notification of unexpected changes to the driver, and an indication regarding the

reason for the fault are included in the system setup. The driver can find out the faults in

the car on the spot and this does not require any other tool for it. In the case of the

vehicle getting stuck in remote areas, the proposed OBD system inside the vehicle can

be connected to the vehicle service center by providing internet facility.

We are implementing our project on an ARM lpc2148 microcontroller. With the help of

the advancement in cloud computing along with the internet of things (IOT) we have

been given a promising opportunity to firmly overcome the challenges caused due to the

expanding transportation issues. It presents a narrative of a multilayered vehicular data

cloud platform with the help of cloud computing and IOT technologies.

The two ingenious vehicular data cloud services, the smart parking cloud service and the

automobile data excavation cloud service, for vehicle warranty analytics in the IOT

environment are presented. The vehicle’s engine contains a certain set of rules that

operate to fulfill the continuous function of the combustion.

To make sure of un-interrupted function and optimal performance, there are different

types of condition monitoring technologies that are currently being used with different

advanced data processing techniques. To develop an embedded system for the

detection of the vehicle’s condition with the help of monitoring all the important

parameters that are mainly used in the evaluation of the vehicle‘s condition, the

person’s travelling information plays a crucial role in supporting refuge, security,

mobility, and also helps in improving the travelling experience.

This real-time passenger information can be in the form of continuous data based on the

performance of their vehicle and the position of its parameters. An in-car organization is

being built to produce a VHR report whenever it is needed by the user. It also acts as a


friendly vehicle by monitoring the flow of the vehicle and where it is located by

controlling (by taking appropriate steps to reduce emissions as per the problems

identified within the VHR). It predicts future faults so that the driver can have

continuous movement and avoid accidents.

The information required to create a health report contains the parameter values (Built-

in sensor results) for different programs inside the vehicle. This data can be obtained

using the OBD-II protocol followed by a vehicle produced after 1996.

It uses Lab VIEW as a platform for an automated diagnostic toolkit that helps in building

the software that is needed to communicate with the vehicle's ECU through the OBD-II

system. The OBD-II technology is designed to detect vehicle condition. The OBD-II scan

plug in the OBD-II port or commonly called Data Connector (DLC), then transmits the

diagnostic to the Raspberry Pi. Compared to the other Microcontrollers such as Arduino,

Raspberry Pi is mostly preferred as it supports the application to get Real-time

diagnostics, diagnostic processing and sends commands to cars at the same time, rather

than Arduino who has to hold another process that has completed the other process.


CHAPTER 2: LITERATURE SURVEY

● Mario Gerla, Eun-Kyu Lee, Giovanni Pau[1]: This paper conveys the

transformation of the Internet of Vehicles to the Vehicular Cloud, the similarity

of Internet cloud for vehicles, providing every service that is required by the

Autonomous Vehicles. It also mentions the evolution from Intelligent Vehicle

Grid to Autonomous, Internet connected Vehicles, and Vehicular Cloud. Paper

discusses the removal of human control, and autonomous vehicles must adeptly

cooperate to maintain the smooth traffic flow on roads and highways.

● Abhinyaa Balasundaram, Aiswarya Udayakumar, BaladharshiniGopalan,

KaaviyaBhaskaran, Bharkathnisha Abdul Muthalip [2]: This paper outlines

Vehicle Emission Monitoring System using IoT. It describes how the sensors and

circuit gathers the pollutant discharge in the vehicle and how the data can be

used for monitoring the pollutant levels.

● Mohammad Rubaiyat Tanvir Hossain, Md. Asif Shahjalal, Nowroz Farhan

Nur[3]: This paper illustrates the concept of autonomous vehicle systems. It

demonstrates the video streaming techniques and remote access. It also

represents the performance level of the system developed in a miniature car.

● Lim, H.T., Volker, L. and Herrscher, D., 2011, June[4]: Challenges in a future

IP/Ethernet-based in-car network for real-time applications. This paper helped us

understand the IP/Ethernet protocols and also how it’s much more efficient and

better compared to other types of networks like CAN, LIM, etc..

● SagarSukode, ShilpaGite[5]: This paper illustrates Intelligent Transportation

System with help of IR sensor, sensor array, gas sensor and temperature sensors.

These will evaluate real-time traffic density. The system uses real-time approach

tracking of automobiles and broadcasting traffic related events.


CHAPTER 3: MOTIVATION AND PROPOSED SYSTEM

3.1 MOTIVATION

The world is continuing to become smarter and smarter as time goes on, and as people

become curious about smart products, just like anyone, they want to try them out, but

they cannot since most of these advanced technological products are not affordable by

most of them. One of the smart products being the vehicle diagnostic system, a lot of

the people really want to try using it as it can help save them money from going to the

vehicle service center for every fault that takes place in their vehicles. In the current day

scenario, BMW is the only company who has implemented the concept of onboard

vehicle fault diagnostics system. The problem with this is that not everyone is able to

afford a BMW and since it is not available in vehicles from the other automobile

companies, people cannot use it. This was our biggest motivation to start this project

because we are a few people who really wanted to try the product but we could not

since we could not afford a BMW. Hence, since we really wanted to try the product, we

made it our goal to make this project as it could also be helpful to people because it is

way cheaper and affordable by the common man.

3.2 PROPOSED SYSTEM

The replacement of the diagnostic Tool kit with Automotive IOT provides less time for

updating ECU data and it is possible to use Wi-Fi for networking other domains of the

vehicle. The method used here for diagnosing the vehicle is much different from the

existing OBD systems. As said earlier, this system does not require a scan-tool,

technician and service centres. This follows the server-client architecture, as cloud being

the server. The different kinds of parts of the vehicle are connected with multiple ECUs

as they have different functions and these ECUs will have different kinds of sensors

attached with it for monitoring. The ECUs will all be connected to the server and the

server will keep collecting the values from the ECUs. The user can view any real-time

value of the parameter just by using a mobile phone. So the user will know the condition

and performance of the vehicle while driving as the updates will keep happening in real-


time. The proposed system will be preloaded with optimum maximum and minimum

values of each parameter. The system will display abnormal indications in the display.

Figure 1 Proposed System


CHAPTER 4:SYSTEM REQUIREMENT

4.1 SOFTWARE REQUIREMENT

1. EMBEDDED C

2. KEIL M VISION

4.2 HARDWARE REQUIREMENT

1. MICROCONTROLLER ARM LPC2148

2. LCD

3. METAL SENSOR

4. RELAY

5. WI-FI

6. GAS SENSOR

7. ACCELEROMETER

8. DC MOTOR


CHAPTER 5: HARDWARE REQUIREMENT

The LPC2141 / 42/44/46/48 microcontrollers are based on the features of 16-bit / 32-

bit-ARM7TDMI-S CPU with both real-time support as well as back-up support, that

combines the microcontroller with a high-speed switched memory that ranges from 32

kB to 512 kB. The wide 128-bit memory interface and unique accelerator build range

enable 32-bit coding at maximum clock speed. For sensitive applications of sensitive

code, an alternative 16-bit Thumb mode lowers the code by over 30% for a small

performance penalty.

Due to its small size and low power consumption, the LPC2141 / 42/44/46/48 is ideal for

applications where miniaturization is a basic requirement, such as access control and

sales. Serial interface communication from a high-speed USB 2.0 device, multiple UARTs,

SPI, SSP to I2C-bus and on-chip SRAM of 8 kB up to 40 kB, perform these devices are

best suited for communication gateways and protocol converters, fixed modems, voice

recognition and endless guessing, which offers greater buffer size and higher

performance power. 32 different timers, single or double 10-bit. ADCs (s), 10 DAC

channels, PWM channels and 45 GPIO speed cables with nine sensitive pins or sensitive

external interfaces make these microcontrollers ideal for industrial control and medical

applications.

5.1 ARCHITECTURE OVERVIEW

The ARM7TDMI-S is a versatile 32-bit microprocessor, that provides high performance

and with low power consumption. The ARM architecture is mainly based on Reduced

Instruction Set Computer (RISC), and the instruction set and the related decode

mechanisms are much easier to use and are simpler than those of Complex Instruction

Set Computers (CISC). This easiness results in a high instruction productivity and

impressive simultaneous interrupt response from a small as well as a cost-effective

processor core. The ARM7TDMI-S processor also uses a unique build strategy called the

Thumb, which makes it well suited for high-volume applications that require memory

restrictions, or application code density can be an issue.


The ARM7TDMI-S processor has two instruction sets:

• The standard 32-bit ARM set.

• A 16-bit Thumb set.

The Thumb set's 16-bit instruction length allows it to double the size of the standard

ARM code while retaining most of the ARM performance benefits over the traditional 16

processor using 16 registers. This is possible because the Thumb code is running on the

same 32-bit register set as the ARM code. Icon code is capable of providing up to 65% of

the ARM code size, and 160% of the ARM equivalent processor functionality connected

to the 16 memory system. optimization of full speed in ARM mode. Recommended

functionality for sensitive and short code programs (such as service disruption services

and DSP algorithms) in ARM mode. The effect of the whole code size will be small but

the speed can go up 30% over Thumb mode.

5.1.1 Pin Control Block

The pin connection block allows the selected microcontroller pins to have more than

one function. The configuration registers command all the multiplexers to allow the

connection between the pin and on chip peripherals. To be activated, the Peripherals

should be connected to the appropriate pins, and before any related interrupt(s) are to

be enabled. The Activity of any of the enabled peripheral functions that is not mapped

to a related pin must be undefined.

The Pin Control Module along with its pin select registers determines the functionality of

the microcontroller in a given hardware environment. After resetting all the pins of Port

0 and 1 are configured as the input with the following exceptions: when debug is

enabled, the JTAG pins automatically will assume their own JTAG functionality; if the

trace is enabled, the Trace pins will resume their trace functionality. The pins associated

with the I2C0 and I2C1 interface are considered to be open drain.


Figure2: Pin diagram of ARM7

5.1.2 General Purpose Parallel I/O (GPIO)

Device pins that are not supposedly connected to certain specific peripheral functions

are managed by the GPIO registers. Pins can be dynamically configured as an input or as

an output. Different registers allow the setting of or the clearing of any number of

outputs at the same time. The value in the output register can be read back, as well as

the current state of the port pins. LPC2141/42/44/46/48 prefer accelerated GPIO

functions over the LPC2000 Devices:

• GPIO registers are shifted back to the ARM local bus for the fastest possible I/O timing.

• Mask registers allow usage of sets of port bits as a group, leaving other bits untouched.

• All GPIO registers can be addressed by bytes.

• Entire port value can be written using one instruction

Features:

• Bit-level set and clear registers allow only a single instruction to set or clear any

number of bits in a single port.

• Direction control of individual bits.

• Separate control of output set and clear.

• All I/O default to inputs after reset.


5.1.3 10-Bit ADC

The LPC2141/42 and the LPC2144/46/48 respectively contain one and two analog to

digital converters. The digital converters are of single 10-bit successive approximation

analog to digital converters. As ADC0 contains six channels, ADC1 contains eight

channels. Thus, the total number of available ADC inputs for LPC2141/42 and

LPC2144/46/48 are respectively 6 and 14.

ADC (Successive Approximation Method)

The SAR architecture mainly uses an algorithm called the binary search algorithm. The

below fig 8.2.2(a) consists of a few blocks such as a single comparator, a single DAC

(Digital to Analog Converter) and a single control logic.

Figure3: ADC convertor (successive approximation method)

Features:

• Contains 10 bit consecutive approximation analog to digital converter.

• Measurement ranges from 0 V to VREF (2.0 V ≤ VREF ≤ VDDA).

• Each of the converters are capable of converting more than 400,000 10-bit samples

every second.

• Every analog input has a dedicated result register to reduce interrupt overhead.

• Single and multiple inputs contain burst mode.

• Optional conversion on transition on input pin or timer match signal.

• Global Start command for both converters (LPC2142/44/46/48 only).

Example: The algorithm is very similar to searching a number from a telephone book.

For example, to search a telephone number from a telephone book first, the book is


opened and the number may be located either in the first half or in the second half of

the book. Further, the relevant section is divided into half. This procedure can be

followed until finding the relevant number.

Figure4: 3 bit example of ADC convertor.

5.1.4 UARTs

Each LPC2141/42/44/46/48 contain two UARTs. Apart from the transmit and receive

data lines, the UART1 OF LPC2144/46/48 also provides an absolute modem control

handshake interface. Compared to the previous LPC2000 microcontrollers, UARTs that

are present in PC2141/42/44/46/48 introduce a very small baud rate generator for both

the UARTs present, enabling the microcontrollers to achieve good baud rates such as

115200 with the use of crystal frequency above 2 MHz. Additionally, auto-CTS/RTS flow-

control functions are implemented entirely in hardware (UART1 in LPC2144/46/48 only).

Features:

• Contains a 16 byte Receive and Transmit FIFOs.

• Register locations conform to ‘550 industry standards.

• Built-in fractional baud rate generator covering a wide range of baud rates without a

need for external crystals of particular values.

• The transmission FIFO control allows the implementation of software (XON/XOFF) flow

to control both UARTs.


• LPC2144/46/48 UART1 is equipped with the standard modem interface signals. The

module even provides complete support for hardware flow control (auto-CTS/RTS).

Serial I/O Controller:

Each LPC2141/42/44/46/48 contain two I2C-bus controllers. The I2C-buses are

bidirectional, they use only two wires for inter IC control: a serial clock line (SCL), as well

as a serial data line (SDA). Every single one of the devices are recognized by their own

unique address that can be operated as either a receiver-only device (e.g., an LCD driver

or even a transmitter with the capability to do both receive and send information (such

as memory)). Transmitters and receivers operate only in either master or slave mode, it

depends on whether the chip initiates a data transfer or is just addressed.

Features:

• They are easy to configure as a master, slave, or master/slave.

• Programmable clocks allow versatile rate control.

• Bidirectional data transfer between masters and slaves.

• Multi-master bus (no central master).

• Mediation between continuous transmitting masters without corruption of serial data

on the bus.


Program 5.1.4 Serial UART

The program 5.1.4 describes the code for initializing, accepting and displaying the

characters through the ARM7 serial UART.

5.2 ACCELEROMETER

Accelerometer is a sensor that measures the physical acceleration of a particular object

due to internal forces or due to mechanical release. The accelerometer behaves like a


wet mass in the spring. When the accelerometer experiences acceleration, the weight is

moved and sent to the acceleration unit.

The principle of working of an accelerometer can be explained with a simple mass (m)

that’s attached to a spring of certain stiffness (k) which in turn is attached to a casing, as

shown in fig 5.2(a).

The dashpot having damping coefficient (c) is usually attached to a given mass in parallel

to the spring. When the mass system containing the spring is subjected to linear

acceleration, a certain force that is equal to mass times the acceleration acts on the

proof-mass causing a deflection. This deflection can be sensed by appropriate means

which then is converted into electrical signals of the same. A certain kind of damping is

required; or else the system cannot stabilize in a quick manner under applied

acceleration. To derive the motion equation of the used system, Newton’s second law is

used, in which all real forces acting on the proof-mass are equal to the inertia force on

the proof-mass.

Figure5: Schematic of an accelerometer.

The accelerometer to be designed will have a range which measures from ±30 ‘g’ with a

resolution of 50 mille ‘g’. The sensor can have a response time of less than 1msec and it

should perform over a temperature ranging from -20 to 80ºC. In this paper the

accelerometer works in 3 axis (x,y,z), but we use 2 axis (x,y). if the proportion of hitting

the vehicle is more than the limited range, the GSM which is present in the system will

start sending the messages to the concerned authorities and to the people who have

registered.


5.3 SPEED CONTROLLING DC MOTOR

Figure6: Connections for clockwise rotation of motor

If we connect this circuit to a small hobby motor we can control the motor with a

processor (MCU, etc.) by applying a logical one, (which is +12 Volts in our example) to

the point A which makes the motor to turn forward. By applying a logical zero, (ground)

it causes the motor to stop turning.

The “high voltage” drivers are the transmission relay that controls the positive voltage

on the motor. This is called the current product. The "low-voltage drivers" are the relay

relays that control the negative voltage currently in the motor. "Check-in now" is the

name for connecting the circuit and the negative side of the power supply, which is

usually ground.

5.4 LCD

The liquid crystal display (lcd) is a subtle panel used to display electronic information

such as text, pictures, and moving pictures. Its uses include computer monitors,

televisions, instrument panel, and other devices from the cockpit view of an aircraft, to

everyday consumer devices such as video players, gaming devices, watches, watches,

calculators and phones. Among its major features is its lightweight construction,

portability, and its ability to be produced at a larger screen size than that used in the

development of cathode ray tube (crt) technology. Low power consumption enables it to

be used on battery-operated electronic equipment. It is an electronically converted

instrument which is made from any amount of pixels which are filled with liquid crystals

and is placed in front of a light source (background light) or a color or monochrome

image display. The first discovery leading to the development of LCD technology, the

discovery of liquid crystals, from 1888. By 2008, worldwide television sales by LCD

specialists had outpaced the sales of crt units.


Each LCD pixel usually consists of a layer of cells that are embedded between two

transparent electrons, as well as two filtering filters, for which the transmission axes are

(in most cases) facing. Since there is no real liquid crystal between the bending filters,

the light passing through the first filter will be blocked by the second polarizer (crossed).

The surface of the electrons in contact with the liquid crystalline material is handled in

order to transport the liquid crystal molecules to a specific location. This treatment

usually consists of a thin layer of irregularly cut polymer using, for example, a cloth. The

direction of the crystal alignment of a liquid is defined by the direction of the rubbing.

Electrodes are made of a transparent conductor called indium tin oxide (ito).

Figure7: LCD pin diagram


5.4.1 FUNCTION DESCRIPTION

The LCD display module is built in the LSI control area, the controller has two 8-bit

registers, an instruction register (IR) and a data register (DR).

IR codes store command codes, such as graphical display and cursor rotation, and RAM

display data address (DDRAM) and character generator (CGRAM). IR can only be

recorded from the MPU. DR temporarily stores data to be written or read in DDRAM or

CGRAM. When the address information is listed in IR, then the information is stored in

the DR from DRAM or CGRAM. With the registration of the signal (RS) of the signal, the

two registers can be selected.

Table 5.4.1(a) LCD status description

Busy Flag (BF)

Whenever the busy flag is 1 or high, the LSI controller goes into the internal operation

mode, and will not accept the next instruction. When RS=0 and R/W=1, the busy flag

becomes the output to DB7. The next instruction should be written after making sure

that the busy flag is low or 0.

Address Counter (AC)

The address counter (AC) is in charge of assigning addresses to both DDRAM and CGRAM

Display Data RAM (DDRAM)

This DDRAM is made to store the display data which is represented in 8-bit character

codes. It can be extended to having a capacity of 80×8 bits or 80 characters. The figures

down below show the relationships between the DDRAM addresses and the positions on

the liquid crystal display.


Figure8:address bit of LCD

Character Generator ROM (CGROM)

The CGROM is able to generate a 5×8 dot or a 5×10 dot character pattern from an 8-bit

character code. See Table 2.

Character Generator RAM (CGRAM)

In CGRAM, the user is able to rewrite characters by program. For the 5×8 dots, around

eight character patterns could be written, and for the 5×10 dots, around four character

patterns could be written.

Write into DDRAM the character code at the addresses shown as the left column of

table 1. To show the character patterns stored in CGRAM.

Table 5.4 LCD command

5.5 WIFI ESP 8266

ESP8266 is designed for mobile, wearable electronic applications and the Internet of


Things with the aim of detecting the lowest energy consumption with a combination of

specific related techniques. The energy-efficient structure works in 3 ways: active

mode, sleep mode and deep sleep mode.

By utilizing advanced power control techniques and logic for low power functions and

no control over switching between sleep and active modes, the ESP8266 consumes

less than 12uA in sleep mode and less than 1.0mW (DTIM = 3) or less than 0.5mW

(DTIM = 10) to stay connected to the access point.If in sleep mode, only the real-time

clock and clock counter remain active. The real-time clock can be interpreted to wake

ESP8266 at any time needed.

ESP8266 can be programmed to wake up when a specific situation is detected. This

low alert feature of ESP8266 can be activated by mobile SoCs, allowing them to stay in

low power standby mode until Wi-Fi is required.To fulfill the need for mobile and

wearable power supplies, ESP8266 can be programmed to reduce the output power of

PA to match various app profiles, commercially using power range.

5.6 GAS SENSOR MODULE

This sensor is used to sense the amount of carbon monoxide present. The output of this

sensor is ‘high’ and it goes ‘low’, whenever the gases are sensed.

Figure9:Gas Sensor


Introduction

The MQ series of gas sensors uses a small internal heater with a chemical-sensor. They

look into a variety of mirrors and are used indoors at room temperature.

They can be measured more or less (see the section about "Load-resistor" and "Burn-

in") but gas or ammunition is required for that.

The results are analog signals and can be read by analog input of Arduino.

Wiring

The wiring that is normally preferred is to connect all the 'A' pins together and all the

'B' pins together as well. It is said to be safer and is assumed to have more reliable

output results.

Figure10: wiring of the gas sensor

In the above shown figure, the heater is connected +5V and is also connected to both

the 'A' pins. This is possible if and only if the heater needs a fixed +5V voltage and not a

variable voltage.

The variable resistor in the above shown figure is the load-resistor and can be used for

determining a good value. A fixed resistor is used as a load-resistor in a lot of the cases.

The Vout is connected to an analog input of the Arduino .


List of sensors

MQ-2

● Is mostly sensitive to Methane, Butane and LPG and smoke.

● This sensor is also sensitive to gases that are flammable and combustible.

● The heater uses 5V.

MQ-3

● It is very sensitive to Alcohol, Ethanol and smoke

● The heater uses 5V

MQ-4

● It is Sensitive to Methane and CNG Gas


MQ-5

● It is sensitive to Natural gas and LPG.


5.7 H-BRIDGE

When the signal is not received by the IR receiver, the potential present at the inverting

input rises higher than that of the non-inverting input of the comparator IC (LM393).

Hence the output of the comparator becomes low, and the LED does not glow. When

the signal is received at the IR receiver module, the potential present at the inverting

input becomes low. Hence the output of the comparator (LM 339) becomes high and

the LED starts to glow. Resistors R1 (100), R2 (10k ) and R3 (330) are used to make sure

that a bare minimum of 10 mA current passes right through the IR LED Devices such as

the Photodiode and other normal LEDs respectively. Resistor VR2 (preset=5k) is used for

adjusting the output terminals. The sensitivity of the circuit diagram can be adjusted

using Resistor VR1 (preset= 10k). A H-bridge is made up of four switches like S1, S2, S3

and S4. When switches S1 and S4 are closed, a certain positive voltage will be applied

across the motor. By opening the two switches S1 and S4 and closing the other two

https://www.elprocus.com/switches-types-working/

https://www.elprocus.com/switches-types-working/


switches S2 and S3, the voltage becomes inverted, allowing an inverse operation of the

motor.

Normally, the H-bridge motor driver circuit can be used to reverse the direction of the

motor and also to break down the motor. The motor stops all of a sudden if the

terminals of the motor are shorted. Or let the motor run free to a stop, when the motor

is removed from the circuit. The table below shows the different operations with the

four switches corresponding to the circuit shown above.

Figure11 : H-Bridge switchconnection

Table 5.7.2: H-Bridge

operation


5.8 L293D MOTOR DRIVER IC

The L293D IC is a distinctive Motor Driver IC that permits the DC motor to be able to

drive in any direction. The L293D IC consists of 16-pins that can be used to control a set

of two DC motors immediately in any direction. By this, we can conclude that, by using a

L293D IC we can take control of two DC motors. Also, this IC is able to drive small as well

as quiet big motors.

This L293D IC functions over the basic principle of the H-bridge, the circuit to control the

motor that allows voltage to flow in any direction. Given that voltage must change the

way it is able to rotate the DC motor in both directions. Thus, the H-bridge circuit using

the L293D IC’s are well positioned to drive the car. Single L293D IC consists of two H-

bridge internal circuits that can be used to rotate two DC engines separately. Typically,

these assemblies are used in robotic systems because of their small control over DC

motors.

Figure12: H-Bridge Pin configuration

https://www.elprocus.com/dc-motor-basics-types-application/

https://www.elprocus.com/dc-motor-basics-types-application/


PIN DIAGRAM OF A L293D MOTOR DRIVER IC CONTROLLER

• Pin-1 (Enable 1-2): When the enable pin is turned high, the left portion of the

IC will work or else it does not. This pin is typically called a master control pin.

• Pin-2 (Input-1): When the input pin is turned high, the current flows through

output 1.

• Pin-3 (Output-1): The output-1 pin should be connected to any one of the

terminals of the motor.

• Pin4 &5: These pins are used for ground.

• Pin-6 (Output-2): This pin should be connected to any one of the terminals of the

motor.

• Pin-7 (Input-2): When this pin turns HIGH then the current flow will be through

output 2.

• Pin-8 (Vcc2): This pin is used for supplying the voltage.

• Pin-16 (VSS): This pin is used to power the integrated circuit.

• Pin-15 (Input-4): When this pin turns high, then the current flow will be through

output-4.

• Pin-14 (Output-4): This pin should be connected to any one of the terminals of

the motor

• Pin-12 & 13: These pins are used for ground.

• Pin-11 (Output-3): This pin should be connected to any one of the terminals of

the motor.

• Pin-10 (Input-3): When this pin turns high, the current flow will through output-3

• Pin-9 (Enable 3-4): When this pin turns high, the right portion of the IC will

start working & when it turns low the right portion of the IC will not work. This

pin is also called as master control pin for the right portion of the IC.


H-BRIDGE MOTOR CONTROL CIRCUIT USING L293D IC

The IC LM293D includes 4-i/p pins out of which, pin2 and 7 on the left hand side of the

IC and Pin 10 and 15 on the right hand side of the IC. The Input pins present on the left

hand side of the IC controls the motor’s rotation. The motor here is connected across

the side and the right i/p for the motor on the right hand side.

This motor rotates based on the IPS we provided across the input pins as Logic 0 and

Logic 1.

Figure13: Pin connection with motor


5.9 DC MOTOR

DC motors convert electrical into mechanical energy and they consist of permanent

magnets and loops of wire inside. When a certain amount of current is applied, a

magnetic field is generated using the wire loops, which then tends to react against the

field outside of the static magnets. The interaction between the fields produces a

certain movement of the shaft/armature. Hence, the electromagnetic energy becomes

motion.

Figure14: DC Motor

Here we use two DC motors for the movement of the rover. A DC motor is considered to

be a form of a rotary electrical machine which is used to convert direct current electrical

energy into mechanical energy. Some of the most common types rely on the forces that

are produced by magnetic fields. Almost every type of DC motor has a certain internal

mechanism, it can be either electromechanical or electronic, to change periodically the

direction in which the current flows in the motor. DC motors were the earliest form of

motor that was widely used, as one of the main reasons was that they were able

powered from existing direct-current lighting power distribution systems. A DC motor's

speed can be varied over a wide range, by using either a varying supply voltage or also

by changing the strength of the current present in its field windings. Small DC motors

can be found in tools, toys, and appliances.


5.10 PROXIMITY METAL SENSOR

This Tube Type Inductive Proximity Sensor Detection Switch NPN DC6-36V 4mm

Normally Open switch LJ12A3-4-Z/BX is a component widely used in the automatic

control industry for detecting, controlling, and non-contact switching. When the

proximity switch is close to some target object, it will send out control signals. When the

metal approaches a proximity switch sensing area, an Eddy Current is induced in metal.

Which in turn disturbs the magnetic field produced by the Inductive Proximity Sensor.

This change is sensed by the sensor. These inductive proximity switches can be non-

contact, no pressure, no spark, quickly issued the electrical command. Positioning

accuracy, operating frequency, service life. Easy to install and suitable for harsh

environments. The above mentioned 4mm proximity sensor can be used to detect a

number of different metals, miniature sized, with a long life, of a low price, shielded

type installation, an anti-interference ability, 1mm detection distance, using for precise

positioning of molds, precision machine tools, and robots.

Figure15: Metal detector


CHAPTER 6 : SOFTWARE REQUIREMENT

6.1 INTRODUCTION TO KEIL µVision3

The µVision3 IDE is a Windows-based software development platform that combines a

robust editor, project manager, and host. µVision3 can integrate all tools which includes

the C compiler, macro assembler, linker/locator, and HEX file generator as well. The

µVision3 IDE offers a number of features and advantages that can help the user swiftly

and also help to successfully develop embedded applications. They are user friendly and

are guaranteed to help the user achieve their design goals.

6.1.1 Features:

1) The µVision3 Simulator is the sole debugger that can completely simulate all of

the on-chip peripherals.

2) Simulation capabilities can be expanded by utilizing the Advanced Simulation

Interface (AGSI).

3) One of the best features of µVision3 is that it incorporates project manager, as

well as an editor, and debugger in a single environment.

4) The µVision3 Device Database can automatically configure the development

tools for the target microcontroller.

5) The µVision3 IDE can integrate extra third-party tools like VCS, CASE, and

FLASH/Device Programming.

6) The ULINK USB-JTAG Adapter assists both the Debugging as well as the Flash

programming with configurable algorithm files.

7) Identical Target Debugger and Simulator User Interface.

8) The Code Coverage feature in the µVision3 Simulator can provide statistical

analysis of the user’s program's execution.

6.1.2 Benefits:

1) We can write as well as test the application code before the production of the

hardware is available.


2) Safety-critical systems can be thoroughly tested and validated. Execution analysis

reports can be viewed and printed for certification requirements.

3) Accelerates application development. While editing, you may configure debugger

features. While debugging, you may make source code modifications.

4) Quickly access development tools and third-party tools. All configuration details

are saved in the µVision3 project.

5) The same tool can be used for debugging and programming. No extra

configuration time required.

6) Shortens your learning curve.

7) Mistakes in tool settings are practically eliminated and tool configuration time is

minimized.

The µVision3 screen provides you with a menu bar for command entry, a tool bar where

you can rapidly select command buttons, and windows for source files, dialog boxes, and

information displays. µVision3 lets you simultaneously open and view multiple source

files.

µVision3 has two operating modes:

1) Build Mode: Allows you to translate all the application files and to generate

executable programs. The features of the Build Mode are described under

Creating Applications.

2) Debug Mode: Provides you with a powerful debugger for testing your

application. The Debug Mode is described in Testing Programs.

In both operating modes you may use the source editor of µVision3 to modify your

source code. The Debug mode adds additional windows and stores an own screen

layout. The following picture shows a typical configuration of µVision3 in the Debug

Mode.

http://www.keil.com/support/man/docs/uv3/uv3_creating_apps.htm

http://www.keil.com/support/man/docs/uv3/uv3_debugging.htm


Figure16: Keil

The tabs of the Project Workspace give you access to:

1) Files and Groups of the project.

2) CPU Registers during debugging.

3) Tool and project specific on-line Books.

4) Text Templates for often used text blocks.

5) Function in the project for quick editor navigation.

6) The tabs of the Output Window provide: Build messages and fast error access;

Debug Command input/output console; Find in Files results with quick file access.

7) The Memory Window gives access to the memory areas in various formats.

8) The Watch & Call Stack Window allows you to review and modify program

variables and displays the current function call tree.

9) The Workspace is used for the file editing, disassembly output, and other debug

information.

10) The Peripheral Dialogs help you to review the status of the on-chip peripherals in

the microcontroller.

http://www.keil.com/support/man/docs/uv3/uv3_ca_create_file_groups.htm

http://www.keil.com/support/man/docs/uv3/uv3_db_dbg_cpuregs.htm

http://www.keil.com/support/man/docs/uv3/uv3_ca_bookstab.htm

http://www.keil.com/support/man/docs/uv3/uv3_dg_template.htm

http://www.keil.com/support/man/docs/uv3/uv3_ca_buildproject.htm

http://www.keil.com/support/man/docs/uv3/uv3_debug_commands.htm

http://www.keil.com/support/man/docs/uv3/uv3_ut_findinfiles.htm

http://www.keil.com/support/man/docs/uv3/uv3_db_dbg_memwin.htm

http://www.keil.com/support/man/docs/uv3/uv3_db_dbg_watchwin.htm


6.1.3 KEIL μVISION 3

Keil Software is an industry standard development tool for the 8051 microcontroller

family. Keil C Compilers, Macro Assemblers, Debuggers, Real-time Kernels, and Single-

board Computers support ALL 8051-compatible derivatives.

6.1.4 µVision3 Overview:

The µVision3 IDE is a Windows-based software development platform that combines a

robust editor, project manager, and makes facility. µVision3 integrates all tools including

the C compiler, macro assembler, linker/locator, and HEX file generator. µVision3 helps

expedite the development process of your embedded applications by providing the

following:

● Full-featured source code editor.

● Device database for configuring the development tool setting.

● Project manager for creating and maintaining your projects.

● Integrated make facility for assembling, compiling, and linking your embedded

applications.

● Dialogs for all development tool settings.

● True integrated source-level Debugger with high-speed CPU and peripheral

simulator.

● Advanced GDI interface for software debugging in the target hardware and for

connection to Keil ULINK.

● Flash programming utility for downloading the application program into Flash

ROM.

● Links to development tools manuals, device datasheets & user’s guides.

6.1.5 Software Development Cycle

When you use the Keil µVision3, the project development cycle is roughly the same as it

is for any other software development project.


● Create a project, select the target chip from the device database, and configure

the tool settings.

● Create source files in C or assembly.

● Build your application with the project manager.

● Correct errors in source files.

● Test the linked application.

The following block diagram illustrates the complete µVision3 software development

cycle. Eachcomponent is described below.

Figure17: Software Development Cycle using Keil µVision3

µVision3 IDE

The µVision3 IDE combines project management, a rich-featured editor with interactive

error correction, option setup, make facility, and on-line help. Use µVision3 to create

your source files and organize them into a project that defines your target application.


µVision3 automatically compiles, assembles, and links your embedded application and

provides a single focal point for your development efforts.

C Compiler & Macro Assembler

Source files are created by the µVision3 IDE and are passed to the C or EC++ Compiler or

Macro Assembler. The compiler and assembler process source files and create

relocatable object files.

Library Manager

The library manager allows you to create an object library from the object files created

by the compiler and assembler. Libraries are specially formatted, ordered program

collections of object modules that may be used by the linker at a later time. When the

linker processes a library, only those object modules in the library that are necessary to

create the program are used.

Linker/Locator

The Linker/Locator creates an executable program file using the object modules

extracted from libraries and those created by the compiler and assembler. An

executable program file (also called absolute object module) contains no relocatable

code or data. All code and data reside at fixed memory locations.

This executable program file may be used:

⮚ To program an Flash ROM or other memory devices,

⮚ With the µVision3 Debugger for simulation and target debugging,

⮚ With an in-circuit emulator for the program testing.

µVision3 Debugger

The µVision3 symbolic, source-level debugger is ideally suited for fast, reliable program

debugging. The debugger includes a high-speed simulator that let you simulate a


microcontroller system including on-chip peripherals and external hardware. The

attributes of the chip you use are automatically configured when you select the device

from the Device Database.

Proload v5.4

Proload is a user friendly software interface for programmer boards from Sunrom

Technologies. Proload gets its name from the "Program Loader" term. It takes in a

compiled HEX file and loads it to the hardware. Any compiler can be used. The source

code can be in Assembly or C, as all of them generate compiled HEX files.

6.2 EMBEDDED C

When designing software for a smaller embedded system with the 8051, it is a very

common place to develop the entire product using assembly code. With many projects,

this is a feasible approach since the amount of code that must be generated is typically

less than 8 kilobytes and is relatively simple in nature. If a hardware engineer is tasked

with designing both the hardware and the software, he or she will frequently be

tempted to write the software in assembly language.

The trouble with projects done with assembly code is that they can be difficult to read

and maintain, especially if they are not well commented. Additionally, the amount of

code reusable from a typical assembly language project is usually very low. Use of a

higher-level language like C can directly address these issues. A program written in C is

easier to read than an assembly program.

Since a C program possesses greater structure, it is easier to understand and maintain.

Because of its modularity, a C program can better lend itself to reuse of code from

project to project. The division of code into functions will force better structure of the

software and lead to functions that can be taken from one project and used in another,

thus reducing overall development time. A high order language such as C allows a

developer to write code, which resembles a human’s thought process more closely than

does the equivalent assembly code. The developer can focus more time on designing the


algorithms of the system rather than having to concentrate on their individual

implementation. This will greatly reduce development time and lower debugging time

since the code is more understandable.

By using a language like C, the programmer does not have to be intimately familiar with

the architecture of the processor. This means that someone new to a given processor

can get a project up and running quicker, since the internals and organization of the

target processor do not have to be learned. Additionally, code developed in C will be

more portable to other systems than code developed in assembly. Many target

processors have C compilers available, which support ANSI C.

All of this is not to say that assembly language does not have its place. In fact, many

embedded systems (particularly real time systems) have a combination of C and

assembly code. For time critical operations, assembly code is frequently the only way to

go. One of the great things about the C language is that it allows you to perform low-

level manipulations of the hardware if need be, yet provides you the functionality and

abstraction of a higher order language.


CHAPTER 7: ADVANTAGES AND APPLICATIONS

This system is mainly implemented for vehicles. Because

nowadays every vehicle has lots of advanced functionality. So

because of this complexity of wire and sensor also increased. If we

are facing any problem in a vehicle this system will help for finding

the fault. So we can solve faults easily without any wiring good

knowledge . We can use this device in railways also or also we can

use it for any kind of transport vehicle.


CHAPTER 8: RESULTS

Figure18: Overview of the model

➢ In the above figure we can see that there are a number of components mounted

on top of the vehicle prototype. Each component plays a significant role in

helping us find the fault in the vehicle.

➢ The ARM controller can also be called as the heart of the model because any

instruction to be given to any of the components, it conveys it.

➢ The vehicle prototype is moved using two DC motors that are connected to the

two wheels at the front.

➢ The above model performs a certain number of operations like, Detecting

vehicles coming nearby, checking the carbon monoxide concentration levels, and

detecting the Brake Failures, etc..


Figure19: Detection of Carbon Monoxide

➢ One of the most important parameters to keep in check is the concentration of

the carbon monoxide gas emitted from the vehicle as it is one of the greenhouse

gases that affects the ecosystem. Keeping it in check not only helps people stay

safe, but also avoids global warming.

➢ The figure 8.2 shows the concentration of the carbon monoxide gas present in

the atmosphere. The concentration of the gas is detected and shown using the

MQ-9 gas sensor.

➢ If the concentration level goes beyond 900, then a warning message will be sent

to the user’s smartphone saying that 80% of carbon monoxide is detected.


Figure20: Detection of Brake Failure

➢ The brake system in a vehicle is by far the most important safety system present

in it. Being able to slow down or stop at a moment's notice will help to avoid an

incident or accident. Improper working of the brakes will not do the job they are

designed to do and will not be as effective when needed.

➢ Most of the time, the brake cables get cut when there might be too much friction

present or extra pressure or force added on the brake pedal.

➢ In our project, we have used a wire that acts like the brake cable. To show the

force or the pressure being added, we add 3.3v.

➢ When we add the voltage by connecting the wire to the 3.3v supply, a message

gets displayed on the lcd saying that a brake failure has been detected.


Figure21: Messages sent to the app

All of the above stated warnings are not only shown on the lcd screen but also are sent

as warnings to the user’s smartphone as shown in Figure 8.4.


CHAPTER 8 : CONCLUSION AND FUTURE SCOPE

8.1 CONCLUSION

In order to understand various complex problems arising in the vehicle the need of

multiple ECUs are needed, which brings the requirement of sophisticated on-board

diagnostic strategies as a result an increase in the amount of computer hardware and

software implementations has been observed. This paper offers improved vehicle stage

method for problem processes strategies, whereby any consolidated bright Entry

Module will be suggested within the vehicle circle structure which is likely to the

problem processes from the finish vehicle inside a sequential run. This precise Entry

Module will thus have the likelihood in order to collect any bunch containing faults

raised by unique ECUs in addition to connect these entities meaningfully to steer the

user in the direction of the real cause of the problem. The work will offer how this kind

of brilliant entry component will seizure, classify it as well to correlate the problem facts

in the spread circle structure, eventually causing real filtering linking main defects from

the vehicle.

8.2 FUTURE SCOPE

As we explained what motivated us to start the project, we said that one of our main

goals was to make the product in such a way that it can be afforded by the common man

and that is definitely possible on a larger scale as well. In the future we can see

advancements of the model as it can be used in vehicles that are smaller than SUVs and

sedans as well if implemented in the right manner. That way, usage of the smart

products can be seen by the common man and as more people tend to buy it, more

research can be done on it and as the world tends to make products more and more

micro in the present day, we can tend to make the circuit of the product much smaller

as well. One day, we can see this product being used in almost all automobiles.


CHAPTER 9 : REFERENCES

1. Muller, K., Steinbach, T., Korf, F. and Schmidt, T.C., 2011, September. A real-time

Ethernet prototype platform for automotive applications.In Consumer.

2. Electronics-Berlin (ICCE-Berlin), 2011 IEEE International Conference on (pp. 221-

225). IEEE.

3. Alderisi, G., Iannizzotto, G. and Bello, L.L., 2012, September. Towards IEEE 802.1

Ethernet AVB for advanced driver assistance systems: A preliminary assessment.

In Emerging Technologies & Factory Automation (ETFA), 2012 IEEE 17th

Conference on (pp. 1-4). IEEE.

4. Application Programming Interface.TTTechComputertechnik AG.

5. Lee, M.Y. and Jin, H.W., 2010, December. User-level network protocol stacks for

automotive infotainment systems. In Embedded and Ubiquitous Computing

(EUC), 2010 IEEE/IFIP 8th International Conference on (pp. 7-14). IEEE.

6. Bruckmeier, R., 2010, June.Ethernet for automotive applications.In Freescale

Technology Forum.

7. Introduction to On-Board Diagnostics II - Roy Cox

8. Onboard Diagnostics and Measurement in the Automotive Industry - Michael

Palocz-Andresen


APPENDIX:

#include <stdio.h>

#include <LPC214x.H> /* LPC214x definitions */

#include <string.h>

#include "lcd.h"

#include "delay.h"

#include "uart.h"

#include "adc.h"

#include "SOFTUART.h"

#define BREAK (1 << 20)

#define METAL (1 << 22)

#define RELAY (1 << 28)

#define IN1 (1 << 16)

#define IN2 (1 << 17)

#define IN3 (1 << 18)

#define IN4 (1 << 19)

unsigned char buff[10],keybuf[6];

#define getCSerial() uart0_getkey()

void START_WORKING(void);

void ACCIDENT_MONITOR(void);


void putSLcd(unsigned char *st);

void ADC_MONITOR(void);

void PRESSURE_MONITOR(void);

void SENSOR_MONITOR(void);

void FORWARD();

int CO=0, NO=0,z=0;

int x=0, y=0;

void lcd_puts(char *p);

unsigned char buf[20],BUFF_H[20],SMS[180];

int count=0;

int F=1;

void lcd_puts(char *p)

{

while(*p) // Point to character

{

lcd_data_write(*p++); // Send character then point to next character

}

}

int main (void)

{

init_lcd();


uart0_init();

uart1_init();

init_adc0();

IO1DIR |= (RELAY);

IO1DIR |= (IN1|IN2|IN3|IN4);

IO1CLR |= (IN1|IN2|IN3|IN4);

IO0CLR |= (RELAY);

IO1DIR &=~(METAL|BREAK);

lcd_clear();

lcd_putstring(LINE1,0,"ONBOARD VEHICLE");

lcd_putstring(LINE2,0,"DIAGNOSTIC..");

delay(20000);

while(1)

{

START_WORKING();

}

}

void START_WORKING(void)

{


FORWARD();

SENSOR_MONITOR();

ACCIDENT_MONITOR();

// CHECK_DATA();

}

void FORWARD()

{

IO1SET|=IN1;

IO1CLR|=IN2;

IO1SET|=IN3;

IO1CLR|=IN4;

}

void STOP()

{

IO1CLR|=IN1;

IO1CLR|=IN2;

IO1CLR|=IN3;

IO1CLR|=IN4;

}

void SENSOR_MONITOR(void)


{

unsigned char buf12[32],buf22[10];

CO = adc_read(ADC0, CHANNEL_1); //PO.28

sprintf(buf12,"CO=%d ",CO);

lcd_command_write(1);

lcd_command_write(0x80);

putSLcd(buf12);

delay(10000);

if(CO>900)

{

lcd_clear();

lcd_putstring(0,0,"80% CO DETECTED");

uart0_puts("$80% CO DETECTED#");

}

else

{

lcd_clear();

lcd_putstring(0,0,"CO IS NORMAL");

delay(10000);

}

if(IO1PIN&METAL)


{

lcd_clear();

lcd_putstring(0,0,"VEHICLE DETECTED");

lcd_putstring(1,0,"SIDE NEAR");

uart0_puts("$VEHICLE DETECTED SIDE NEAR#");

STOP();

delay(5000);

}

if(IO1PIN&BREAK)

{

lcd_clear();

lcd_putstring(0,0,"BREAK FAILURE ");

lcd_putstring(1,0,"DETECTED");

uart0_puts("$BREAK FAILURE DETECTED#");

STOP();

delay(5000);

}

}

void ACCIDENT_MONITOR(void)

{


unsigned char buf12[64];

x = adc_read(ADC0, CHANNEL_2); //PO.25

y = adc_read(ADC0, CHANNEL_3); //PO.4

sprintf(buf12,"x=%d y=%d ", x, y);

lcd_clear();

lcd_putstring(0,0,buf12);

delay(5000);

if((x < 500)||(x > 600))

{

lcd_clear();

lcd_putstring(0,0,"ACCIDENT OCCURS");

uart0_puts("$ACCIDENT OCCURS#");

STOP();

delay(5000);

}

if((y < 500)||(y > 600))

{

lcd_clear();

lcd_putstring(0,0,"ACCIDENT OCCURS");

uart0_puts("$ACCIDENT OCCURS#");

STOP();


delay(5000);

}

}

void putSLcd(unsigned char *st) {

for( ;*st ;lcd_data_write(*st++) );

}

"Designing onboard vehicle diagnosis fault monitoring system ...

Documents

Transcript of "Designing onboard vehicle diagnosis fault monitoring system ...