F15: Car Report
Contents
Grading Criteria
- How well is Software & Hardware Design described?
- How well can this report be used to reproduce this project?
- Code Quality
- Overall Report Quality:
- Software Block Diagrams
- Hardware Block Diagrams
- Schematic Quality
- Quality of technical challenges and solutions adopted.
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.
Team Members & Responsibilities
- Yasmine Jamjoum
- Hardware Design and Software Implementation of CAN Bus
- Khang Doan
- Hardware Design and Software Implementation of CAN Bus
Schedule
| Week# | Date | Planned Task | Actual |
|---|---|---|---|
| 1 | 10/12-10/18 |
• Purchase all required parts • Download and install programs and data sheets for CAN Bus interface and OBD-II connection |
• Parts ordered on 10/16 • All required programs and data sheets were downloaded and installed |
| 2 | 10/19-10/25 |
• Gather all parts • Test all components separately • Plan and design hardware design diagrams |
• Testing components separately was successful • Waiting on a few components • Diagrams for hardware design were complete |
| 3 | 10/26-11/1 |
• Begin hardware design • Test the hardware design along the way |
• Started hardware design • Started project report |
| 4 | 11/2-11/8 |
• Complete the hardware design • Test the hardware as a whole |
• Realized we needed a transceiver • Waiting on the transceiver before we can continue with the hardware design completion |
| 5 | 11/9-11/15 |
• Complete the hardware design • Test the complete hardware connection • Research about the software interface for OBD-II: CAN Bus protocol
|
• Received the transceiver • Completed the hardware design • Updated all hardware diagrams • Tested and Debugged the whole system |
| 6 | 11/16-11/22 |
• Begin the software interface for OBD-II: CAN Bus protocol
|
• Began research on CAN Bus Protocol • Obtained additional data sheets for CAN Bus and OBD-II connection |
| 7 | 11/23-11/29 |
• Begin the software interface for OBD-II: CAN Bus protocol |
• Started software programming for CAN bus |
| 8 | 11/30-12/6 |
• Complete the software interfaces for CAN Bus • Begin Debugging |
• Completed the software interfaces for CAN Bus • Started Testing and Debugging
|
| 9 | 12/7-12/13 |
• Finish Debugging the software • Interface the hardware with software • Test system design |
• Completed the debugging phase of the software • Started interfacing the hardware with the software • Tested the device on an actual vehicle • Replaced hardware component to fix hardware connection • Continued the project report |
| 10 | 12/14-12/17 |
• Complete system testing • Complete the project report • Demo the project |
• Completed system testing • Created video for presentation • Completed the project report • Presented the project on Thursday, December 17, 2015 |
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, and a OBD-II to DB-9 cable to connect the 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 Rx and Tx pins on the SJ One Board along with the voltages and common ground. The pin diagram of the DB-9 connector is shown as Figure 2. 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. 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 3.
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.
Software Design
Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it. The Software Design section is isolated to talk about high level workings rather than inner working of your project.
Implementation
This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.
Testing & Technical Challenges
Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again? Make a smooth transition to testing section and described what it took to test your project.
Include sub-sections that list out a problem and solution, such as:
My Issue #1
Discuss the issue and resolution.
Conclusion
Conclude your project here. You can recap your testing and problems. You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?
Project Video
Upload a video of your project and post the link here.
Project Source Code
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
