Vehicle Diagnostic Monitoring System

ARSLAN SHAHID ARSLAN TARIQ FAISAL M. SALEEM

Abstract

Vehicle Diagnostic Monitoring System is a new dimension in the field of Automobiles. It consists of an On-Board Diagnostic System which is a core element of all the modern day vehicles, and a communication system. This system collects the data from the vehicles On-Board Computer; ECU (Electronic Control Unit) and sends it to a remote location through a GSM modem, to monitor the performance and maintain statistics. This system can enhance Vehicles performance by periodic inspections from remote locations. Vehicle Diagnostic Monitoring System comprises of two parts. The first part is the data acquisition circuit and will be connected to the Vehicles OBD-II interface. It will get data from the OBD-II system by using some commands and then will convert the returned hex values to easily understandable form. The converted values will then be displayed on an in-vehicle display unit. Next it will send this data to the second part of the project, the communication circuit through serial interface. This circuit comprises of a GSM modem. The GSM modem will then send this data to a remote location over the air through SMS.

This project will provide advantage to both, the vehicle owner and the vehicle manufacturer. The vehicle owner can inspect his Vehicle from remote locations and can have all the information about his vehicle no matter where he is. The Vehicle Manufacturers can analyze the performance of their vehicles from remote locations and thus can know the pros and cons of different systems being used in the vehicle. They can improve their future vehicle models on the basis of this feedback.

ii

Table of Contents
1 Introduction ...........................................................................................................................................................1 1.1 2 Block Diagram of Vehicle Diagnostic Monitoring System..........................................................................2

Technical Background ..........................................................................................................................................4 2.1 2.1.1 2.1.2 2.1.3 2.2 2.3 2.4 2.5 2.6 2.6.1 2.7 2.7.1 2.7.2 On-Board Diagnostic System .......................................................................................................................4 OBD-I ..................................................................................................................................................4 OBD-1.5 ..............................................................................................................................................4 OBD-II.................................................................................................................................................4 The OBD-II ..................................................................................................................................................4 OBD-II Protocols .........................................................................................................................................5 Identifying the OBD-II Protocol ..................................................................................................................6 OBD-II Codes [5].........................................................................................................................................6 ISO 9141-2 ...................................................................................................................................................6 Protocol Initialization [16] .................................................................................................................7 Controller Area Network (CAN) ..................................................................................................................7 Working of CAN [17] ..........................................................................................................................8 Types of Data Frame [17] ...................................................................................................................9

Table 2.2 Extended CAN ........................................................................................................................................ 10 2.8 2.9 2.9.1 2.9.2 2.10 GSM ........................................................................................................................................................... 10 The SIM-300 DZ GSM Module ................................................................................................................. 12 Key Features of SIM-300 DZ ............................................................................................................ 13 SIM-300 DZ Pin Out ......................................................................................................................... 14 AT Commands ........................................................................................................................................... 16 Basic AT Commands: ........................................................................................................................ 16 Extended AT Commands: .................................................................................................................. 16

2.10.1 2.10.2 2.11

PIC Microcontrollers .................................................................................................................................. 16 PIC18F4580 ...................................................................................................................................... 17

2.11.1 2.12 2.13

MCP2551 ................................................................................................................................................... 18 ELM327 [10].............................................................................................................................................. 18 ELM327 Functionality [10] .............................................................................................................. 19

2.13.1

iii

2.14 2.15 2.16 3

MAX232 .................................................................................................................................................... 20 Liquid Crystal Display ............................................................................................................................... 22 PIDs (Parameter IDs) [16] ......................................................................................................................... 24

Design & Implementation ................................................................................................................................... 25 3.1 3.1.1 3.1.2 3.2 3.3 Technical Block Diagram of Vehicle Diagnostic Monitoring System ....................................................... 25 The Data Acquisition Circuit............................................................................................................. 26 Processing, Display and Communication Circuit ............................................................................. 28 Flow Chart of the Microprocessor Code .................................................................................................... 30 Server Side Software .................................................................................................................................. 32

Results................................................................................................................................................................. 34 4.1 4.1.1 4.1.2 4.1.3 4.1.4 4.2 Results ........................................................................................................................................................ 34 Diagnostic Trouble Codes ................................................................................................................. 34 Real Time Data .................................................................................................................................. 34 Freeze Frame Data ........................................................................................................................... 34 Clearing Diagnostic Trouble Code ................................................................................................... 34 Server Side Database.................................................................................................................................. 38

Conclusion and Future Enhancements ................................................................................................................ 39 5.1 5.2 Conclusion ................................................................................................................................................. 39 Future Enhancements ................................................................................................................................. 40

References: .................................................................................................................................................................. 41 Appendix A: C Source Code ...................................................................................... Error! Bookmark not defined. Appendix B: PCB Design ........................................................................................... Error! Bookmark not defined. Appendix C: List of Components ............................................................................... Error! Bookmark not defined. Appendix D: Project Timeline .................................................................................... Error! Bookmark not defined. Appendix E: Data Sheets ............................................................................................ Error! Bookmark not defined.

iv

Table of Figures
FIGURE 1-1 BLOCK DIAGRAM OF THE PROJECT....................................................................................... 2 FIGURE 2-1 OBD-II CONNECTOR PIN-OUT ................................................................................................. 4 FIGURE 2-2 ISO-9141-2 BUS SYSTEM .......................................................................................................... 7 FIGURE 2-3 GSM SYSTEM ARCHITECTURE ............................................................................................. 11 FIGURE 2-4 SIM-300 DZ .............................................................................................................................. 13 FIGURE 2-5 SENDING SMS USING SIM-300 DZ ......................................................................................... 15 FIGURE 2-6 PIC18F4580 .............................................................................................................................. 17 FIGURE 2-7 FUNCTIONALITY OF MCP 2551 ............................................................................................. 18 FIGURE 2-8 ELM327 BLOCK DIAGRAM .................................................................................................... 19 FIGURE 2-9 MAX232 INTERFACE WITH MICROCONTROLLER ............................................................... 21 FIGURE 2-10 INTERFACING A 16X2 LCD WITH PIC18F4580 .................................................................... 22 FIGURE 2-11 DISPLAYING DATA ON LCD USING MICROCONTROLLER ............................................... 23 FIGURE 3-1 TECHNICAL BLOCK DIAGRAM OF THE PROJECT ............................................................... 25 FIGURE 3-2 BLOCK DIAGRAM OF THE DATA ACQUISITION CIRCUIT .................................................. 26 FIGURE 3-3 SCHEMATIC DIAGRAM OF THE DATA ACQUISITION CIRCUIT ......................................... 27 FIGURE 3-4 BLOCK DIAGRAM OF THE PROCESSING DISPLAY AND COMMUNICATION CIRCUIT ..... 28 FIGURE 3-5 THE PROCESSING DISPLAY AND COMMUNICATION CIRCUIT .......................................... 29 FIGURE 3-6 FLOW CHART OF THE MICROCONTROLLER CODE ............................................................ 31 FIGURE 3-7 BLOCK DIAGRAM OF THE SERVER SIDE SOFTWARE APPLICATION ................................ 32 FIGURE 3-8 FLOW CHART OF THE SERVER SIDE APPLICATION ........................................................... 33 FIGURE 4-1 TESTING OF THE DATA ACQUISITION CIRCUIT ................................................................. 35 FIGURE 4-2 TEST RESULTS OF THE DATA ACQUISITION CIRCUIT ....................................................... 36 FIGURE 4-3 TEST RESULTS OF THE DATA ACQUISITION CIRCUIT WITH HYPER TERMINAL............. 37 FIGURE 4-4 MYSQL DATABASE ................................................................................................................ 38 FIGURE 1 APPENDIX B: PCB DESIGN OF CONTROLLER CIRCUIT (TOP VIEW) ..................................... 48 FIGURE 2 APPENDIX B: PCB DESIGN OF CONTROLLER CIRCUIT (BOTTOM VIEW) ............................. 49

List of Tables
TABLE 2-1 STANDARD CAN FRAME .......................................................................................................... 9 TABLE 2-2 EXTENDED CAN FRAME ......................................................................................................... 10 TABLE 2-3 GSM AIR INTERFACE SPECIFICATIONS SUMMERY ............................................................. 12 TABLE 2-4 SIM-300 KEY CHARACTERISTICS ........................................................................................... 13 TABLE 2-5 SIM-300 DZ PIN OUT ................................................................................................................ 14 TABLE 2-6 PROTOCOLS SUPPORTED BY ELM327 .................................................................................. 19 TABLE 2-7 PROTOCOLS SUPPORTED BY ELM327 .................................................................................. 20 TABLE 2-8 DB9 CONNECTOR PIN-OUT ..................................................................................................... 21 TABLE 2-9 OBD-II MODES, CORRESPONDING PIDS AND DATA EVALUATION .................................... 24 TABLE 1 APPENDIX C. LIST OF COMPONENTS FOR FIG. 3.3 .................................................................. 50 TABLE 2 APPENDIX C. LIST OF COMPONENTS FOR FIG. 3.5 .................................................................. 51

vi

1 Introduction
Modern day vehicles now come with an On-Board Diagnostic System simply called OBD. This refers to a Vehicles self diagnosis and reporting capability. This allows the vehicle owner to diagnose a problem in the vehicle as soon as it occurs. Thus it has simplified the process of finding malfunction areas in a vehicle [1]. Early versions of OBD system would only illuminate a Malfunction Indicator Light (MIL), in case of detection of a problem but would not describe the exact location of the problem. Modern OBD systems have an advantage of diagnosing the exact nature of the problem, if it occurs, as well as providing the real time data of the vehicle, e.g. Speed, RPM, Coolant temperature etc. Modern OBD systems comprises of a number of sensors in a vehicle. These sensors include, temperature sensors, speed sensors etc. Whenever these sensors find some trouble in any subsystem of the vehicle, they immediately report to the Engine Control Unit (ECU). ECU then illuminates the Malfunction Indicator Light (MIL) to inform the vehicle owner. OBD system is made compulsory for all vehicles producing in USA after 1996. [4] Latest versions of the OBD system use a standardized interface to connect to specially designed hand held devices and scan tools to read data from vehicles. The difficulty with OBD system is that, whenever a problem occurs in a vehicle, the owner has to take the vehicle to the some technician. The technician connects a specifically designed hand held device to extract data from the vehicle. Thus it takes a lot of time to know the exact problem in the Vehicle. VEHICLE DIAGNOSTIC MONITORING SYSTEM comprises of a circuit which is capable of reading data from a vehicles OBD interface and sending it to a remote location using a GSM modem [16]. This will allow to monitor Vehicles health from remote locations thus reducing the cost of specially designed hand held devices and scan tools and particularly it will immediately inform the owner about the vehicle malfunction. Moreover, it will allow the vehicle manufacturers to check their newly launched models periodically remotely, so that they can improve their up-coming models on the basis of their own reliable feedback. The Block Diagram of the Vehicle Diagnostic Monitoring System is as below:

1.1 Block Diagram of Vehicle Diagnostic Monitoring System

OBD-II System

Data Acquisition Circuit

Sensor 1

Sensor 2 Processing, Display and Communication Circuit

Sensor 3

Sensor 4

Sensor N

Remote User

Figure 1-1 Block Diagram of the Project

The bigger block at the left side of the figure is the Vehicles OBD system. It comprises of various sensors and is directly connected to the Engine Control Unit of a Vehicle. Vehicle Diagnostic Monitoring System comprises of the 2 blocks shown at the right side of the Block Diagram. The Upper is the Data Acquisition System. It will extract data from the Vehicles OBD-II interface and convert it to RS232 serial interface for further processing. The lower block is the Data Processing, Display and Communication Circuit. It is the heart of the project. It comprises of PIC18F4580 microcontroller. The Microcontroller will get data from Vehicle through the Data Acquisition Circuit and will then process it and display it on LCD. Also at the same time, it will forward that data to SIM-300 DZ modem for sending it to remote locations. More specifically, the Microcontroller will send a set of Commands to the Data Acquisition Circuit. The circuit will return back some hex values. The Microcontroller will convert these hex values and will display them on LCD. Also it will send this data to GSM modem, which will send it to remote locations. Chapter 2 in this document will describe the technical background of the VEHICLE DIAGNOSTIC MONITORING SYSTEM explaining the complete Background of OBD systems, GSM communication systems and the techniques being used in the project. Chapter 3 will describe the design and implementation procedure of the whole project. All the circuits designed and implemented are discussed in detail in chapter 3. Chapter 4 will demonstrate the results and outcomes of the project while chapter 5 will conclude the report with purposed future enhancements, which can be made in this project in the future for innovations.

2 Technical Background

2.1 On-Board Diagnostic System

The On-Board Diagnostic System is compulsory in all USA made cars after 1996 [4]. In developing countries like Pakistan, this system is not present in all cars due to the price factor. Usually cars in Pakistan are having OBD-I instead of the latest, OBD-II. The 3 generations of this system are described as follows. On-Board Diagnostic System is a sub system of the ECU. Its subparts are different types of sensors which collect respective data from different parts of the vehicle. This data is taken to the Vehicles Engine Control Unit, the ECU, which then illuminates the Malfunction Indicator Light (MIL), if an error code is generated. The reason of introducing OBD system in vehicles is to make them safer and make troubleshooting easy. Whenever some problem occurs in some subsystem of the vehicle, the driver is immediately informed by the OBD system through MIL. The technician can easily get to the problem and remove it by using this system.

2.1.1 OBD-I
The first generation of On-Board Diagnostic System was the OBD-I. This system was designed for annual emission testing checks in California, USA but it couldnt be successful because it could not become a standard.

2.1.2 OBD-1.5
After OBD-I, OBD-1.5 was launched in 1994 by General Motors but they didnt called it a new generation of OBD-I, yet it was a modified version of the OBD-I. It used post catalyst oxygen sensors to measure the emission. [4]

2.1.3 OBD-II
OBD-II is the latest among all and has become a standard now. OBD-II standard defines the Interface type, pin-out and electrical signaling protocols used over it and the messaging format. The interface contains a pin for power supply so that the diagnostic devices and scan tools can get power from the vehicle itself.

2.2 The OBD-II

The OBD-II standard connector is a 16-pin (2x8) female J1962 connector. It is required to be within 2 feet of the steering wheel. Its layout and pin configuration is given below.

Fig. 2.1.OBD-II Connector Pin-Out [4]

Pin 2 - J1850 Bus+ Pin 4 - Chassis Ground Pin 5 - Signal Ground Pin 6 - CAN High (J-2284) Pin 7 - ISO 9141-2 K Line Pin 10 - J1850 Bus Pin 14 - CAN Low (J-2284) Pin 15 - ISO 9141-2 L Line Pin 16 - Battery Power [4] Pin 1, 3 and Pin 11 are Vehicle manufacturer specific, while Pin 8,9,12 and Pin 13 are left for further enhancements [4].

2.3 OBD-II Protocols

There are five signaling protocols which are being used with OBD-II. Every vehicle having OBD-II system uses one of these five protocols. The protocols are as under: 1. SAE J1850 PWM (Pulse Width Modulation) - 41.6 kbps, standard of the Ford Motor Company. 2. SAE J1850 VPW (Variable Pulse Width) - 10.4 kbps, standard of General Motors. 3. ISO 9141-2 it has an asynchronous serial data rate of 10.4 kbps. It is somewhat similar to RS232 protocol. 4. ISO 14230 KWP2000 (Keyword Protocol 2000).

5. ISO 15765 CAN (250 kbps or 500 kbps).

2.4 Identifying the OBD-II Protocol

The OBD-II protocol being used in a vehicle can be found by examining the OBD-II connector as follows: J1850 PWM --The connector should have metallic contacts in pins 2, 4, 5, 10, and 16. J1850 VPW --The connector should have metallic contacts in pins 2, 4, 5, and 16, but not 10. ISO 9141-2 -- The connector should have metallic contacts in pins 4, 5, 7, 15 and 16. ISO 9141-2/KWP2000 --The connector should have metallic contacts in pins 4, 5, 7, 15, and 16. CAN --The connector should have metallic contacts in pins 4, 5, 6, 14 and 16. [4]

2.5 OBD-II Codes [5]

The OBD-II codes received from a vehicle are of the following type: P1234 Every digit in these codes has a separate meaning described as below [2]. The first character is the System Code. It can be P, B, C or U. P stands for Powertrain B stands for Body C stands for Chassis And U is for undefined error. The second digit is the code type. It may be 0 or 1. If it is 0 it stands for a generic code. If it is 1 it stands for a Manufacturer Specific Code. The third digit tells the sub-system that generated the code. For example in the above case third digit is 2. This means that this code is generated by the Fuel/Air Injection Circuit. The fourth and fifth digits informs about the particular problem occurred in the sub-system told by the third digit. [3]

2.6 ISO 9141-2

This protocol runs with the help of K line and L line in the OBD connector. It is the first protocol used in vehicles which communicates serially using K and L line. K line is bi-directional, used for communication in the car. L line is just used for initialization. K line is full duplex means it can send and receive commands at a same time but L line is half duplex means it can simply send data which is used for initialization or waking the system. K line can be use for initializing the system as well which then neglects the use of L line. OBDs 7th pin is composed of K line and 15th pin is composed of L line. [16]

Fig 2.2 ISO-9141-2 Bus System [16]

It can transfer data up to 10,400 bits per second. Although this data rate is very slow but it was a good start to get data from the car using serial communication. This protocol runs on high and low level logic. 0 is represented by a low logic means zero volts and 1 are represented by high logic means 12 volts. Only 2 microseconds delay occurs in changing states i.e. from high logic to low logic or vice versa. The message packet of this protocol is composed of header byte, some data bytes and error checking byte which is usually called as checksum byte. Message packet of this data cannot be greater than 12 bytes.

2.6.1 Protocol Initialization [16]

Handshaking process initializes this protocol. Certain steps have to follow to initialize this protocol. Following are some steps used to establish communication using ISO 9141-2 protocol. Find pin 7 in the OBD connector which is K line which is used for serial communication. Set baud rate to 5 so that 5 bits per second can be transmitted. Send 0x33 hex value on K line which takes it to OBD port for initializing the communication. Once 0x33 hex values is transmitted, set the baud rate to 10.4 Kbps means 10400 bits per seconds can be transmitted. OBD port will return the 0x55 hex value on the K line and after this hex value OBD port transmits 0x08 hex value two times on the K line. Once 0x08 is received on the K line, take its compliment and send it back to the OBD port which then returns 0xCC hex value which is the compliment of 0x33.

Above steps initialize the protocol. Once the protocol is initialized, request can be send to the OBD port for receiving data from the vehicle. This is a slow protocol to communicate with the vehicle and error checking is also not available in it but its structure make it reliable so user should wait after sending some command for data from the vehicle.

2.7 Controller Area Network (CAN)

Controller Area Network (CAN) is a vehicle wiring bus standard. It is a serial bus protocol. It was introduced by Robert Bosch GmbH in 1986 [6]. Prior to CAN there was a very complex wiring system in 7

cars. The CAN bus has reduced this complexity in wiring and this in return has reduced the vehicles weight a lot. CAN has now become a vehicle industry standard, because of its reliability and easy troubleshooting. It gives data rates up to 1 Mbps. CAN have two protocols, CAN 2.0A and CAN 2.0B. CAN 2.0A uses 11 bits identifier with its frames while CAN2.0B uses 29 bits of identifier. The messages are sent on priority basis. The frame with highest priority is sent first while the others wait for their turn. The frames with the lowest integer value have the highest priority. Every frame sent back acknowledgement after reaching the destination. The CAN protocol uses only two wires for communication. These are named as CAN-High and CANLow (CANH & CANL).

2.7.1 Working of CAN [17]

Two types of CAN 2.0A controllers are available. One type of controller sends CAN2.0A messages and receives CAN2.0A message but whenever it receives CAN 2.0B message, it creates an error. Another CAN2.0A controller which is also known as passive CAN2.0B controller sends and receives CAN2.0A messages and if CAN2.0B message come it informs about it and then delete/discard it. CAN 2.0B controller can always identify the CAN 2.0A message. Sending and receiving messages or data is not based on addressing scheme. Each message which contains specific identifier in it, is broadcast means send to all nodes present in the vehicle. The specific node which acknowledge that identifier, accept that message and start processing and the other nodes discard that message. There is a chance which can cause messages to collide means two messages sent at a same time. So CAN identifiers also stop the collision of messages as it sets priority of messages. Lower value of CAN message identifier transmits first shows higher priority and higher value of CAN message identifier transmits later and shows lower priority. [17] Types of Messages/Frames Four types of messages/frames can be transmitted on CAN bus. Each message has different function and used for different purposes.

2.7.1.1.1 Data Frame/Message

Data message has following fields: Arbitration field The Cyclic Redundancy Check field The acknowledgement field The data field

Arbitration field It is used for identifying the priority of the message/frame. When two messages transmit at the same time, arbitration field prevents collision among them on the basis of message identifier. It consists of 11 bit identifier and RTR bit in CAN2.0A and has 29 bit identifier and RTR in CAN2.0B. 8

Cyclic Redundancy Check Field It is used for identifying error which occurs in frames during transmission. It contains 2 bytes of data message. Acknowledgement Field It is used at the end of the message/frame. It acknowledges the reception of message. If CAN controller receives message accurately, it sends a dominant acknowledgement bit which replaces the recessive acknowledgement bit. It is then checked by transmitter that acknowledgement is dominant or recessive. If acknowledgement bit is dominant, frame is not retransmitted but if acknowledgement bit is recessive, frame is retransmitted. Data Field It can contain maximum of 8 byte data which includes PID or mode which is used to request specific data.

2.7.1.1.2 The Error Frame/Message

It is transmitted when any error in frame is identified by node. This message causes all nodes to broadcast the message to transmitter which automatically request the original transmitter to retransmit the message.

2.7.1.1.3 The Remote Frame/Message

It is used to extract any data from other node. It is same as data message. The only difference is that it does not contain any data.

2.7.1.1.4 The Overload Frame/Message

When transmitter sends commands very quickly to the node, it become busy and transmits the overload frame.

2.7.2 Types of Data Frame [17]

2.7.2.1.1 Standard CAN
S O F 11-bit Identifier R T R I D E r0 DLC 0 to 8 bytes Data CRC ACK E O F I F S

Table 2.1. Standard CAN Frame [17]

SOF (Start Of Frame) It shows start of frame and it is used to synchronize the message with CAN bus. Identifier It is used to priorities frames on CAN bus. Lower numerical value frame identifier will get higher priority and higher numeric value frame identifier will get lower priority. RTR (Remote Transmission Request) This bit is dominant when we want to extract data from other node. 9

IDE (Identifier Extension) If this bit is dominant then it means that 11 bit identifier is used i.e. Standard CAN message and extension is disabled. r0 This bit is reserved for future use. DLC (Data Length Code) It contains the number of bytes of information that we want to transmit. Data should not be more than 8 bytes. CRC (Cyclic Redundancy Check) These two bytes are used for error detection. ACK (ACKNOWLEDGEMENT) It replace recessive bit with dominant bit whenever it receives a correct message. It tells that correct message was transmitted or not. EOF (End Of Frame) It contains 7 bits field which represents end of message. IFS (Inter Frame Space) It contain 7 bit field which tells that in how much time microcontroller will take to shift accurately received message to its correct place. 2.7.2.1.2 S O F

Extended CAN
S R R I D E 16 bit Identifier R T R r1 r0 DLC 0-8 Bytes Data CRC ACK E O F I F S

11-bit Identifier

Table 2.2 Extended CAN Frame [17]

SRR (Substitute Remote Request) Its function is same as RTR. It just replaces it because it is extended CAN frame. IDE (Identifier Extension) If it is in recessive state than it shows that there are more than 11 bits identifier and more bits are still coming. r1 This bit is reserved for future use.

2.8 GSM
GSM stands for Global system for Mobile Communication. It is a second generation (2G) full duplex digital telephony standard developed by European Telecommunications Standard Institute (ETSI) [7]. This is the standard system being employed in the whole world today for Mobile communication. The basic architecture of a GSM system is as under: 10

BTS

BTS

BSC

HLR

VLR

AUC

MS

BTS

BTS

PSTN

BTS

BSC

MSC

ISDN

BTS

Data Network

OMC Operation Support subsystems `` MS Base station Subsystem Network Switching Subsystem Public Networks

Fig 2.3 GSM System Architecture [11]

The GSM call setup comprises of three steps. First a wireless connection is established between the Mobile Base Station Subsystem and the Network Switching Subsystem. The Base Station Subsystem comprises of Base Transceiver Subsystems (BTS) and the Base Station Controller (BSC). Next is the Network Switching Subsystem. Mobile Switching Center is the heart of the Network Switching Subsystem. The MSC checks the status of the Mobile user through its Home Location Register (HLR), Visitor Location Register (VLR) and the Authentication Center (AUC). After Authentication, the connectivity is forwarded to the Public Networks. Public Networks may include Public Switched Telephone Network (PSTN), Integrated Services Digital Network (ISDN) and the Data Networks.

11

Some worth mentioning features of GSM Specifications are summarized as below.

Parameter Reverse Channel Frequency Forward Channel Frequency Tx/Rx Frequency Spacing Tx/Rx Time Slot Spacing Modulation Data rate Frame Period Users per Frame Time Slot Period Bit Period Modulation Interleaving (max. delay) Voice Coder Bit Rate

Specifications 890-915 MHz 935-960 MHz 45 MHZ 3 Time Slots 270.83333 kbps 4.615 ms 8 576.9 s 3.692 s 0.3 GMSK 40 ms 13.4 kbps

Table 2.3. GSM Air Interface Specifications Summery [8]

2.9 The SIM-300 DZ GSM Module

SIM-300 is a GSM/GPRS modem that works on both 900 MHz and 1800MHz frequencies. It is a very small and light weight module and can be used for a vast variety of Applications. It is a slave device with 48 pins and can be configured/controlled with its AT (Attention) Commands to send and receive SMS, send and receive calls and GPRS connectivity.

12

Fig 2.4 SIM-300 DZ [9]

2.9.1 Key Features of SIM-300 DZ

The key features of SIM-300 module are as under: Feature Power Supply Frequency Bands Transmit power 1W at DCS 1800 and PCS 1900 GPRS Multislot Class-10 (default) GPRS Connectivity GPRS Multislot Class -8 (Optional) GPRS Mobile Station Class-B GPRS data downlink transfer: max. 85.6 kbps Data GPRS GPRS data uplink transfer: max. 42.8 kbps Text and PDU Mode SMS SMS Storage: SIM Card SIM Interface External Antenna Physical Characteristics 13 Support SIM card 1.8V and 3 V Connected via 50 Ohm antenna connector or antenna pad Size: 330.15 x 330.15 x 30.3 mm Implementation 3.4 V to 4.5 V GSM 900, DCS 1800, PCS 1900 2W at EGSM900

Weight: 8g Firmware Upgrade Firmware Upgrade over Serial Interface

Table 2.4 SIM-300 key characteristics [9]

2.9.2 SIM-300 DZ Pin Out

The SIM-300 DZ Pin Out is as follows. Pin no. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Name DBG_RXD DBG_TXD RXD TXD STATUS SIM_DATA SIM_CLK SIM_RST SIM_VDD KBR0 R1 PWRKEY DISP_CLK DISP_DATA VRTC DISP_D/C GND MIC2P MIC2N MIC1N MIC1P Pin no. 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 Name SPK2N SPK2P TEMP_BAT VCHG ADC0 GND GND GND ANTENNA GND GND GND GND VBAT VBAT GP01 NETLIGHT DCD DTR RTS CTS

14

22 23 24

AGND SPK1P SPK1N

46 47 48

DISP_CS NC GND

Table 2.5 SIM-300 DZ Pin out [9]

Pin 3 and Pin 4 of SIM300DZ are RxD and TxD respectively. They are connected with the Microcontroller or Hyper Terminal to send AT Commands to the modem. These AT Commands control the full functionality of the modem. The flow chart for the processes explaining the sending of SMS by using SIM-300DZ is given below. [13]

START

Initializing the Serial Connection

Select SMS Message Format

Setting Preferred SMS Storage

Send SMS Message

Ctrl + z

END

Fig. 2.5. Sending SMS using SIM-300 DZ

15

First a serial connection is initialized with the Sim-300 DZ with a specific Baud rate. After the establishment of the serial connection, SMS Message format is selected. There are two modes which can be selected. These are the Text Mode and the PDU (Protocol Description Unit) Mode. After the mode selection, memory is selected for SMS storage and then the recipient number is entered at the Send Message stage along with the string which is to be sent in the message. As soon as this process is complete Ctrl + z is pressed to send the message if using Hyper terminal. An alternative to Ctrl + z, if using microcontroller, is to send a string 0x1A to the SIM -300 DZ. Its binary value is same as that of Ctrl + z. These all steps require AT Commands to send specific data to the SIM-300 DZ modem. These AT Commands are discussed in the next section.

2.10 AT Commands
AT stands for Attention Commands. AT Command set is an instruction set for devices like SIM-300DZ Modem. SIM-300DZ can be configured and used using these commands. AT Commands are categorized into Basic and Extended commands. These are as follows:

2.10.1 Basic AT Commands:

Basic Commands do not start with + sign e.g. ATD: For Dialing a Number ATE: For setting Echo. ATA: For answering a call. [14]

2.10.2 Extended AT Commands:

Extended Commands start with a + sign e.g. AT+CMGS: Send SMS AT+CMGF: Select Message Format AT+CPMS: Preferred SMS Storage AT+CMGD: Delete SMS

2.11 PIC Microcontrollers

PIC stands for Peripheral Interface Controller. PIC Microcontrollers are based on Harvard Architecture and they are being made by Microchip Technology, USA. These microcontrollers are vastly used around the world because they have a very simple and short instruction set. They have only 35 instructions set. The Microcontroller used in this project is PIC18F4580. The main features of this Microcontroller are described as under.

16

2.11.1 PIC18F4580
The PIC18F4580 is a new arrival in the PIC18 series microcontrollers. The built-in CAN module of the PIC18F4580 is the main reason of its use in this project.

Fig. 2.6 PIC18F4580

The CAN module in the PIC18F4580 is a serial interface having CANTx and CANRx pins. It can be used for communicating with another PIC on CAN. It supports CAN1.2, CAN 2.0A and CAN 2.0B. CAN module in PIC18F4580 supports all five frame types of the CAN protocol i.e. 1. Standard data Frame 2. Extended Data Frame 3. Remote Frame 4. Error Frame 5. Overload Frame Reception [15] The CAN module can be used by initializing through the following steps in the coding. CAN set flags CAN Initialize CAN set operation mode CAN set mask 17

CAN set filter CAN read/write

2.12 MCP2551
MCP 2551 is a CAN bus transceiver from Microchip. It is used as a transmitter and receiver between the Microcontroller and the CAN bus. MCP2551 basically converts the 12V of CAN bus to 5V for the Microcontroller and vice versa. The functionality of MCP2551 can be understood through the following diagram.

CAN Tx of Microcontroller

CANH

MCP2551
CAN Rx of Microcontroller CANL

Fig 2.7 Functionality of MCP2551

2.13 ELM327 [10]

ELM 327 is a 28 pin IC from ELM Electronics. The function of this IC is to convert the data from OBDII to RS-232 protocol. The RS-232 is a 9-pin serial protocol and is in use in a vast variety of applications. The key features of the ELM 327 are as under: It supports 9 OBD-II protocols. It automatically searches for the protocol being used in a particular vehicle. It can be configured with AT Commands.

The Block Diagram of the ELM 327 functionality is as under:

18

OBD-II Interface J-1962

Command and Protocol Interpreter

RS-232 Interface

Fig. 2.8 ELM327 Block Diagram [10]

2.13.1 ELM327 Functionality [10]

When ELM327 circuit is connected with an OBD-II interface of the vehicle and Hyper Terminal, it shows the version of ELM as soon as the connection is established. This shows that the Circuit is correctly connected and responding. Also a sequence of four blinking LEDs confirms this. After the start of successful communication, one can send a number of Commands to read various values from the vehicle. For example: >SP h This command is used to set the protocol from one of the nine protocols supported by ELM327. h is the number of the protocol. The complete range of protocols is as under: Value of h 0 1 2 3 4 5 6 7 8 9 Automatic SAE-J1850 PWM (41.6 kbps) SAE-J1850 VPW (10.4 kbps) ISO-9141-2 (5 baud init, 10.4 kbps) ISO-14230-4 KWP (5 baud init, 10.4 kbps) ISO-14230-4 KWP (fast init, 10.4 kbps) ISO-15765-4 CAN (11 bit ID, 500 kbps) ISO-15765-4 CAN (29 bit ID, 500 kbps) ISO-15765-4 CAN (11 bit ID, 250 kbps) ISO-15765-4 CAN (29 bit ID, 250 kbps) Protocol Selection

Table 2.6. Protocols Supported by ELM327 [10]

19

After the Protocol Selection, next comes the mode selection. There are nine modes which are available and data can be extracted from them using PIDs, after the mode is selected. These modes are as under:

Mode no. 01 02 03 04 05 06 07 08 09

Mode Show current Data Show Freeze Frame Data Show Diagnostic Trouble Codes Clear Trouble Codes and Stored Values Test Results, Oxygen Sensors Test Results, Non-Continuously Monitored Show Pending Trouble Codes Special Control Mode Request Vehicle Information

Table 2.7. Protocols Supported by ELM327 [10]

After setting the mode, various commands can be sent to the ELM327 to view different values. For example, ATRV is used to display the Voltage Out from the OBD-II Interface; ATDP is used to display the current protocol and so on.

2.14 MAX232
MAX232 is an Integrated Circuit from MAXIM. It converts the RS232 voltage levels to TTL Compatible logic levels. This conversion is necessary if RS232 serial devices are to be connected with TTL compatible devices i.e. Microcontrollers or PCs (Hyper Terminals) etc.

20

Fig 2.9 MAX232 Interface with Microcontroller [12]

The capacitors used are of 10F each. They are used in the circuit to reduce noise in the circuit. The serial connector used is DB9 Female Connector. Its pin configuration is as follows.

Pin no. 1 2 3 4 5 6 7 8 9

Function Data Carrier Detect Receive Data Transmit Data Data Terminal Ready Signal Ground Data Set Ready Request to Send Clear to Send Ring Indicator

Table 2.8 DB9 Connector Pin-Out [18]

21

2.15 Liquid Crystal Display

Liquid Crystal Display (LCD) is a visual display device used to display different types of data e.g. Characters, graphical etc. The LCD found suitable for this project is a character LCD which shows 16 characters per line in 2 lines. This is simply called a 16x2 LCD.

Fig. 2.10. Interfacing a 16x2 LCD with PIC18F4580

This LCD can be easily interfaced with any port of the microcontroller. In this diagram, the LCD is connected to PORTD of the PIC18F4580 microcontroller. The Data Pins are D0 to D7 on the LCD. The potentiometer is used to adjust the brightness of the LCD display. The steps to display some data on the LCD are shown below.

22

START

Initialize PORT X of the Microcontroller

Initialize LCD connected at PORT X of the MCU

Clear Display

Turn Cursor Off

Send data to LCD as a string

STOP

Fig. 2.11 Displaying Data on LCD using Microcontroller

First the port of the Microcontroller is Initialized which is connected with the LCD. After this the LCD is initialized. Then the screen is cleared to remove all garbage values and the curser is set to off. After that the data is sent to the LCD as a string to display it.

23

2.16 PIDs (Parameter IDs) [16]

Parameters Identifiers are used to access the real time data as well as freeze frame data which includes Diagnostic Trouble Codes saved in the vehicles microcontroller from the vehicle OBD port. If we add PID after Mode 1 then it will extract the current data running on vehicle which includes rpm, speed, coolant temperature etc. If we add PID after Mode 2 then it will extract the Diagnostic Trouble Codes saved in the vehicle Following is a Table which contains the Mode and the corresponding PID to extract the data. Type of data which is extracted from the vehicle in the result of given Mode and PID is also given in table.

Mode (hex) 01

PID (hex) 04

Data Bytes Returned 1

Description Calculated Engine Load value Engine Coolant Temperature Vehicle Speed Intake Temperature Fuel Pressure Throttle Position

Min. Value

Max. Value

Units

Formula

100

A*100/255

01 01 01 01 01

05 0D 0F 0A 11

1 1 1 1 1

-40 0 -40 0 0

215 255 215 765 100

C Km/h C kPa %

A-40 A A-40 A*3 A*100/255

Table 2.9. OBD-II Modes, Corresponding PIDs and Data Evaluation [16]

24

3 Design & Implementation

3.1 Technical Block Diagram of Vehicle Diagnostic Monitoring System

MCP2551 CAN LCD

CAN Rx

J1850 PWM Microcontroller MAX232 Serial Interface MAX232 ELM327 J1850 VPW ISO9141-2 KWP-2000

To Other CAN Devices

CAN Tx

GSM

Processing, Display and Communication Circuit

Data Acquisition Circuit

Fig 3.1 Technical Block Diagram of the Project

The On Board Diagnostic System, OBD-II, is a core element of the Engine Control Unit (ECU) of modern day vehicles. It comprises of different sensors which gather data from different sub-systems of the car and take this data to OBD-II interface. Vehicle Diagnostic Monitoring System comprises of the 2 parts shown in this Block Diagram. The Right part is the Data Acquisition System. It will extract data from the Vehicles OBD-II interface and convert it to RS232 serial interface The left part is the Data Processing, Display and Communication Circuit. It is the heart of the project. It comprises of PIC18F4580 microcontroller. The Microcontroller will get data from Vehicle through the Data Acquisition Circuit and will then process it and display it on LCD. Also at the same time, it will forward that data to SIM-300 DZ modem for sending it to remote locations. 25

The PIC18F4580 can also be connected to other CAN devices for further enhancements in the project.

3.1.1 The Data Acquisition Circuit

The core element of the Data Acquisition Circuit is ELM327. The Block Diagram of the data acquisition circuit is shown below.

MCP2551 CAN

J1850 PWM Serial Interface To Microcontroller MAX232 ELM327 J1850 VPW ISO9141-2 KWP-2000

Fig. 3.2 Block Diagram of the Data Acquisition Circuit

The ELM327 circuit will be connected to the OBD-II interface of the car. It will use MCP2551 to connect with the vehicles which have CAN bus in them. Otherwise it will use the simple 7805 voltage regulator circuitry to change the 12V signaling of the vehicle to 5V TTL compatible logic levels. ELM327 will change the protocol being run on the vehicle to the RS232 serial protocol and it will be connected to the serial interface through the MAX232 IC. The microcontroller will be connected to this serial interface for further use of the project. This serial interface can also be connected with Hyper Terminal to send AT commands to the ELM327 directly thus checking the functionality of this circuit.

26

The schematic diagram of the complete circuit is shown below.

Fig. 3.3 Schematic Diagram of the Data Acquisition Circuit [10]

This circuit comprises of resistors, capacitors, diodes, transistors, voltage regulators and LEDs other than ELM327 and MCP2551. Capacitors are used for reducing noise and ripples in the circuit. Diodes are used for controlling current direction and four LEDs are used for showing different states of the circuit in operation. The OBD-II interface of the Vehicle gives 12V output. So 7805 voltage regulators are used to provide constant 5V. Pin no. 4, 5, 7, 15 and 16 on the left side of the diagram are ISO-K line and ISO-L line respectively. These pins are used when there is ISO 9141-2 protocol in a vehicle. Pins 2, 4, 5, 10, and 16 will be used if there is J1850 PWM protocol in the vehicle. Pins 2, 4, 5, and 16 will be used if there is J1850 VPW protocol in the vehicle Pins 4, 5, 7, 15, and 16 will be used if there is ISO 9141-2/KWP2000 protocol in the vehicle. The pins to the right are the 9 pins of the DB9 serial interface. These pins will be used to communicate with the Microcontroller.

27

The Microcontroller is connected with the RS232 serial interface at the right side of the figure using MAX232 Circuitry. It will send commands to the ELM327 to extract data. ELM327 will use the CAN Transceiver MCP2551 for vehicles where CAN protocol is available. Where there will be other than CAN, rest of the pins will be used, which are described above, accordingly. MCP2551 is a CAN bus transceiver IC. It will change the 12V CAN bus signals to 5V TTL Compatible Logic levels.

3.1.2 Processing, Display and Communication Circuit

The main part of the project is the Processing, Display and Communication Circuit. It comprises of PIC18F4580 Microcontroller. This circuit takes data from the RS232 and processes it and displays it on a 16x2 character LCD and then sends it to SIM-300DZ GSM Modem. The GSM Modem then sends this data through SMS. The Block Diagram of this Circuit is as follows.

Microcontroller

LCD

Multiplexer

MAX 232 SIM-300DZ Serial Interface

Data Acquisition Circuit

Fig. 3.4.Block Diagram of Processing, Display and Communication Circuit

28

The schematic diagram of this circuit is given below.

Fig. 3.5 The Processing, Display and Communication Circuit

PORTD of the Microcontroller is connected with a 16x2 character LCD which will be used to display the vehicles data. The potentiometer connected with the LCD is used to adjust the brightness of the LCD. The Microcontroller is connected to the Data Acquisition Circuit through USART serial module. MAX232 is required in between the two circuits to ensure TTL compatible logic levels. The Microcontroller sends commands to the Data Acquisition Circuit and it returns corresponding values. Some of these values may be in hexadecimal format, so the MCU convert these values to decimal and then forwards them to PORTD to display them on LCD. There is only one USART serial module in PIC18F4580, so multiplexing is required for communication with the GSM module as well. For this purpose a set of 7 NOR Gates is used. 7802 ICs are used for this purpose. One 7802 contains 4 NOR Gates, so two such ICs are being used in the above circuit of which one NOR Gate is left unused. Three LEDs at PORTB will lit when data transmission/reception will be in progress from the MCU. The circuit at the lower right corner of the diagram is the power supply circuit. It is designed to take power from the vehicle itself instead of using any other source i.e. battery. This circuit consists of 7805 29

Voltage Regulator. 7805 converts 12V from pin 16 of the OBD-II, J1962 interface and converts them to 5V. Capacitors are used for noise immunity in the power supply circuit. Example of Microcontroller interface with the Data Acquisition Circuit is as follows: The Microcontroller sends PID commands to ELM327 through USART. The ELM327 returns hex values. For example to check the RPM of the car, the Microcontroller sends command: >01 0C And the return valve will be like: 41 0C 0D 2D The value 0D 2D is a two byte hex value and it will be converted to decimal by the microcontroller. The converted value will be: 3373 This value will then be divided by 4 to get the actual value of the engine RPM that is: 3373/4 = 843 rpm

3.2 Flow Chart of the Microprocessor Code

The PIC18F4580 Microprocessor is the heart of the project. It will control the Data Acquisition Circuit as well as the Display, Processing and Communication Circuit. First it will send AT commands to the Data Acquisition Circuit to extract data from the vehicle, and then it will convert this data from hex values to decimal values for easy understandability. After that it will display this data on a 16x2 LCD and then forward this data to SIM-300 DZ modem for sending it to a remote server.

The flow chart of the program which is written for this microcontroller is shown below.

30

START

USART Initialize

Send Commands to ELM327

ELM327 Responds

NO

YES

Process the Returned Values

To LCD

TO SIM300DZ

END
Fig. 3.6 Flow Chart of the Microprocessor Code

31

3.3 Server Side Software

The data from SIM300-DZ modem will be sent as an SMS to a mobile phone. Moreover it can also be sent to another SIM-300 DZ modem which may be connected to a server at a remote location. For this, a software can be developed for the remote server also. This software will be in C language and will be used to read received data from the SIM-300 DZ modem and then store it to the database of the server. This will allow keeping a record of all the diagnostic data of a vehicle. This data can also be analyzed graphically by making graphs of the data taken from the vehicle time to time. This can be useful for the vehicle manufacturers to analyze the performance of their vehicles and make improvements accordingly. The Block Diagram of the Server Side Software Application is as under.

SIM-300 DZ

Serial Interface

SMS Fetching Software

MySQL Data Base

Fig. 3.7 Block Diagram of the Server Side Software Application

32

The Flow Chart of the Software Application for the Server will be as follows.

START

Initialize Serial Interface

NO

Receive SMS

YES

Parse SMS

Divide SMS into fields

Insert fields to the SQL Database

STOP

Fig. 3.8 Flow Chart of the Server Side Application

33

4 Results

4.1 Results
The main part of the assigned project is to read vehicles data from the OBD port. This data includes freeze frame data, Diagnostic Trouble Codes and real time data. After successfully reading the vehicles data it is transmitted to remote location with the help of GSM modem through SMS.

4.1.1 Diagnostic Trouble Codes

If any node in the vehicle produces some error which makes the MIL On then it means that node is generating some code. These codes can be successfully read and send to the remote location by using our hardware.

4.1.2 Real Time Data

Real time data read from the vehicle and send to the remote user periodically. Microcontroller keep on sending request to data acquisition hardware which sends the corresponding information back to the microcontroller which displays that data on LCD interfaced with it and also send it to the remote location by using GSM modem through SMS periodically.

4.1.3 Freeze Frame Data

Any information stored in the vehicle can also be extracted and pass to the user by above mentioned procedure

4.1.4 Clearing Diagnostic Trouble Code

This hardware can also clear the diagnostic trouble codes if any, stored in the vehicle.

34

Fig 4.1. Testing of the Data Acquisition Circuit

For testing the hardware, we have interface data acquisition hardware with computer through serial port. Hyper Terminal is used for testing the data acquisition hardware which consists of ELM327, MCP2551 and MAX232. User will communicate with the vehicle through serial port at data rate of 38400 baud. Successful interface and correct parameters setting shows the version of ELM used which in our project is ELM327 v1.1. This shows that communication has been established and now any command can be send from the computer to read corresponding vehicles data. User can send AT or OBD commands to read the data. Different modes of command give different type of data.

For example > AT RV command returns voltage and > 0105 returns Coolant temperature of the vehicle. To read Diagnostic Trouble Codes from the vehicle > 03 command should be send to the vehicle. Each command is send to the ELM327 from computer through serial interface which then process it and send it to the vehicles OBD port.

Once the testing of data acquisition hardware is done than the other part of the project is to interface data acquisition hardware with the microcontroller using serial port. Microcontroller sends request to ELM327 using serial communication which then collect the corresponding data from the vehicles OBD port and send it back to the microcontroller. LCD interfaced with microcontroller displays that data and GSM modem attached with the microcontroller send the same data shown on LCD to the remote user through SMS.

35

Fig 4.2. Test Results of the Data Acquisition Circuit

> AT SP 3 command means that ISO 9141-2 protocol has been selected for communication with the vehicle through OBD port. > ATDP command is displaying the protocol selected. > 010C is the OBD command which returns rpm in hex values. By applying appropriate formula, it can be converted it in to rpm. OD 2D Hex = 3373 Decimal RPM= 3373/4=843 rpm > 0105 is also the OBD command which returns the coolant temperature of the vehicle in hex values. Applying an appropriate formula converts it to the coolant temperature in C. 7F Hex = 127 Decimal Coolant temperature =127-40=87 C

36

Fig 4.3. Test Results of the Data Acquisition Circuit with Hyper Terminal

> ATRV command returns the voltage of the car which is 14.7 V when tested in vehicle in the Start condition. It was 12.5V when the car was switched off.

37

4.2 Server Side Database

Fig 4.4. MySQL Database

The server side application will receive the data sent by the car and will parse it and save it to a MySQL Database. The Database consists of eight values initially. These values are as below: 1. Vehicle ID It will be a unique Vehicle ID sent by the Vehicle every time to distinguish it from other vehicles. 2. Protocol It will store the protocol being used in the specific vehicle e.g. ISO9141-2. 3. Voltage It will store the Voltage output of the OBD-II interface. 4. RPM It will store the RPM of the engine at the time of the receiving of the SMS. 5. Temperature It will store the temperature of the vehicle coolant. 6. Speed - It will store the speed of the engine at the time of the receiving of the SMS. 7. IATEMP It will store the Air Intake Temperature of the Vehicle. 8. Fuel Pressure It will store the Fuel temperature of the Vehicle.

The Protocol value is a character type array value. Voltage is of float data type. While all other values are integer type values.

38

5 Conclusion and Future Enhancements

5.1 Conclusion
This project gave us a lot of information about technology used in the vehicles for extracting meaningful data and trouble codes from it, wireless communication, serial communication between microcontrollers etc. We didnt have much knowledge about how to communicate with vehicle wirelessly but due to team work and hard work, we are now able to communicate with any vehicle wirelessly. Once our system is attached with any vehicles OBD-II then It can be monitored wirelessly from remote location until this system is plugged out. The objective of this project was to create a wireless universal scan tool for vehicle which reads data from the vehicles OBD-II and sends it to the remote location through SMS. This scan tool is compatible with all cars which has any OBD-II protocol running in it. This thesis shows that most of the assigned project tasks have been completed. The major achievement was communication with OBD-II port which is the main part of the project. Any type of information of the vehicle can be extract out by communicating with OBD-II port. The other achievement was wireless communication using GSM modem. It gives user advantage of remote monitoring vehicle. Now you dont have to bring your car to workshop for minor problems. ECU of the vehicle can be fully monitored from anywhere around the country. Vehicles useful parameters means real time data can also be monitored by this project. This gives a new dimension in the field of automotives. Now vehicles can be monitored and diagnose from any location. We have learned a lot from this project. We have not just learned about protocols of the automotives but also wireless transmission of the vehicle information as well. Now we have gained enough knowledge about embedded systems, automotives and wireless communication systems. Projects we will be assigned in the future can be easily handled as experience gained by this project is very useful. Guidance at each step provided by our project advisor Mr. Adnan Elahi will help us in handling the future projects more easily and in a much efficient way. We are thankful for the cooperation provided by our project advisor Mr. Adnan Elahi.

39

5.2 Future Enhancements

Following are the enhancements that can be made in the future.

Communication with vehicle on flex ray which is the latest protocol of automotives and have the ability to communicate at data rate up to 10 Mbps. GPS implementation can tell the location of the vehicle. So along with other parameters of the car i.e. real time data and diagnostic trouble codes, location of the vehicle can also be monitored which increases the security of the car. This project is based on GSM system. GPRS can be used instead of GSM or along with GSM. GPRS can allow integrating the data on web server. GPRS is much more reliable and fast then GSM. So we can use GPRS for wireless communication.

40

References:
[1] Doo-Hee Jung, Gu-Min Jeong and Hyun-Sik Ahn, Remote Vehicle Diagnostic System Using Mobile Handsets, Department of Electrical and Electronics Engineering, Korea Polytechnic University, Korea,2004. Peter David, Ruben Fernandez,OBD II Diagnostic: Secrets Revealed, Kotzig Publishing, Inc, 2004. Peter David,OBD II Fault Codes Reference Guide, Kotzig Publishing, Inc, 2004. The OBD-II Home Page Sponsored by Autotap OBD-II Diagnostic Scanner 2011, B&B Electronics. Available from: http://www.obdii.com/connector.html [Accessed on January 12, 2011]. OBD-Codes.com, The OBD-II Trouble Codes Repair Site 2011, Available from: http://www.obdcodes.com/faq/obd2-codes-explained.php [Accessed on January 10 , 2011]. CAN-CIA Website [Online]. Available from: http://www.can-cia.org/index.php?id=161. [Accessed on November 20]. Global System for Mobile Communication, 2011 [online]. Available from: http://www.naavi.org [Accessed on February, 2011]. Theodore S. Rappaport, Wireless Communications Principles and Practice, 2 nd Edition 1990, Ch # 10, page 555. Electronic Document Sim300DZ Datasheet, Available from: http://www.sim.com. [Downloaded on November 20, 2010 ] Electronic Document ELM327 Datasheet, Available from: http://www.elmelectronics.com. [Downloaded on April 20, 2011 ] Theodore S. Rappaport, Wireless Communications Principles and Practice, 2nd Edition 1990, Ch # 10, page 552. Cool Circuits Collection [Online], 2011. Available from: http://www.coolcircuit.com/circuit/rs232_driver/ [Accessed on January 31, 2011]. Cellular-News [Online]. Available from: http://www.cellularnews.com/gprs/GPRS_classes_and_coding_schemes.shtml [Accessed on December 4, 2010]. Developers Home, Introduction to AT Commands [Online], 2004-2011, Available from: http://www.developershome.com/sms/atCommandsIntro.asp [Accessed on December 4, 2010]. Electronic Document PIC18F4580 Datasheet, 2009 Microchip Technology Inc. Presentation on ISO 9141-2 and J1939 Protocols on OBD-II. [Online]. Available from: http://www. Flens1.csie.ncku.edu.tw [Downloaded on April 1, 2011]. Application Report: Introduction to the Controller Area Network by Steve Corrigan, Copyright 2003 by Texas Instruments Incorporated [online]. Available from: , 2010http://www.scribd.com/doc/6676048/sloa101. Accessed on October 22, 2010. Affordable Hi-Quality S-Video + Stereo Distribution System by Keith Doxey, 2002 [online]. Available from: http://www.diyha.co.uk/electronics/comm1.html [Accessed on January 31, 2011].

[2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17]

[18]

41