F16: E-Bike - Revision history

146 user13: /* Hardware Interface */

2016-12-20T09:24:57Z

‎Hardware Interface

146 user13: /* MOSFET */

2016-12-20T09:22:56Z

‎MOSFET

146 user13: /* Conclusion */

2016-12-20T09:21:54Z

‎Conclusion

146 user13: /* Appendix */

2016-12-20T09:01:58Z

‎Appendix

146 user13: /* References Used */

2016-12-20T08:52:23Z

‎References Used

146 user13: /* Acknowledgement */

2016-12-20T08:52:09Z

‎Acknowledgement

146 user13: /* Grading Criteria */

2016-12-20T08:51:30Z

‎Grading Criteria

146 user13: /* Testing & Technical Challenges */

2016-12-20T08:49:51Z

‎Testing & Technical Challenges

146 user13: /* Implementation */

2016-12-20T08:49:31Z

‎Implementation

146 user13: /* Hardware Interface */

2016-12-20T08:49:07Z

‎Hardware Interface

@@ Line 236: / Line 236: @@
-The ADC interface utilizes the on-board 12-bit ADC built into the LPC1768 CPU. We needed to understand the pins, registers, and how they worked to give a digital voltage reading. The CPU uses a 12-bit successive approximation register to get the reading of the analog voltage as displayed in the diagram above. The max operating voltage it can read is 3.3V since that is also its reference voltage. With this in mind, we knew we had a sample size of 0.8mv which was accurate for our needs. After figuring all this out, following the manual for the driver and for actually computing information was easy. We are using a voltage dividing circuit to measure the overcharge voltage of the battery according to the table below. The overcharge voltage is sent to an ADC channel on the CPU (we had 8 different ones to choose from), and the voltage we read there gives us a percentage that can be calculated based on the known maximum value.
+The ADC interface utilizes the on-board 12-bit ADC built into the LPC1758 CPU. We needed to understand the pins, registers, and how they worked to give a digital voltage reading. The CPU uses a 12-bit successive approximation register to get the reading of the analog voltage as displayed in the diagram above. The max operating voltage it can read is 3.3V since that is also its reference voltage. With this in mind, we knew we had a sample size of 0.8mv which was accurate for our needs. After figuring all this out, following the manual for the driver and for actually computing information was easy. We are using a voltage dividing circuit to measure the overcharge voltage of the battery according to the table below. The overcharge voltage is sent to an ADC channel on the CPU (we had 8 different ones to choose from), and the voltage we read there gives us a percentage that can be calculated based on the known maximum value.
 <br> <br>
 Table 1: Overcharge Voltage Chart Readings
@@ Line 279: / Line 279: @@
 =====UART=====
-The screen on our e-bike utilizes the UART communication bus. In particular, we are using UART2 from the LPC1768 CPU. The details of the driver code and communication are given in the software section below. For the hardware interface, it's important to note that our screen's RX and TX complement the board's, and both devices share a common ground.
+The screen on our e-bike utilizes the UART communication bus. In particular, we are using UART2 from the LPC1758 CPU. The details of the driver code and communication are given in the software section below. For the hardware interface, it's important to note that our screen's RX and TX complement the board's, and both devices share a common ground.
 [[File:CmpE146 F16 Screen.JPG|500px|center|thumb|Figure #6. Screen]]

@@ Line 309: / Line 309: @@
 All MOSFET decisions are based on GPIO input and the battery level. The decisions our task makes is based on the flow chart below.
-[[File:CmpE146 F16 SoftFlow.png|500px|center|thumb|Figrue #9. MOSFET Decisions]] <br>
+[[File:CmpE146 F16 SoftFlow.png|500px|center|thumb|Figure #9. MOSFET Decisions]] <br>
 <br>

@@ Line 420: / Line 420: @@
 == 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?
+Our e-bike embedded system is a project we are very proud of. It integrated many of concepts we not only learned in CMPE146, but at SJSU during our undergrad education. The protocols, design processes, and algorithms incorporate something from many of our classes which makes us especially proud of the work we put in. We will continue testing and working on this project as our senior project next semester because the end product was very satisfying despite the long hours put in to reach it. Perhaps the biggest thing we learned was to create more time for testing to not only fix defects, but to improve on the original design. During testing, we had to adapt parts and change the circuit as new issues came up. While we are happy with the product now, we know there's still so much more we can do with it. Future work includes improving the grip between the motor and wheel, cleaning up the cables, doing more robust testing on the generator circuit, improving heat dissipation inside the circuit box, and removing the screen to display battery information on a mobile app instead. We were a little skeptical that we could complete all the tasks we outlined at the beginning of the project, but as we got more into it, it was easier to work on because things started getting more interesting and fun. We ended up hitting the core aspects of our initial objectives by doing a ton of research on thing we didn't know and polishing up on concepts we already had a strong grasp on. Ultimately, what we have built will be a part of the future for our planet in some form or another because our current energy consumption is not sustainable. Using the very prominent embedded systems concepts developed on our bike here, we hope we can continue to improve it and contribute to a healthier future.
 * [[File:CmpE146_F16_Ebike.jpg|500px|center|thumb|Figure #10. Completed E-Bike]]

← Older revision		Revision as of 09:01, 20 December 2016
Line 439:		Line 439:

	=== Appendix ===		=== Appendix ===
−	~~You can list the references you used~~.	+	*[http://www.nxp.com/documents/user_manual/UM10360.pdf LPC1758 Datasheet]
		+	*[http://www.st.com/content/ccc/resource/technical/document/datasheet/bf/f6/23/6a/d8/7f/4a/e0/CD00000701.pdf/files/CD00000701.pdf/jcr:content/translations/en.CD00000701.pdf IRF630 Power MOSFET Datasheet]
		+	*[https://www.itead.cc/wiki/Nextion_Instruction_Set Nextion Screen Instruction Set]

@@ Line 433: / Line 433: @@
 == References ==
 === References Used ===
 * [http://www.popularmechanics.com/cars/how-to/a181/1276826/ Mounting a Motor]

← Older revision		Revision as of 08:51, 20 December 2016
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>~~
−
	== E-Bike ==		== E-Bike ==

← Older revision		Revision as of 08:49, 20 December 2016
Line 403:		Line 403:

	== 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:~~

	===Software Challenges ===		===Software Challenges ===

@@ Line 401: / Line 401: @@
 **Battery ---> Buck Converter ---> SJOne Board ---> Screen
 **Generator ---> Rectifying Bridge ---> Boost Converter ---> Battery
 == Testing & Technical Challenges ==

← Older revision		Revision as of 08:49, 20 December 2016
Line 242:		Line 242:

	=== 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.

	=====ADC=====		=====ADC=====