F15: Car Report - Revision history

Preet: /* Grading Criteria */

2015-12-19T18:01:17Z

‎Grading Criteria

Proj user18: /* Implementation */

2015-12-19T07:11:46Z

‎Implementation

Proj user18: /* Implementation */

2015-12-19T07:02:48Z

‎Implementation

Proj user18: /* Implementation */

2015-12-19T07:00:51Z

‎Implementation

Proj user18: /* Conclusion */

2015-12-19T06:59:55Z

‎Conclusion

Proj user18: /* Implementation */

2015-12-19T06:33:25Z

‎Implementation

Proj user18: /* Software Design */

2015-12-19T06:32:18Z

‎Software Design

Proj user18: /* Conclusion */

2015-12-19T06:29:28Z

‎Conclusion

Proj user18: /* Issue #3 */

2015-12-19T06:27:42Z

‎Issue #3

Proj user18: /* Issue #2 */

2015-12-19T06:27:13Z

‎Issue #2

← Older revision		Revision as of 18:01, 19 December 2015
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 over CAN BUS Protocol'''		'''Car Project: OBD-II Design over CAN BUS Protocol'''

@@ Line 260: / Line 260: @@
 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 represent a block diagram of the software implementation.
+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.]]

@@ Line 260: / Line 260: @@
 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.
+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 represent a block diagram of the software implementation.
-[[File:CMPE146_F15_CarReport_softwareBlockDiagram.jpg|500px|thumb|centre|Figure 1. 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 ==

@@ Line 261: / Line 261: @@
 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.
 == Testing & Technical Challenges ==

@@ Line 277: / Line 277: @@
 == 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 8 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.
+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 8. Final Design.]]
+[[File: CMPE146_F15_CarReport_FinalDesign.jpg|500px|thumb|centre|Figure 9. Final Design.]]
 === Project Video ===

@@ Line 251: / Line 251: @@
 === Software Design ===
-The CAN 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 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 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.
+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 ===

@@ Line 273: / Line 273: @@
 === 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 were correct.
+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 ==

@@ Line 270: / Line 270: @@
 === 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 system to our CAN controller on the SJ One Board.
+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 ===