Difference between revisions of "F15: Car Report"

From Embedded Systems Learning Academy
Jump to: navigation, search
(→‎Hardware Interface)
(→‎Grading Criteria)
 
(95 intermediate revisions by one other user not shown)
Line 1: Line 1:
−
=== Grading Criteria ===
 
−
<font color="green">
 
−
*  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.
 
−
</font>
 
−
 
 
== Project Title ==
 
== Project Title ==
−
'''Car Project: OBD-II Design using CAN Protocol'''
+
'''Car Project: OBD-II Design over CAN BUS Protocol'''
  
 
== Abstract ==
 
== 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.
+
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 OBD-II to DB-9 cable, transceiver, and CAN Controller on the SJ One Board were used to connect our device to the car's system 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 ==
 
== Objectives & Introduction ==
−
//Show list of your objectives.  This section includes the high level details of your project.  You can write about the various sensors or peripherals you used to get your project completed.
 
  
−
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.  
+
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 temperature levels. OBD-II is used by mechanics, car owners, agencies, and car manufactures to ensure vehicle is within the EPA emission standards. The car's system responds, accepts, and implements an OBD-II interface through the CAN communication. The CAN communication is used widely in the automobile industry due to its very deterministic and reliable connection that guarantees a message will be transmitted, received, and executed. All controls in a car are transported on the CAN BUS protocol. The CAN communication is a broadcast bus that has baud rates of 100K, 125K, 250K, 500K, or 1M per second. The CAN communication is half duplex that transmits and receives a signal at a time with a differential pair. The differential pair is used for better noise limitation over long distances. 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.
+
To design a OBD-II, we used a voltage regulator, switching circuit, transceiver, OBD-II to DB-9 cable, DB-9 connector, and a CAN controller on the SJ One board. We used CAN interface to transmit and receive information regarding the vehicle. The OBD-II to DB-9 cable is used to connect from the car's system through the OBD-II port to the CAN Controller on our SJ One Board. However, since CAN voltage levels can't be directly accepted, we need to convert the CAN signals to logical signals through a MCP2551 transceiver. The transceiver permits the CAN interface between our CAN controller and the OBD-II. The voltage regulator allows the longer distance connection by increasing the voltage levels. The objective of this project is to design an OBD-II device that connects to a car's system over CAN communication to establish strong and reliable connection to gather valid and real-time information like MPH, RPM, engine check, temperature, car performance, and any faults. A simple flowchart regarding the overview of how the system works is shown in Figure 1.
  
−
[[File:CMPE146_F15_CarReport_Flowchart.jpg|500px|thumb|centre|Figure 1. A simple Flowchart of the Overview System Connection.]]
+
[[File:CMPE146_F15_CarReport_Flowchart3.jpg|500px|thumb|centre|Figure 1. A simple Flowchart of the Overview System Connection.]]
  
 
=== Team Members & Responsibilities ===
 
=== Team Members & Responsibilities ===
 
*  Yasmine Jamjoum
 
*  Yasmine Jamjoum
−
**  Hardware Design and Software Implementation of CAN Bus
+
**  Hardware Design and Software Implementation of CAN BUS
 
*  Khang Doan
 
*  Khang Doan
−
** Hardware Design and Software Implementation of CAN Bus
+
** Hardware Design and Software Implementation of CAN BUS
  
 
== Schedule ==
 
== Schedule ==
−
Show a simple table or figures that show your scheduled as planned before you started working on the project.  Then in another table column, write down the actual schedule so that readers can see the planned vs. actual goals.  The point of the schedule is for readers to assess how to pace themselves if they are doing a similar project.
 
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 53: Line 39:
  
 
• All required programs and data sheets were downloaded and installed
 
• All required programs and data sheets were downloaded and installed
 +
 +
• Began researching information on OBD-II devices and CAN BUS Protocol
 
|-
 
|-
 
! scope="row"| 2
 
! scope="row"| 2
Line 94: Line 82:
  
 
|  
 
|  
−
• Realized we needed a transceiver
+
• Realized we needed more hardware components
 +
 
 +
• Waiting on the components before we can continue with the hardware design completion
  
−
• Waiting on the transceiver before we can continue with the hardware design completion
+
• Continued researching about the hardware and software interface for OBD-II over CAN BUS Protocol
  
 
|-
 
|-
Line 106: Line 96:
 
• Test the complete hardware connection
 
• Test the complete hardware connection
  
−
• Research about the software interface for OBD-II: CAN Bus protocol
+
• Continue researching about the hardware and software interface for OBD-II over CAN BUS Protocol
  
  
Line 117: Line 107:
  
 
• Tested and Debugged the whole system
 
• Tested and Debugged the whole system
 +
 +
• Continued researching about the hardware and software interface for OBD-II over CAN BUS Protocol
  
 
|-
 
|-
Line 122: Line 114:
 
| 11/16-11/22
 
| 11/16-11/22
 
|  
 
|  
−
• Begin the software interface for OBD-II: CAN Bus protocol
+
• Begin the software interface for OBD-II over CAN BUS protocol
  
  
 
|  
 
|  
−
• Began research on CAN Bus Protocol
+
• Started the software interface for OBD-II over CAN BUS protocol
 +
 
 +
• Continued researching about the hardware and software interface for OBD-II over CAN BUS Protocol
  
 
• Obtained additional data sheets for CAN Bus and OBD-II connection
 
• Obtained additional data sheets for CAN Bus and OBD-II connection
Line 134: Line 128:
 
| 11/23-11/29
 
| 11/23-11/29
 
| |  
 
| |  
−
• Begin the software interface for OBD-II: CAN Bus protocol
+
• Continue the software interface for OBD-II over CAN BUS protocol
  
 
|  
 
|  
−
• Started software programming for CAN bus
+
• Continued software programming for CAN BUS Protocol
  
 
|-
 
|-
Line 143: Line 137:
 
| 11/30-12/6
 
| 11/30-12/6
 
|  
 
|  
−
• Complete the software interfaces for CAN Bus
+
• Complete the software interface for OBD-II over CAN BUS protocol
  
 
• Begin Debugging
 
• Begin Debugging
 +
 +
• Begin interfacing the hardware with the software
  
 
|  
 
|  
−
• Completed the software interfaces for CAN Bus
+
• Completed the software interface for OBD-II over CAN BUS protocol
 +
 
 +
• Started interfacing the hardware with the software
  
 
• Started Testing and Debugging  
 
• Started Testing and Debugging  
Line 166: Line 164:
 
• Completed the debugging phase of the software
 
• Completed the debugging phase of the software
  
−
• Started interfacing the hardware with the software
+
• Completed interfacing the hardware with the software
  
 
• Tested the device on an actual vehicle  
 
• Tested the device on an actual vehicle  
Line 196: Line 194:
  
 
== Parts List & Cost ==
 
== Parts List & Cost ==
−
//Give a simple list of the cost of your project broken down by components.  Do not write long stories here.
 
  
 
'''Hardware'''
 
'''Hardware'''
Line 207: Line 204:
  
 
• LCD Display [$34.99]
 
• LCD Display [$34.99]
 +
 +
• SJ One Board [$80.00]
  
 
• Vehicle: 2004 Acura TL [$10,100]
 
• Vehicle: 2004 Acura TL [$10,100]
Line 217: Line 216:
  
 
== Design & Implementation ==
 
== Design & Implementation ==
−
The design section can go over your hardware and software design.  Organize this section using sub-sections that go over your design and implementation.
 
  
 
=== Hardware Design ===
 
=== Hardware Design ===
−
//Discuss your hardware design here.  Show detailed schematics, and the interface here.
+
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 that connects to the car. The OBD-II system can be found in cars manufactured in the year 1996 and later. The OBD-II device reveals the car's status such as temperature, MPH, and error faults. The OBD-II to DB-9 cable, as shown is Figure 3, is used to connect a vehicle's system to retrieve information over the CAN Bus. The pin diagram of the OBD-II to DB-9 connector is shown as Figure 4. However, this cable cannot convert CAN voltage signals to logical signals, so we used a MCP2551 transceiver. This transceiver will produce logical signals that the micro-controller on our SJ One Board can fully understand and implement from the OBD-II port.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. 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 5. 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 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 stabilize the voltage at a certain level going through the circuit that is shown as Figure 6 along with the pin diagram. We needed to increase the voltage level to deliver the system over long distances.  
−
The ODB-II hardware design included a battery supply, voltage regulator, MPC 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. An on-board switch is used to enable and disable the whole system. 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.  
 
  
−
[[File:CMPE146_F15_CarReport_Pin_Diagram_of_OBD-II_and_DB.jpg|500px|thumb|centre|Figure 1. Pin Diagram of the OBD-II and DB-9.]]
+
[[File:CMPE146_F15_CarReport_DB-9Connector1.jpg|500px|thumb|centre|Figure 2. DB-9 Connector.]]
  
−
[[File:CMPE146_F15_CarReport_MPC2551.jpg|500px|thumb|centre|Figure 1. Pin Diagram of the MPC 2551 Transceiver.]]
+
[[File:CMPE146_F15_CarReport_obd_cable.jpg|500px|thumb|centre|Figure 3. OBD-II to DB-9 Cable.]]
 +
 
 +
[[File:CMPE146_F15_CarReport_Pin_Diagram_of_OBD-II_and_DB.jpg|500px|thumb|centre|Figure 4. Pin Diagram of the OBD-II and DB-9.]]
 +
 
 +
[[File:CMPE146_F15_CarReport_MPC2551.jpg|500px|thumb|centre|Figure 5. Pin Diagram of the MPC 2551 Transceiver.]]
 +
 
 +
[[File:CMPE146_F15_CarReport_VoltageRegulator1.jpg|500px|thumb|centre|Figure 6. Pin Diagram of the LM7805 Voltage Regulator.]]
  
 
=== Hardware Interface ===
 
=== Hardware Interface ===
−
In this section, you can describe how your hardware communicates, such as which BUSes used.  You can discuss your driver implementation here, such that the '''Software Design''' section is isolated to talk about high level workings rather than inner working of your project.
 
  
−
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.
+
To implement this project, we used CAN BUS Protocol with a CAN High and CAN Low signals. CAN BUS Protocol is a reliable broadcasting bus that uses two wires for transmitting or receiving. One signal is activated at a time with differential pairs where one wire does a certain function and the corresponding wire does the opposite operation. The CAN BUS Protocol has a 120-Ohm termination resistor at the ends of the CAN BUS to prevent any signal reflection. The car system is connected from the OBD-II port of the car to our board through an OBD-II to DB-9 cable. The CAN High and CAN Low pins of the DB-9, which are pins 7 and 2, are connected to the transceiver's CAN High and CAN Low. The wires connected to the CAN High and CAN Low are twisted together to reduce noise. The Rxd and Txd pins of the transceiver are connected to the Td and Rd pins on the SJ One Board, which are pins P0.0 and P0.1, where we have a CAN controller. Pin VDD of the transceiver is connected to the Vcc of 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 adjust the voltage levels to interface over long distances. Drivers were written to interface the CAN BUS protocol in order for information from the car to be transmitted and received. The ODB-II port from the car along with the connection of the OBD-II to DB-9 cable will connect to the car's system to transmit and receive information regarding the vehicle's status and any faults over CAN communication. Figure 7 displays the overall schematics of the hardware connection.
 +
 
 +
 
 +
[[File:CMPE146_F15_CarReport_Schematics.jpg|500px|thumb|centre|Figure 7. Schematics of the Hardware Connection.]]
  
 
=== Software Design ===
 
=== 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 CAN BUS protocol uses a differential pair to establish communication. With the CAN High and CAN Low, there are two possible states: dominant and recessive. At idling or recessive state, the two wires are at the same voltage level(~2.5V). At the dominant state, the CAN High has a voltage level of 3.5V and the CAN Low has a voltage level of 1.5V, creating a ~2V different between the pair. Since both CAN High and Low are used to produce these two states, the CAN BUS is only half-duplex. The transceiver we're using in this project could go up to 1Mbps, but we decided to go with only 500Kbps.  
 +
 
 +
The CAN BUS frame contains from 50-114 bits depending on which CAN protocol in use. For this project, we are using the Standard CAN. The part of the frame that we are interested in is the 11-bits identifier. The identifier also determine priority during arbitration. 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. The engine ECU is continuously broadcasting information like: engine RPM, fuel system status...etc. 
 +
 
 +
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. To first establish communication on the CAN BUS, we first turn off all filter to ensure 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 ===
 
=== 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.
+
 
 +
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 have 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 translate this data into something understandable. We then output this data into the console. Figure 8 represents a block diagram of the software implementation.  
 +
 
 +
[[File:CMPE146_F15_CarReport_softwareBlockDiagram.jpg|500px|thumb|centre|Figure 8. Block Diagram of the software implementation.]]
  
 
== Testing & Technical Challenges ==
 
== 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:
+
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 OBD-II and CAN BUS implementation. Once the hardware and software were complete, it was time to interface the CAN BUS protocol to the car's system. We faced difficulties communicating over the CAN BUS protocol but after further research, we were able to communicate to the car's system over CAN communication. The 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 had to do further research issues resolving the problems without any feedback from any person with experience in CAN communication. 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 implement CAN communication to the car's system to gather the real-time information from the vehicle. 
  
−
=== My Issue #1 ===
+
=== Issue #1 ===
−
Discuss the issue and resolution.
+
Our first issue we faced 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 about the hardware implementation and CAN communication.
 +
 
 +
=== Issue #2 ===
 +
Our second issue was that we had difficult understanding and implementing the CAN BUS protocol. We had trouble transmitting or receiving information from the car. We continued researching on the CAN BUS protocol and we analyzed the drivers. After very long hours of research and close analyzation, we were able to enable the CAN communication from the car's system to our CAN controller on the SJ One Board.
 +
 
 +
=== Issue #3 ===
 +
Every time we plugged the OBD-II into the vehicle and ran the software, the voltage regulator became extremely hot and the transceiver started smoking. We tested 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 was correct.
  
 
== Conclusion ==
 
== 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?
+
 
 +
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 the application of the OBD-II device. After completing this project, we learned how the CAN BUS protocol works, what's in the hardware implementation for an OBD-II device, and how to write drivers for the CAN BUS protocol. Figure 9 displays the final design of our OBD-II. We learned how the information is transmitted and received to capture real-time data of a vehicle. We gain more insight on how the car's system connects over the CAN BUS protocol through the OBD-II to DB-9 cable to the transceiver and CAN controller. 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 that can be transmitted and received. We are planning to incorporate and enhance this project into other projects that we will be working on in future classes. We look forward to working on this project in the future and building on it for other projects that we will be completing in the future.
 +
 
 +
[[File: CMPE146_F15_CarReport_FinalDesign.jpg|500px|thumb|centre|Figure 9. Final Design.]]
  
 
=== Project Video ===
 
=== Project Video ===
−
Upload a video of your project and post the link here.
+
https://youtu.be/7Dob8sZ-bcg
  
 
=== Project Source Code ===
 
=== Project Source Code ===
−
*  [https://sourceforge.net/projects/sjsu/files/CmpE_F2015/ Sourceforge Source Code Link]
+
 
 +
https://sourceforge.net/projects/obd2/files/OBD2%20on%20FREERTOS/
  
 
== References ==
 
== References ==
 
=== Acknowledgement ===
 
=== Acknowledgement ===
  
−
We would like to thank the following people for their contributions during this project:
+
We would like to thank the following people for their contributions and inspiration during this project:
  
−
Preet Kang
+
Preet Kang and Dr. Haluk Ozemek
  
 
=== References Used ===
 
=== References Used ===
Line 276: Line 300:
  
 
http://fabiobaltieri.com/2013/07/23/hacking-into-a-vehicle-can-bus-toyothack-and-socketcan/
 
http://fabiobaltieri.com/2013/07/23/hacking-into-a-vehicle-can-bus-toyothack-and-socketcan/
 +
 +
'''OBD2 PID'''
 +
https://en.wikipedia.org/wiki/OBD-II_PIDs
  
 
=== Appendix ===
 
=== Appendix ===

Latest revision as of 18:01, 19 December 2015

Project Title

Car Project: OBD-II Design over CAN BUS 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 OBD-II to DB-9 cable, transceiver, and CAN Controller on the SJ One Board were used to connect our device to the car's system 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 temperature levels. OBD-II is used by mechanics, car owners, agencies, and car manufactures to ensure vehicle is within the EPA emission standards. The car's system responds, accepts, and implements an OBD-II interface through the CAN communication. The CAN communication is used widely in the automobile industry due to its very deterministic and reliable connection that guarantees a message will be transmitted, received, and executed. All controls in a car are transported on the CAN BUS protocol. The CAN communication is a broadcast bus that has baud rates of 100K, 125K, 250K, 500K, or 1M per second. The CAN communication is half duplex that transmits and receives a signal at a time with a differential pair. The differential pair is used for better noise limitation over long distances. 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 CAN controller on the SJ One board. We used CAN interface to transmit and receive information regarding the vehicle. The OBD-II to DB-9 cable is used to connect from the car's system through the OBD-II port to the CAN Controller on our SJ One Board. However, since CAN voltage levels can't be directly accepted, we need to convert the CAN signals to logical signals through a MCP2551 transceiver. The transceiver permits the CAN interface between our CAN controller and the OBD-II. The voltage regulator allows the longer distance connection by increasing the voltage levels. The objective of this project is to design an OBD-II device that connects to a car's system over CAN communication to establish strong and reliable connection to gather valid and real-time information like MPH, RPM, engine check, temperature, car performance, and any faults. A simple flowchart regarding the overview of how the system works 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

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

• Began researching information on OBD-II devices and CAN BUS Protocol

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 more hardware components

• Waiting on the components before we can continue with the hardware design completion

• Continued researching about the hardware and software interface for OBD-II over CAN BUS Protocol

5 11/9-11/15

• Complete the hardware design

• Test the complete hardware connection

• Continue researching about the hardware and software interface for OBD-II over CAN BUS Protocol


• Received the transceiver

• Completed the hardware design

• Updated all hardware diagrams

• Tested and Debugged the whole system

• Continued researching about the hardware and software interface for OBD-II over CAN BUS Protocol

6 11/16-11/22

• Begin the software interface for OBD-II over CAN BUS protocol


• Started the software interface for OBD-II over CAN BUS protocol

• Continued researching about the hardware and software interface for OBD-II over CAN BUS Protocol

• Obtained additional data sheets for CAN Bus and OBD-II connection

7 11/23-11/29

• Continue the software interface for OBD-II over CAN BUS protocol

• Continued software programming for CAN BUS Protocol

8 11/30-12/6

• Complete the software interface for OBD-II over CAN BUS protocol

• Begin Debugging

• Begin interfacing the hardware with the software

• Completed the software interface for OBD-II over CAN BUS protocol

• Started interfacing the hardware with the software

• 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

• Completed 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]

• SJ One Board [$80.00]

• 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 that connects to the car. The OBD-II system can be found in cars manufactured in the year 1996 and later. The OBD-II device reveals the car's status such as temperature, MPH, and error faults. The OBD-II to DB-9 cable, as shown is Figure 3, is used to connect a vehicle's system to retrieve information over the CAN Bus. The pin diagram of the OBD-II to DB-9 connector is shown as Figure 4. However, this cable cannot convert CAN voltage signals to logical signals, so we used a MCP2551 transceiver. This transceiver will produce logical signals that the micro-controller on our SJ One Board can fully understand and implement from the OBD-II port.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. 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 5. 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 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 stabilize the voltage at a certain level going through the circuit that is shown as Figure 6 along with the pin diagram. We needed to increase the voltage level to deliver the system over long distances.

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 MPC 2551 Transceiver.
Figure 6. Pin Diagram of the LM7805 Voltage Regulator.

Hardware Interface

To implement this project, we used CAN BUS Protocol with a CAN High and CAN Low signals. CAN BUS Protocol is a reliable broadcasting bus that uses two wires for transmitting or receiving. One signal is activated at a time with differential pairs where one wire does a certain function and the corresponding wire does the opposite operation. The CAN BUS Protocol has a 120-Ohm termination resistor at the ends of the CAN BUS to prevent any signal reflection. The car system is connected from the OBD-II port of the car to our board through an OBD-II to DB-9 cable. The CAN High and CAN Low pins of the DB-9, which are pins 7 and 2, are connected to the transceiver's CAN High and CAN Low. The wires connected to the CAN High and CAN Low are twisted together to reduce noise. The Rxd and Txd pins of the transceiver are connected to the Td and Rd pins on the SJ One Board, which are pins P0.0 and P0.1, where we have a CAN controller. Pin VDD of the transceiver is connected to the Vcc of 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 adjust the voltage levels to interface over long distances. Drivers were written to interface the CAN BUS protocol in order for information from the car to be transmitted and received. The ODB-II port from the car along with the connection of the OBD-II to DB-9 cable will connect to the car's system to transmit and receive information regarding the vehicle's status and any faults over CAN communication. Figure 7 displays the overall schematics of the hardware connection.


Figure 7. Schematics of the Hardware Connection.

Software Design

The CAN BUS protocol uses a differential pair to establish communication. With the CAN High and CAN Low, there are two possible states: dominant and recessive. At idling or recessive state, the two wires are at the same voltage level(~2.5V). At the dominant state, the CAN High has a voltage level of 3.5V and the CAN Low has a voltage level of 1.5V, creating a ~2V different between the pair. Since both CAN High and Low are used to produce these two states, the CAN BUS is only half-duplex. The transceiver we're using in this project could go up to 1Mbps, but we decided to go with only 500Kbps.

The CAN BUS frame contains from 50-114 bits depending on which CAN protocol in use. For this project, we are using the Standard CAN. The part of the frame that we are interested in is the 11-bits identifier. The identifier also determine priority during arbitration. 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. The engine ECU is continuously broadcasting information like: engine RPM, fuel system status...etc.

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. To first establish communication on the CAN BUS, we first turn off all filter to ensure 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 have 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 translate this data into something understandable. We then output this data into the console. Figure 8 represents a block diagram of the software implementation.

Figure 8. Block Diagram of the software implementation.

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 OBD-II and CAN BUS implementation. Once the hardware and software were complete, it was time to interface the CAN BUS protocol to the car's system. We faced difficulties communicating over the CAN BUS protocol but after further research, we were able to communicate to the car's system over CAN communication. The 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 had to do further research issues resolving the problems without any feedback from any person with experience in CAN communication. 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 implement CAN communication to the car's system to gather the real-time information from the vehicle.

Issue #1

Our first issue we faced 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 about the hardware implementation and CAN communication.

Issue #2

Our second issue was that we had difficult understanding and implementing the CAN BUS protocol. We had trouble transmitting or receiving information from the car. We continued researching on the CAN BUS protocol and we analyzed the drivers. After very long hours of research and close analyzation, we were able to enable the CAN communication from the car's system to our CAN controller on the SJ One Board.

Issue #3

Every time we plugged the OBD-II into the vehicle and ran the software, the voltage regulator became extremely hot and the transceiver started smoking. We tested 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 was 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 the application of the OBD-II device. After completing this project, we learned how the CAN BUS protocol works, what's in the hardware implementation for an OBD-II device, and how to write drivers for the CAN BUS protocol. Figure 9 displays the final design of our OBD-II. We learned how the information is transmitted and received to capture real-time data of a vehicle. We gain more insight on how the car's system connects over the CAN BUS protocol through the OBD-II to DB-9 cable to the transceiver and CAN controller. 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 that can be transmitted and received. We are planning to incorporate and enhance this project into other projects that we will be working on in future classes. We look forward to working on this project in the future and building on it for other projects that we will be completing in the future.

Figure 9. Final Design.

Project Video

https://youtu.be/7Dob8sZ-bcg

Project Source Code

https://sourceforge.net/projects/obd2/files/OBD2%20on%20FREERTOS/

References

Acknowledgement

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

Preet Kang and Dr. Haluk Ozemek

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/

OBD2 PID https://en.wikipedia.org/wiki/OBD-II_PIDs

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

Retrieved from "http://socialledge.com/sjsu/index.php?title=F15:_Car_Report&oldid=22768"