1 Spring 2013/V0.1 Senior Design: A Hands-on Experience with The Engineering Process This is an iterative process Problem Design Constraints Test Specification Design Simulation Test Verification Prototyping Test Verification Hardware Implementation, Design Refinement, packaging Test Verification Design II Design I

2 Spring 2013/V0.1 Problem: recognize that a problem exists, and develop a concise statement of the problem. Objectives: study the parameters of the problem, and convert them into engineering language you are familiar with. Literature Survey: assimilate existing knowledge about the problem, and search for similar data (related experiments, evaluations, etc.) The Engineering Process a design methodology...

3 Spring 2013/V0.1 Analysis: analyze the problem based on the knowledge gained from the literature survey, produce a set of design constraints, and generate test specifications to verify these design constraints. Synthesis: manipulate the analysis to yield a family of solutions (typically through simulation and prototyping). Evaluation: choose the best solution and verify it meets the design constraints. Presentation: communicate the solution to your peers/management. The Engineering Process a design methodology continued...

4 Spring 2013/V0.1 Design I Structure Lectures: Meets once a week –Thursdays for Design I lectures, some weeks Tuesdays for Entrepeneurship lectures –Lectures on team building, planning, software design, design document Assignments: –Writing assignments for design document in conjunction with GE 3513 tech writing –Website (see syllabus) Presentations: mid-term, end-of-semester Must demonstrate working prototype of project at end of semester!!

5 Spring 2013/V0.1 Design I Structure (cont.) Grading: Design Document, presentations, weekly deliverables, peer reviews, web site, advisor input, etc (see syllabus) –Team members do not necessarily all get the same grade! –Custom grading forms for each team/presentation Funding: Donations and other funding –Ryan Green will handle this, $200 per team Lab Space: Room 311, shared by Senior Design I & II Conference Room: Simrall 206

6 Spring 2013/V0.1 Success in Design 1 is Up to You! Progress on technical goals is entirely up to the team –Faculty advisor is not a task master – only “advises” –The team sets the weekly goals, measures weekly progress Many projects require you to explore new technologies on your own initiative –Welcome to life-long learning! –Take advantage of all possible resources

7 Spring 2013/V0.1 Design I Pitfalls Design I is the critical semester –Design II difficulty depends on Design I success Pitfalls –Poorly specified goals, constraints for project Much time spent in semester beginning on this!!! –Poor implementation choices for key technical aspects Spend time on tradeoff analysis, survey of alternatives! –Lack of weekly progress Schedule a weekly meeting with your faculty advisor NOW. Make REAL progress – connect wires, write code! –Malfunctioning teams (more on this later)

8 Spring 2013/V0.1 Design I Complaints Believe it or not, we do listen to you! –Increased from 1 hour to 4 hours spread over two semesters –Integrated Design I writing with Tech Writing –Added lab/meeting space reserved for Senior Design Common complaints –“Too much work for too little credit” Design takes time – get used to it Work smarter to reduce effort by using faculty, expert resources –“Why do we have to do assignment X? Just let us do our design!” Planning, documentation, oral communication – all are a real part of design!!!

9 Spring 2013/V0.1 Planning Your Project Phase 1 – System definition –Specifications and Features –Physical Interface –Subsystem definition and investigation of alternatives for each subsystem Phase 2 – Design/test of individual subsystems –Requires prototyping of different subsystems, perhaps even prototyping of different alternatives. Do not be surprised when something that you assumed turns out not to be true, requiring you to backtrack! –agreement between team members on how subsystems will interact Phase 3 – Subsystem integration –Connecting subsystems together and getting them to work correctly takes time!

10 Spring 2013/V0.1 Writing Assignments vs. Project Development The writing assignments LAG the project development –Your project development should be well ahead of the writing assignments, as the due dates for the writing assignments are spread out without regard to project development. Having the project development ahead of the writing assignments make the writing assignments easier, since you have something to write about! –Writing up the different alternatives for a subsystem will be easy since you have already had actual experience with the subsystems.

11 Spring 2013/V0.1 Pitfalls in Project Development Do not assume that a circuit you find via Google will work the way that it is documented. –Until you build it yourself, you know nothing. –Understand the circuit! Simulate in Pspice if that is an option! –If it is an analog circuit, when you integrate it with other components (like a microprocessor), it may quit operating. Read the datasheet!!!!!! –If the datasheet specs are unsuitable, then don’t waste your time. Consider packaging – if the part is only available a surface mount package, it will be harder to prototype with. If a design has a lot of components, consider using a PCB from the start since breadboard wiring will drive you crazy. Order spare parts so that if something breaks, you will have a backup.

12 Spring 2013/V0.1 Pitfalls in Project Development (cont) Be careful how you divide the labor –The best way is to divide it by subsystem, with lots of communications between the team members on how the subsystems interact In a hardware subsystem that has a microcontroller, you cannot divide the software development and the external hardware development between multiple people –Software is needed to drive the hardware, and the software creator needs an intimate understanding of the hardware. –You can divide it by functionality which combines hardware+software (Joe will handle the LCD code and LCD interfacing, Sally will handle the DAC code and DAC interfacing). Everybody must contribute technically. You cannot have somebody whose only job is the web page or documentation!

13 Spring 2013/V0.1 Assign. #1: Product Specification One page Contains Applications, Features, Specifications –Applications: how can this be used? –Features: what can it do? –Specifications: quantitative measures of what it can and cannot do, requirements for use Visually appealing, tells all in one page –Contains one or more graphics of product itself and usage of product in typical scenarios Post this on your web site (use.pdf files)

14 Spring 2013/V0.1 Example Specifications Signal tolerances (> 30% duty cycle clock at 1MHz +/-1%) Supply current range (.5 mA min to 100 mA max) Power efficiency (83% supply efficiency at rated load) Speed, Response time (interrupt service latency < 10  S) Conversion rate (12-bit conversion at 500Ksamples/sec) Transmission distance (100 M with unobstructed view) Quantization error (+,- 5mV) Frequency response (20 Hz to 20 KHz, +/- 3 dB) Signal-to-noise ratio (50 dB min) Power requirements (7 to 12 V DC) Environmental (functions in range of -25 C to +125 C) Limitations (requires Windows XP or later) Battery life (battery lasts for 20 hours of constant use)