EE 477 Final Report - Purdue University
ECE 477 Final Report
Spring 2006
Team Code Name: _______SPOTDash_______________________ Team ID: ___14__
Team Members (#1 is Team Leader):
#1: ______Yuk Hang Chan________ Signature: ____________________ Date: _________
#2: ______Nathanael Huffman_____ Signature: ____________________ Date: _________
#3: ______Yuan-Jiun Sung________ Signature: ____________________ Date: _________
#4: ______Wei Zhou______________ Signature: ____________________ Date: _________
REPORT EVALUATION
|Component/Criterion |Score |Multiplier |Points |
|Abstract |0 1 2 3 4 5 6 7 8 9 10 |X 1 | |
|Project Overview and Block Diagram |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Team Success Criteria/Fulfillment |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Constraint Analysis/Component Selection |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Patent Liability Analysis |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Reliability and Safety Analysis |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Ethical/Environmental Impact Analysis |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Packaging Design Considerations |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Schematic Design Considerations |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|PCB Layout Design Considerations |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Software Design Considerations |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Version 2 Changes |0 1 2 3 4 5 6 7 8 9 10 |X 1 | |
|Summary and Conclusions |0 1 2 3 4 5 6 7 8 9 10 |X 1 | |
|References |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Appendix A: Individual Contributions |0 1 2 3 4 5 6 7 8 9 10 |X 4 | |
|Appendix B: Packaging |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Appendix C: Schematic |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Appendix D: Top & Bottom Copper |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Appendix E: Parts List Spreadsheet |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Appendix F: Software Listing |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Appendix G: FMECA Worksheet |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Technical Writing Style |0 1 2 3 4 5 6 7 8 9 10 |X 8 | |
|CD of Project Website |0 1 2 3 4 5 6 7 8 9 10 |X 1 | |
| |TOTAL | |
TABLE OF CONTENTS
|Abstract |1 |
| 1.0 Project Overview and Block Diagram |1 |
| 2.0 Team Success Criteria and Fulfillment |3 |
| 3.0 Constraint Analysis and Component Selection |4 |
| 4.0 Patent Liability Analysis |12 |
| 5.0 Reliability and Safety Analysis |15 |
| 6.0 Ethical and Environmental Impact Analysis |19 |
| 7.0 Packaging Design Considerations |22 |
| 8.0 Schematic Design Considerations |24 |
| 9.0 PCB Layout Design Considerations |27 |
|10.0 Software Design Considerations |29 |
|11.0 Version 2 Changes |34 |
|12.0 Summary and Conclusions |35 |
|13.0 References |37 |
|Appendix A: Individual Contributions |A1 |
|Appendix B: Packaging |B1 |
|Appendix C: Schematic |C1 |
|Appendix D: PCB Layout Top and Bottom Copper |D1 |
|Appendix E: Parts List Spreadsheet |E1 |
|Appendix F: Software Listing |F1 |
|Appendix G: FMECA Worksheet |G1 |
Abstract
The driver interface system for the Purdue solar car provides relevant information about the status and performance of the vehicle to the operator, allowing the operator to make accurate race decisions based on up-to-date information. This system displays the information using an LCD menu system which the operator navigates with an RPG and a “Back” button, allowing real-time selection of displayed data and giving the operator the ability to change car parameters. The information, received by the driver interface board from the other nodes on the CAN bus, is organized and then displayed to the operator. The following sections provide specifics about the design and operational characteristics of this system as well as detailing the design process used to successfully complete this project.
1. Project Overview and Block Diagram
The SPOT Dash driver interface includes a control unit based on a PIC 18F4680 microcontroller, a display unit using an I2C LCD display, an RPG encoder and two push buttons. It communicates with the Maximum Power Point Trackers (MPPTs) and the telemetry device on the solar car via CAN bus (Figure 1.1). In order to upgrade the electronic components on the solar car, three projects from senior design class were selected to complete the design of an information system. Those three teams are the Telemetry Team, the Maximum Power Point Tracker Team, and the Driver Interface Team. The MPPTs are used to maximize the power going into the battery pack by finding the optimal spot on the I-V curve. The telemetry system is used to get GPS data and the status of the motor controller and the battery pack as well as to communicate with the chase car. The driver interface then integrates all the information available from the different nodes on the CAN bus and displays it to the driver. By providing more useful data of the solar car to the driver, the three devices are designed for maximizing the chance to win a race.
In the driver interface system (Figure 1.2), there is a menu system, which is navigated by the driver using the RPG encoder and the return push button. The driver can select the information he wants to display on the LCD using the RPG and the requested information will be displayed. When a serial cable is plugged in, the device will switch to debug mode automatically and output a menus system to a terminal on the connected PC. The system includes the ability to control the on-off status of the MPPTs allowing the driver to turn off individual MPPTs to prevent the battery cell from being overcharged. Additionally, the device can read and display text messages sent from telemetry system (which could come from the chase car) and display them to the driver. After 10 seconds of no activity the system switches back to idle mode and displays the most important information on the solar car to the driver: speed, battery level and current level.
Figure 1.1 Solar Car Block Diagram
[pic]
Figure 1.2 SPOT Dash Block Diagram
[pic]
2. Team Success Criteria and Fulfillment
The following list details the five Project Specific Success Criteria which were written to guide the design and prove functionality:
An ability to display vehicle status information on an LCD.
An ability to navigate display menus and make selections using an RPG.
An ability to perform LCD backlight power management (e.g., turn the backlight on for X seconds after the RPG is turned/pressed).
An ability to obtain vehicle diagnostic information via the CAN bus.
An ability to switch to “debug” mode (when a RS-232 cable is connected) in which a diagnostic menu is displayed.
All five of the success criteria were demonstrated successfully to the course staff and were also documented in a video presentation.
Constraint Analysis and Component Selection
3.1 Design Constraint Analysis
This section will consider the design constraints associated with building a driver interface for the solar car. It will discuss the requirements and show the major component selection rationale used to meet these constraints. From an electrical perspective, this product should be as efficient as possible and cannot exceed 400mA at 12Vdc (4.8W). This product should fall well under this specification by considering how and where power can be saved. From a usability and packaging perspective, this device has to be small enough to be mounted in the cockpit of the solar car, be visible to the driver without requiring much distraction from the task of driving, and allow driver interaction in a comfortable manner. Since all of the power for the car comes from the solar cells, and the main purpose of the car is racing, it is important to keep the weight of this product at a minimum.
3.1.1 Computational Requirements
This product will communicate with other nodes on the CAN bus, display information to the driver on a serial LCD, and allow the driver to navigate the menus to select desired information. This product will provide a changing display which will revert to an idle screen showing the most critical information after a timeout period from the last user input. From a computation standpoint, these are all fairly slow (low microcontroller utilization) tasks relative to the 40MHz clock speed of the microcontroller.
2. Interface Requirements
LCD and LED Interfacing:
The interface to the LCD is a 2-wire I2C interface which operates at standard 5Vdc CMOS logic levels. The LEDs will be driven directly by pins from the microcontroller since the microcontroller can source or sink 25mA per pin up to 200mA for the whole device.
Communications Interfacing:
The CAN interface requires two pins and will interface with a Microchip MCP2551-I/SN CAN transceiver for CAN communication with other nodes in the vehicle. The RS-232 interface requires 2 pins and will interface with a MAX3235ECWP RS-232 level translator.
Driver Interfacing:
The driver will interact with this product using an RPG with an integrated push button for selection and up to four other buttons all of which will be mounted on the steering yoke of the solar car. Two regular I/O pins will be used to decode the quadrature output of the RPG and the buttons will be connected to the microcontroller which will provide de-bouncing via software. Any buttons located at the end of the steering harness will be isolated optically to protect from harnessing errors or static buildup.
Analog Interfacing:
In order to provide feedback for the diagnostics, this product will sample the 5Vdc supply voltage and provide this information in the diagnostic report. In addition to monitoring the supply voltage, there will be an on-board temperature sensor and a phototransistor sensitive to visible light to allow automatic LCD backlight control. Three I/O pins in the A/D bank will be used to accomplish the analog interfacing.
Cable Interfacing:
For all signals that connect to a wiring harness, with the exception of the CAN and RS-232 signals, optical isolation will be provided so that external noise is not coupled into the system and also as a protection feature in the event of a cabling failure. The signals of interest are the buttons and RPG output signals which will be on the steering wheel.
All of the external devices communicate at the standard 0-5Vdc voltage levels. While the PIC18F series of microcontrollers is capable of sourcing/sinking 25mA of current per pin with a limit of 200mA sourcing/sinking for the whole device, a majority of the I/O from the microcontroller will interface with CMOS logic which requires very little drive current, and most of the LEDs and other higher current devices will interface with the micro through transistors to reduce the amount of current the microcontroller will need to source or sink. Table 3.1.1 shows a summary of the I/O pins required (30 in total), leaving 6 free I/O ports for debugging or design errors or additions.
Table 3.1.1 Summary of I/O for PIC18F4680
|# of Pins |Voltage Swing |Use |Description/Direction |
|2 |0-5Vdc |SPI/I2C |I2C interface |
| | | |(LCD) |
|2 |0-5Vdc |CAN |must use pins 10,11 |
|2 |0-5Vdc |RS232 |must use pins 1,44 |
|3 |0-5Vdc |Buttons |User interface buttons |
| | | |remote buttons w/ optoisolation |
|2 |0-5Vdc |RPG |OutputA,B from RPG (optoisolated) |
|3 |0-5Vdc |A/D ports |Temp, Voltage, Light detect |
|3 |0-5Vdc |LED |LEDs |
|1 |0-5Vdc |Buzzer |Buzzer enable |
|3 |0-5Vdc |Programmer |ICSP |
|1 |0-5Vdc |Reset | |
|2 |0-5Vdc |Crystal |Crystal input, all solar projects to |
| | | |use same crystal |
|3 |0-5Vdc |Cable Connections |I/O for detecting cable connections |
3. On-Chip Peripheral Requirements
PWM:
The PIC18F series of microcontrollers provides a number of on-chip peripherals and this product makes use of many of them. As previously mentioned, the ability to control the brightness of the LCD module based on user preferences and ambient lighting conditions requires a method of controlling LED brightness. Using 3 channels of 10-bit PWM, 1 channel will control the brightness of the LCD backlight, 1 channel will control the brightness of all of the other LEDs, and the remaining channel will control the buzzer.
CAN:
The ECAN module will be utilized to provide a communication with the CAN network on the solar car. Since CAN is a multi-tap network, two or more on-board connections can be provided while still only needing 1 CAN channel. A CANOpen stack for the PIC18F series microcontrollers is available from Microchip.
RS-232:
The EUSART module will be utilized to provide RS-232 communications which will not only facilitate development and debugging but provide an interface for the solar pit crew to read diagnostic information from the driver interface and change system settings without using the driver interface (which would be inconvenient when the car is in pit configuration).
A/D:
The A/D module will be utilized for measuring analog voltages including a temperature sensor, the supply voltages, and the phototransistor.
Timers:
The timer modules provide the ability to track time between user inputs (for the timeout feature) and provide regular interrupts for button debouncing and cable status checks.
4. Off-Chip Peripheral Requirements
A majority of the functionality of this product can be accomplished using the internal peripherals so the only external devices will be level translators for the CAN and RS-232 interfaces and a buzzer. The buttons and RPG are external components that communicate with the microcontroller but the decoding and de-bouncing will be taken care of in software on the microcontroller.
3.1.5 Power Constraints
For this product there are a number of things that need to be considered from a power standpoint, the most obvious of which is the fact that all of the power for the car comes from the solar panels (or the battery which is charged by the solar cells). For best performance, as much of the available power needs to go to the propulsion of the vehicle so all of the supporting electronics should be designed in the most efficient manner possible. The power constraint dictated by the solar team is 400mA at 12Vdc which translates to 4.8W of available power for this product. For the aforementioned reasons, this product should use as little power as possible during operation and dynamically manage the power consumption as much as possible. In order to manage power, peripherals that are not in use will be shut down and the LCD backlight brightness will be dynamically adjusted based on ambient light and user preferences to minimize power consumption. Another consideration, when looking at efficiency, is the operating temperature which will vary significantly in the car (rising above 110° F) and affect the efficiency of the devices in this product.
3.1.6 Packaging Constraints
One of the themes of this product is efficiency and while there are no set packaging criteria, this product will be as light as possible to reduce the effect of adding it to the existing system. Due to the situation of the driver while operating the car, it is necessary to separate the buttons and RPG from the package so that they will be accessible to the driver. One of the goals of the user interface is to make it a module so that it can be replaced with minimal effort by the pit crew in the case of damage or failure while still being robust enough so that it will not be a failure point for this system. This module will securely attach to the steering wheel which will provide easy access to that driver without significantly altering the current cockpit design. To protect the product, optical isolation is provided for the signals that run to this module recognizing that the cable harness will be subject to stresses as the steering wheel moves and there is a potential for this to cause problems.
Since the solar car is optimized for efficiency and not comfort, this product will need to remain reliable in an environment with a significant amount of vibration. Aside from a secure mounting in the box, connectors with a positive lock will be utilized and the harnessing will be secured to reduce the load seen by the connectors on this product. The connectors have been selected with this environment in mind, the MTE connectors are used extensively in the existing designs on the solar car with excellent results and the sub-D connector provides jackscrews which helps keep the cable secure.
3.1.7 Cost Constraints
Due to the nature of this design and intended use this product does not directly compete with any existing products on the market and so it does not have to compete at a specific price point. Although this is true, the solar team relies on donations and external funding and the money not only funds the current designs but is used to optimize and research new technologies. The driver interface should be designed as economically as possible so that the solar team can spend the money on other projects which translate to a direct performance improvement of the car. This product should be completed at a cost less than $200/unit recognizing that the design is more expensive in the quantity required by the solar team. One of the features of this product is its extensibility so that new features could be added without purchasing a new design, which saves money over a longer period of time.
1. Component Selection Rational
Microcontroller:
This report will compare the PIC18F4680 which is what this product is based on to the PIC18F2680 and to the AT89C51CC03. One of the design constraints is the use of a PIC18F series microcontroller because the solar team has invested in development tools in this product family. This report will also compare to an Atmel part for thoroughness and comparison with other microcontrollers on the market. See Table 3.2.1 for an at-a-glance comparison.
Table 3.2.1 Microcontroller feature summary
| |PIC18F4680 |PIC18F2680 |AT89C51CC03 |
|Pins: |44 |28 |44 or 64 |
|I/O: |36 |25 |36 |
|Flash (Kb): |64Kb |64Kb |64Kb |
|SRAM (bytes): |3328 |3328 |2304 |
|CAN: |Yes |Yes |Yes |
|EEPROM (bytes): |1024 |1024 |2048 |
|A/D: |11x 10bit |8x 10bit |8x 10bit |
|PWM: |4 channel 10bit |1 channel 10bit |5 channel 8bit |
|SPI: |Yes |Yes |Yes |
|USART |Yes |Yes |Yes |
|Timers: |1 8bit, 3 16bit |1 8bit,3 16bit |3 16bit |
|Cost: |$6.08 |$5.54 |$7.13 |
Information in this table can be found the following datasheets: Microchip:[1] Atmel: [2]
Since the two PIC18F microcontrollers come from the same family they share similar characteristics but there are a few important things to note. First off is the I/O difference, knowing that this product needs 30 pins of I/O but this could be overcome by utilizing the PLD which, while not leaving as much room for expansion, would be able to satisfy the I/O problem. The bigger problem is the lack of more than one PWM channel since this product needs 3 channels of PWM. A possible solution to this problem would be to implement an off-chip PWM for the extra channels but this would require additional hardware which would quickly eat up the $0.54 cost savings between the devices. Looking at the minimal cost difference, the need for PWM, and available on-chip resources, the PIC18F4680 comes out on top as the most economical and practical since it meets all of the design constraints and provides more flexibility than does the PIC18F2680 microcontroller.
After ruling out the PIC18F2680, the comparison comes down to the PIC18F4680 and the AT89C51CC03 microcontrollers. For the sake of argument this analysis ignores the requirement to use the PIC18F series and compares only the technology and economics of these two microcontrollers. The big differences are seen when looking at the available SRAM, EEPROM, and the microcontroller cost. While the Atmel part has 1Kb more EEPROM than the PIC18F, it lacks almost 1Kb in SRAM. This product will not be storing large amounts of data to EEPROM but having more SRAM could be very important, especially when trying to display information on an LCD. It should also be noted that 1Kb of SPI-compatible EEPROM can be purchased for less than $0.50 even in small quantities [3]. The Atmel microcontroller also has an extra PWM channel when compared to the PIC18F4680 but the design constraints require only 3 channels of PWM. It should also be noted that the Atmel part can sink only 10mA per pin with a device sinking limit of 71mA compared to the PIC18F’s 25mA per pin source/sink and a 200mA source/ sink device limit. Coupled with the additional cost and the smaller amount of SRAM of the Atmel microcontroller, the PIC18F4680 is again the best choice for this product. The power dissipation for both devices is 1W so there will not be much power savings by going with one or the other.
Power Supply:
For the power supply there were a number of options on the market. Due to the aforementioned need for efficient power consumption, linear regulators can be ruled out in favor of switching power supplies which provide a much greater efficiency. One of the power supplies mentioned in the power supply notes (LTC1174-5) [4] is a possible candidate. Another candidate is a part made by Maxim (MAX1684) [5]. Unlike the microcontrollers, direct comparison of these two parts is more difficult because the graphs in the datasheets require some extrapolation since not all possible combinations are shown. A cursory comparison of the two shows that the Maxim part could provide slightly more than the maximum power (4.8W) available to this product while the Linear part will supply up to 600mA at 5Vdc (3W). Looking at the total power consumption for this product either of these devices will be able to supply enough current to adequately power it.
Fig 3.0.1 LTC1174-5 Efficiency graphs
[pic] [pic]
(a) (b)
Fig 3.0.2 Max1684 De-rating curves
[pic]
The Linear part does not show the curve for 12Vdc in on the same curve as the efficiency vs. load current but between the two graphs (a, b) in Figure 3.0.1. Comparing the previous two graphs with the line “F” in Figure 3.0.2 shows that at 300mA, 12Vdc input the two devices perform with nearly identical efficiency. From an electrical standpoint, either of these devices would satisfy the design constraints. Using DigiKey as a reference the Maxim part is listed at $8.56 whereas the Linear part is listed at $6.88. The Linear part is in an 8-lead package and requires 1 inductor, 4 capacitors, and 1 diode as external parts. The Maxim part is in a 16-lead package and requires 1 inductor, 8 (1 optional) capacitors, and 1 diode. Taking into account the additional components, cost differences, and board real-estate; the Linear part fits all of the requirements, takes up less space and requires fewer external components making this the preferred option.
LCD:
This comparison will focus on two different LCD modules, the LCD2041 from Matrix Orbital [6] which features a serial interface, and the CFAH2004A-YYB-JPE from Crystalfonz [7] which features a parallel interface. Each of these displays has an LED backlight and draws similar amounts of current (100mA, 5Vdc for the Matrix Orbital and 101.6mA, 5Vdc for the Crystalfonz) and they are similarly sized. The main differences between these two displays are cost ($57.00 for the Matrix Orbital vs. $22.55 for the Crystalfonz) and ease of system integration. Although there is a sizeable price difference between the two, the all-in-one solution provided by the serial LCD module provides ease of integration. The ability to plug the LCD module in and get it working quickly will aid in getting a more usable user interface. Using a serial LCD module has the additional benefit of easily changing to a different serial display with minimal software impact and no hardware modification. This provides flexibility for the solar team if new display technology is desired.
3. Patent Liability Analysis
1. Results of Patent and Product Search
A thorough patent search using the USPTO website [8] gives a number of results related to the driver interface system. The first round of searching was done by using keyword “Display” and “Vehicle” on the title and a total of 397 patents were found. Of these results was selected for detailed analysis. The key world “Information” was added in order to refine the search parameters. 27 matches were found and of those, 4 were selected for analysis. All four patents describe similar functions: displaying the status of the vehicle to the driver at real time.
United State Patent Number: 5,006,829 Filed March 31, 1988
Information display system for a vehicle
This patent includes a plurality of sensors, a display unit and a pair of input buttons. The sensors are used to detect various conditions of the vehicle. The two input buttons are used for sequentially shifting the item which is currently displayed on the display unit. The user can manually select the specific information to display onto the display unit, but after a certain time interval, the display unit will restore the default display information. The control unit is capable of selecting different information to be displayed on different sections of the display unit. Additionally, indicators are used to alert the user of other messages or information. The key claim leading to potential infringement seems to be the manual switch of the patent. The design has similar features to that of the Solar Car driver interface (the user and sequentially navigation through out the menu by turning the RPG button). This patent is assigned to Honda Giken Kogyo K.K. [9]
United State Patent Number: 6,289,332 Filed March 18, 1999
Integrated message display system for a vehicle
This integrated message system acts as a centralized message provider for a variety of alerts and vehicle status. There is a hierarchy of message levels where each message level has a unique output protocol. Each output protocol will generate different outputs, such as textual or graphical message, an auditory alert, etc. The system also integrates a variety of subsystems such as a collision warning system and a cruise control system. Similar to the solar car driver interface, this patent consists of three major modules: a control unit, a display unit and an audio transducer. When there is an alert, both systems will generate a textual message and an audio signal to indicate the user. This patent is assigned to Freightliner Corporation. [10]
United State Patent Number: 5,121,112 Filed December 26, 1989
Display apparatus for vehicle
This patent includes a plurality of sensors, a priority determining module, a display control module and a display unit that have two display segments. Each signal is assigned a degree of priority. When higher priority message comes in, it is shown on the main display segment. When lower priority message comes in, it is shown onto the indication display segment. The crux of this patent seems to be the two segments of display. In the solar car driver interface, a separate area of the display will be used to indicate an alert message. This patent is assigned to Nissan Motor Company, Ltd. [11]
United State Patent Number: 5,764,139 Filed October 22, 1996
Information display apparatus for vehicles
This patent consists of various sensors for detecting the running conditions of the vehicle. Status of the vehicle is updated and stored in memory. Each piece of information is assigned a degree of importance. When the vehicle is running straight, the display area is increased to show more speed information and when the vehicle is traveling in reverse, the display area increases to contain information about the conditions behind the vehicle. The key claims of this patent are that the vehicle’s operating data is collected frequently and stored in memory and when the vehicle is running straight, the display area of speed will be increased. When a vehicle is traveling straight, an increased speed display keeps the driver alert in order to avoid exceeding the speed limit. This patent is assigned to Toyota Jidosha Kabushiki Kaisha. [12]
2. Analysis of Patent Liability
4.2.1 Literal infringement
Literal infringement occurs when one manufactures and/or uses an invention or improvement for which someone else owns a patent issued by the government, without obtaining permission of the owner of the patent by contract, license or waiver [13]. In other words, each of the patented invention’s claims must be found in the design. Three out of four of the patents under review are not examples of literal infringement. The fourth, “Information display system for a vehicle” looks as if there could be some literal infringement on the part of the solar car driver interface. “The Integrated message display system for a vehicle”; “The Display apparatus for vehicle” and “The Information display apparatus for vehicle” are each substantially different from the design in question.
“The Information display system for a vehicle” is very similar to what is being designed in this project. One of the patented invention’s claims is that it has a pair of manual buttons for sequentially shifting the item of information, which is similar to the way of operation in the design project. The other part of the key claim is that after certain time interval, the display is changed back to the default display mode from user configuration mode. However, there is one claim that made by the patent assignee that states that the system will assign priority level to each individual signal. The message priority level is clearly not a part of solar car driver interface.
4.2.2 Infringement under doctrine of equivalents
Unlike literal infringement, infringement under doctrine of equivalents is not as easily identified. It is hard to determine what function is substantially the same and what is not. The three other patents have similar functions but they also have some substantially different functions from the solar car driver interface.
All four patents found, as well as the solar car driver interface, consist of a control unit, a display unit and an interfacing used to control the system. Their purposes are the same as well: displaying the vehicle’s status to the user. To identify the distinction, the focus should be on the way the information is displayed. Each patent has a unique feature for displaying the information. For example the “Information display apparatus for vehicle” has a function that increases the speed display area when the vehicle is running straight. This feature is not provided by the solar car driver interface. Unlike the “Display apparatus for vehicle”, this design project does not have a priority determining module. Each individual status is displayed only if the user selects it. For the “Integrated message display system for a vehicle”, the message system has a defined a hierarchy of message levels, whereas this design project only supports one message at a time without priority.
Clearly, this design project does not infringe on any of the three patents mentioned above except the Information display system for a vehicle. Although the functionality may be similar to each other, the differences are easily identified. Further investigation needs to be done for the Information display system for a vehicle, as this is the only patent that may be infringed under the doctrine of equivalents to the design project.
4. Reliability and Safety Analysis
There are four major components included in this reliability analysis section. They’re 5V DC/DC Converter, microcontroller, CAN transceiver and RS232 transceiver. They were chosen because they’re crucial to the operation of SPOT Dash and working above the room temperature which increases their chances of failure.
The reliability model for all the components was taken from the Section 5.1 of the Military Handbook Reliability Prediction of Electronic Equipment [14]. The environment constant ((E) is 4.0 for all the components, because SPOT Dash is mounted on a moving vehicle. The quality factor ((Q) is 1.0 for all the components, because they were all commercial components. The learning factor ((L) is 1.0 for all the components, because they were all in production for more than two years. The choices for the remaining of parameters are explained below in each individual table.
5.1 LTC1174HVCS8-5 5V DC/DC Converter
(p = (C1(T + C2(E) (Q(L (MIL-HDBK-217F, Section 5.1)
Table 5.1.1 Reliability Parameters for LTC1174HVCS8-5
|Parameter |Value |Justification |
|C1 |0.020 |Assumed for linear MOS device with 101 to 300 transistors. (MIL-HDBK-217F, |
| | |Section 5.1) [14] |
|C2 |0.0034 |8 Pin SOIC device |
| | |C2 = 3.6 x 10-4 (Np)1.08 |
| | |(MIL-HDBK-217F, Section 5.9) [14] |
|(T |2.8 |Linear MOS device |
| | |TJ used 70C (Normal operation from 0°C to 70) |
| | |(MIL-HDBK-217F, Section 5.8) [14] |
|(E |4.0 |Assumed ground mobile environment |
| | |(MIL-HDBK-217F, Section 5.10) [14] |
|(Q |1.0 |Commercial component |
| | |(MIL-HDBK-217F, Section 5.10) [14] |
|(L |1.0 |Years in production ≥ 2.0 |
| | |(MIL-HDBK-217F, Section 5.10) [14] |
Calculation Results:
(p = 0.0696 Failures/106 Hours
MTTF = 1 / (p = 14367816 Hours ≈ 1.4368 x 107 Hours
2. PIC18F4680 Microcontroller
(p = (C1(T + C2(E) (Q(L (MIL-HDBK-217F, Section 5.1) [14]
Table 5.2.1 Reliability Parameter for PIC18F4680
|Parameter |Value |Justification |
|C1 |0.14 |8-bit Microprocessor |
| | |(MIL-HDBK-217F, Section 5.1) [14] |
|C2 |0.021 |44 Pin SMT device |
| | |C2 = 3.6 x 10-4 (Np)1.08 |
| | |(MIL-HDBK-217F, Section 5.9) [14] |
|(T |0.98 |Digital MOS device |
| | |TJ used 85°C (Normal operation from -40°C to 85°C) |
| | |(MIL-HDBK-217F, Section 5.8) [14] |
|(E |4.0 |Assumed ground mobile environment |
| | |(MIL-HDBK-217F, Section 5.10) [14] |
|(Q |1.0 |Commercial component |
| | |(MIL-HDBK-217F, Section 5.10) [14] |
|(L |1.0 |Years in production ≥ 2.0 |
| | |(MIL-HDBK-217F, Section 5.10) [14] |
Calculation Results:
(p = 0.2212 Failures/106 Hours
MTTF = 1 / (p = 4520795 Hours ≈ 4.52 x 106 Hours
5.3 MCP2551I/SN CAN Transceiver
(p = (C1(T + C2(E) (Q(L (MIL-HDBK-217F, Section 5.1) [14]
Table 5.1.1 Reliability Parameters for MCP2551I/SN
|Parameter |Value |Justification |
|C1 |0.0050 |Assumed for Digital MOS device with 101 to 1000 transistors. |
| | |(MIL-HDBK-217F, Section 5.1) [14] |
|C2 |0.0034 |8 Pin SOIC device |
| | |C2 = 3.6 x 10-4 (Np)1.08 |
| | |(MIL-HDBK-217F, Section 5.9) [14] |
|(T |0.98 |Digital MOS device |
| | |TJ used 85 °C (Normal operation from -40°C to 85°C) |
| | |(MIL-HDBK-217F, Section 5.8) [14] |
|(E |4.0 |Assumed ground mobile environment |
| | |(MIL-HDBK-217F, Section 5.10) [14] |
|(Q |1.0 |Commercial component |
| | |(MIL-HDBK-217F, Section 5.10) [14] |
|(L |1.0 |Years in production ≥ 2.0 |
| | |(MIL-HDBK-217F, Section 5.10) [14] |
Calculation Results:
(p = 0.0185 Failures/106 Hours
MTTF = 1 / (p = 54054054 Hours ≈ 5.41 x 107 Hours
5.4 MAX232A/SO RS232 Transceiver
(p = (C1(T + C2(E) (Q(L (MIL-HDBK-217F, Section 5.1) [14]
Table 5.2.1 Reliability Parameters for MAX232A/SO
|Parameter |Value |Justification |
|C1 |0.0050 |Assumed for Digital MOS device with 101 to 1000 transistors. |
| | |(MIL-HDBK-217F, Section 5.1) [14] |
|C2 |0. 0034 |8 Pin SOIC device |
| | |C2 = 3.6 x 10-4 (Np)1.08 |
| | |(MIL-HDBK-217F, Section 5.9) [14] |
|(T |0.98 |Digital MOS device |
| | |TJ used 85 °C (Normal operation from -40°C to 85°C) |
| | |(MIL-HDBK-217F, Section 5.8) [14] |
|(E |4.0 |Assumed ground mobile environment |
| | |(MIL-HDBK-217F, Section 5.10) [14] |
|(Q |1.0 |Commercial component |
| | |(MIL-HDBK-217F, Section 5.10) [14] |
|(L |1.0 |Years in production ≥ 2.0 |
| | |(MIL-HDBK-217F, Section 5.10) [14] |
Calculation Results:
(p = 0.0185 Failures/106 Hours
MTTF = 1 / (p = 54054054 Hours ≈ 5.41 x 107 Hours
5.5 Reliability Conclusion
Table 5.5. Component MTTFs
|Component Name |MTTFs |
|5V DC/DC Converter |1.44 x 107 Hours |
|Microcontroller |4.52 x 106 Hours |
|CAN Transceiver |5.41 x 107 Hours |
|RS232 Transceiver |5.41 x 107 Hours |
The calculated MTTFs are placed in Table 5.5.1 for easier observation. Despite the fact that microcontroller has the lowest MTTF, it is considered to be adequate since there is no safety hazard relates to the failure of the microcontroller. The worst scenario for such failure is just an inoperable device. On the other hand the MTTF for the 5V DC/DC Converter is inadequate. The expected MTTF should be greater than 109 hours, since this component provides power to the entire project. One way to improve the reliability is to add a heat sink to the component for reduction of the operating temperature. Thus the failure rate will be reduced. For the similar reasoning as the microcontroller, the MTTFs of the CAN and RS232 Transceiver are considered adequate.
In conclusion, the MTTF is well above 106 hours for the major components in the worst case scenario and the overall reliability of the design is adequate.
5. Ethical and Environmental Impact Analysis
6.1 Ethical Impact Analysis
1. Hardware Issues
The design team members carefully analyzed each case regarding safety and reliability of the driver interface system during the component selection and PCB design phases of the product development cycle.
One extremely dangerous situation would be the driver interface system suddenly catching fire as a result of an overheating problem or completely shutting down because of damage to microcontrollers and LCD. With the failure of this system, the driver can still operate the vehicle; this is a distraction and potential danger to the driver during a race. Hence, careful selection of power component, microcontroller, user interface, and PCB design is necessary from an ethical point of view.
A high-efficiency step-down DC/DC converter was chosen not only for its high efficiency but also because of its protection against short circuits; thus in case of output voltage greater than 5V (the power required for all the peripherals), the microcontroller and LCD won’t get overheated and cause a fire hazard for the driver [4].
Since the driver interface system’s selection buttons will be mounted away from the LCD and routed through a wiring harness, optical isolation was installed to protect the microcontroller and LCD from damage. Optical isolation provides an insulating gap between two sides of a circuit to prevent currents from flowing between connected devices [15].
The PCB board was also carefully designed to avoid overheating and short-circuit problems. Most of the PCB board components are digital, with high operating efficiency; hence, minimum heat will be generated. Digital and analog components were separated from each other to avoid signal interference and short circuiting. Because of some instability of the car, the four mounting-hole positions were accurately measured to make the board fit nicely into the plastic enclosure [16].
Although these components and the PCB board were chosen and designed carefully, there is a chance that these devices will fail because of improper usage, or because they have reached the end of their lifespan. Hence, warning labels and cautions have been included in the user manual to inform the drivers of potential hazards and advise them of actions they should take to minimize the damage.
2. Software Issues
The driver interface system must provide accurate and timely information to the driver. The RPG user interface is an easy control mechanism that provides instantaneous information on the car’s operating conditions to the driver. By setting the CAN communication interrupts at the highest priority and utilizing the program’s built-in error detecting mechanism, vehicle information can be displayed correctly, in real time.
3. System Issues
Because of vibration considerations in the solar car, the electronic components within the driver interface system have the potential to fail mechanically and detach from the circuit board. Surface mount components were used where possible and the connectors have board-retention devices to reduce the mechanical strain. The LCD and PCB were tightly mounted in a plastic enclosure.
Designed by a team with a concern for ethical impacts, the driver interface system has gone through various tests under different conditions. The FMECA table provides user information on different failure modes, causes, and criticality. Solutions for these failure modes and instructions for handling damaged products are also given in the user manual as a reference for the customers.
1. Environmental Impact Analysis
Environmental issues associated with the manufacture, use, and disposal of the driver interface system have been considered during the design phase of the product development cycle. By utilizing solar energy as the primary source of power, the issue of air pollution is resolved. Now the main environmental concern would be waste problems associated with the manufacturing processes of printed circuit boards and mercury- and lead-related products, and with disposal of non-biodegradable products such as transistors, integrated circuits, and plastic enclosures [17].
1. Product Manufacture
The driver interface system consists of a plastic enclosure, an LCD, a printed circuit board, and a number of electronic components. Each of these components must be selected and analyzed carefully for its environmental impact before mass production of the product. The plastic enclosures made of starch-based plastics are not biodegradable and will prevail on earth for many years. Though a biodegradable plastic that breaks down in sunlight is on the market, it proved too costly. The design team thus stayed with the original idea of non-biodegradable plastic but, to encourage the customers to recycle these plastic enclosures, suggest offering a monetary reward in exchange for them [18].
A number of hazardous by-products are produced during the PCB manufacturing cycle. These sources of waste include airborne particulates, waste rinse water, spent copper bath, acid solution waste, spent removal solution, spent plating bath, spent etching waste, and more. A consensus must be reached between the design team and the manufacturers to cure PCB waste problems. While designing the PCB, surface mount components (resistors, transistor, capacitors, etc.) were used primarily by the design team to reduce the amount of metal and number of etching processes required. Manufacturers can use abrasives, non-chelated cleaners for cleaning and board preparation, and dry photoresist removal for pattern printing and masking. They can also recycle and reuse various solutes and solvents to reduce waste generated during the PCB manufacturing processes [19]. Many electronic components such as microcontrollers, temperature sensors, crystals, and others are inherently non-biodegradable. In addition to this non-biodegradable characteristic, the crystal also contains lead, a highly toxic metal that can cause serious damage to the brain, kidneys, nervous system, and red blood cells [20]. Because of budget constraints, the team decided to use the leaded crystal. However, if the company wants to mass-produce the driver interface system, a nonleaded crystal is recommended.
2. Normal Use
The driver interface system is environmentally friendly during normal operation. The primary power comes from the solar energy that is converted by the Maximum Power Point Tracer (MPPT) and stored in a battery pack. Since the entire car runs on solar energy, there would be no issues regarding air pollution or potential chemical hazards.
3. Disposal/Recycling
As discussed in the product manufacture section, when the driver interface system reaches the end of its life cycle, it is recommended and encouraged to recycle the product and dispose of it properly, from an environmentally friendly point of view.
The plastic enclosure, which is not biodegradable, should be recycled. The manufacturers and the design team should encourage users to recycle it by offering a reward for its return. Recycled plastics can be used for future product development and to reduce company costs. Being known as an environmentally friendly company will enhance the company’s reputation and attract more customers.
PCB board, which contains many hazardous chemicals and metals, should be disposed of properly. Through the recycling process, the manufacturer can recover precious metals such as gold, silver, copper, and nickel from the PCB board and reduce production costs.
Since many electronic components within the driver interface system are inherently non-biodegradable, it is recommended that the entire system as a whole be recycled at the end of its life cycle. An improper disposal of the driver interface system will not only pollute in various ways (lead in soil and water, etc.) but will also hamper the company’s growth and reputation. In the short term, establishment of a recycling program may not seem cost effective. But an environmentally friendly company will certainly attract more customers and avoid many lawsuits associated with environmental issues in the near future.
6. Packaging Design Considerations
1. Commercial Product Packaging
1. BMW iDrive (see Fig. B-1 Appendix B)
BMW introduced the iDrive in 2001 as a pioneering driver information/entertainment system and was arguably BMW’s biggest corporate disaster in auto industry. The iDrive is a multimedia driver Interface. The iDrive system gives drivers the ability to access hundreds of functions by manipulating a single knob. Features like the audio player, air-condition, GPS navigation and even power seat control are all integrated into one giant menu. Operating somewhat like a standard shift, the knob must be pushed in one of the eight compass directions to access a particular menu [21].
Positive and Negative aspects : The iDrive system gives drivers the ability to control hundreds of functions, far more than can be controlled on other vehicles, with less “clutter” then is typically found on a dashboard. BMW was the first auto company to recognize the standard driver interface as becoming increasingly complex, overwhelming, and that adding more individual controls was not the solution [21].
However, fitting every function onto a menu that control by a single knob will easily confuse the driver. In the main menu page, there are eight application sub-menus: Climate, Communication, Navigation, and Entertainment, plus BMW Assist, Vehicle, Help, and Configuration. Some functionality does not fall into any category initiatively. And it takes huge amount of effort to learn to use the iDrive. Showroom salesman estimated that a comfort level could be reached in as little as two weeks [21].
Aspects copied or adapted to design project: The single knob operation will be copied in to this design project. Similarly, An RPG button will be used to navigate the menu. Like the iDrive, the solar car diver interface will break down the functionality into sub-menus.
Unique aspects of design project: Unlike iDrive, there will be an idle mode in the menu system so that when the driver is not accessing the menu, the unit will only display some of the more important information such as speed and battery level for the solar car. Monitoring the battery level is important, with this information displayed; the driver will be able to drive at optimized speed with efficient configuration.
2. ScanGauge 3-in-1 Auto Computer (see Fig. B-2 Appendix B)
The packaging of this product consists of a plastic casing with a two line LCD display and five push buttons. The product incorporated a standard OBD-II diagnostic connector for receiving various engine information and driving statistics from the vehicle. It also provides backlights for night use and user adjustable contrast ratio for the LCD display.
Positive and Negative aspects : This product displays a great amount of information through the standard OBD-II interface which includes engine trouble codes , varies digital gauge information, and a trip computer. The packaging of the product is extremely rigid and easy to install on the vehicle, however the product provides minimal user-friendly functions and input methods. The product uses five push buttons which is not the most ideal control scheme. Furthermore, the small two line LCD display make the menu navigation and information display harder since screen real estate is at a premium.
Aspects copied or adapted to design project: Similar to the ScanGauge product, this design project has a character-based LCD display, navigable interface, displays detailed vehicle information and has similar plastic packaging.
Unique aspects of the solar car driver interface: the CAN bus external interface and the RPG for user navigation. The CAN bus allows high expandability and provides a simple interfacing protocol between different devices in the solar car. Another unique aspect of this project is the user control and display interfaces. In contrast to the ScanGauge product, the design project incorporates an RPG for user inputs and a more user-friendly menu system which allows intuitive navigation.
2. Project Packaging Specifications
The driver interface system is packaged in a Serpac plastic enclosure with the following dimensions: 5.64”x3.25”x1.91”. An LCD display which can display 20x4 characters is placed on the front side of the enclosure. Two 6-pin MTE connectors located on the left side of the enclosure are used for the CAN communications. The design can be powered from the CAN connector or by a standalone power supply on the solar car. On the bottom of the enclosure, there is a standard DB-9 connector for serial communications. When a serial cable is connected, the design will switch to debug mode automatically.
Two buttons are connected to the design externally. Those buttons include a RGP encoder, and a push button. The RGP encoder and the return push button are used to navigate through the menu system. To ensure the easy accessibility of the driver, the buttons will be mounted onto the steering wheel of the solar car.
7. Schematic Design Considerations
1. Theory of operation
Power Supply:
A +12VDC supply from the solar car provides power to the driver interface board, which is stepped down to +5VDC using a switching regulator LTC1174-5 [4] configured to provide current up to 600mA . The estimated power consumption of the driver interface board, with the LCD backlight on 100%, is less than 2.25W (450mA at 5VDC) so there is plenty of margin in the power supply design. The +5VDC supply was chosen to simplify the power requirements since all of the peripherals where also chosen to support at +5VDC supply. Decoupling is accomplished using Low ESR surface mount capacitors [4].
Microcontroller:
The PIC18F4680 [1] microcontroller was chosen for this project. The PIC microcontrollers provide In-Circuit Serial Programming (ICSP) capability using just 3 pins on the microcontroller which are brought out to a header. The microcontroller receives the input of a 10MHz crystal and then will use a PLL to achieve desired operating frequency which will be determined by the solar team to balance needed frequency with the power considerations. The crystal load circuit is configured as shown in the PIC datasheet previously referenced. The user input (except the RPG) is received through the SPI port which is connected to the PLD. The LCD is driven by I2C which can share the SPI port as shown in [22]. In the case that this method causes problems, additional circuitry is provided to allow the SPI interface to be implemented on general purpose I/O. The microcontroller also provides PWM signals to manage the on-board LED brightness to help conserve power. The on-chip A/D is used to check supply voltage level and read the voltage from a temperature sensor. Regular I/O is used for the cable detect signals for the CAN connections and the RS-232 connection. In order to provide debug support, an RS-232 interface is provided. Decoupling is provided in accordance with the recommendations by Microchip [23].
.
LCD Interface:
The LCD interface [6] is an I2C interface to be implemented on the SPI bus as previously described. The two I2C pins and power and ground are brought to a header since the LCD module will be mounted away from the board. Backlight management and LCD contrast are controlled in software by commands from the microcontroller to the LCD controller.
User Interface:
The user interface consists of an RPG with an integrated select button, and up to four other buttons. Since space is limited on the steering wheel in the solar car, there will only be 2 buttons and the RPG available to the driver while driving and the other 2 buttons will be available for future expansion. Because the buttons will be mounted away from the enclosure and routed through a wiring harness, optical isolation is provided as a precautionary measure to protect the microcontroller and PLD from damage.
Analog:
This product has very little contact with the analog world, but there is a temperature sensor (LM19CIZ [24]) that provides a linear output voltage dependant on the ambient temperature as well as a photosensor that produces a changing resistance (from 8KOhms to 16KOhms) in response to the amount of ambient light. This will allow dynamic LCD backlight control since the microcontroller will have information about the brightness in the cockpit of the car and adjust the backlight accordingly (this feature can also be disabled by the operator).
Indicators:
LEDs:
There are 9 LEDs on the circuit board which will provide functionality as described below. A green LED will light when power (5VDC) is applied to the circuit, a second LED will blink alternating between red and green to show microprocessor operation (watchdog), a third will light green to denote debug mode (serial cable plugged in), and the six remaining will be available for debug and status purposes and have three of each color (red and green). With the exception of the watchdog and power LEDs, the LEDs are configured in two banks in common anode configuration and a PWM signal is supplied to each of the banks to control brightness. The two PWM signals will be out of phase by 180 degrees so that only one bank of LEDs will be lit at any one time to minimize power consumption.
Buzzer:
A 12VDC buzzer with integrated drive circuitry is provided to provide additional alerts to the driver of important information or errors. The LCD backlight can also be strobed to provide visual alerts.
8. PCB Layout Design Considerations
The driver interface PCB was arranged into the following major sections:
1. DC/DC converter (Power component) [4] - This is a high efficiency DC/DC converter which takes the 12V input voltage from the battery pack and steps down to 5V output voltage.
2. PIC18 microcontroller (Digital component) [1] – The major digital component on the PCB board requires 5V operating voltage and 40MHz operating frequency.
3. CAN bus interface (Digital component) [25] – Two connectors used for CAN to provide flexibility of adding additional nodes to the car. However, these two connectors are not required for CAN bus. This device also requires 5V operating voltage.
4. Programmable logic device (PLD) (Digital component) [26] – The PLD requires a 44 pins PLCC socket which operates at 5V input voltage. This PLD provides extra I/O pins to our microcontroller.
5. Bicolor LED (Digital component) [27] - These bicolor LEDs require a 5V operating voltage and 330Ω current limiting resistors. These LEDs are used for software development purposes as well as for displaying information regarding the connectivity of the entire driver interface system.
6. Optical isolator (Digital component) [28] - This optical isolator is required for our push button interface which operates at 5V input voltage. The push button is connected to a 2x7 MTE right angle programming header.
7. Temperature sensor (Analog component) [24] - One of the few analog components on the PCB board requires a 5V input voltage and must be separated from digital components to avoid mixed signals or noisy signals.
Several layout design considerations were carefully analyzed and considered by the team before the start of the layout processes. First of all, the team placed decoupling capacitors under the microcontroller to provide instantaneous current to the ICs. This design could help lower power consumption and balance out the inductive losses of the traces. Crystal was also placed near the microcontroller to keep the clock signal from being coupled into other signals on the board. It also reduced EMI since the traces act as antennas, the shorter the traces emit less EMI [29].
According to the IC datasheets, analog components must be placed as far away from the digital components as possible to avoid mixed signals. However, since there is only on major analog component (temperature sensors), the team decided that it is easy to separate the digital components from the analog components and this issue was not a major concern. Nevertheless, the components within each functional block (digital and analog blocks) should be placed as close as possible to minimize the length of the traces. The design consideration is that the longer the track length, the greater its resistance, capacitance and inductance. All of these factors could result in undesired results on the team’s circuit board such as noisy signals and EMI. Also, to avoid placement errors, the team used insertion outline on some footprints to pass the design rule check (DRC thinks the boarder of the footprint is a trace if the insertion outline is not enabled) [29,30].
When laying out the traces, the team used 40 mils wide power and ground traces to provide plenty of margins. Since the power and ground traces will take the most space on the PCB board, the team decided to route these traces first. The power and ground traces could most likely be smaller than 10 mils without issues but 40 mils traces were used for the higher current applications and 20-24 mils traces for the lower current areas and 12 mils for the hard-to-route areas. The wider the trace, the less the trace temperature will rise. Most signal traces were 12 mils with the minimum tolerance of 8 mils. The space between two traces was greater than 8 mils to avoid short circuit [29,30].
Since the PCB board will be mounting into a plastic enclosure, the team took the positions of the four mounting holes into design considerations. These mounting-hole locations are 1.375 inches on top and bottom of each side from the center of the box. To fit into the plastic enclosure, the size of the PCB board size was also considered by the team. The box is around 5”x3.5”, so the estimation of a board size 4.5 inch by 2.75 inch should fit the enclosure nicely.
The active components were purposely placed on the top layer and the passive components on the bottom layer. Doing so helps make interfacing, soldering, and debugging of the PCB board easier. Another reason was for industry preparation where it is more expensive to have larger components on both sides due to the way manufacturers solder the boards. It was also easier for the team to identify problems and assembly the board if the active components were placed on the top. All the MTE connectors (RS232 connector, CAN connector, etc.) were also arranged to hang over the boundary for easier accessibility from the outside of the plastic enclosure.
While the team considered most critical considerations for the PCB board, there were also some common design constraints that the team did not include. For instance, heat-sinking of the DC/DC was not necessary since it operates at a 94% efficiency rate. The temperature sensor’s quiescent current is less 10 micro ampere which gives rise to less 2˚C in still air, and a heat-sink would cause an error in the measurement of the temperature. This design did not utilize copper pours because the shielding properties of the ground pours were not necessary in this design [29,30].
9. Software Design Considerations
10.1 Software Considerations
10.1.1 Configuration Bits
The configuration bits for PIC18F4680 starts from address 300001 to 30000D. The range 300008 to 30000D is used for memory read/write protections which are not applicable to this project. The rest are documented and explained in the Table 10.1.1. [31]
Table 30.1.1 Configuration Bits
|Address |Category |Setting |Reason |
|300001 |Oscillator |HS-PLL |This project used an external oscillator, thus the HS-PLL|
| | | |option is required. |
|300002 |Power Up Timer |Disabled |Not needed |
| |Brown Out Detect |Enabled |Brown Out is enabled to reset the device when voltage is |
| |Brown Out Voltage |2.0 V |below 2.0V |
|300003 |Watchdog Timer |Enabled |Prevents the software bugs, self restarting |
| |Watchdog Postscalar |1:32768 | |
|300005 |PortB A/D Enable |Enabled |A/D channels are used in the design |
| |Low Power Timer1 |Disabled |Not used in the software |
| |MCLR Enable |Enabled |Needed for programming the microcontroller |
|300006 |Stack Overflow Reset |Enabled |Stack overflow protection |
| |Low Voltage Program |Disabled |Not needed |
10.2 Mapping of Memory
The microcontroller used in this project is PIC18F4680 which has 64 KB of programming memory, 3328 bytes of data memory and 1024 bytes of data EEPROM.[1] The following table illustrates the memory usage.
Table 10.4.1 Memory Usage Estimation
|Data Type |Estimate Usage |Location |
|Stack |100 Bytes |Data memory |
|Heap |200 Bytes |Data memory |
|Local Variables |30 Bytes |Data memory |
|Global Variables |550 Bytes |Data memory |
|Code |20 KBytes |Programming memory |
The size of the final code is given by the Microchip compiler and is 20 Kbytes. The size of the current data memory usage is 880 bytes which is also given by the compiler. Hence there is still 2.5KB of data memory and 46 KB programming memory left for future expansion.
The usage of calling stack is estimated at 100 bytes, because the deepest function calling is three levels. In each of the three levels, there are five integer and character variables. They occupy twenty-five bytes for each function calling. Along with the storage of the system registers, one hundred bytes of stack space is a sufficient for the operation of the project. Hence the memory overflow is unlikely to happen.
10.3 Mapping of External Interface
This design project only employed a few external devices. Below is a table that describes the mapping of the registers to each external device.
Table 10.5.1 Mapping of External Components
|Mapped Register |Input/Output |External Device |
|RA3 |General Input |RPG OutB |
|RA4 |General Input |DBG Cable Detection |
|RA5 |General Input |RPG OutA |
|RD6 |General Output |Buzzer with Driver |
10.4 Utilization of Peripherals
This design project utilized the following peripherals from the microcontroller: A/D, SPI, I2C, CAN, USART and timer. All the peripherals connected to the external devices are listed in Table 10.4.1.
Table 10.6.1 On-board Peripheral Connected with External Components
|Mapped Register |Peripherals Used |External Device |
|AN0 |A/D |5V Sensor |
|AN1 |A/D |Temperature Sensor |
|AN2 |A/D |Light Sensor |
|SDA |I2C |LCD |
|SCL |I2C |LCD |
The A/D channels are used for measuring power supply voltage, light sensor voltage, and temperature sensor voltage. The Vdd and Vss were chosen as the reference voltages for these A/D channels, because the input signals are all based on the same source. The I2C module is used to update LCD with desired menu and vehicle status. The LCD is running at 100 Kbps with slave mode, hence the microcontroller also has to be running at 100 Kbps with Master mode. The USART module is used to communicate with a laptop computer through the RS232 interface. The USART module will be initialized at baud rate of 9600 bps under asynchronous mode. The CAN module is responsible for both sending and receiving from other nodes on the CAN network. The three solar car teams agreed to run at 125 Kbps with 11 bits message identifier. The timer module is used for both the power saving timeout function and the push button scanning. It is configured to generate an interrupt every 6 ms.
10.5 Code Organization
The code will be organized as a hybrid of polling and interrupt driven. The main polling loop is used for executing code based on various global flags and taking RPG inputs from the driver. The interrupts are used for receiving solar car status from other nodes on the CAN network, light sensor, push button checking, and power saving counter.
10.6 Debug Routines
The debug mode is offered through the RS232 interface to a PC terminal. The main polling loop will check RA4 register to determine whether the RS232 cable is plugged in. If it’s plugged in, the debug routine will be activated and send the text menu through USART.
2. Software Design Narrative
10.2.1 Main Module (main.c)
This module contains the interrupt service routines (ISR) and the main function of the system. The ISR routine services both the timer interrupt and the CAN receive interrupt. The timer ISR will increment the timer count variable for every timer interrupt. This timer counter is used to send out CAN requests periodically, adjust the backlight intensity and set the idle flag. The CAN receive ISR is responsible for copy the data from the CAN receive buffer into the main data array (rdata1 and rdata2).
The main function will first call the initialization functions for each peripheral. Then it will enable all the interrupts and call display menu functions from the I2C Module. Next it will start the polling loop which calls detectLR( ) function from the RPG module, then it will checks if the serial cable is plugged in and whether the time out flag is generated by the timer. If the time out flag is set, an idle page with speed and battery information will be displayed.
10.2.2 Analog to Digital Module (a2d_func.c)
There are two functions included in this module. The first one is used for the initialization of the A2D module. The second one (atd_convert(char channel )) is used to obtain the result of a conversion from a specified channel number. Both of the functions are invoked in the Main Module.
10.2.3 CAN Module (can_func.c)
There are four functions included in this module. They’re responsible for sending out CAN requests to the Telemetry system and MPPTs. The sending process involves first setting the CAN transmitting registers with the data and then set the CAN transmission flag. They’re all invoked in the Main Module.
10.2.4 I2C Module (LCD_I2C.c)
There are eleven functions in the I2C Module. They are divided into four groups: initialization function, I2C send functions, displaying functions and conversion function. The initialization function and the displaying functions are invoked in the Main Module. The I2C send function and conversion function are invoked locally by the displaying function.
The initialization function sets the on board I2C module control registers to the desired value, and then it sends the address of LCD (default 0x56) through the I2C bus to prepare the LCD for further transmission. The I2C send functions take multiple signed or unsigned character arrays, and insert a delay loop between the transmissions of each character. The conversion function takes in two character (representing lowest significant bytes and most significant byte of an integer) and a destination character array of five bytes. It converts the hex values from the two characters to decimal based and then convert the decimal values into the corresponding ASCII values.
The display functions consist of a main display system menu function, an idle page display function and three utility functions. The three utility functions are responsible for general LCD functions. They’re clear the entire screen, set the cursor to the start of a line and send individual LCD commands. The display system menu function takes in a menu index and offset, then use the menu index to determine the root option and use the offset to determine sub level menu. It then sends this sub level menu option to LCD using the I2C sending functions. The idle page function displays the speed of the solar car in large digit mode, the current and voltage of the battery packs in bar mode. All of the special modes are invoked by sending corresponding instructions to the LCD through I2C.
10.2.5 RPG Controller Module (RPG.c)
There are three functions included in this module. They’re all invoked in the Main Module. The first two functions are used for initialization of the corresponding pins on PORTA and the detection of a push button.
The detectLR() function detects the input from RPG movement and determines the next position. There is a global variable last_pos and a lookup table associate with this function. Initially last_pos equals 0. Every time the detectLR( ) is invoked, it gets value of register PORTAbits.RA5 and PORTAbits.RA3, and then it checks against the lookup table for last_pos and the new values. Depends on the combination, the function returns zero, one or two. The zero means no change, one means left turn, two means right turn. For example, if last_pos equals 00, and the new reading equals 10, then the function will return two which means right turn.
10.2.6 Timer Module (timer_func.c)
There is only one function in this module. It is used for initialization of the on-board timer peripheral and it’s called in the Main Module.
10.2.7 UART Module (unart_menu.c)
There are seventeen functions in the UART Module. They can be divided into three groups: initialization functions, UART send/receive functions and display menu functions. The two initialization functions is called in the Main Module and it’s used to initialize the on-board UART peripheral and the serial cable detection port. The four UART send/receive functions are called by the menu display functions in this module. They are used for input and output single/multiple characters from and to the UART module. The printf function from the Microchip C18 library was utilized for those functions.
The rest of the functions are used for displaying varies levels of menus. The display_debug_menu( ) function is the main pooling loop which displays the main debug menu and waits for an input from the UART module. It then invokes other sub level menu functions depends on the input. Then the sub level menu functions will pull the data from the main data array (rdata1 and rdata2) and invokes the UART send function.
10. Version 2 Changes
11.1 Software Changes
• Enhance menu system expandability and maintainability.
To reduce the complexity of the menu control, instead of directly updating the LCD, memory buffer should be used to store LCD screen display.
• Serial LCD should be used in this design
Current design use I2C communication, the needed of receiving I2C acknowledgment added delay to the program, which slows down the CAN bus communication.
• CAN cable detection
Device won’t work properly without present of CAN connection. In case of CAN cable doesn’t get connected, device should indicate user.
• Faster baud rate for serial connection
Current serial debug menu take a while to update the menu display, faster baud rate will make the debug appear faster without delay.
• Dedicated CAN buffer to ensure ability to handle busy traffic
Should use a FIFO for receiving CAN message. Current design cannot handle more than one CAN message appearing together.
• Cable Harness for push buttons should be located outside the enclosure for easier installation
2. Hardware Changes
• PLD with more programming memory or no PLD and just use microcontroller pins.
Original design was to use a PLD to expand extra I/O. However, selected PLD do not have enough program memory for the shift register code to fit for a shift-in shift-out register.
• Spend more time doing enclosure measurements so that all four mounting holes match the enclosure box.
• To fix the Hardware debug on PCB and remove the need of fly wiring.
• Get the directions on the MAX232 part correct to prevent rework.
• Spend more time in layout so that the finished product looks more refined.
Summary and Conclusions
This report provides an overview of the design, implementation and testing aspects of the SPOT Dash project. It showed how the SPOT Dash will be used in the Purdue solar car as well as defining the specifications of the project and documenting the accomplishment of each of those specifications. In addition, it also discussed varies business and social issues involved with a commercialized product, including patent infringement, reliability and environmental impacts. This project allowed the team to get first-hand experience designing a product that will find a use in the real world.
The initial design stage of the project is often overlooked and most time should be spent in this phase to ensure a functional and well designed product. Extra time spent on reviewing datasheets and application notes will eliminate time wasted later debugging hardware errors and will make the product more professional looking. Additionally, in industry, failure to accurately research the part datasheets could result in a second or third pass of the hardware which adds delays to the schedule and increases development cost.
Accurately documenting and specifying the requirements and features up from and assigning priority to them is very important in a project that has a concrete schedule such as this one. In industry a product which is not completed on-time will have a reduced feature set or the completion date will slip. In a project such as this, where there is a finite amount of time and a concrete deadline, assigning priority to features was important since there was not enough time to implement all of the “nice-to-have” features but more than the basic functionality was accomplished.
The intra-team collaboration was extremely helpful and beneficial to all parties involved. This collaboration took the four-person teams and provided more of a “real-world” experience since designs often have to interface with those of other groups or departments and many decisions have impacts on other groups hardware and software. Since this project communicates with two other senior design projects, a lot issues occurred through the semester such as CAN protocol were resolved quickly and flawlessly. There were also great ideas and questions proposed during those meetings which allowed the combined experience of the three teams to be put to work solving complicated problems.
Overall teamwork was the single most important factor that contributed to the successful completion of this project. The SPOT Dash would not be completed successfully without the dedication from each team member and numerous instances of help from members on the other two teams. This valuable experience will benefit each team member in future projects and provides a concrete example of a successful engineering design as an excellent way to finalize the undergraduate engineering career.
References
1] Microchip Technology Inc. Technical Staff, PIC18F2585/2680/4585/4680 Data Sheet, Microchip Technology Inc., 2004, April 30 2006 [date accessed]
[2] Atmel Corporation Technical Staff, AT89C51CC03 Data Sheet, Atmel Corporation, 2006,
April 30 2006 [date accessed]
[3] Catalog Page 727, Serial EEPROMs, Digi-key Corporation, 2006, Thief River Falls, MN.
April 30 2006 [date accessed]
[4] Linear Technology Corporation Technical Staff, LTC1174 Data Sheet, Linear Technology Corporation, 1994, April 30 2006 [date accessed]
[5] Maxim Integrated Products, Inc. Technical Staff, MAXIM Low-Noise, 14V Input, 1A, PWM Step-Down Converters, Maxim Integrated Products, Inc.,
April 30 2006 [date accessed]
[6] Matrix Orbital Technical Staff, LCD2041 User Manual, Matrix Orbital Inc., 2004,
April 30 2006 [date accessed]
[7] Crystalfontz America, Inc. Technical Staff, CGAH2004A-YYB-JPE Data Sheet, Crystalfontz America, Inc., 2004, April 30 2006 [date accessed]
[8] United State Patent and Trademark Office,
[9] Honda Giken Kogyo K.K., “Information display system for a vehicle,”
U.S. Patent 5,006,829, March 31, 1988
[10] Freightliner Corporation,”Integrated message display system for a vehicle,”
U.S. Patent 6,289,332 , March 18, 1999
[11] Nissan Motor Company, Ltd., “Display apparatus for vehicle,”
U.S. Patent 5,121,112, December 26, 1989
[12] Toyota Jidosha Kabushiki Kaisha, “Information display apparatus for vehicles,”
U.S. Patent 5,764,139, October 22, 1996
[13] Literal infringement. (n.d.) The People's Law Dictionary. (2005). Available: April 30 2006 [date accessed]
[14] Department of Defense Technical Staff, Military Handbook Reliability Prediction of Electronic Equipment, Department of Defense, 1991.
[15] Patton Electronics Co. Technical Staff, “About Optical Isolation”, October 28 1994, Available: technotes/about_optical_isolation.pdf April 12 2006 [date accessed]
[16] Yuan-Jiun Sung, “Homework 6: Printed Circuit Board Layout Design”. Feb 23 2006, Available: April 12 2006 [date accessed]
[17] Wei Zhou, “Homework 10: Software Design Considerations”, Mar 29 2006, Available: April 12 2006 [date accessed]
[18] Wei Zhou, “Homework 11: Reliability and Safety Analysis”, April 12 2006, Available: April 12 2006 [date accessed]
[19] California Environmental Protection Agency, (July 19, 2005). [Online], Frequently asked questions, July 12 2005, Available: April 12 2006 [date accessed]
[20] D. Farley, (Feb. 1998), “Dangers of Lead Still Linger”, FDA Consumer Magazine, Available: April 12 2006 [date accessed]
[21] John H. Day, (June 21, 2004), ”Can BMW iDrive Pass The Road Test now?”, Electronic Design, Available: April 30, 2006 [date accessed]
[22] Broadcast Equipment Ltd., [Online], Mixing I2C and SPI on the same pins, Available: April 30, 2006 [date accessed]
[23] Microchip Technology Inc., Power Consideration Application Notes, Available: April 30, 2006 [date accessed]
[24] National Semiconductor Corporation Technical Staff, LM-19 Temperature Sensor Data Sheet, National Semiconductor Corporation, 2003, Available: April 30, 2006 [date accessed]
[25] Molex Corporation Technical Staff, 2.54mm (.100") Pitch C-Grid Breakaway Header Data Sheet, Molex Corporation, 2003, Available: April 30, 2006 [date accessed]
[26] MILL-MAX Corporation Technical Staff, STANDARD PLCC SOCKETS For Through Board Mount, MILL-MAX Corporation, 2004, Available: April 30, 2006 [date accessed]
[27] Lite-On Electronics Inc. Technical Staff, LED GREEN/RED BICOLOR 1210 SMD Data Sheet, Lite-On Electronics, Inc., 2004, Available: April 30, 2006 [date accessed]
[28] Catalog Page 1665, Opt-isolators, Digi-key Corporation, 2006, Thief River Falls, MN. Available: April 30, 2006 [date accessed]
[29] Motorola Semiconductor, AN1259, Available: April 30, 2006 [date accessed]
[30] D. Jones, “PCB Design Tutorial”, June 29 2004, Available:
April 30, 2006 [date accessed]
[31] Han-Way Huang, PIC Microcontroller: An Introduction to Software and Hardware Interfacing, Thomson Delmar Learning, 2005
*The IEEE format is referenced from University of Calgary Effective Writing Program website. The link of the document can be found at .
Appendix A: Individual Contributions
A.1 Contributions of Jason Chan:
I was the team leader of the team. I was responsible for the software development. Unlike other team, we were working with two other senior teams for the Purdue solar team. I conduct most of the inter team communication, include organizing the inter team meeting and reporting to the formal Solar Club President, Kevin Rosswurm. I also designed the design’s main menu system, debug menu and idle page display. As a Team leader, I was supposed to ensure work load shared equally among team members. I am satisfied with the distribution of work load among software and hardware group of the team.
During the early design stage, our team began by holding a lot of meeting with the solar team. I discussed with the solar car driver and solar team to make sure the design will satisfy their need. I also did measure and investigate the operation environment inside the solar car to maximize the functionality of the Driver Interface.
For the Software development, I start of by exploring the MPLAB software and got myself familiar with PIC18 family’s operation. After getting ourselves familiar with the development tool, me and wei zhou worked together to communicate to the LCD display. We spent a long time on learning the I2C protocol. But with the help of Nathanael, we realized the missing of pull up resistor was the reason why our LCD has not been working.
Setting Serial connection and cable detection was one of my contributions, too. I constructed the basic control structure of the serial debug menu, the way of the design is easy to implement, but difficult for future expansion.
After I configured the RGP buttons, I built the basic display and control structure of our menu system. Wei Zhou joined in to help the debug process. After getting the system menu and debug menu semi-functional, I added code in the timer interrupt that Wei Zhou wrote and configure the idle page display. Learning the Large Digit Display Function provide by the LCD manufacturer, I was able to develop a nicely looking idle page with the most important information shown on the screen.
Nathanael’s previous hardware experience brought a huge contribution to our project. I was able to concentrate on the software development without worrying the hardware. Wei Zhou was a wonderful partner, he provide me a positive comment on register setting. We were able to work along so well that we can conquer any software soft ware challenge. As a team leader, I believe I have successfully corporate all the team members’ specialty together and have completed a wonderful project.
A.2 Contributions of Nathanael Huffman:
This semester I worked on a number of different aspects of the design. Having worked on a full circuit board design during an internship, I was familiar with the design process from the documentation stages to the board fabrication stages. Knowing that the initial design and specification is the most difficult part of the design, I pushed the team to focus on getting useful and acceptable PSSCs and spent a lot of time helping out with the initial homework. I was responsible for the Component Selection Rationale homework which I successfully completed as well as the Schematic and Schematic narrative homework. Knowing that a good job on the schematics not only makes the design smoother but helps in debugging problems down the road, I spend a lot of time in the component datasheets to make sure the interfacing hardware was acceptable. I was vocal in the team meetings about what I thought would work and was careful to evaluate any of the decisions with the hardware impact in mind. These decisions included putting down a PLD incase we needed to I/O expand as well as defining the power circuitry and microcontroller we would use.
Although my formal responsibilities from a homework standpoint were completed, I spent numerous hours doing the difficult routing and fixing traces that were peppered with vias. I realized that with some forethought and a willingness to rip up some existing tracks, the number of vias could be reduced by about 40% and the board would end up looking better as a side benefit. I spent time re-routing the optical isolation section on the board so that the components would line up instead of being slightly off-grid which was how they were placed initially. I also changed the placement polarized capacitors, diodes, and optical isolators so that the components were all oriented in the same direction to aid assembly and provide a more professional-looking product. I pushed our design team to complete the PCB ahead of schedule so that there would be ample time for PCB submission and worked hard to pull my share of the accelerated load.
Once the board came back I was responsible for assembly and spent about a week soldering all of the components onto the PCB and doing some initial hardware debugging. I found a few errors related to incorrect net names, OrCAD layout issues where the net would be on the wrong layer but it would show a positive connection. I built the interfaces and cables necessary (with the exception of the RS-232 cable) to communicate from the board to the outside world.
After the hardware was assembled, tested, and functional, I began working on our packaging design. I took the enclosure and cut the holes for the connectors and the LCD, mounted the LCD to the enclosure lid, added the rubber gasket material to give it a more finished look, and made and installed the labels that indicate the function of each port.
I directed and edited the PSSC video, pitched in on all of the various PowerPoint presentations and edited (content, grammar, and formatting) and compiled this report to bring all of the different parts together and give it a unified look and feel.
A.3 Contributions of Yuan-Jiun Sung (David):
It has been a pleasure to work with my teammates, Nathanael, David, and Jason, on this semester’s senior design project. Each team member contributed to his area of expertise in order to complete this project. Since I was the PCB designer for my ECE362 mini project, I was elected to be responsible for the same task in this senior design project. Below I will describe the major contributions that I accomplished throughout the project.
As the team’s PCB designer, my first major contribution was to complete the PCB layout. Although I was the PCB designer on my ECE362 mini project, I utilized another program, called PCB123, to complete the PCB design for the mini project. Hence, to get familiar with OrCad Plus, I attended the PCB help section held by Purdue Solar Racing, and read the PCB Design Tutorial written by David Jones. The help section and design tutorial were helpful, but I still needed some hands-on experience to become familiar with this program. Eric, a team member from Team 12, helped me a lot with the initial PCB layout processes. I took about two days to finish the footprints creation and one week to complete the routing and arrangement of the footprints. Nevertheless, the fun part was correcting the PCB errors. Originally, we had around 150 errors. By rearranging traces, recreating some footprints, and sending our PCB to check for errors in , these errors were completely checked and corrected after two weeks. The design process as a whole was tough, but it went quite smoothly, thanks to the help of my teammates.
My other major contribution involved writing the user manual and senior design report for my team. The software team worked on the programming for our project, and Nathanael, the other hardware team member, worked on the packaging. To reduce the amount of workload during the final week, I took on the responsibility of completing these reports. Since these reports will give readers an overview of what our project is about, I tried to cover as many topics as I could and discussed each topic in depth. I also included several pictures of our project in the user manual in order to illustrate it clearly. The senior design report and the revised design and professional homework were completed one week before the final week, and the user manual was completed prior to the deadline.
Some other contributions included checking the ethical and environmental designs of our project, finding possible solutions for potential failure modes, researching CANOpen, I2C, and SPI configuration. I also helped Jason find patents for our projects regarding possible infringements according to doctrine of equivalence.
Throughout this senior design project, I acquired a great deal of hardware and software knowledge, either from the course staff or teammates. This course not only reinforced my existing knowledge, but also encouraged the learning of new skills. It also taught me the importance of teamwork and the significance of individual contribution. We have had an outstanding semester and a successful project, which is the ultimate accomplishment of every team member’s effort.
A.4 Contributions of Wei Zhou (David):
In this project, I played an important role on assembling the team members and selecting the team project in the beginning. As the project moved on, I designed the group website and helped with component selection. I also contributed to the PCB routing stage of the project by creating new parts. During the second half of the semester, my main responsibilities were software coding, meeting with other teams about CAN protocol implementation, and software/hardware debugging. Overall I believe my contribution was an important factor to the success of this project.
I started talk to Jason and David since last semester about the possibility of doing the senior design project together. I also participated in the first Solar Racing team meeting to learn about the project and expressed my interest in the project to Professor Nyenhuis. After deciding the project, I designed the group website and was responsible for its maintenance. In the following week, I did a lot of research on the LCD selection which led to the selection of LCD2041 from Matrix Orbital.
For the software portion of the project, my majority time spent went into calculating and setting up the correct register values for all of the on-board peripherals (including A2D, timer, UART, and the troublesome CAN) used in this project. In the process, I also helped team 12 and 13 on setting up the CAN control register for both receiving and sending messages. I also wrote the interrupt service routine (ISR) for both CAN receive and timer. The coding of the ISR and enabling of interrupt prove to be a challenging task, because PIC employs a unique approach where only two ISR functions are allowed and there are three different sets of registers controlling the interrupt priority and enable. Besides the ISRs, I wrote the entire CAN request functions, conversion functions, and I2C sending functions. My codes laid the foundation for the menu display on the LCD.
My debugging effort was significant to the success of the project as well. I fixed most of the software bugs including the extremely difficult to catch ones, such as the LCD only works on software reset, but not after power up. The debugging process was a great learning experience, because it involves both of the hardware and software issues.
I was also in charge of the software narrative and reliability homework for the project. The software report was difficult at the time, because we only had about 30% of the coding done. I feel very fortunately it passed. On contrary, the reliability homework was well done, because I spent a lot of time looking through the military handbook and thinking about various failure modes (FMECA sheets) for the project.
In conclusion, I have contributed 160 hours to this project. It was a pleasant experience, because I gained knowledge in a lot of different areas of embedded system design.
Appendix B: Packaging
Figure B.1 BMW iDrive Figure B.2 ScanGauge 3-in-1 Auto Computer
[pic][pic]
Figure B.3 SPOT Dash Front Panel Figure B.3 SPOT Dash Side view
[pic][pic]
Appendix C: Schematic
Figure C.1 Page one of the schematic (Power block, LED block, RS232 block, CAN block, and Button interface with optical isolation)
Figure C.2 Page two of the schematic (Microcontroller block, PLD block, and headers)
Appendix D: PCB Layout Top and Bottom Copper
Figure D.1 Top PCB Layer with top silkscreen
[pic]
Figure D.2 Bottom PCB Layer with bottom silkscreen
[pic]
Appendix E: Parts List Spreadsheet
|ECE477 Team14 Revised: Friday, April 28, 2006 |
|2 Revision: 1.9 | | | |
|Team 14 | | | | |
|Bill Of Materials February 24,2006 11:25:45 | | |
|Item |Quantity |Reference |Part | | |
|______________________________________________ | | |
|1 |1 |C1 |100uF | | |
|2 |2 |C2,C3 |22pF | | |
|3 |10 |C4,C8,C9,C10,C11,C12,C13, |0.1uF | | |
| | |C14,C15,C16 | | | |
|4 |3 |C5,C6,C7 |15uF | | |
|5 |1 |D2 |1n5818 | | |
|6 |6 |D3,D4,D5,D6,D7,D8 |dualLED | | |
|7 |7 |ISO1,ISO2,ISO3,ISO4,ISO5, |PC317 |
| | |ISO6,ISO7 | | | |
|8 |2 |J1,J14 |CAN | | |
|9 |1 |J2 |Programming Header |
|10 |1 |J3 |LCD Interface | |
|11 |1 |J4 |12Vdc Input | |
|12 |1 |J5 |RS232, DB-9 | |
|13 |4 |J6,J7,J8,J9 |CON12A | |
|14 |1 |J10 |CON14 | | |
|15 |1 |J11 |ispGAL programmer |
|16 |1 |J12 |Extra I/O | |
|17 |1 |J13 |Light Detect | |
|18 |1 |L1 |100uH | | |
|19 |2 |Q1,Q2 |PNP BCE | |
|20 |1 |Q3 |NPN BCE | |
|21 |7 |R1,R2,R5,R6,R10,R11,R43 |10K | | |
|22 |2 |R3,R42 |300 | | |
|23 |11 |R4,R7,R8,R9,R12,R13,R14, |0 | | |
| | |R15,R16,R44,R45 | | | |
|24 |10 |R17,R18,R19,R20,R21,R22, |330 | | |
| | |R23,R38,R39,R40 | | | |
|25 |12 |R24,R25,R26,R27,R28,R31, |3K3 | | |
| | |R32,R33,R34,R35,R36,R37 | | | |
|26 |2 |R29,R30 |3.3K | | |
|27 |1 |R41 |16K | | |
|28 |1 |R46 |1k | | |
|29 |1 |U1 |LTC1174- 5/SO | |
|30 |1 |U2 |MCP2551I/SN | |
|31 |1 |U3 |PIC18F4680-I/PT | |
|32 |1 |U5 |MAX232A/SO | |
|33 |1 |U6 |ISPGAL22V10C/LCC |
|34 |1 |U7 |Buzzer | | |
|35 |1 |U8 |LM19CIZ | |
|36 |4 |U9,U10,U11,U12 |mounting hole | |
|37 |1 |Y1 |CRYSTAL/SM | |
Appendix F: Software Listing
/**************************************************************************/
/**File Name: main.c ***/
/**Programmer: (Jason)yuk hang chan, (David)Wei Zhou ***/
/**Last time of revision: 4/27/2006 ***/
/**Function Include:void initial_Can();
void high_ISR (void);
void low_ISR (void);
void delayex (void);
void print_sub_menu_3(void);
void print_sub_menu_4(void);
void display_debug_menu(void);
void display_CAN_data(unsigned int request);
void idle_page_display(); ***/
/**Discription: The main funciton is responable for all the control
of the design project. When the device is reboot,
the Program counter will be set to the begining of
main. This file also include the LOW and HIGH interrupt.
This interrupt are set to handle Timer, CAN receive
and AtoD data collection ***/
/* Compile options: -ml (Large code model) */
/* Version 1.03 (3/8)
Detecting the postion from RPG button, and output "LL", "LH","HL"
or "HH" to the LCD display.
*/
/* Version 3.01( 4/15)
I2C LCD Working; CAN message send and receive ; Serial output working
Sperate all the function into different Files:
Files: LCD_I2C.c
RGP.c
uart_menu.c
*/
/*Vesrion 4.01(4/20)
System menu build, User can go in or return from the menu
Timer works and is able to change the LCD brightness according to
the light sensor's data. But the device is not yet be able to send and
receive can message
Files: LCD_I2C.c
RGP.c
uart_menu.c
timer_func.c
a2d_func.c
*/
/*Vesion 4.01Final_Version (4/27)
ALL functionality works include I2C to communicate with LCD,
Serail communication for debug menu works,
LCD brightness changes accordingly,
Be able to Send and receive can message,
Be able to receive text message via can from telemetry group
Files: Files: LCD_I2C.c
RGP.c
uart_menu.c
timer_func.c
a2d_func.c
CAN_func.c
*/
#include
#include "p18f4680.h"
#include
#include "i2c.h"
#include
#include "uart_menu.h"
#include "RGP.h"
#include "LCD_I2C.h"
#include "timer_func.h"
#include "a2d_func.h"
#define space 0x20
#pragma config WDT = OFF
//Global variable
unsigned int RPGoutA;
unsigned int RPGoutB;
unsigned int SPI[8];
unsigned int timer_count;
unsigned int idle_count=0; //Count the Time to go into Idle Mode.
char idle_flag = 0;
unsigned int menu_level = 0;
unsigned int menu_level2 = 1;
unsigned int menu_index[4] ;
unsigned char tempcanstat;
unsigned char rxb0_buf[14], rxb1_buf[14];
#pragma udata buffer_low
static unsigned char rec_data1[254]; //to store lower 8 bits of the data
#pragma udata
#pragma udata buffer_high
static unsigned char rec_data2[254]; //to store higher 8 bits of the data
#pragma udata
//unsigned int can_data2[100];
//dedicated pointers for access the two 254 bytes monsters
char * rdata1 = &rec_data1[0];
char * rdata2 = &rec_data2[0];
/*********************/
//Function Prototype//
/*********************/
void initial_Can();
void high_ISR (void);
void low_ISR (void);
void delayex (void);
void print_sub_menu_3(void);
void print_sub_menu_4(void);
void display_debug_menu(void);
void display_CAN_data(unsigned int request);
void idle_page_display();
/**************************************************************************/
/*Function name: high Interrupt
/*Usage: See high_ISR
/*Return Value: None
/**************************************************************************/
#pragma code high_vector = 0x08
void high_interrupt (void)
{
_asm
goto high_ISR
_endasm
}
/**************************************************************************/
/*Function name: Low Interrupt
/*Usage: See low_ISR
/*Return Value: None
/**************************************************************************/
#pragma code low_vector = 0x18
void low_interrupt (void)
{
_asm
goto low_ISR
_endasm
}
/**************************************************************************/
/*Function name: high_ISR
/*Usage: Read in CAN message and copy the data from CAN buffer
/* To Local memory buffer
Also Handle the increment of timer
And responsable for triggering the Idle page
/*Return Value: None
/**************************************************************************/
#pragma code
#pragma interrupt high_ISR
void high_ISR (void)
{
// unsigned char temp;
unsigned int resulttemp;
// unsigned char* temptemp;
unsigned char i, *cpt; // pointer to char
unsigned char temp_rxb0;
unsigned char temp_data;
unsigned char temp_data2;
unsigned int eightfour = 132;
unsigned int eightzero = 128;
unsigned int oneninethree = 193;
PIR1 = PIR1 & 0x02;
if (PIR3bits.RXB0IF)
{
// handle RXB0 interrupt;
//copy over the data from RXB0 buffers into local buffer
PIR3bits.RXB0IF = 0;
//Figure out what to do with message
if (RXB0DLC == 3)
{
cpt = &RXB0D0;
for (i = 0; i < RXB0DLC; i++)
{
if (i < 8 && i>= 0)
{
rxb0_buf[i] = *cpt++;
}
}
temp_rxb0 = rxb0_buf[0]; //rxb0do stores the desinated character
temp_data = rxb0_buf[1]; //shift RXB0D1 data into upper 8 bits
temp_data2 = rxb0_buf[2];
rdata1[temp_rxb0] = temp_data;
rdata2[temp_rxb0] = temp_data2;
}
RXB0CONbits.RXFUL = 0; //clear receive full flag
}//end if PIRbits.RXB0IF
if (PIR1bits.TMR2IF == 1)
//if the timer 2 (TMR2IF) interrupt is called
{
T2CON = 0x00; //CloseTimer2();
PIR1bits.TMR2IF = 0; //clear the interrupt
if ( timer_count == 100 ) //mod 100 is around 0.8 second
{
timer_count ++;
request_tele_data(eightzero);
}
if ( timer_count == 225 ) //mod 100 is around 0.8 second
{
timer_count ++;
request_tele_data(oneninethree);
}
else if ( timer_count == 450 ) //mod 100 is around 0.8 second
{
timer_count ++;
request_tele_data(eightfour);
}
else if (timer_count >= 500) //10seconds=1532 Here Important change 4/22
{
timer_count = 0;
idle_count++;
if (idle_count > 3 )
idle_flag = 1;
else
idle_flag = 0;
resulttemp = atd_convert(2);
if (resulttemp < 100)
{
IdleI2C();
LCD_command(153);
puti2c_delay(28);
}
else if (resulttemp >100 && resulttemp 200 &&resulttemp 300 &&resulttemp 400 &&resulttemp 500 &&resulttemp 600 &&resulttemp 700 &&resulttemp 800 &&resulttemp 0){
start_of_line(4);
puts_i2c("Return");
menu_level--;
menu_index[menu_level] = 0;
}
}
if(push_on == 1){
/*****************************************************/
idle_count = 0;
idle_flag = 0;
//Here
clear_screen();
if(menu_level ==0){
if(menu_index[0] ==5){
//Display_battery current
}
else{
menu_level++;
menu_index[menu_level] = 0;
}
}
/******************************************************/
else if(menu_level == 1){
if(menu_index[0] == 0){
switch(menu_index[1]){
case 0://turn on/off tracker
case 1://turn on/off tracker
case 2://turn on/off tracker
case 3://turn on/off tracker
case 4://turn on/off tracker
case 5://turn on/off tracker
case 6://turn on/off tracker
case 7://turn on/off tracker
toggle_mppt(menu_index[1]);
/******Here******/
display_CAN_data(menu_index[1]*8 + 6);
break;
case 8:
menu_level--;
menu_index[0] =0;
break;
default:
break;
} //end switch statement
}
/*----------------------------------------------*/
else if(menu_index[0] == 1){
if(menu_index[1] != 8){
menu_level++;
menu_index[menu_level] = 0;
}
else
menu_level--;
}
/*----------------------------------------------*/
else if (menu_index[0] == 2){
switch(menu_index[1]){
case 0: //display GPS time
break;
case 1:
menu_level++;
menu_index[menu_level] = 0;
break;
case 2:
menu_level++;
menu_index[menu_level] = 0;
break;
case 3:
menu_level --;
menu_index[0] =0;
default:
break;
} //end switch statement
}
/*----------------------------------------------*/
else if(menu_index[0] == 3){
switch(menu_index[1]){
case 0: //read text message
break;
case 1://earse text message
break;
case 2:
menu_level--;
menu_index[0] = 0;
break;
default:
break;
}
}
/*----------------------------------------------*/
else if (menu_index[0] == 4){
switch(menu_index[1]){
case 0:
menu_level++;
menu_index[menu_level] = 0;
break;
case 1:
//display tele temp
break;
case 2:
//display motor temp
break;
case 3:
menu_level--;
menu_index[0] =0;
break;
default:
break;
}//end switch
}
/*----------------------------------------------*/
else if(menu_index[0] == 6){
switch(menu_index[1]){
case 0:
//display motor speed
display_CAN_data(0x80);
break;
case 1:
//display motor temp
display_CAN_data(0x85);
break;
case 2:
//display driver state
display_CAN_data(0x87);
break;
case 3:
// display heat sink temp
display_CAN_data(0x86);
break;
case 4:
menu_level--;
menu_index[0] = 0;
default:
break;
}//end switch
}
}
else if(menu_level == 2){
/*----------------------------------------------*/
if(menu_index[0] ==1){
if(menu_index[2] ==6){
menu_level--;
menu_index[1] = 0;
}
else{
display_CAN_data(menu_index[1]*8 + menu_index[2]);
}
}
/*----------------------------------------------*/
else if(menu_index[0] == 2){
if(menu_index[1] ==1){
switch(menu_index[2]){
case 0: //display location 1
break;
case 1: //display location 2
break;
case 2: //display location 3
break;
case 3:
menu_level --;
menu_index[1] = 0;
break;
default:
break;
}//end switch statement
}
/*----------------------------------------------*/
else if(menu_index[1] == 2){
switch(menu_index[2]){
case 0: //display X accel
break;
case 1: //display Y accel
break;
case 2: //display Z accel
break;
case 3:
menu_level --;
menu_index[1] = 0;
break;
default:
break;
}//end switch statement
}
}
else if(menu_index[0] == 4){
if(menu_index[1] ==0){
if(menu_index[2] == 8){
menu_level --;
menu_index[1] = 0;
}
else{
display_CAN_data(4+menu_index[2] * 8);
while(1);
}
}
}
/********************************************************/
} //level 2
push_on = 0;
} //end push on
if(idle_flag ==1)
idle_page_display();
turn_direction = detectLR();
//Check and latch the turn_direction
if((turn_direction != turn_direction2)|| (menu_level != menu_level2)){
turn_direction2 = turn_direction;
menu_level2 = menu_level;
if(idle_flag ==1)
idle_page_display;
//Display which menu entry to display
if(turn_direction == 2){
idle_count = 0;
idle_flag = 0;
clear_screen();
if(menu_level ==0){
menu_index[0] ++;
menu_index[0] = mood(menu_index[0],7);
}
else if(menu_level == 1){
menu_index[1] ++;
switch(menu_index[0]){
case 0:
case 1:
menu_index[1] = mood(menu_index[1],9);
break;
case 2:
case 4:
menu_index[1] = mood(menu_index[1],4);
break;
case 3:
menu_index[1] = mood(menu_index[1],3);
break;
case 6:
menu_index[1] = mood(menu_index[1],5);
break;
default:
break;
}//end switch statement
}//end level 1
else if(menu_level == 2){
menu_index[2] ++;
switch(menu_index[0]){
case 1:
menu_index[2] = mood(menu_index[2],7);
break;
case 2:
menu_index[2] = mood(menu_index[2],4);
break;
case 4:
menu_index[2] = mood(menu_index[2],9);
break;
default:
break;
}
}// end level 2
}
else if(turn_direction ==1){
idle_count = 0;
idle_flag = 0;
clear_screen();
if(menu_level ==0){
menu_index[0] --;
menu_index[0] = mood(menu_index[0],7);
}
else if(menu_level == 1){
menu_index[1] --;
switch(menu_index[0]){
case 0:
case 1:
menu_index[1] = mood(menu_index[1],9);
break;
case 2:
case 4:
menu_index[1] = mood(menu_index[1],4);
break;
case 3:
menu_index[2] = mood(menu_index[1],3);
break;
case 6:
menu_index[1] = mood(menu_index[1],5);
break;
default:
break;
}//end switch statement
}//end level 1
else if(menu_level == 2){
menu_index[2] --;
switch(menu_index[0]){
case 1:
menu_index[2] = mood(menu_index[2],7);
break;
case 2:
menu_index[2] = mood(menu_index[2],4);
break;
case 4:
menu_index[2] = mood(menu_index[2],9);
break;
default:
break;
}
}// end level 2
}
//Diciding Idle page or Normal Page
if(idle_flag ==1)
idle_page_display();
else
display_system_menu( menu_index,menu_level);
} //End if Latch check
for (i = 0; i< 5; i++)
delay();
}//END while(1) loop
}//end of Main function
/**************************************************************************/
/*Function name: delay */
/*Usage: delay */
/*Return Value: None */
/**************************************************************************/
void delay (void)
{
int i;
for (i = 0; i < 5; i++);
}
/**************************************************************************/
/*Function name: print_sub_menu_3 */
/*Usage: Telemetry InFO */
/*Return Value: The choice user choose */
/**************************************************************************/
void print_sub_menu_3(void){
int i,j;
char ret_char[5] = {' ',' ',' ',' ',' '}; //Initialize the buffer
printf("--------Requesting data from Telemetry ...\n",menu_index);
//Request CAN message and delay
for(i=0; i < 9; i++)
{
request_tele_data(i+208);
for (j=0;j= 0) &&( request = 128) &&( request ................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- the florida state university
- apcd provider file submission guide
- collaborative and prescriptive authority agreement
- businessplus account code overview
- primary care management module user manual
- ee 477 final report purdue university
- introduction
- fmha instruction 1927 b usda rural development
- xerox 03d provider 4intf
- a guide to prescribing administering and dispensing
Related searches
- final maturity of ee savings bonds
- final maturity date for ee bonds
- calculate ee bond final value
- ee savings bonds final maturity
- final cost report nysed
- purdue university plagiarism checker
- purdue university salaries
- project final report template
- project final summary report template
- final grant report sample
- project management final report example
- project management final report template