Vehicle Faulty Lamp and Flasher Identifier

Transcription

1 Vehicle Faulty Lamp and Flasher Identifier Senior Design Dec05-13 Final Report Client Iowa State University Faculty Advisor Professor Gary Tuttle Team Members Joshua Halbur, CPR E Ramy Henin, CPR E Deepak Mishra, CPR E Dhaval Patel, EE Faisal Tamin, EE REPORT DISCLAIMER NOTICE DISCLAIMER: This document was developed as a part of the requirements of an electrical and computer engineering course at Iowa State University, Ames, Iowa. This document does not constitute a professional engineering design or a professional land surveying document. Although the information is intended to be accurate, the associated students, faculty, and Iowa State University make no claims, promises, or guarantees about the accuracy, completeness, quality, or adequacy of the information. The user of this document shall ensure that any such use does not violate any laws with regard to professional licensing and certification requirements. This use includes any work resulting from this studentprepared document that is required to be under the responsible charge of a licensed engineer or surveyor. This document is copyrighted by the students who produced this document and the associated faculty advisors. No part may be reproduced without the written permission of the senior design course coordinator. November 11, 2005

2 Table of Contents LIST OF FIGURES... III LIST OF TABLES...IV LIST OF DEFINITIONS...V SECTION 1: INTRODUCTORY MATERIAL EXECUTIVE SUMMARY Need For The Project Project Activities Final Results Recommendations For Future Work ACKNOWLEDGMENT PROBLEM STATEMENT General Problem Statement General Solution Approach OPERATING ENVIRONMENT INTENDED USERS AND USES Intended Users Intended Uses ASSUMPTIONS AND LIMITATIONS Assumptions Limitations EXPECTED END PRODUCT AND OTHER DELIVERABLES Sensor System Control Unit Displaying Device Prototype SECTION 2: PROJECT APPROACH AND RESULTS END PRODUCT FUNCTIONAL REQUIREMENTS RESULTANT DESIGN CONSTRAINTS Design Objectives Design Constraints APPROACHES CONSIDERED AND ONE USED Display Technology LCD Segment LED Display Result Sensing Technology Lamp Sensing Technology Flasher Sensing Technology Controller Technologies Microcontroller Current Routing Technology Testing Approach Considerations Individual Systems Testing Full System Testing Environmental Testing Recommendations Regarding Project Continuation or Modification DETAILED DESIGN Display System Processing System Hardware Design Software Design Sensor System Comparator Current Sensor i

3 2.4.4 Full System IMPLEMENTATION PROCESS DESCRIPTION END-PRODUCT TESTING DESCRIPTION Individual System Testing Testing of Sensory System Software Testing of the PIC Full System Testing Environmental Testing PROJECT END RESULTS Hardware results Software results Overall system results SECTION 3: RESOURCES AND SCHEDULES RESOURCES REQUIREMENTS Personnel Effort Requirements Other Resource Requirements Financial Requirements SCHEDULES SECTION 4: CLOSURE MATERIAL PROJECT EVALUATION COMMERCIALIZATION RECOMMENDATIONS FOR ADDITIONAL WORK LESSONS LEARNED What Went Well What Did Not Go Well Technical Knowledge Gained Non-Technical Knowledge Gained What Would Be Done Differently RISK AND RISK MANAGEMENT Anticipated Potential Risks Anticipated Risks Encountered and Risk Management Unanticipated Risks Encountered Changes Made Due to Unanticipated Risks Encountered PROJECT TEAM INFORMATION CLOSING SUMMARY APPENDIX A: MICROCONTROLLER PROGRAM CODE LCD Driver Faulty Detector Code Cross reference for the lamps APPENDIX B: SUPPLEMENTAL INFORMATION ON SELECT HARDWARE ii

4 List of Figures Figure 1: Top-Level components diagram of the end product... 8 Figure 2: Sensory System Schematic Figure 3: LCD Pin out Figure 4: PIC Pin out Figure 5: Previous Sensory System Design Figure 6: Detailed project Gantt chart excluding deliverables Figure 7: Project Gantt chart for deliverables only Figure 8: Comparison Gantt chart for the first half of the project tasks Figure 9: Comparison Gantt chart for the second half of the project tasks Figure 10: Completion percentages for each task Figure 11: Block Diagram of the LCD Figure 12: Block diagram for the ACS750LCA iii

5 List of Tables Table 1: Bill of Materials Table 2: The 16 I/0 pins of the LCD Table 3: Original personnel effort requirements Table 4: Revised personnel effort requirements Table 5: Original additional resource requirements Table 6: Revised additional resource requirements Table 7: Original Financial Requirements Table 8: Revised financial requirements Table 9: Project Evaluation Summary Table 10: Tolerances for the LCD and controller Table 11: Electrical characteristics for the LCD and controller Table 12: ACS750LCA-057 specifications iv

6 List of Definitions BJT Bipolar Junction Transistor Burden Resistor that limits current flow. resistor Client Senior design / Iowa State University Component Refers to a part that is being monitored for failure by the system. This includes flasher units, bulbs, and bulb filaments. De-bounce The period of time designated to allow for a physical switch to reach its steady state. Decoder A device used to encode a bus of n bits into a single bit signal that goes to a specific switch. Basically, this decoder acts as a de-multiplexer in the circuit. Filament A part of a lamp/bulb that produces light. Flag Binary value that is set in software that states the occurrence of an event. I/O Input / output Instrument panel The panel displaying vehicle information such as speed, RPM and system status indicators. Lamp / bulb Used interchangeably to refer to the component installed in a vehicle to produce light. LCD Liquid crystal display Logic high +5 Volts Logic low 0 Volts Make The vehicle manufacturer. (e.g. Ford, Toyota, Mercedes, etc.) Microcontroller Integrated circuit that implements low level logic in order to complete a given set of tasks. Model The configuration of the make. (e.g. Camry, Taurus) MOSFET Metal Oxide Semiconductor Field-Effect Transistor PIC Programmable integrated circuit Processing unit The system that collects information from the sensory system and relays the data to the display. Steady state value The output that a system reaches after period of time, where the output remains relatively fixed. v

7 Section 1: Introductory Material This section includes an introduction to the project as well as the general problem statement solution approach, operating environment, intended users and uses as well as the initial assumptions and limitations. 1.1 Executive Summary Need For The Project The general problem in a vehicle s faulty lamp detection system is that it is not precise enough to inform the user with the exact details of the failure. The vehicle faulty lamp detection system does not specify which bulb has failed and if there are multiple filaments which have burned out. The best way to solve this problem is to design a system which monitors each individual bulb. The system shall have features such as being able to report if there is a failure in a multiple filament lamp, report if there is a failure in the instrument panel, report multiple failures and clearly delineate each failure and perform self tests. The project shall consist of a design stage, a testing stage and a mock implementation stage to show the functionality of the device. The mock implementation stage shall show if the system works and if it is a feasible system for auto manufacturers Project Activities The project consisted of the following activities: 1. Project definition 2. Technology considerations 3. Implementation / design considerations 4. End product design 5. End product prototype implementation 6. End product testing 7. End product demonstration Final Results All the tasks mentioned in section have been attempted. Please refer to table 9, project evaluation summary for further details. A prototype was designed and built based on the project requirements. However, the testing phase was not completed due to the failure of the decoder component. Please refer to section 2.7 for details on the project results. 6

8 1.1.4 Recommendations For Future Work After careful consideration, the group does not recommend continuing the project beyond the scope of this project due to the advancing technologies used today by many vehicle manufacturers. 1.2 Acknowledgment Professor Tuttle has been an excellent advisor for the team. In addition to his advising duties, he has helped the team members with the selection of parts, procurement of parts and test equipment as well as much needed help during the implementation and testing phase. 1.3 Problem Statement This section discusses the general problem statement and the general problem solution General Problem Statement The general problem for motorists is realizing when exterior lights and/or a flasher unit are faulty. These individuals can be hazardous to themselves and others if other drivers are unable to see a brake light or turn signal due to a failure in the aforementioned systems. Most individuals would be unaware of failed lights because they do not see the exterior lights when they are in use. Many vehicles have a system which lets the user know when a lamp is out, however these systems do not alert the user of multiple lamp failures, flasher failure, or where the failure is located. The systems also do not alert the motorist when an instrument panel indicator has failed General Solution Approach To help solve these problems, a simple system to detect a faulty light has been designed. To do this, the team has designed a circuit to test the lights and the flasher unit. The circuit will then relay a signal back to a processing circuit that will read the signal and display, if needed, that a light bulb or flasher unit has failed. This system is designed to test all major exterior lights as well as instrument panel lights on startup. The system will also periodically test these lights during the operation of the vehicle, that is, during the time when the vehicle s ignition is on. To test each exterior light, the system designed contains three parts as shown in Figure 1. The first part is the fault detector. This will detect whether the light is faulty and relay this to the second part. The second part is the processing circuit which will read and interpret the data from the fault indicators and output the results to the third part. The third and final part is the display. The display will output the processed results from the processing circuit. 7

9 Figure 1: Top-Level components diagram of the end product 1.4 Operating Environment The operating environment for this product is similar to that of any other electronic component in the vehicle. The controller will be mounted in one of two places in the vehicle, mounted in the engine bay or inside the vehicle behind the instrument panel. It must be able to withstand extreme temperatures. The device must remain functional despite a shock from a relatively low speed vehicle collision; one where there vehicle is still in drivable condition. Also, it must be able to tolerate vibrations due to the engine or an uneven road surface. In the event that it is mounted in the engine bay, it must be able to operate in a polluted environment. In addition to a shock from a vehicle collision, the product must also withstand shocks from any road debris that may get swept up from the road. While it is not intended to operate if immersed in water, the unit must remain operational in harsh weather conditions. 1.5 Intended Users and Uses This section describes who this product is intended for use by and what those uses are Intended Users The product is intended for use by anyone that is licensed to operate a motor vehicle as well as automotive mechanics Intended Uses The product is designed to detect faulty lamps on the exterior of the vehicle or a faulty indicator in the instrumental panel. The exterior lights are monitored because the 8

10 driver may be unaware of the functionality of these lights while operating the vehicle. Also, these exterior lights and the indicators in the instrument panel are crucial to the safe operation of the vehicle. Therefore the product should be able to detect and report a faulty filament as quickly as possible. 1.6 Assumptions and Limitations The two following sections are lists of the assumptions and limitations that are to be planned around Assumptions The following is a listing of the assumptions: 1. The reporting will be within the vehicle on the instrument panel using an LCD. 2. If necessary, the user can cross reference the user manual for complete instructions on how to locate the faulty lamp and ensure the system self-test is fully functional. 3. The system will be designed to be an autonomous system. 4. The system shall be able to monitor up to a maximum of 28 filaments. 5. The dashboard lights shall be tested on startup. 6. The system self test shall be implemented upon start up only and shall only test the sensory equipment and controller. 7. The flasher units will only be tested upon turn signal / flash hazard activation. 8. The design shall be a proof-of-concept due to lack of time, funding, and equipment for testing and implementation of a production quality model Limitations The following are the current limitations provided by the client: 1. The system shall be for a new vehicle, installed during manufacture of the vehicle. 2. The system shall monitor all exterior and instrument panel lamps within the vehicle. 3. The system will report any faulty bulbs. 4. The system shall be able to distinguish a failed flasher unit. 5. The system shall be able to detect and report specific faulty filaments within multi-filament bulbs. 6. The system shall be able to delineate multiple lamp failures and report them to the user. 7. The system shall be able to withstand the operating environment within a vehicle. 8. The system shall have a self test to ensure that it is working properly. 9. The results shall be displayed to the user until the failures have been remedied. 10. The system shall be light weight and small enough to fit inside a motor vehicle. 9

11 1.7 Expected End Product and Other Deliverables The overall system is a proof-of-concept which is implemented only at a bread board level. A complete set of software is included within the design and a working circuit that a designated microcontroller can use to detect failures. Listed below are brief descriptions of the individual subsystems Sensor System This is a device that will be installed inside the vehicle. The purpose of this device is to sense when one or more vehicle light bulbs or flasher units have failed. This sensory system will be activated by the controller Control Unit This device activates the sensory system, performs a system check, and analyzes the received signals to determine if there is a failure. The system is able to delineate multiple failures based on input from the sensory system. The system will then output appropriate information to the display Displaying Device This device is an LCD that will be installed in the instrument panel of the vehicle. The purpose of this device is to display messages from the control unit. The screen displays a message to indicate the exact light bulbs or flasher units that have failed. Also, the display does not disturb the driver Prototype The prototype created is a proof-of-concept artifact to prove that this project is feasible given the technologies available. It is not able to support 28 lights, and is not to be mounted in a vehicle. Since this design is only a proof-of-concept design, no user manual will be created for use. 10

12 Section 2: Project Approach and Results The following sections contain detailed descriptions of the project approach, design, and results. 2.1 End Product Functional Requirements The following is a list of functions that are performed by the end product as specified by the client: The system is able to detect faulty bulbs as well as the exact faulty filament in a multi-filament bulb. The detection process is a sequential process, that is, each bulb or flasher unit is tested separately in a specified order. Fault messages are displayed only after the completion of the detection process. The detection process is performed periodically only when the vehicle s ignition is on. During the operation of the vehicle, the system tests all the bulbs and flasher units and displays the appropriate messages. This ensures that the user gets informed of a failure within a reasonable amount of time. This detection system does not interfere with any other system in the vehicle, and only functions autonomously with all other systems to guarantee that no obstruction can exist. 2.2 Resultant Design Constraints Design Objectives The following is a list of the design objectives for the end product: Develop a system that tests for faulty bulbs including multi-filament bulbs in a vehicle. Integrate the capability of detecting dysfunctional flasher units. Design this system such that it can be easily integrated into a vehicle during manufacturing. The system will use the vehicle s electrical power system. Add an LCD unit to the system to report to the user the exact problem and its location. That is, inform the user of the exact bulb that is burnt out or a problem with a flasher unit. The LCD will also act as a means to report the system status to the user, including self-test and detection process results. Integrate a PIC to control the functionality of the testing and current sensing circuits as well as handle the interface with the LCD. 11

13 Implement a self-test protocol by which the system can ensure its own functionality prior to testing of bulbs and flasher units. Design this system such that the minimum numbers of components are needed. This will allow the end product cost to be low Design Constraints This following list covers the design constraints for the system. 1. Size - The system will be compact enough to be installed within the vehicle. 2. Durability - The system will be able to withstand the environment within the vehicle. 3. Testing - The system will test all exterior and instrument panel lamps once upon vehicle start up and the exterior lamps every 5 minutes thereafter while the vehicle s ignition is on. The turn signal and hazard flasher units will only be tested when their corresponding switches are activated for more than 2 seconds. The system will measure the flasher units period and compare it with a range of acceptable values. If a flasher unit s period is out of that range, the system will report a failure. The system will perform a self-test upon vehicle startup to ensure proper operation of the testing circuits and controller. 4. Reporting - The system shall be able to determine the specific component failure and report this malfunction to the driver via an LCD located in the instrument panel. The system shall be able to detect and report multiple failures. 5. Operation - At no point should the testing system interfere with the proper operation of any lamp or flasher unit. 6. Design - The system will have to be calibrated to the vehicle in which it is installed. The system will be designed to test up to 28 filaments and 2 flashers, but will be scaleable with slight software and possibly hardware modifications. 7. User assistance - The vehicle s users manual will have a section that the user may cross-reference for assistance in locating/remedying the detected failure. 12

14 2.3 Approaches Considered and One Used This section covers the technology considerations for the three main components (display, sensing, and controller) and the results of these considerations Display Technology The use of an LCD or 7-Segment LED displays was considered LCD An LCD would allow for text messages, rather than only alpha-numeric codes, to be displayed to the user identifying the failure that has occurred. This will increase the ease of use of this product for the end user. However, an LCD is more sensitive to extreme temperatures, requires a larger mounting area, and has a much higher price Segment LED Display A 7-Segment LED display would allow the end product to operate in a wider temperature range and requires less mounting area, allowing the end product to be smaller. Due to the limited character capabilities of a 7-Segment LED display, only alpha-numeric codes, and not text messages, can be displayed. This makes the operation for the user more complex Result Due to the flexibility of using an LCD, the team opted to spend the extra money and chose it as the display technology for the end product Sensing Technology There are two different systems which were considered, the first is the vehicle s lamps and the second is the vehicle s flasher units. This subsection covers these considerations Lamp Sensing Technology Two technologies were considered for testing the proper functionality of lamps: light sensing and current sensing Light Sensing The main benefit of using a light sensor is its ease of implementation. Since a light sensor does not directly interact with the bulb or its electrical system, there is no need to modify the existing wiring system. Since light sensors work by simply sensing the amount of light at the sensor, it is prone to outside interference such as the sun or oncoming vehicle lights. 13

15 Current Sensing A current sensor, since it is directly linked to the bulb, is not prone to outside interference, thus, is more accurate. Because a current sensor has a direct link to the bulb, it requires modifications to the existing electrical system. Because the electrical system will be modified, the current needs to be rerouted and thus another technology, current routing technology, would need to be considered Result A current sensor was chosen for the lamp sensing technology because of its resistance to outside interference Flasher Sensing Technology Two technologies were considered for testing the proper functionality of the flasher units: current sensing and voltage comparator Current Sensing A current sensor would be the most accurate way to test the flasher units. The downside to using a current sensor is that it will need to be wired in series with the flasher unit and therefore will have to deal with the high currents. In addition, it has a much higher price Voltage Comparator A voltage comparator will be able to detect the flasher failure and is cheaper and easier to install into the system Results The voltage comparator was chosen because of its low cost and ease of implementation Controller Technologies A PIC was the only technology considered for the control unit. The current routing circuitry was included within the controller technology portion because it is not an autonomous system, but a system which is directly controlled by the PIC Microcontroller Only one technology was considered for the microcontroller. The rationale for this selection is shown below PIC A PIC is easily programmable and readily available for the needs of the project Results 14

16 Since a PIC was the only technology considered for the system s control, the PIC was selected Current Routing Technology Three technologies were considered for routing the high current: relays, MOSFETs, and BJTs Relay Relays have the ability to handle high currents. However, they require a large amount of mounting space compared to other possible choices and require a larger input voltage to switch states MOSFET MOSFETs have fast switching capabilities, low power loss, and require minimal mounting area. When implemented properly, MOSFETs provide near seamless current routing. MOSFETs that are within the project s budget, however, lack the current handling capabilities required BJT BJTs have moderately fast switching capabilities, low power loss, and require minimal mounting area. When implemented properly, BJTs provide near seamless current routing. BJTs that are within the project s budget, however, lack the current handling capabilities required Results Due to the high current handling requirements of this project, relays were chosen for the current routing solution. 15

17 2.3.4 Testing Approach Considerations This section consists of the testing approach considerations Individual Systems Testing This section describes how each individual system in the design shall be tested Testing of Sensory System The system shall be constructed and then tested on a test bench. The only portions of the system that need to function properly are the sensors. The sensors shall be tested for sensitivity and also to ensure that they correctly output the proper values for failed lamps and working lamps Software Testing of the PIC The system shall be tested with a test bench created by the team. Mock inputs from the vehicle and the sensory system shall be supplied by the test bench and pending proper output the PIC shall pass testing. The system shall be tested for proper self test implementation; proper light detection; proper detection and reporting of single filament, multiple filament, and flasher unit failures Full System Testing The entire system shall be constructed using the sensory system model and a PIC. A test bench shall be created and the system shall be implemented using hardware. The parts ordered are assumed to work correctly as specified by the vendor. A minimal check shall be performed to ensure that they are properly working upon receiving them. The system shall undergo the testing where several scenarios are played, such as, ignition, testing during operation of the lamps, testing single lamp failures, testing flasher unit failures, and testing for multiple lamp failures. If all tested aspects pass successfully for all selected scenarios, the system shall pass the test. If any aspect fails, then the system shall fail and updates to the system shall take place to ensure the system is working Environmental Testing Upon completion of system testing, the system shall undergo environmental testing. The system shall undergo thermal cycling, and vibration testing to ensure it is qualified for use in a vehicle. This option may not be feasible to the team due to lack of time, experience and funding for the task. 16

18 2.3.5 Recommendations Regarding Project Continuation or Modification The group recommends that the project does not continue beyond this effort. Due to a vast changing automotive world and the rapid acceleration in use of microcontroller and microprocessors in vehicles, this project s scope is not a feasible endeavor. Vehicles today have processors and computing systems which can not only detect faulty lamps, but check many different systems and even control the vehicle s traction control system, fuel economy to an extent and other major vehicle systems. This project shows that it is feasible to have a faulty lamp monitoring system; however, in comparison to the new technologies used today, it is not feasible to continue this design. It is feasible to start a new design with a much broader scope, allowing more functionality of the product. 2.4 Detailed Design The design for the faulty vehicle light system contains three main subsystems. The three subsystems are: sensor system, controller system, and display system. Figure 1 shows a system schematic of the sensory systems and Table 1 shows the bill of materials. 17

19 Figure 2: Sensory System Schematic 18

20 Table 1: Bill of Materials Quantity Part Description Unit Cost Reference 1 MicroChip 16F877A-I/P Microcontroller $ - Figure 1 Omron G5A-234P-DC12 Relay $ 4.34 Figure 3: Relay 1 Fujitsu FTR-F1CA012V Relay $ 2.28 Figure 3: Relay 2 Fairchild 74F538PC 1-of-8 Decoder $ LT 339 Comparator $ - Figure 3: Comparator 1, 2 1 Allegro ACS704 Current Sensor $ - Figure 3: Current Sensor Resistor Resistor Figure 3: R1 Resistor Resistor Figure 3: R2 Resistor Resistor Figure 3: R3 2 Resistor Resistor Figure 3: R4, R8 2 Resistor Resistor Figure 3: R5, R9 2 Resistor Resistor Figure 3: R6, R7 2 Diode Diode Figure 3: D1, D2 1 HDM LCD Display Figure Display System The display system consists of an LCD. The LCD used is the HDM16416L-1-L30S LCD from The LCD has a display area of 16x4 characters, has a built on HD44780 or equivalent LCD controller board and costs $ The LCD unit has a total of 16 I/O pins. The pin usage is as follows: 3 pins for power supply 1 pin for data/instruction input 1 pin for read/write data 1 pin for enable 8 pins for data bus 1 pin for backlight anode 1 pin for backlight cathode This is also shown in Figure 3 and Table 2. Tolerances for the LCD and controller are shown in Table 10 of Appendix D. VDD for the LCD is set to 5 +/-.025V at 25 degrees Celsius. Table 11 of Appendix D shows the electrical characteristics of the LCD. 19

21 Figure 3: LCD Pin out Table 2: The 16 I/0 pins of the LCD ( 20

22 2.4.2 Processing System The processing system has two design components, the hardware design and the software design Hardware Design The processing system is comprised of a PIC, a decoder, and n solid state switches (where n is the number of filaments to be tested). The PIC being used is Microchip PIC, part number 16F877A. The PIC is responsible for controlling, testing, and interpreting the test data and displaying the appropriate output on the LCD. The PIC pin out is shown in Figure 4. Figure 4: PIC Pin out m The decoder accepts an m bit wide bus (where 2 = n + 2 ). The decoder specifies the filament to test. There are two modes of operation, the first is when the lamps are on and the second is when the lamps are off. The processor controls a set of relays which act as the switches. The relays used 21

23 have been listed in the bill of materials in table 2, and are referenced on the final schematic. During operation of the relays, an inductor inside the relay is used to throw a switch. This inductor creates a reverse current, which can possibly damage the decoder and microcontroller. To protect against this, a diode is connected, shown the system schematic (figure 1), to allow for the dissipation of the reverse current Software Design About the Software Design The software for the PIC 16F877A microcontroller was written in the C programming language. The code was written using the MPLAB IDE and compiled using the CCS C compiler for Microchip PICmicro MCUs Customizability Prior to compiling the software, there are a number of options that are customizable. The first option is the number or filaments to be tested. Any integer from 0 to 28 may be entered. Hardware modifications (namely the decoder) may be necessary to accommodate the number of filaments. The second option is the propagation delay. This option sets the amount of time between when the decoder is switched on and when the input from the current sensor is read. The time is entered in milliseconds. The third option is the de-bounce time. This time is to allow for the flasher clicks to reach a steady state value. The fourth and fifth options are the minimum and maximum flasher rates, respectively; these values represent the number of times the flasher clicks on (allows current to flow) per second. There is also a source file named codes.c that contains two arrays that store the messages for each failure. The messages are split into two arrays due to hardware limitations of the microcontroller. Each message may be up to 12 characters in length Overall System Overview The system starts by calling an initialization function. Then the system performs a self test. If the self test fails, the software exits. If the self test passes, the program enters a loop where it checks to see if a flasher has been activated. If one has been activated, the system performs the flasher test for as long as the flasher is active. If no flasher is active, the software checks a flag stating if the filament tests are done. This flag is initially set to false. If the flag is set false, a filament is tested. If the flag is 22

24 set to true, the system displays the first three failures. If there are more than three failures, the program scrolls through them during the subsequent loop iterations. After all the failures are displayed, the flag is set to false and testing process begins again. The loop continues to run for as long as the vehicle s ignition is in the on position. An array is maintained Initialization The software starts when the vehicle s ignition is set to the on position. Upon startup, the software runs an initialization process. The purpose of this process is to initialize the LCD and display a welcome message so that the user knows the display is functioning properly. Additionally, the initialization process initializes any global variables needed. The array that stores the results of the flasher and filament tests is initially set so that all the elements are considered passing Tests The testing process consists of setting the decoder output to the desired element to test and the enable to logic high. After a short delay (determined by the programmer before compiling the program) the software checks the input from the current sensor, which is either a logic high or logic low. The software then records if the test passed or not in an array. The decoder s enable is then set back to a logic low Self-test After the initialization process, the software performs a test to ensure the sensor is functioning properly. There are two parts to the self test. The first part is testing a high output from the current sensor. The software enables the output of the decoder that allows current to pass through the sensor. The software then tests to see if it receives logic high. The second part of the test is to test a low output from the current sensor. The software enables the output of the decoder that allows no current to pass through the sensor. The software then tests to see if it receives a logic low. The purpose of these tests is to ensure that the current sensor is not stuck at either high or low. If either test fails, a message is displayed on the LCD and the program exits Filaments Test 23

25 After the self test passes, the software enters a loop where it tests each individual filament that is connected to the system. An iteration of the loop tests one filament if the flasher test does not need to be performed. A test consists of setting the appropriate decoder output and then checking for logic high on the input from the current sensor. The result of the test is stored in the results array. Upon completion of the test, the test counter is incremented so that the next filament is tested during the next iteration of the loop. When all filaments have been tested, a flag is set to true so that the display function knows the tests are completed Flasher Test At the start of an iteration of the main loop, the states of the flashers are checked. If either flasher is active, the flasher test is started. The test runs for as long as the flasher is active. While the test is running, the number of times the flasher goes high (allows current to pass) is stored. A timer is used to keep track of how long the flasher was active. When the flasher is deactivated, the rate is calculated and is determined to be passing or not based on the minimum and maximum rate values. The result of the test is stored in the results array Display Results When the flag indicating the tests are done is true (i.e. all the filaments have been tested), the display function starts. An iteration of the main loop displays up to three failures. If there are more than three failures, the display function scrolls through them in the subsequent iterations of the main loop. When all the failures have been displayed, the flag is set back to false so that the filament tests can be run again Sensor System Two types of sensing technologies have been implemented for use in this design. The first is a current sensor which tests the lamps, and the second is a comparator circuit which tests the flasher unit Comparator The comparator is an LM 139. The comparator checks to see that the lamp and the flasher are working. If the lamp and flasher are working, the comparator output oscillates between logic high and 24

26 logic low while the flasher is active. The microcontroller checks to see if the comparator s output is oscillating within a predetermined frequency range. If the frequency falls within the predetermined range, then the lights connected to the flasher are functional. If there is no oscillation, then the flasher has failed. Since the comparator s output is either high or low, no analog to digital conversion is needed and the microcontroller can be directly connected to the output. The LM 139 was selected due to its voltage clamping abilities on the output Current Sensor Initially only one current sensor was chosen for this design. The sensor selected for this design was the Allegro ACS704ELC-005 current sensor. The device measures current from a range of -8 to +8 amps. However, there are two problems with this design shown in Figure 5. Figure 5: Previous Sensory System Design 25

27 The first is that the circuit does not test during operational mode based on the current wiring scheme (this problem was solved by correcting the wiring scheme). The second problem faced was that there are two modes of operation. The first is a cold start. The lamps operate so that initially they have very small resistances which cause very large currents due to a fixed 12 volt dc power supply. As time progresses the filaments in the lamps heat up and the resistance increases. As a result, the range of current that the sensor must be able to handle (based on calculations and verified by labs tests) is from.5 amps to 5 amps during normal operation of a lamp to 4.8 amps to 36 amps during a cold start. This dynamic range created a problem in that if a current sensor with a large input range was used, then the microcontroller would have trouble detecting subtle changes in the current sensor s output. To solve this problem, burden resistors have been added to the design to current limit the circuit during a cold start condition. The resistors have been set so that the summation of the burden resistor and the cold start resistance of the lamps is approximately 5 ohms. This enables the use of one current sensor for the design. The current sensor used in the circuit is the ACS704ELC-015. This current sensor has a range from -15 to 15 amps. The output of the current sensor has been connected to a differential amplifier to account for a 2.5 Voltage offset, which is part of the chip to allow for negative currents. The amplifier design is shown in the final schematic (figure 2 ) and the resistors were sized so that the output of this amplifier is from 0 to 12 V. The lowest current tested resulted in an output that was approximately 0.08 V from the differential amplifier. In order for the PIC to see this as a proper functioning lamp, the output had to be magnified to approximately 2 V. To magnify this an non inverting op amp circuit was implemented to amplify the output of the differential amplifier. The resistor values were set so that the.08 V output of the differential amplifier was magnified to approximately 3 volts. The overall design is shown in figure Full System. The system diagram with the microcontroller removed can be found in Figure 2. The schematic shows the systems with the PIC and decoder removed. The bill of materials can be found in table 1. 26

28 2.5 Implementation Process Description The implementation process consists of 2 parts: circuit schematic development and PIC programming. The team created breadboard circuit for the sensory system. A problem encountered was that the current sensor needed a special mounting board. The team overcame this by soldering wires to the leads on the current sensor. This solution was not a good method of solving the problem because the leads on the current sensor broke during testing. Another sensor with a test board was purchased. This solved the current sensor problems. The PIC programming includes modifying an existing LCD driver and creating code to implement the tests, process the results and display the failures on the LCD. 2.6 End-Product Testing Description This section shall consist of the testing activities Individual System Testing This section shall describe how each individual system in the design was tested Testing of Sensory System The system was constructed and then tested on a test bench. The only portions of the system that needed to function properly were the sensors. The sensors were tested for sensitivity and also tested for correct output for failed lamps and working lamps. The sensor was tested and a 2.5 volt offset was found. To alleviate this problem a differential amplifier was connected to the output and then an non inverting amplifier was connected to that output to ensure a proper input to the PIC. This concluded testing of the sensory system, which was successful Software Testing of the PIC The system was tested with a test bench created by the team. Mock inputs to simulate the vehicle and the sensory system shall be supplied by the test bench. The propagation delay for the test was set to a large value, so that the person testing had time to simulate the desired conditions. The system was tested for proper inputs for the self test, filament test and flasher test. This individual software testing of the PIC was successful Full System Testing 27

29 The full system testing consisted of integrating the PIC circuit with the current sensing circuit. The purpose of this test was to ensure the software and hardware interfaced properly. Unfortunately, when the circuit was tested, the decoder caused a failure in the system. The problem was that the decoder Vcc and input voltages from the PIC did not match and as a result, caused the decoder to have an over-current fault. This cause of this failure was initially unknown and a second decoder was tested and resulted in the same failure. After further isolated, individual testing of the decoder, the cause was determined, but not until after a third decoder had failed. When trying to come up with a solution, the final decoder failed Environmental Testing Due to lack of time, funding, and facilities, the environmental testing will not be done. 2.7 Project End Results Hardware results All hardware was tested and functioned properly with the exception of the decoder. The problem was due to a voltage mismatch and could be resolved by obtaining a more reliable decoder Software results After a number of revisions, the software has been tested and is working correctly Overall system results The result of the overall system test is inconclusive due to the failure of the decoder. Further testing with a different decoder would be required to ensure proper operation. 28

30 Section 3: Resources and Schedules The following section contains detailed information about the resources that were originally stated in the original project plan as well as the resources used up to date and a revision of these resources. The original and updated project schedule and Gantt chart are also discussed, as well as a Gantt chart indicating the completion percentage of each project task. 3.1 Resources Requirements This section describes in detail the various resources that were used throughout all project phases. These resources include man hours and labor, cost estimates, as well as other resources Personnel Effort Requirements This section describes both the original and current estimates of resource requirements for personnel effort. Table 3 shows an estimate of the amount of time required to complete the following project tasks: 8. Project definition 9. Technology considerations 10. Implementation / design considerations 11. End product design 12. End product prototype implementation 13. End product testing 14. End product documentation 15. End product demonstration 16. Product testing The totals are calculated for each task as well as for each engineer working on the project. Table 4 has the revised totals. Note that task 9 has been removed from the updated personnel effort requirements because it is redundant with task 6. Table 3: Original personnel effort requirements Engineer's Name Task 1 Task 2 Task 3 Task 4 Task 5 Task 6 Task 7 Task 8 Task 9 Totals Dhaval Patel Ramy Henin Joshua Halbur Deepak Mishra Faisal Tamin Totals

31 Table 4: Revised personnel effort requirements Engineer's Name Task 1 Task 2 Task 3 Task 4 Task 5 Task 6 Task 7 Task 8 Totals Dhaval Patel Ramy Henin Joshua Halbur Deepak Mishra Faisal Tamin Totals Revised Other Resource Requirements Table 5 shows the original additional resource requirements. This estimate includes hardware parts that might be acquired as part of the technology research but not necessarily used in the end product. Table 5: Original additional resource requirements Item Team Hours Other Hours Cost 1. Project poster including printing 15 $ Project plan documentation $ Prototype Parts $ Subtotal $ Table 6 shows the revised additional resource requirements. Table 6: Revised additional resource requirements Item Team Hours Other Hours Cost 1. Project poster including printing 15 $ Project plan documentation $ Prototype Parts $ Subtotal $ revised Financial Requirements Table 7 shows the original financial requirements for the project as a whole (parts and labor). 30

32 Table 7: Original Financial Requirements Item Team Hours Other Hours Cost 1. Project poster including printing 15 $ Prototype Parts/ Testing $ Subtotal $ Labor at 10.50/hr Dhaval Patel 142 $1, Ramy Henin 149 $1, Joshua Halbur 134 $1, Deepak Mishra 126 $1, Faisal Tamin 127 $1, Subtotal $7, Total $7, Table 8 shows the revised financial requirements for the project as a whole (parts and labor). Table 8: Revised financial requirements Item Team Hours Cost 1. Project poster including printing 15 $ Project plan documentation $ Prototype Parts/testing $ Subtotal $ Labor at 10.50/hr Dhaval Patel $1, Ramy Henin 142 $1, Joshua Halbur 145 $1, Deepak Mishra $1, Faisal Tamin 136 $1, Subtotal $7, Total $7,

33 3.2 Schedules Figure 6 is the original Gantt chart detailing the start date and duration of each task to be done in the project. All subtasks are listed as well. The chart details both semesters of the project. It is worth noting that the project was on hold over the summer of 2005 because of the summer vacation, and continued as normal in late August of 2005 with the beginning of the fall semester. 32

34 Figure 6: Detailed project Gantt chart excluding deliverables 33

35 Figure 7 is the original Gantt chart detailing project deliverables only. These include recurring tasks such as weekly meetings and s as well as major reports which include the project plan (this document), project poster, end product design report and the final project report. Figure 7: Project Gantt chart for deliverables only An updated Gantt chart has been created to assess the project s progress up to date and compare it to the original Gantt chart. This helps the team determine how the project progress stands in comparison with where it should be at. Figure 8 shows this comparison for the first half of the tasks, and Figure 9 shows the second half. It is important to note that the original project schedule is in black and blue and the updated project schedule is in maroon and green as shown in the figures. Currently the project is scheduled to be completed prior to the originally anticipated date as shown in Figure 9. The schedule for project reporting and deliverables remains unchanged, and therefore is shown as in the original project schedule. Figure 10 shows the up to date completion percentages for each tasks on the updated project schedule. 34

36 Figure 8: Comparison Gantt chart for the first half of the project tasks. 35

37 Figure 9: Comparison Gantt chart for the second half of the project tasks. 36

38 Figure 10: Completion percentages for each task. 37

39 Section 4: Closure Material This section contains detailed contact information about all those involved in the project as well as a summary of the project. 4.1 Project Evaluation This section is a summary of the project assessment process. Each of the major project phases have been evaluated based on completion, meeting phase goals, being on schedule, and being under budget. The following are the different assessment levels and their descriptions: Greatly Exceeded: All minimum requirements were met with much extra work to better the end product. Exceeded: All minimum requirements were met with the addition of some extra work. Fully Met: All minimum requirements were met. Partially Met: Some of the minimum requirements were met. Not Met: Task or phase was attempted, but none of the minimum requirements were met. Not Attempted: Task or phase was not attempted at all. The following is a list of the major project phases and deliverables along with the corresponding evaluation and a justification for each: Project Phases: Project Definition: Fully Met The project definition phase s goals were to define the requirements and goals for the project. The goals of this phase were all accomplished successfully. Technology Considerations: Exceeded Team members were able to research the scope of this project to determine the current technologies that can be used. The goals of this phase were accomplished and exceeded which led to being able to select the correct parts for the prototype. Implementation / Design Considerations: Fully Met The goals of this phase were all accomplished, and the result was being able to determine the target environment for the prototype and the end product. End Product Design: Partially Met 38

40 The goals of this phase were partially met. The end product design was finalized and approved; however, further modifications are required due to hardware implementation issues. End Product Prototype Implementation and Testing: Partially Met This phase is being completed. Current the team is testing the prototype. Due to a hardware failure, this portion of the project has been suspended. End Product Documentation: Not Attempted Given the time constraints for this project, the end product documentation was not attempted. This decision was made based on the fact that the prototype is a simple version of what the end product would be like. In other words, developing documentation for the prototype will not be applicable for the end product. End Product Demonstration: Not Attempted Since the implementation and testing phases have not yet been completed, no demonstration has been shown to the client. Deliverables: Project Plan Document: Fully Met The project plan document was submitted on time. It included the basic ideas and goals of the project. Project Poster: Fully Met The project poster was completed successfully and on time. It was intended to give a brief idea of the project given the requirements drafted in the project plan document. Final Report: Fully Met The design document contained all the details of the project design and how it was implemented. This document acted as a guide during the prototype implementation and testing phase. The following table summarizes the project evaluation for each phase and deliverable, as well as presents a percentage of completion for each 39

41 Table 9: Project Evaluation Summary Phase / Deliverable Evaluation Project Definition Technology Considerations Implementation / Design Considerations End Project Design Prototype Implementation and Testing End Product Documentation End Product Demonstration Project Plan Document Project Poster Final Report Fully Met Exceeded Fully Met Fully Met Partially Met Not Attempted Not Attempted Fully Met Fully Met Fully Met 4.2 Commercialization This design does not have the potential for commercialization due to the reasons found in section Recommendations for Additional Work The group does not advise additional work with this design due to the reasons found in section However, a new project with a much broader scope could be defined, where more subsystems are controlled and monitored by a microcontroller or microprocessor. 4.4 Lessons Learned This section covers some of the pros and cons of the project and an overview of the non-technical knowledge gained What Went Well All aspects of the design and individual component testing went very well. Communication between team members and the faculty advisor was excellent. 40

42 4.4.2 What Did Not Go Well The procurement of parts did not go well. There were several communication problems between the team, the buyer, and the test equipment supplier. This problem caused a major delay in the project schedule, pushing back testing. Otherwise, there were no delays. Due to inability to procure a mounting board for the current sensor, wires had to be soldered on to the very small device. The stress of these wires proved to be too much for the current sensor and resulted in the breaking of the ground lead. There were also some problems with documentation. The problems were that some documentation was omitted (project evaluation criteria) from the design document, making it much harder to update and evaluate the group Technical Knowledge Gained Some technical knowledge gained were PIC programming and troubleshooting, circuit development, part interface matching, testing practices, and increased soldering skills Non-Technical Knowledge Gained Some non-technical knowledge gained were risk management, time management, team working skills, documentation skills, and communication skills What Would Be Done Differently Some major points that would have been changed if this project was done again would be to maintain better communication between the buyer and the parts vendor. Also, maintain a more precise track record of the documentation to ensure that sections are not omitted. Keeping track of the parts list and prices as they are selected would also be beneficial. 4.5 Risk and Risk Management This section shall discuss the risks encountered and how the team managed those risks. 41

43 4.5.1 Anticipated Potential Risks Some of the anticipated risks are listed below: 1. Loss of documentation This risk was avoided by properly maintaining copies of documentation, schematics, software, and log books. 2. Loss of team member This risk was avoided by ensuring proper documentation. 3. Insufficient quantities of parts This risk was avoided by finding multiple vendors and ensuring proper lead times and ordering extra quantities. 4. Late arrival of parts and equipment This risk was avoided by allowing time into the schedule for parts arrival Anticipated Risks Encountered and Risk Management The only anticipated risk encountered has been the late arrival of parts. This risk has been solved by adding time in to the project schedule to allow for late parts. As a result, the team managed the risk and stayed on schedule Unanticipated Risks Encountered Some of the unanticipated risks are listed below: 1. Non-local group member 2. Faulty parts 3. Breaking of parts Changes Made Due to Unanticipated Risks Encountered The team faced two unanticipated risks. The first was a non-local group member. As a result of this, the team changed its method of communication with the team member. Instead of communicating through team meetings only, the team ed, and phoned the non-local member. This problem was easily solved by utilizing different ways of communication. The second risk was the breaking of parts. The soldered wires on the current sensor caused the ground lead to break off rendering the sensor useless. Currently, the team is investigating a solution to remedy this problem. 42

44 4.6 Project Team Information The following is a list of all parties involved in the project and their contact information, including the faculty advisor and the client. A. Client information: Client s name : Senior Design (Iowa State University) B. Faculty advisor information: Faculty advisor : Associate Professor Gary Tuttle Office address : i Coover Hall Ames, IA ii. 247 ASC I Ames, IA Mailing address : RR 4 BOX 176 Ames, IA Office phone number : Home phone number : Fax telephone number : address : gtuttle@iastate.edu C. Student team information: 1. Name : Josh Halbur Major : Computer Engineering Mailing address : 632 Squaw Creek Dr. # 7 Home phone number : (primary) Cell phone : address : jhalbur5@iastate.edu / enginerds@gmail.com 2. Name : Ramy Henin (Team Leader) Major : Computer Engineering Mailing address : 4701 Steinbeck # 4 Home phone number : (primary) Cell phone : address : rhenin@iastate.edu 3. Name : Deepak Mishra Major : Computer Engineering Mailing address : 1300 Gateway Hills #104 Cell phone number : address : dmishra@iastate.edu 4. Name : Dhaval Patel (Communications Coordinator) Major : Electrical Engineering Mailing address : 1121 Delaware Ave #5 43

45 Cell Phone number : address : dpatel83@iastate.edu / dhaval.s.patel@gmail.com 5. Name : Faisal Tamin Major : Electrical Engineering Mailing address : 246 North Hyland #111 Cell phone : address : faisal@iastate.edu / sweetsal@gmail.com 4.7 Closing Summary The faulty lamp detection system for vehicles is an important issue. The current systems available for detecting faulty lamps in vehicles have limited functionality. Driving with a failed lamp or flasher could cause accidents due to confusion during turning or limited visibility. The system will be able to periodically test for multiple faulty lamps and failed flashers and display an indication of failure. In addition to the detection of faulty lamps and flashers, the system will also be able to detect failed instrument panel bulbs. If the instrument panel lights have failed, the motorists will not be informed of any problems or failures that occur in their vehicles. This is a feature not found in many vehicles, and will help the motorists identify problems. When this system is completed, it will serve motorists mainly by informing them about the vehicle s lighting system, thus limiting possible hazards that may be caused. (This closing summary will be changed for the bound final report to reflect the final test results.) 44

46 4.8 Appendix A: Microcontroller program code This Appendix contains the software code portion of the design LCD Driver This section includes the driver for the LCD. #define lcd_cursor(x) lcd_write(((x)&0x7f) 0x80) #define LINE1 0x00 /* position of line1 */ #define LINE2 0x20 /* position of line2 */ #define LCD_RS PIN_E2 // Register select #define LCD_RW PIN_E1 #define LCD_EN PIN_E0 // Enable #define LCD_D4 PIN_D4 #define LCD_D5 PIN_D5 #define LCD_D6 PIN_D6 #define LCD_D7 PIN_D7 unsigned char line[4]= {0x0, 0x40, 0x10, 0x50}; unsigned char currline = 0; void LCD_STROBE(void) { output_high(lcd_en); // delay_ms(5); output_low(lcd_en); } /* write a byte to the LCD in 4 bit mode */ void lcd_write(unsigned char c) { output_bit(lcd_d7,c & 0x80); output_bit(lcd_d6,c & 0x40); output_bit(lcd_d5,c & 0x20); output_bit(lcd_d4,c & 0x10); LCD_STROBE(); output_bit(lcd_d7,c & 0x08); output_bit(lcd_d6,c & 0x04); output_bit(lcd_d5,c & 0x02); output_bit(lcd_d4,c & 0x01); LCD_STROBE(); delay_us(40); } /* Clear and home the LCD */ void lcd_clear(void) { currline = 0; output_low(lcd_rs); } lcd_write(0x1); delay_ms(2); /* Go to the specified position */ void lcd_goto(unsigned char pos) { output_low(lcd_rs); 45

47 } lcd_write(0x80 + pos); /* write one character to the LCD */ void lcd_putch(unsigned char c) { if(c == '\n') { if(currline == 3) { currline = 0; // lcd_clear(); } else currline++; lcd_goto(line[currline]); } else { output_high(lcd_rs); } } lcd_write(c); /* initialise the LCD - put into 4 bit mode */ void lcd_init(void) { /* step 1 */ delay_ms(15);// power on delay /* step 2 */ output_low(lcd_rs); output_low(lcd_rw); output_low(lcd_d7); output_low(lcd_d6); output_high(lcd_d5); output_high(lcd_d4); /* step 3 */ LCD_STROBE(); delay_ms(5); /* step 4 and 5 */ LCD_STROBE(); delay_us(100); /* step 6 */ LCD_STROBE(); delay_ms(5); // init! // init! output_low(lcd_d4); LCD_STROBE(); delay_us(40); 46

48 } lcd_write(0x28);// 4 bit mode, 1/16 duty, 5x8 font, 2lines lcd_write(0x0c);// display on lcd_write(0x06);// entry mode advance cursor lcd_write(0x01);// clear display and reset cursor Faulty Detector Code This section includes the software to test the systems under questions. **************************************************************************** IOWA STATE UNIVERSITY SENIOR DESIGN DEC05-13 VEHICLE FAULTY LAMP/FLASHER IDENTIFIER ****************************************************************************/ /**************************************************************************** NOTES: results[0] - turn signal results[1] - hazard results[2..29] - filaments PIN_A5 - decoder enable bit PIN_A0..A4 - decoder data bits decoder output: 0 - high self test 1 - ground self test 2 - turn signal flasher 3 - hazard flasher 4 - filament : 31 - filament PIN_C0 - input from current sensor PIN_C1 - input stating which flasher was activated (turn or hazard) PIN_B0 - interrupt input for either PIN_E2 - LCD_RS (register select) PIN_E1 - LCD_RW (read/write) PIN_E0 - LCD_EN (enable) PIN_D4..D7 - LCD_D4..D7 (data) ****************************************************************************/ /*USER DEFINABLE SETTINGS */ #define LIGHTS_COUNT 6 //number of lights <= 28 #define PROPAGATION_DELAY 2000 //time in ms before checking if the light works #define DEBOUNCE 0 //ms #define MIN_FLASHER_RATE 1 //goes high per second #define MAX_FLASHER_RATE 4 //goes high per second /* */ 47

49 #include "16F877A.h" #device *=16 #include<stdlib.h> #FUSES XT, NOPROTECT, NOWDT, NOLVP, NOBROWNOUT #use Delay(clock = ) #define CURRENT_SENSOR_IN PIN_C0 #define TURNSIG_ON PIN_C1 #define HAZARD_ON PIN_C2 //decoder outputs #define HIGH_TEST 0 #define GROUND_TEST 1 #define TURN_SIGNAL_TEST 2 #define HAZARD_TEST 3 #define LIGHTS_START 4 array #define TESTS_COUNT 2 + LIGHTS_COUNT //starting position for light tests in results #define tstart 122 #include "lcddriver.c" #include "codes.c" byte timer, dtimer; byte seconds, stoptime; short changed, old; byte flashcount; float flasherresult; byte currtestnum; short testsdone; byte i; byte results[tests_count]; //function signatures void init(); byte selftest(); void runtest(); void displayresults(); void flashertest(); void decoderoutput(byte testnum); void decoderoff(); #inline void db(); #inline void pd(); #INT_RTCC //seconds counter for flasher test 48

50 void clock_isr() { if(--timer == 0) { ++seconds; timer=tstart; } } #INT_TIMER1 //timer for display scrolling void timer1_isr() { if(dtimer++ >= 6) { dtimer = 0; if(testsdone) { lcd_clear(); displayresults(); } } else dtimer++; } void main() { init(); if(!selftest()) { printf(lcd_putch, "Sensor failure!\n"); decoderoff(); return; } timer = tstart; set_rtcc(0); setup_counters(rtcc_internal, RTCC_DIV_32); dtimer = 0; setup_timer_1(t1_internal T1_DIV_BY_8); set_timer1(0); enable_interrupts(int_timer1); enable_interrupts(int_timer2); enable_interrupts(int_rtcc); enable_interrupts(global); while(1) { //main loop if(input(turnsig_on) INPUT(HAZARD_ON)) flashertest(); else { 49

51 } } } if(!testsdone) runtest(); void init() { delay_ms(2000); set_tris_a(63); lcd_init(); lcd_clear(); decoderoff(); printf(lcd_putch, " Vehicle Faulty\n Lamp/Flasher\n Identifier"); delay_ms(2000); lcd_clear(); printf(lcd_putch, " IOWA STATE\n UNIVERSITY\n Senior Design\n Dec05-13"); delay_ms(2000); lcd_clear(); seconds = 0; flashcount = 0; flasherresult = 0; currtestnum = 0; testsdone = 0; } for(i = 0; i < TESTS_COUNT; i++) results[i] = 1; //initially set all to pass byte selftest() { //test high decoderoutput(high_test); //0x20 for the enable pd(); if(!input(current_sensor_in)) //should be high to pass return 0; //failed //test ground decoderoutput(ground_test); pd(); if(input(current_sensor_in)) return 0; decoderoff(); //0x20 for the enable //should be low to pass //failed } return 1; //passed void runtest() { /*for debugging purposes*/ lcd_clear(); if(currtestnum < 16) printf(lcd_putch, "Light test:\n%s",codes0[currtestnum + 2]); 50

52 else printf(lcd_putch, "Light test:\n%s",codes1[currtestnum ]); /* */ decoderoutput(currtestnum + 4); pd(); INPUT(CURRENT_SENSOR_IN)? (results[currtestnum + 2] = 1) : (results[currtestnum + 2] = 0); decoderoff(); } if(currtestnum == LIGHTS_COUNT - 1) { currtestnum = 0; testsdone = 1; } else currtestnum++; void flashertest() { short flasherid; if(input(hazard_on)) flasherid = 1; else if(input(turnsig_on)) flasherid = 0; decoderoutput(flasherid + 2); /*for debugging purposes*/ lcd_clear(); printf(lcd_putch, "Flasher Test:\n"); printf(lcd_putch, "%s", codes0[flasherid]); /* */ flashcount = 0; seconds = 0; while(input(turnsig_on) INPUT(HAZARD_ON)) { changed = old ^ INPUT(CURRENT_SENSOR_IN); old = INPUT(CURRENT_SENSOR_IN); if(input(current_sensor_in) && changed) { flashcount++; } db(); } stoptime = seconds; decoderoff(); flasherresult = ((float)flashcount) / ((float)stoptime); if(flasherresult >= MIN_FLASHER_RATE && flasherresult <= MAX_FLASHER_RATE) results[flasherid] = 1; else 51

53 } results[flasherid] = 0; void displayresults() { static int nextstart = 0; static int fnum = 1; int line = 0; for(i = nextstart; i < TESTS_COUNT && line < 3; i++) if(results[i] == 0) { if(line == 0) printf(lcd_putch, "failures:"); if(line == 1) nextstart = i; } if(i < 16) else line++; fnum++; printf(lcd_putch, "\n%d: %s", fnum, codes0[i]); printf(lcd_putch, "\n%d: %s", fnum, codes1[i - 16]); } line = 0; fnum -= 2; if(i == TESTS_COUNT) { if(line > 0) delay_ms(5000); fnum = 1; nextstart = 0; testsdone = 0; } void decoderoutput(byte testnum) { OUTPUT_A(0x20 testnum); //0x20 for the enable } void decoderoff() { OUTPUT_A(0); } #inline void db() { delay_ms(debounce); } #inline void pd() { delay_ms(propagation_delay); 52

54 } Cross reference for the lamps This section contains the outputs that will be displayed on the LCD for failures due to certain lamps. //Each string may be up to 12 characters in length const char codes0[16][12] = { //flashers: {"F0"}, {"F1"}, //lights: {"L0"}, {"L1"}, {"L2"}, {"L3"}, {"L4"}, {"L5"}, {"L6"}, {"L7"}, {"L8"}, {"L9"}, {"L10"}, {"L11"}, {"L12"}, {"L13"} }; const char codes1[14][12] = { //lights: {"L14"}, {"L15"}, {"L16"}, {"L17"}, {"L18"}, {"L19"}, {"L20"}, {"L21"}, {"L22"}, {"L23"}, {"L24"}, {"L25"}, {"L26"}, {"L27"} }; 53

55 4.9 Appendix B: Supplemental Information on Select Hardware Figure 11: Block Diagram of the LCD ( 54

56 Table 10: Tolerances for the LCD and controller ( Table 11: Electrical characteristics for the LCD and controller ( 55

57 Figure 12: Block diagram for the ACS750LCA-057 ( 56

58 Table 12: ACS750LCA-057 specifications ( 57