Difference between revisions of "F15: Car Report"

Revision as of 00:13, 18 December 2015

Grading Criteria

Project Title

Car Project: OBD-II Design using CAN Protocol

Abstract

For our project, we will be building an OBD II device that will interface with a vehicle through CAN Bus protocol. OBD II stands for On-Board Diagnostic II, which is used to track and monitor a vehicle's status and functions. A DB-9 connector to OBD-II cable and SJ One Board were used to connect our device to the car in order to record real-time information of the vehicle like the temperature, engine check, and MPH. After gathering all required information, you can diagnose any faults in the vehicle that may appear.

Objectives & Introduction

A device like OBD-II was introduced to the automobile industry in the late 1970's and it is still widely used today as a diagnostic tool for a vehicle from engine control to parts records. OBD-II is used by mechanics, car owners, agencies, and car manufactures to ensure vehicle is within the EPA emission standards. As California has become one of the leading states for the car industry, we decided building an OBD-II will lead to a better understanding of CAN Bus interface that is widely used in the car industry.

To design a OBD-II, we used a voltage regulator, switching circuit, transceiver, OBD-II to DB-9 cable, DB-9 connector, and a micro controller on the SJ One board. We used CAN interface to transmit and receive information regarding the vehicle. The objective of an OBD-II is to establish strong and reliable connection to a vehicle in order to gather valid and real-time information like MPH, RPM, engine check, temperature, car performance, and any faults. The OBD-II to DB-9 cable is connected to the car and SJ One Board. A simple flowchart regarding the overview of how the system is connected is shown in Figure 1.

Figure 1. A simple Flowchart of the Overview System Connection.

Team Members & Responsibilities

• Yasmine Jamjoum
  • Hardware Design and Software Implementation of CAN Bus
• Khang Doan
  • Hardware Design and Software Implementation of CAN Bus

Schedule

Parts List & Cost

Hardware

• OBD-II to DB-9 Cable [$9.95]

• Prototype board [$12.99]

• DB-9 Male Connector, Switch, LED, resistor, LM7805 voltage regulator [$10.99]

• LCD Display [$34.99]

• Vehicle: 2004 Acura TL [$10,100]

Software

• Windows Vista/7 (32 or 64-bit)

• Eclipse IDE

Design & Implementation

Hardware Design

The ODB-II hardware design included a battery supply, voltage regulator, switch circuit, MCP 2551 transceiver, a DB-9 connector as shown in Figure 2, and a OBD-II to DB-9 cable, as shown in Figure 3, that connects to the car. The OBD-II system can be found in cars manufactured in the year 1996 and later. The OBD-II connection to the car reveals the car's status such as temperature, MPH, and error faults. The CAN Bus pins from the DB-9 connector are connected to the CAN H and CAN L of the transceiver. The transceiver's Rxd and Txd pins are connected to the Td and Rd pins on the SJ One Board along with the voltage and common ground. The pin diagram of the OBD-II to DB-9 connector is shown as Figure 4. The switch circuit is used to enable and disable the whole system along with a red LED to alert the user the system is activated. A voltage regulator is used to stablize the voltage going through the circuit that is shown as Figure 5 along with the pin diagram. The transceiver was used to transmit and receive from and to the CAN protocol. The purpose of the transceiver is to interface the CAN protocol and the actual physical bus. The transceiver allows a suitable signal to be transmitted over the CAN bus protocol. The pins of the transceiver are connected to the SJ One Board along with voltage and common ground. The pin diagram of the transceiver is shown as Figure 6.

Figure 2. DB-9 Connector.

Figure 3. OBD-II to DB-9 Cable.

Figure 4. Pin Diagram of the OBD-II and DB-9.

Figure 5. Pin Diagram of the LM7805 Voltage Regulator.

Figure 6. Pin Diagram of the MPC 2551 Transceiver.

Hardware Interface

To implement this project, we used CAN Bus Protocol with a CAN High and CAN low signals. The Rx and Tx pins on the SJ One Board are connected to the CAN H and CAN L pins from the DB-9 connector. The DB-9 connector will allow the connection of the OBD-II to DB-9 cable to the vehicle that will transmit and receive information regarding the vehicle's status and any faults occurring in the vehicle. In between the connection of the DB-9 connector and the SJ One Board, we have a MCP 2551 transceiver to allow the interface between the CAN protocol and the bus. The CAN H and CAN L pins from the transceiver are connected to the CAN H and CAN L of the DB-9 connector which are pins 7 and 2, respectively. The TxD and RxD pins of the transceiver and connected to the Rx and Tx of the SJ On Board which are pins P0.1 and P0.0, respectively. Pin VDD of the transceiver is connected to the Vcc from the SJ One Board and pin Vss of the transceiver is connected to common ground. The voltage regulator is connected to the Vcc of the DB-9 connector, common ground, and the switch circuit. The switch circuit is used to enable the whole system and the voltage regulator is used to stabilize the voltage levels. Drivers were written to drive the CAN Bus protocol in order for information from the car to be transmitted and received.

Figure 4. Schematics of the Hardware Connection.

Software Design

The CAN BUS continuously send out information throughout the network to every node. To listen to the broadcast from the CAN BUS, we have to decide on which message to filter out. Each message from the CAN BUS has a very specific parameter ID (PID). For example engine RPM would have a PID hexadecimal value of 0x0C. Another thing to notice is the lower the hexadecimal value would have the higher priority. This is another characteristic of the CAN BUS protocol. To first establish communication on the CAN BUS, we first turn off all filter to insure our hardware and software are working correctly. After ensuring our hardware and software work, we look at what PID we are interested in, we begin to filter out the unwanted messages. After storing our wanted messages in a buffer, we start to process the raw data. We translates these data into something that is understandable based on a formula.

Implementation

Our first step in implementing our design is to initialized all port, baudrate and which CAN we are using (CAN1/CAN2). In addition, we also have to set up the Rx and Tx queue size. This is done through the init function in the CAN API. Next, we have to ensure our hardware is working correctly by accepting all messages on the CAN BUS. We got to be careful not to overwhelm our buffer. After successfully receiving messages from the bus, we begin to look for what PID we are interested in. After setting up the filter, we store all of our wanted messages for later processing. Since the data we are receiving are hexadecimal values, we use a formula to translated this data into something understandable. We then output this data into the console.

Testing & Technical Challenges

The testing phase for our project was very time consuming since an actual car was required for every testing procedure. We had to constantly go back and forth to our workstation and the parking lot. First, we begin the testing phase by testing our hardware circuitry to ensure there weren't any short circuits. Next, we developed the drivers for the hardware implementation. Once the hardware and software were complete, it was time to interface the CAN Bus protocol using a vehicle. We faced many difficulties transmitting and receiving information over the CAN Bus. Advise we would give someone if he or she started our project from scratch is try to get help from peers that have experience in CAN Bus Protocol. When we ran into problems, we didn't have anyone to turn to for advise or help. After identifying the problems, we still had issues trying to resolving the problems. Another piece of advise we would give is allocate a lot of time for debugging. This project requires most of the time for debugging purpose to transmit and receive the real-time information from the vehicle.

Issue #1

Our first issue was that the parts took awhile to come in from the manufacturers. Our resolution was to begin researching and try to learn as much as possible to start the hardware and software implementation.

Issue #2

Our second issue was the CAN Bus protocol wasn't transmitting or receiving any information from the car. We analyzed the drivers and kept researching more about the CAN Bus Protocol. After very long hours of research, we were able to transmit and receive information from the vehicle.

Issue #3

Every time we plugged the OBD-II into the vehicle and run the software, the voltage regulator becomes extremely hot and the transceiver starts smoking. We testing different points in the hardware when we realized that the voltage wasn't correct. Our resolution was to change the voltage regulator to a new a voltage regulator. After we swapped the voltage regulator, the voltage level were correct.

Conclusion

Starting this project, we didn't have much knowledge in the CAN Bus protocol. This project has extremely increased our knowledge in CAN bus Protocol and application of the OBD-II device. After the completing this project, we learned how the CAN Bus protocol works, what's in the hardware implementation, and how to write drivers for the CAN Bus protocol. We learned how the information is transmitted and received to capture real-time data of a vehicle. Also, we learned how important an OBD-II device is and how it is used be many different people for similar purpose.

In the future, we would like to work more on this project to enhance the application of the CAN Bus protocol. We would like to be able to transmit and receive more information from the vehicle and add additional features when transmitting and receiving. We look forward to working on this project in the future and build on it for other projects that we will be completing in the future.

Project Video

https://youtu.be/cF5lDp5a2Z4

Project Source Code

• Sourceforge Source Code Link

References

Acknowledgement

We would like to thank the following people for their contributions during this project:

Preet Kang

References Used

Introduction to CAN Hacking

http://hackaday.com/2013/10/21/can-hacking-introductions/

Introduction to CAN Protocols

http://hackaday.com/2013/10/29/can-hacking-protocols/

Hacking into Vehicle

http://fabiobaltieri.com/2013/07/23/hacking-into-a-vehicle-can-bus-toyothack-and-socketcan/

Appendix

OBD-II to DB9 Cable

https://www.sparkfun.com/products/10087

LPC1759 Datasheet

http://www.nxp.com/documents/data_sheet/LPC1759_58_56_54_52_51.pdf

LPC176x/5x User manual

http://www.nxp.com/documents/user_manual/UM10360.pdf

MCP 2551 Transceiver

http://www.electroschematics.com/wp-content/uploads/2015/07/MCP2551-datasheet.pdf