MQP Projects Manual

This page contains an on-line version of the ECE Department's MQP Manual. This manual is intended to help students get their MQP off to a good start. Inside, you'll find information about creating a project proposal, locating MQP Project Centers, finding laboratory facilities and much more.

If you have any questions about starting an MQP, chances are, they will be answered here!

Contents

1.0 Introduction

The Undergraduate Projects Committee of Electrical and Computer Engineering department has compiled this manual to help you find and complete an MQP that will satisfy your educational objectives. This document provides a single source that contains information about many of the project opportunities that are available to you. However, since your MQP may be a highly specialized, personally created endeavor, it is impossible to cover all of the topics that you may require. If, after reading this manual, you still find some of your questions are unanswered, please consult with your academic advisor or one of the members of the Undergraduate Projects Committee (see section 8.3).

2.0 Project Planning Calendar

Since your choice of an MQP topic may influence your course selection and schedule for your senior year, you should plan to find an MQP as soon as possible in your junior year. If you delay, you will find that many of the projects listed in this manual already have project groups assigned. Once this happens, most advisors will have a full MQP load scheduled and will be reluctant to consider additional projects!

Detailed information concerning the registration procedure for an MQP is available in the "WPI Projects Program" booklet distributed by the Projects Office. Dates of interest for this academic year are as follows.

This program will feature information on WPI Project Centers and special Project Programs, both for MQPs and IQPs. It will be held in Perrault Hall.

There are no classes held today. Meet with your academic advisor to schedule senior year courses and slots for your MQP.

All students planning to complete an ECE MQP next year should attend this event (scheduled for 5:00-6:00 PM in AK 116). This meeting will provide students with general information and advice about choosing and conducting an MQP in the ECE department. Discussion will focus on describing the resources available to MQP students in the department.

By this time you should have selected an MQP and have formed a project team. Now you should formally register for the MQP. Remember, if you are just starting to think about an MQP now, you are going to have a hard time finding an advisor who still has projects available!

On Project Presentation Day there are no classes. Students who are completing their MQPs will be presenting the results of their work throughout the day. All students and faculty are invited to attend these presentations. Juniors are strongly encouraged to attend!

3.0 What is an MQP?

The Undergraduate Catalog states the following:

The Major Qualifying Project should demonstrate application of the skills, methods and knowledge of the discipline to the solution of a problem which would be representative of the type to be encountered in one's career. The project's content area should be carefully selected to complement your total educational program.

MQP activities range through research, development, and application, can involve analysis or synthesis, can be experimental or theoretical, and can emphasize a particular subarea of the major or combined aspects of several subareas. Serious thought should be given to which of these types of activities are to be included.

In addition, most MQPs will provide you with a capstone design experience. What this means is that the MQP is a project that culminates your WPI education with the application of ideas from your coursework to designing a product, instrument, device, or program which integrates theory and practice. Although most MQPs satisfy this WPI requirement, it is possible that your MQP will not. You should discuss the design content with your potential MQP advisor to determine if it provides a capstone design experience. If it does, make sure your project advisor checks the capstone design box when your get your registration form signed. If the MQP you are interested in does not qualify as capstone design, then your MQP advisor will tell you how you can satisfy this requirement, possibly by doing additional independent study work with that advisor.

Since you can do nearly anything that requires engineering skill as an MQP, it is difficult to create a definition that will apply to all MQPs. Indeed, every MQP progresses somewhat differently depending on the individual student's needs, the advisor's interest, the student's motivation, team dynamics, and many other factors. While this looseness might be disquieting for some, it can be the MQP's biggest asset since it allows you to participate in a real engineering project that you have a hand in defining, thus allowing you to fully experience the thrill of solving a challenging problem and the agony of chasing false leads.

3.1 Project Definition

During the project definition phase, you will begin to determine exactly what you will do for your MQP. The idea for the project might be something that you thought up on your own, or it might be one of the project ideas that have been presented by the faculty. In either case, you'll have some homework to do in order to turn an idea into a project.

The process of defining the project usually involves writing a project proposal. At this stage, this proposal might be a short (3-5 page) paper where you establish the basic definition of the project along with the project goals, projected schedules and budgets, and the methodology you will use to satisfy the project objectives. During the first term of your MQP, you'll probably spend a lot of time refining this proposal, but it's best to get started now so that you're ready when the time comes.

Writing a proposal, even at this stage, probably won't be a trivial task. To define the project you'll have to do some research to understand more about the topic area that the project involves. Even if you're a wizard at some of the skills you need, chances are that the project will involve skills that are not so well developed. Doing this initial research might require you to dig out some old course notes or go to the library to find books on the subject. After spending some time reading about the subject you should begin to get a good idea about what the project may involve.

Once you have an idea about what's involved, you can determine what skills you're strong in and which skills you need. At this point you can start selecting a team to work with you on the project. Just like a manager in industry, you should put together a team that 1) is really motivated and excited about the project and wants to do a great job and 2) collectively thinks they have, or can teach themselves, all of the skills they need to be successful.

Now, you and your team can get together to identify the project goals. These goals might require additional research into one or more areas; designing, building and testing hardware; simulating designs; writing software; or developing mathematical proofs. The more you learn, the more you'll discover you need to learn, but, you have to start somewhere. Start by creating a prioritized list of tasks that must be accomplished. Next, the team can decide who will be responsible for each task in the MQP. You can now make a project schedule which shows the order in which tasks must be done (you can't build hardware until it's designed!) and who will do each one. Along with the schedule you should develop milestones, or intermediate objectives, that will give you a sense of accomplishment and progress. For example, if your project requires designing a digital filter, you might decide on a milestone which says that at the end of A-term you will show your advisor a working program that simulates a digital filter. Nothing is more satisfying than reaching an important milestone on time (or, better yet, early!).

The methodology you use to accomplish your project is essentially a description of how you intend to proceed from milestone to milestone. Typically, your methodology will involve: researching a topic; defining requirements; getting an idea about how to satisfy those requirements; validating the idea; designing, building, and testing the idea; and verifying the result. Again, you'll spend a lot of time refining your methodology as you learn more about the project, but it's never too early to start thinking about the issues.

Now that you've done your homework, you can take all the notes you've gathered and start writing your proposal. Typically, this proposal will be organized as follows:

1. Introduction

A good concise description of what the project is. This section should orient the reader by explaining what the project definition and goals are, why it is a good or important thing to do, and what your general approach will be.

2. Literature Review

A summary of what the current state-of-the-art is based on your reading about the topic. In this section, you must prove to your reader that you know what you're talking about, and therefore, are the best one for the job.

3. Methodology

In this section, you must describe As completely as possible how you intend to accomplish the goals you presented in the introduction. Your job here is to convince the reader that you not only know what you're talking about, you have a plan to get there!

4. Schedule and Budget

This is where you present a detailed description showing the projected completion date and cost associated with each project step. Often schedules are presented in the form of a Pert or Gantt chart. These charts clearly show the relationship between tasks and the effect of missing a milestone on the project deadline. In industry, engineers and managers are rated on how well they do in terms of meeting milestones on-time and on-budget. Your schedule should show the reader that you understand the relative sequencing of events and, to some extent, you understand their complexity.

5. A project specification

By the end of your proposal you should be able to come up with a fairly detailed list of the features and functions that you expect your completed project to perform. Appendix B contains an example of such a list for a digital music device. Given such a specification, you will be able to quickly focus your MQP efforts on those aspects of the project that are important to achieving your goals. You'll also have a perfect basis for evaluating both your progress and the quality of your work.

3.2 Research

The research phase of a typical MQP begins in the first term. This is when you will start refining the initial proposal that you wrote to get the project going. Based on your initial proposal, your advisor will probably have comments and suggestions for sources of specific information that you will need. Your advisor will probably also identify areas that you missed originally that you now need to explore. In addition, you may have obtained more information about the project since you wrote the initial proposal.

During this phase, you will start following-up on all of these directions. You should keep a notebook and write down all of the questions that need answers and possible sources of information. You should also write down the answers to questions as you find them and also the sources, including page numbers, where you found the answers (just in case you need to go back).

Your biggest source of information for this phase will probably be your course notes, texts, and the library. There are PCs in the library that you can use to search for books and journal articles. In addition, the library has an electronic card-catalog where you can search for material from any workstation on campus.

Once you've completed the research phase, you will be fairly knowledgeable about the problem you are working on. You will know what others before you have done, how well their approach worked, and how you can do better. You will fully understand the nuances of the problem and will know the tools and techniques that are needed to solve the problem better, faster, or less expensively than anyone else. If you've kept careful notes along the way, you will also have a significant store of information that will prove useful when you write your MQP report.

Now its time to put your ideas to work!

3.3 Design

The design phase of a project can take many forms, depending on the nature of your particular MQP. For example, in a theoretically-oriented MQP, the design phase might consist of completing the proof of a new technique for calculating the effects associated with some physical phenomenon. In order to test this technique, you might have to develop a program that performs the necessary calculations on a variety of examples for which theoretical or experimental results already exist. For hardware-oriented projects, the design phase normally involves taking the detailed specifications derived through your research and designing and building a circuit that you expect will satisfy them.

Although each MQP will have different kinds of design components, the design phase is really that time when the theoretical knowledge you have accumulated about the project, along with the skills you've learned in the classroom, are applied to solve a real problem. In engineering terms, design is the point in time when you take a theory and reduce it to practice. This means creating theoretically justifiable designs, not making guesses and creating a working design through trial and error during system debugging!

Of course, no design effort is complete until the results are proven!

3.4 Evaluation

Proving that your design is correct can be difficult, but it is essential. For example, if you are designing a new controller for a heart rate controller in a pacemaker it's no good to tell the patient that it "should" work. You've got to demonstrate that it does work (and will continue working)!

Part of this proof is done in the design phase where you calculate the current flows, power dissipations, logic timings, and other design parameters. The rest of this proof is done when you take your constructed device into the laboratory and test it.

Again, the nature of the testing depends on the specific type of project. If you're building a board that will be launched on the Space Shuttle, you'll be putting your design in ovens and refrigerators (to test thermal cycling) and putting it on shaker tables (to verify mechanical stability). If you're testing theoretical results, you may be running experiments and taking measurements to correlate theory with observation.

In either case, the purpose of the evaluation stage is to ensure that your design meets the specifications you derived. Usually, you will have certain expectations for your results that are a result of the research you did. Now is the time to verify these expectations. Often, you'll find one or more deviations from the specifications. When this happens, you'll have to determine if the original specification is somehow in error, of if there was an error that occurred during the design phase. Indeed, by the time you successfully complete the evaluation phase it's quite likely that you will have done additional research, updated your design, and re-evaluated your results one or more times.

But, once you're done, you really have something to shout about!

3.5 Reporting Results

In an engineering environment, shouting about your results usually takes the form of reporting your findings to your colleagues, customers, and possibly the engineering community through presentations and through written reports. Although few beginning engineers realize it, the best way to communicate to your boss how well you are doing is to make good presentations and to write excellent reports. To teach you about this process all MQPs conclude with a substantial written report and an oral presentation.

The MQP report documents the entire project. In this report, you will present the project, the research you did, the details of your design, and the results of your evaluation. It would be difficult to overstate the importance of a quality report and, even though it is the last thing you will turn in related to the project, you should start writing it when the project begins.

Appendix C contains information describing the style of the report in detail. For now, the general form of the report is as follows:

1. Introduction

The introduction should explain the project to the reader, should describe any relevant research that has been done by others, and should detail what you did that is novel. By the end of the introduction, the reader should know what you did, why you did it, how you did it better, and should be introduced to the vocabulary necessary to understand the rest of the report. It is important that the introduction flow logically, starting with a general overview and ending with a description of the flow of the report. Details of your design should generally be left out of the introduction. Rather, you should concentrate on communicating the basic concepts.

2. Report Body

The body of the report is where you start getting into the details. Be conscious of keeping a logical organization. Most MQPs evolve along a winding path, encountering several wrong paths on the way towards finding the correct one. Don't follow the same path in the report! Once the project is complete, you'll know what sequence of steps you should have followed. The body should flow according to the same path you wish you had followed. Including "wrong" directions can be useful so that others reading the report don't make the same mistakes, but make sure "wrong-way's" are in proper context. All too often, reports have ten pages describing the wrong design and then one sentence at the end that says "so we threw out that design and used a new one"!

In addition to the details of the design process, the body of the report usually includes information about the economics of the project, an analysis of the project results, and other information. See the MQP written report guidelines for additional information.

3. Conclusions

A typical report concludes with an assessment of the project as a whole. Were all project objectives accomplished? If not, why not? Are there ways to do even better? If the project is part of a multi-year MQP it may be important to describe areas in the design where performance was marginal or inconsistent. Often, this section will also include suggestions for future work.

The MQP Oral Presentation is similar to the written report, but is presented in a more abbreviated format. Details on the oral presentation are contained in Appendix D. In brief, the oral presentation will briefly introduce the project, describe the major innovations that made the project succeed, present an evaluation or demonstration of the project, and then will conclude by assessing the project status and prospects.

4.0 Finding the Right Project

To prepare for finding a project, and to be able to properly assess the suitability of a project to your educational objectives, ask yourself the following questions.

  1. Out of all the EE, basic science and mathematics courses you have taken, which did you enjoy the most? Which did you not enjoy? When answering these questions, try to identify project areas in which you would be willing to invest three or four terms of intensive work. Try not to limit yourself to one single subdiscipline.
  2. What do you want to do after you graduate? Try to be specific! An honest answer to this question will lead you to an understanding of the skills you need to perform the job you envision. If you cannot specify what you want to do, try starting by figuring out what you are not interested in doing.
  3. What do you want to learn while you work on your MQP? If you tell your MQP advisor what you want to get out of your MQP, it is often possible to structure the project to emphasize those areas of interest.
  4. What type of project partners do you want? Working with your best friend might be either the best or worst decision you could make. Your partners' talents should complement some of your own, particularly if the project requires diverse abilities.

4.1 What To Do if You Have A Project Idea

Section 9 and Section 10 of this manual identify the specific research interests of the faculty as well as specific MQP topics that each has identified and is ready to advise. You should read these sections carefully to determine whether or not there are projects on the list that are of particular interest to you. Another source of ideas are the booklets entitled "Innovations" that, until recently, were published annually by the Project Center. Past issues are available at the Project Center and provide a compilation of the abstracts of completed MQPs. A quick review of one or more of the issues will provide many ideas of the range and composition of the projects you might undertake.

If there are projects in Section 10 that interest you, make appointments to discuss them with the faculty who have suggested them. Do this as early as you can since some of the most interesting projects are often those that appeal to the largest number of students. Do not wait until you have found a team of project partners - often, the faculty member who has proposed the project can help form teams from among those who have shown interest. And, while it is important to get an early start, there is often no need for concern that a project will be taken by the first group that applies. Typically, faculty interests in a specific project area are sufficiently broad that more than a single project can be undertaken related to a specific MQP topic.

But, what if there is nothing among the list of projects in Section 10 that interests you. Beyond that, what if you have a project idea of your own. The answer is to develop the project yourself or with a group of like-minded partners. In fact, many project advisors encourage students to take this approach since the project undertaken is more likely to satisfy your personal educational and professional goals.

If you plan to take this option, it is extremely important that you do some groundwork in advance of seeking a project advisor.

  1. Develop a clear idea of the educational goals and objectives of the project. What makes you believe that your idea would be a good project? What would you learn? Would other students be interested in your project? Why?
  2. Talk the project over with your academic advisor. Your advisor can help you better define the project and gain a clearer understanding of its feasibility. Your advisor may also recommend professors who might be interested in advising such a project. Once you know the subject areas your project involves you can also identify prospective advisors using the information in section 8 of this manual.
  3. Find one or two partners who have the same timetable as yours, are interested in the project idea, and perhaps complement your background and skills. Professors will seldom agree to single-student projects, and there are benefits to working with other students. You might advertise on the ECE MQP Bulletin Board (located opposite the mailboxes), the ECE MQP newsgroup (wpi.ee.mqp), or in Newspeak for a partner.
  4. Prepare a concise description of the project. This need not be lengthy; a one or two page description is adequate. The sample one-page description shown in figure 3 illustrates the depth that is required. Remember, if you cannot describe your project objective in a simple, concise manner, you probably really do not understand what you would like to accomplish.
  5. Do not confuse this first step with the Project Proposal that your advisor will expect you to prepare as a first order of business once your project work begins. That proposal will be, in reality, the contract you sign with your advisor. It will not only describe the objectives of the project, but will present as well the results of your search for related work accomplished by others, describe in detail the approach that will be taken, identify the resources required, present a carefully prepared project budget, and include as task schedule against which you and your advisor can measure your team's progress. [A separate manual "Preparing the MQP Proposal" describes this document in more detail.]
  6. With your project description completed, examine the list of faculty project areas (located in Section 9) to identify those with a potential interest in your topic. Send or deliver copies to those you believe might be interested in advising your project and make appointments for subsequent more detailed discussion. If you encounter any difficulties with this process or are in doubt as to which faculty to approach, any member of the Department's Undergraduate Project Committee can be approached for assistance; see section 8.3 .

4.2 Practical Expectations

Remember, you and your advisor can tailor most project ideas to address your ideas and needs. Remember too that advisors will be anxious to scale-back ideas that are too ambitious. It is far better to scale-back the goals of the project so that the probability of successfully achieving those objectives is high than to fail to achieve a set of unreasonably ambitious ones.

It is also important to stress that the relationship that will exist between you and your advisor will be distinctly different from the student/faculty relationship you have experienced thus far. This is because one of the important objectives of the MQP is to begin your transition from undergraduate academic life to that which you will encounter in graduate school or in the commercial world. As such, most advisors will play the role of a supervisor with whom you have made a contract. You have promised to achieve a series of goals with a defined set of resources and in accordance with an established schedule and your supervisor will be meeting with you regularly to observe and discuss your progress.

Do not expect that your advisor will direct you. If you run into problems which you are having difficulty to overcome, your advisor may direct you to consult with some other member of the faculty or to review some source material - BUT - your advisor will not do your work for you. Most advisors will let you make mistakes and deal with their consequences. If you get behind schedule, your advisor will be anxious to hear you describe your plans for getting back on schedule.

In brief, your MQP will be a taste of engineering life as you will encounter it after you have obtained you Bachelor's degree.

Worcester Polytechnic Institute
Major Qualifying Project - Capstone Design 
Electrical & Computer Engineering
 
Project Title:  Automated Antenna Control
 
Project Description: 
 
 The objectives of this project will be to design and
construct an automated antenna positioning system.  In 
operation, the system will automatically locate and store
the direction of the strongest signal at a selected
receiver frequency and will orient the antenna in that 
direction. The search and positioning sequence will also be
initiated either whenever the signal level drops below a 
pre-established threshold or the receiver frequency is 
changed. 
 
Details: 
 
 The RF signal from the antenna will be processed to 
produce an output proportional to the signal-level of the
received signal.  This signal will then be compared to some
threshold level and digitized.  A system controller will 
monitor the signal level as the antenna is rotated through 
a full revolution.  Once the position at which the 
strongest signal exists is determined, the antenna will be 
repositioned for optimum reception.  The antenna, which is 
expected to be located at least one-hundred feet from the
receiver/controller system, will be rotated by a motorized,
stepper-drive assembly.
 
Student Team:
 
John H. Jones, EE Box 125
Mary L. Harris, EE Box 201 
Casey E. Lenger, EE Box 247

           Figure 3: Example Project Description

4.3 Co-op Students

If you are now a co-op student, or plan to become one, it is very important for you to make arrangements for a project now. Trying to find a project a few weeks before you return from a co-op assignment is extremely difficult at best. At worst, you may find that you will miss your planned graduation date. It is also important that you plan your schedule with the help of your academic advisor. Once you are on co-op, keep in touch with your future MQP advisor and partners.

5.0 Off-Campus Projects and Project Centers

There is no rule that requires performing your MQP entirely on campus (although it must have a faculty advisor). It is possible to perform an off-campus project. These off-campus projects offer several advantages:

  1. Access to laboratory equipment not available at WPI,
  2. A corporate, engineer liaison advisor,
  3. The possibility of continuing on full time after graduating (although not a policy, it happens often enough to be of interest),
  4. Working on a "real world" problem, in a corporate environment.

The disadvantages of off-campus projects include:

  1. You may have to travel to do project work,
  2. The corporate engineer advisor may not always be available for advising.

Working on an off-campus, corporate sponsored project can be a valuable educational experience that is well worth the trade-offs involved. First, contact the faculty advisor associated with the off-campus project. If the project still looks interesting, contact the corporate sponsor/advisor for the project. A listing of off-campus projects is available in the Projects Office.

6.0 On-Campus Project Centers and Programs

7.0 ECE Department Laboratories

To support student projects and faculty research, the ECE department maintains several different laboratories. The General Laboratories are setup specifically to satisfy the laboratory needs for the majority of MQPs. You may use these laboratories for your project work as long as you follow the laboratory policies provided in Section 7.3.

The specialized laboratories are typically associated with the research activities of one or more faculty. You or your advisor may arrange to use one of these laboratories if it contains equipment necessary to complete your MQP. In addition to the General Laboratory policies, these laboratories may have additional rules established by the supervisor.

7.1 ECE Department Laboratories

1) MQP Projects Laboratory - AK111/113

Supervisor: Mr. James O'Rourke

This laboratory is located in the same area as the EE Shop providing convenient access to components, equipment, and support personnel. This laboratory contains most of the equipment necessary to support the design, development, testing, and building of nearly all MQPs. The laboratory normally contains microprocessor development systems, general purpose computers, computer data acquisition capabilities, logic analyzers, oscilloscopes, and other general purpose test equipment. More specialized equipment can be brought into this laboratory by special request.

2) PC Computer Laboratory - AK120

Supervisor: Mr. David Holl

This laboratory is primarily intended for software development, schematic capture, and documentation. The laboratory contains more than 30 networked PCs that support Viewlogic's Workview Plus design software (for digital design and simulation) along with other PCs with pspice, Microsoft C, word processing software, printed circuit design software, and other tools.

3) MQP Laboratory - AK113

4) Microprocessor/Digital Laboratory - AK227

Supervisor: Mr. David Holl

The workstation laboratory provides access to several networked DecStations. This laboratory can be used to access tools such as Maple, Mathematica, Viewlogic's PowerView, and other software tools requiring a workstation environment.

7.2 General Laboratory Hours

The General Laboratories are open, but not necessarily monitored from 8:30am until 4:45pm, Monday through Friday. Since the lock in these doors cannot be left in an "unlocked" position, a door stop must be used to keep the door open. If you find that the door has accidentally closed during published open hours, please ask someone in the ECE office or ECE shop to open the door for you.

Although the specific hours for the General Laboratories may change due to the availability of staff or TAs, every attempt is made to keep the laboratories accessible according to the following schedule (for any given term, the hours are posted on the door to the laboratory):

General Laboratory Hours

    Day       Mon    Tue     Wed   Thu       Fri      Sat        Sun

    Time     ...7:00 am - 10:00pm ...       7am-6pm  1pm-5pm  1pm-12:00am
The building is closed after 10pm. Any students who do not have outside door keys will be asked to leave the building after this time. If no laboratory monitor is available after normal business hours or on a weekend, the laboratory will be closed. At some times, the laboratory may be monitored by a watchperson. For any problems related to scheduled times, contact Mr. James O'Rourke.

7.3 General ECE Laboratory Policy

In order to provide a safe, functional laboratory environment the ECE Department has established the following laboratory policy which must be followed by all students using a laboratory:

  1. Students must sign in at the laboratory monitor's desk before using the facilities, and sign out when they are done.
  2. Students must clean up their area after using the laboratory. This includes putting chairs and stools under benches and returning equipment to its proper place.
  3. PCs and printers may not be moved or disconnected.
  4. Project equipment may not remain set up overnight or between unmonitored periods without prior permission.
  5. Equipment may not leave the laboratory without permission of Mr. O'Rourke or the professor in charge. NOTE: Project Advisors do not have the authority to loan out equipment.
  6. Equipment may not be borrowed for more than three consecutive days at a time during the regular term and cannot leave the building. The amount of laboratory equipment is limited and must be shared by many students. Variations from this policy are possible between terms and should be discussed with Mr. O'Rourke.
  7. MQP students may use the General Laboratories during scheduled course hours as space and equipment permit.
  8. Any equipment that is found to be malfunctioning should be reported to the ECE Shop (x5554) by whomever discovers it.

Use during unmonitored times:

  1. Project Advisors are responsible personally for their students during unmonitored periods. All of the above rules must be adhered to, including ensuring that students sign in and out in the Laboratory Register.
  2. Only Project Advisors may allow undergraduates to use the laboratories during unmonitored periods. TAs and other graduate students may not let undergraduate students into the laboratory.
  3. Advisors should insure that all equipment is put away and that all doors are locked.
  4. Advisors must be in the building while their students are using any laboratory. Furthermore, there must be at least two students in the laboratory at all times. This is to insure that in case of an accident, there is someone to get help. If this requirement cannot be met, the advisor must remain in the laboratory while the student is there.
  5. Students must not borrow equipment during unmonitored hours.

8.0 Project Operation and Support Services

8.1 Project Expenses

  1. A project group must register with the ECE shop (AK 111) if they want to request components from the shop. To register, fill out the registration form available at the shop window. All members of a project group must provide the information requested on the form. The project advisor must fill in the project account to be charged.
  2. Students should plan on submitting a budget to their advisor(s). The budget should include anticipated component costs (available from the ECE shop). All requests for components from the ECE shop should be transacted using the project identification code assigned to you at the time that a project is registered with the ECE shop. All charges for components will be made against the project account. Students will be required to show an ID card when charging components against their assigned project account.
  3. Each project is allowed to spend up to $125 per registered student for hardware and software expense. Incidental copying, travel, books and related material are the student's responsibility, the only possible exception being funded off campus projects, which are handled through the Projects Center. As a general rule, only project costs that are approved by the project advisor and cleared through the ECE shop is reimbursable. Project costs will be closely monitored by the shop (on a computer) and by your advisor. You may obtain the current status of your account by asking at the ECE shop window.
  4. The shop is the primary source of components, having a selection adequate for most projects. These components are signed out on a project requisition form which is obtained at the ECE shop window. If special components are necessary, they should be identified early on in the project so that they may be ordered early to help ensure that they will be available when needed. Many vendors have a $50 or $100 minimum on purchase orders and unless the cost of the component(s) exceed this minimum, these components will go on a vendor order list and will be ordered when this minimum is reached.
  5. Under certain circumstances, you may need to purchase a component on your own. Before purchasing the component, you must fill out a component request form and have it approved by your project advisor and signed by Mr. O'Rourke. This gives you permission to purchase the component(s) and be reimbursed. Failure to follow this procedure may result in the component cost not being reimbursable. WPI will allow only one reimbursement per project and this is normally done at the end of the project. All receipts for reimbursement must be signed by Mr. O'Rourke. Please note it is the student's responsibility to keep the project within budget and orders or reimbursements over this amount will not be approved.
  6. At the conclusion of your project, all components and equipment must be returned to the ECE shop. Exceptions to this would be projects kept by the advisor or a student. If a student should want to keep a project, a payment equal to the cost of the components must be made to WPI c/o the ECE department.
  7. All students are required to turn a shop release form (which reflects the above status) into the registrar's office before they graduate. This form is available at the ECE shop window.

8.2 ECE Shop Services

The following services are available from the ECE shop:

  1. There is a limited supply of equipment and tools that can be signed out for project use. Some of the heavy demand items may be limited to a one day sign-out on a first-come, first-served basis.
  2. Project lockers are available in the Computer (AK 227) and Communications (AK 320) Project Laboratory areas. Find an empty locker in the area you wish to work in and note the key number on the locker. You may sign the key out of the shop.
  3. The shop has a limited wood and small machine shop that you may use to fabricate your project.
  4. The status of your account is kept on a computer and is available to you on request.
  5. Data books and reference material on some of the software used in the department are available for use at the shop window. We try to keep data books on all our stocked parts. There is also a set of Data Books in Gordon Library on reserve.
  6. The shop also provides technical assistance and general logistical support for MQPs. See Mr. O'Rourke in AK 111a (E-mail orourke@ee) or call him at 831-5233.

The shop is open from 8:00 AM to 12 noon, and 1:00 PM to 5:00 PM, Monday through Friday. The shop is closed on the weekend.

8.3 Projects Office Resources and Responsibilities

Registration -- The Projects Office handles all aspects of project registration for the Registrar's Office. You should pick up a registration form at the Projects Office, fill it out completely, obtain the required signatures, and return it to the Projects Office.

Off-Campus Projects -- If you register for an off-campus project, be sure to indicate that the project is off-campus on your project registration form. The Projects Office will contact the off-campus organization to officially confirm your project, and also to ask the organization to fund your project. Many companies such as GE and DEC are quite generous, while others have more limited resources. If your project is funded by an organization, you will have to keep careful records and receipts of your expenditures, and fill out a WPI expense report in order to be reimbursed for project related expenses.

Legal Agreements -- Many off-campus organizations have entered into legal contracts with WPI. The agreements cover such issues as royalties, patents, insurance, etc. If an organization has a legal agreement with WPI, you will be required to sign a form indicating that you have read the contract and agree to abide by it.

Project Telephone -- If you need to make long-distance calls as part of your project, a telephone, located in the Project Center, is available to you. The telephone is monitored by work-study students and is usually available during the normal business hours during each term.

Writing Resource Center -- If you need help with writing, or if English is your second language, the Writing Resource Center can help you develop and improve your writing skills. The Center is located in Salisbury Labs.

Information -- For general project information, see Mr. Charles Kornik in the Projects Office.

Help in the ECE Department

The ECE Department has made the following sources of MQP information available:

Located across from the ECE mailboxes, this board is reserved for information regarding ECE Department MQP activity, such as schedules for general laboratory access, advertisement for MQP students and partners, notices of important events, deadlines, etc.

This is a directory contains files that hold information that may be useful to you throughout the MQP process. MQP-related documents such as the MQP Manual (this document), MQP Written Report Guidelines and Oral Presentation guidelines are available as postscript files. Other files contain text describing useful information such as test equipment availability and location and project laboratory hours. This information is accessible from both wpi and ee under the directory name /EEMQP. A readme file in that directory explains the content of each of the files.

A campus-wide newsgroup called wpi.ee.mqp is available to provide a forum for students to discuss ECE MQP-related issues. This newsgroup establishes an "MQP Community" where a variety of different MQP groups can easily communicate to exchange information about MQP-related topics. Such topics might be solicitations for project partners, or requests for information about specialized hardware and how to locate components. Many faculty members monitor this list and may be able to help you by providing general guidance on topics such as test procedures or approaches to researching new topics. Instructions for accessing this newsgroup can be found in Appendix A.

If you need special help, see your academic advisor first. If you still need help, contact any of the ECE faculty who are currently on the Department's Undergraduate Project Committee. Currently, the members of this committee are: academic year, they are:

Professor Duckworth   AK 312
Professor Labonté     AK 310
Professor Michalson   AK 309
Professor Brown       AK 307
Mr. O'Rourke          AK 111a   Shop Supervisor

9.0 Faculty Projects

The ECE faculty are an eclectic group of people that have a wide array of interests and ideas for projects. To find out what the faculty propose, what their interests are, and what other projects are proposed by students and by industry check out the Project Exchange page.

Appendix A - An Example High-Level Project Specification

Project: The MIDIfier

Description: The MIDIfier is an audio post-processor that allows assigning MIDI note-on, note-off, and velocities to audio events. The MIDIfier works by using fully parametric filters to select audio events based on frequency and amplitude.

The user shall be able to select an audio event by adjusting filter gain, bandwidth, and center frequency and by setting a desired amplitude threshold. If an audio signal of the correct frequency exceeds the user selected threshold, then a MIDI message containing a user assignable MIDI channel number, a user assignable note-on code, and a velocity code is transmitted. When the audio signal drops below threshold, the appropriate MIDI note-off message is sent.

Minimum and maximum velocities must be user assignable with a signal just breaking threshold being assigned the minimum velocity. Velocities may be assigned by linearly mapping received signal amplitude to a velocity between the minimum and maximum.

Two channels of input are provided which may be used in either of two user-selectable configurations. In configuration 1, both input channels are completely independent, driving independent parametric filters and thresholds. In configuration 2, the signal from channel 1 drives both filters and threshold detectors in parallel. In either case, the filter/threshold outputs generate independent, user-assignable MIDI messages.

A monitor function must be provided that allows a user to listen to each post-threshold audio signal independently to aid in correctly setting the filters. In addition, front panel LED indicators must show that a pre-filter signal is present and if the threshold is exceeded for each channel. An overload indicator LED must signal the user in the event that the allowable input signal levels are exceeded. MIDI out and thru connectors must be provided.

Detailed System Specifications:

Frequency Response:  20Hz to 20KHz

Input Impedance:     >10K Ohms

Output Impedance:    100 Ohms 

Maximum Input        +28dBu 
Signal:

Nominal Input        User selectable -10 or +4 dBu
Level:

Output Level:        Adjustable from -40dBu to +4dBu with maximum signal
                     input and maximum filter gain. 

Filter Center Freq:  Adjustable from 20Hz to 20KHz. 

Filter Gain:         Adjustable from -12 to +12dB.

Filter Bandwidth:    Adjustable from 1/12 to 2/3 Octave.

Threshold Range:     Continuously adjustable down to -10dBu.

Signal Present:      Indicator lights when input exceeds -20dBu 

Input Overload:      Lights when input signal exceeds +12dBu. 

Connectors:          Audio inputs and outputs are standard 1/4" mono
                     phone jacks.  MIDI connectors are standard 5-pin 
                     DIN. 

Power:               External UL approved transformer.

Size:                Standard 1 unit rack mount.

Switches:            Configuration 1/2. 

                     Input -10 or +4. 

                     Output monitor in/out. 

                     Power on/off.

                     MIDI out on/off. 

                     8 or fewer button keypad for entering user options 

Controls:            Channel 1/2 Gain, Channel 1/2 Bandwidth, Channel 
                     1/2 Frequency, Channel 1/2 Threshold, Monitor
                     Level. 

Indicators:          16 x 2 LCD user display, Signal present (channel 
                     1/2), Input overload (channel 1/2), Threshold
                     exceeded (channel 1/2), Output monitor in, MIDI
                     off. 

Price Target:        $175 in quantities of 100.

Appendix B - Written Report Guidelines

B.1 Introduction

This document is intended to provide guidelines for preparing the written MQP report which is submitted at the conclusion of the project. Most of these guidelines are based on common sense. They are offered to help improve the overall quality of the MQP report and should be used in conjunction with other campus resources to prepare a quality project report. As with everyone else, an engineer's primary means of communication is through spoken and written English (in this country). Do not subscribe to the stereotype that engineers have a poorer command of English than other professionals.

It would be difficult to overstate the importance of a quality report. The report is one important element in the evaluation of the project by your advisor. In addition, the project report is the vehicle by which the results of your work are disseminated. It must be structured correctly and written precisely if it is going to be of any use to the intended audience. There is no excuse for misspelled words, incomplete sentences or poor punctuation in a report.

Even though handing in the report is the last thing before being officially done with the project, the writing should not be left until all of the work has been completed. The ``write as you go'' method of report generation often saves time and headaches in the end. By writing the report in installments, you will avoid omitting an important measurement before the equipment has been taken down. The process of report writing often results in the need for more technical work in order to make the project complete. In addition, it is a lot easier to write about things when the work is still fresh in your memory. Three (or more!) terms is a long time to remember small but important details.

Remember that the ideas, the findings and the conclusions put forth are the primary purpose for the report. Following these guidelines will help ensure that the reader is presented with a report which follows an orderly presentation, is well documented and free of mechanical flaws. The content is up to you.

B.2 Format and Style Issues

The format and style of the report are the first things that the reader will see. Attention paid to the details of report format and structure will complement the written content. These issues are dealt with by Turabian[1].

Your report should be typed. This document was prepared with Microsoft Word. Word is one of many different tools that are available on campus. Other tools available include Interleaf and LATEX on workstations and WordPerfect on PCs. These tools relieve the user of most formatting and typesetting concerns and generally provide facilities for tabulating data and drawing figures.

B.2.1 Report Format

Any technical report can be broken down into three main components, including:

  1. The front matter.
  2. The body.
  3. Reference material.

The physical formatting of each page should be according to the specifications published by the archival body, generally the library. In the absence of these, a good rule of thumb is to allow one inch on the top, bottom and the unbound side. A margin of at least one and one quarter inches should be allowed on the side of the page which goes into the binding.

For a project report, the front matter consists of:

  1. The title page.
  2. An abstract. This is a short, stand alone description of the project which should convey the problem, the approach, the solution, the results and the conclusions. An abstract is the often the first thing to be read and will determine whether the reader decides to go further. The abstract should contain the maximum amount of specific information. For an MQP, the abstract should be limited to about eighty words.
  3. Acknowledgments. These are optional.
  4. A table of contents. This is a list of page numbers indicating where to find each section in the report. Major and minor section divisions should be listed in the table of contents.
  5. A list of figures. This is a list of each figure, its caption and its page number.
  6. A list of tables. This is patterned after the list of figures.
  7. An executive summary. This can be thought of as an extended abstract. It should contain a terse discussion of all significant goals, work, and results of the project. You should limit yourself to no more than five pages.

The body of the report is where you put the substance. Generally speaking, it should contain an introduction to the problem, your objectives, a review of pertinent literature and the details of your approach to the problem. It should end with a summary of what you have done and your conclusions. It should be constructed of well defined divisions such as chapters, sections and subsections. Each division should be numbered, with each section numbered to reflect the chapter. Each subsection should reflect the section.

As its name implies, the reference material consists of the material you referenced in the body of the report. If you point the reader to any books, technical papers, reports or manufacturer's information for more details regarding something you discuss, then your reference material would include a list of technical references. The style of these references is discussed in Section C.2.2.4 below. Other appropriate reference material would be included through the use of appendices. Material appropriate for inclusion in appendices include experimental data, computer programs, detailed schematics, device data sheets and anything else which adds to report completeness but which is not appropriate for inclusion in the report body. Copies of readily available material should not be included in the appendices; reference to the material is sufficient.

For many engineering design projects, the report should contain a maintenance and/or user manual. This manual should be a stand-alone section and included as an appendix which is referred to in the body of the report.

B.2.2 Report Style

Virtually every technical report uses figures, tables, equations and references to aid with clarity, succinctness and completeness. This section addresses how these items should be included in the report.

B.2.2.1 Figures and Tables

A figure or table is used to better illustrate a point.

A well designed figure or table can save you a lot of writing while doing a better job of getting your message across than by using a lot of confusing words. An important example would be the use of timing diagrams to describe the operation of a microprocessor system.

A figure is located as close as practical to, and preferably after, the first place it is referenced, but it should not split up paragraphs. The figure is accompanied by a number and caption, both of which go below the figure. Use the number when you refer to a specific figure. An example of a correct figure reference is "The basic algorithm for performing integrity monitoring is illustrated in Figure 1." Proper figure format is shown in Figure 1. Figures should be numbered consecutively within each major division of the report. That is, if your report is broken down into chapters, number each figure consecutively within that chapter. Each figure number should reflect the major division. For example, the first figure in Chapter 2 would be referred to as "Figure 2.1."

         Figure 1: Generic RAIM Algorithm.

The caption associated with the figure should be able to convey some understanding of the figure to the reader without reference to the report text. Proper sentence structure and punctuation should be used in the caption, complete with a final period.

Figures should be in black and white only. This makes mass reproduction possible because not all photocopiers reproduce all colors. In addition, color figures may become ambiguous when photocopied into black and white. Figures should not be drawn freehand. Drawing packages such as Corel Draw are available on the Department PCs and tools such as Xfig are available on workstations that you may use to create proper figures. Similarly, a variety of tools ate available for creating Graphs.

Also, a figure does not substitute for clearly written text. Every figure should be both referenced and explained in the supporting text.

A table is just like a figure with two exceptions.

First, the number and caption go above the table. Second, when referring to a specific table the word table is capitalized and never abbreviated. Figures and tables should be numbered separately but with the same numbering convention. A sample table is given in Table 1.

Table 1: The design summary for the 8/14 VRM

                   8

                   14 

                   0.169 rad

                   0.195 rad

outer diameter     146 mm 

rotor slot         133 mm 
diameter

stator diameter    112 mm 

air gap            0.127 mm 

stator trunk       52 mm
diameter

shaft diameter     40 mm

N                  276 turns

B.2.2.2 Equations

Equations are a natural component of technical reports. Each significant equation should be displayed. That is, it should not be buried in the text. If the equation is ever referred to in the text, the equation should be numbered to facilitate the reference. The number should be in parenthesis at the right margin of the equation. This format is shown with the definition of the total harmonic distortion (THD), which is given by

(1)

A sample equation reference would be "As noted in Equation 1, the THD ..." Notice that references to equations take the same form as references to figures. Also note that equations should include proper punctuation. Punctuate an equation just as you would a sentence.

If any calculations are presented in the report, the SI system of units should be employed. The only exception to this would be when the use of SI units deviates from the accepted set of units for that field. For example, the semiconductor devices field usually uses centimeters, not meters, as its fundamental length. In any case, the units being used should be stated explicitly.

B.2.2.3 Abbreviations and Acronyms

Define abbreviations and acronyms the first time they are used. Acronyms that will be recognized by any practicing electrical engineer do not have to be defined. Acronyms which do not need to be defined include IEEE, SI, MKS, CGS, ac, dc and rms. Redefine acronyms when first used in the text even if they have been defined in the abstract. Do not use acronyms in titles unless they are unavoidable. Accepted unit abbreviations may be found in most introductory texts for the subject area you are working in.

B.2.2.4 References and Bibliography

References are used to direct the reader where to go for more explicit information about a topic. You do not need to include a direct quote from the source in order to justify your reference. For example, the following text is an example of how you might use a reference.

Thus, the basic requirement of a GPS integrity monitoring system is to alert the user if their reported position is outside of the accuracy requirements for the current phase of flight. Furthermore, the user must be alerted in a timely fashion so that an alternate source of navigation information can be used. Table 1 lists the typical integrity monitoring requirements for various phases of flight[3].

The number of the reference is enclosed in the square brackets. In the list of references at the end of the report, we would find

[3] "Minimum Operational Performance Specification for Airborne Supplemental Navigation Using Global Positioning System (GPS)," RTCA Document RTCA/DO-208, July 1991.

It is important that references be complete. There is nothing more frustrating and time consuming than tracking down an incomplete reference. A typical reference should provide:

  1. Names of the authors.
  2. Title of the paper.
  3. Full title of the journal.
  4. Year of publication and the volume number.
  5. First and last page numbers.

For a book, the author, book title, publisher and year of publication should be stated, along with the chapters to which you refer. For other types of documents check a style guide for the appropriate reference format.

B.2.2.5 Some Common Mistakes

The word "data" is plural, not singular. The subscript for the permeability of free space is zero, not a lower case "o." In American English, periods and commas are within quotation marks, like the period at the end of "this sentence." A parenthetical statement at the end of a sentence is punctuated outside of the closing parenthesis (like this). (A parenthetical sentence is punctuated within the parentheses.) A graph within a graph is an "inset," not an "insert." The word "alternatively" is preferred to the word "alternately" (unless you really mean something that alternates). There is no period after the "et" in the Latin abbreviation et al. The abbreviation i.e. means "that is" and the abbreviation e.g. means "for example." These and other foreign language phrases should be set in italics.

When expressing volumes, use either of these forms: "" or ";" do not use "." In the text, tables and figures, use a zero before decimal points: "0.25," not ".25."

Do not mix complete spellings and abbreviations of units. Use "" or "Webers per square meter," not "." Spell units when they appear in text: ". . . a few centimeters," instead of ". . . a few cm."

B.3 Report Content

The report is intended to be complete documentation for your project and it should reflect that. It should be detailed, complete, concise and precise. Don't waste your time and the readers' time with extra words. Completeness and precision do not imply a lot of words. Technical papers are a good example of this.

The precision of your words is very important. Just as in the legal profession, many technical words have very precise concepts associated with them. Loose usage of these words may seem like a way of avoiding the usage of the same words over and over again. The more likely result is a confused reader; be consistent with your choice of words. For example, electric motors and electric machines are not necessarily the same. While every electric motor is an electric machine, not every electric machine is an electric motor.

Also, do not use an imprecise word (such as "several") when a precise word (such as "three") is possible. It is usually apparent when vague language is being used as a substitute for the technical work which would enable precision. This is very damaging to the quality of the report and the overall quality of the project.

You should view the project report as a document which reflects your learning experience. Dead ends should not necessarily be omitted from the report. If they were significant, put them in. Having said this, it is also important to realize that the report is not a diary. The organization of the report deserves careful thought over and beyond how the project was executed.

The level of the report should match the intended audience. An MQP report should be written so that any junior electrical engineering student can understand it. This is particularly true of any user's or maintenance manuals that are included with the report.

If the project report has multiple authors, you have a little more work ahead of you. Care must be taken to be sure that notation is consistent between authors. In addition, it is very easy for multiple authors to repeat each other. Outlining the report before the writing begins will help eliminate redundancy.

Strunk and White[2] do an excellent job of illustrating and then describing ways around common writing problems. It is a short book and the time invested in reading it before you begin writing in earnest will be repaid in reduced revision time and improved readability of your report.

Your advisor's job is to make sure that your report is technically correct. Everything else is your responsibility. You should not expect your advisor to spend his or her time correcting your English. If the writing is poor, don't be surprised if your advisor refuses to read it. If your advisor must help you with your English, don't be surprised if your grade reflects this fact. By this point in your career you should be competent in written communication. If you are not, take advantage of the writing resources offered on campus. The Writing Resource Center may be able to help you understand the types of writing mistakes you are making so that you may become a better writer. Don't hesitate to use their services. The projects office also has handouts on how to write a project report.

It is vital to allow for multiple drafts, with time to critically read each draft and make all necessary changes in content an organization. It is unreasonable for you to expect your advisor to be able to turn your drafts around in 24 hours. Plan your time accordingly.

B.4 Summary

This document has provided a brief overview of what is expected in an MQP report. Most of these guidelines have dealt with the mechanical features of the document. While these are easier to take care of than the actual report content, their importance cannot be overstressed. Following these guidelines will result in a report which has the essential components of a professional quality report.

B.5 References

  1. L. Turabian, A Manual for Writers of Term Papers, Theses, and Dissertations, The University of Chicago Press, 1973.
  2. Strunk and White, The Elements of Style, 3rd ed., Macmillan Publishing Company, 1979.

Appendix C - Oral Presentation Guidelines

C.1 Introduction

This document is intended to provide some general guidelines for the content and style of oral MQP presentations. The ability to give effective oral presentations is one of the most important skills a technical professional can possess; no matter how good your work is, if you cannot effectively communicate its results and significance in both written and oral formats, you and your work will not be fully appreciated. Fortunately, the MQP provides an opportunity for you to gain experience giving an oral technical presentation. This presentation is a requirement in the Department of Electrical and Computer Engineering.

While some of the guidelines refer specifically to MQP presentations, and others to technical presentations, many of them are common to all presentations. No matter where your career path leads, it is highly likely that you will need to develop effective presentation skills to be successful. You will be called upon to give presentations to supervisors, managers, prospective employers, clients, customers, research sponsors, colleagues, conference attendees, and so on. You will be judged not only by what you have to say, but also by how well you say it, and even how you look while you are saying it. This document will try to address some of the concerns resulting from this fact of professional life.

C.2 Designing Your Presentation

A presentation must be carefully tailored to the specific format, audience, presentation media, and level of formality associated with the presentation forum. In this section, the appropriate form and content for an MQP presentation will be discussed.

C.2.1 Format

The format for MQP presentations is very brief; typically five minutes per project plus five minutes per project student is budgeted. (Thus, a two-person team gets 15 minutes, etc.) This time also includes questions from the audience, so the actual presentation time is less. The brevity of this format may please you at first, but it is one of the most difficult things about the format. Simply put, there is not nearly enough time for you to give a detailed description of your project. Instead, you must focus on an overview that gives the audience a general appreciation for:

More specifically, an outline of your talk should be not unlike the outline of a written report, with:

It is considered extremely unprofessional to exceed the allocated time for a presentation. (On the other hand, finishing early doesn't really send a very good message, either; that shouldn't be a problem for these brief presentations, though.) You should focus on the "big picture" at the expense of technical details that you might feel are important. There simply isn't enough time to talk about everything you've done (if there is, then you haven't done much). You will find that tailoring your talk to the right length and level of detail might require several tries.

A demonstration of your project is nice, iff:

C.2.2 Audience

The audience for MQP presentations generally consists of junior and senior ECE students and ECE faculty, plus assorted family and friends. The level to which you should gear your talk is that of a competent junior or senior ECE student, i.e., assume that the listener understands basic ECE concepts. The talk should be accessible to the students without boring the faculty to tears.

C.2.3 Presentation Media

It is said that a picture is worth a thousand words; depending upon the image resolution and the richness of your vocabulary, it may even be worth more, from an information theoretic viewpoint. The visual aids you use for your talk can make a deep impression (either good or bad) on your audience. The best visual aid for this type of presentation is a set of viewgraphs (also known as overhead slides or transparencies). These can be easily generated by a photocopier from any clear original with good contrast. Every major point in your presentation should be represented in some form on a viewgraph. They convey information to the audience and help to prompt the speaker.

Here are some guidelines for using viewgraphs:

Remember that your viewgraphs don't have to tell the whole story-that's what you're there for. They should, rather, focus the attention of the audience to key points and provide a basic understanding of how any pieces of the project fit together.

C.2.4 Level of Formality

The word that best describes the impression that you should try to give the audience is "professional". This applies to your appearance, manner of speech, and visual aids. You should dress as if you are going on a job interview. Speak in clear and complete sentences, avoiding slang and obscure technical jargon. Your viewgraphs should be typeset using some sort of package designed for the presentation of technical materials; the one you are using for your report will probably do nicely, as long as you can select an appropriate font size (or enlarge it on a photocopier). If hand drawings must be used, they should be very carefully prepared.

C.3 Presentation Style

Once you have determined the content of your talk and visual aids, you must pull it together into a presentation. This will require practice-it is easy to find yourself tongue-tied the first time that you attempt to describe or explain something, even if you understand it well. Here are some pointers for preparing the presentation.

C.4 Handling Questions

The best way to handle questions from the audience is to be prepared. Elicit questions from the practice audiences. Try to anticipate anything that might confuse or intrigue people. Be aware of anything you have done which is unconventional or impractical, and be ready to discuss why. Your advisor may be of some help here.

It is a good idea, if you can anticipate certain questions, to prepare "backup slides" for answering them. For example, there may be derivations, data, circuit diagrams, or whatever that were too detailed for the main body of your presentation, but would serve to answer a tough question quickly and painlessly.

Don't try to snow anyone; if you don't know the answer to a question, say so. Perhaps someone in the audience can provide an answer; ask for a little help if you need it.

C.5 Logistics

This year's MQP presentation day will be Wednesday, April 21st; no classes will be held that day.

Each presentation will be assigned a specific time slot and room; multiple parallel sessions will be held throughout the day. You should attend the entire session; don't just come in for your presentation. One reason is that any canceled presentations will change the time of yours; another is courtesy to the other presenters. Be sure to contact your advisor immediately if you cannot give your presentation at the assigned time. If your MQP schedule makes a D term presentation impossible (e.g. if you finish and graduate B term), see your advisor to schedule a presentation during your final term.

An overhead projector and screen will be available for your use in the presentation rooms; you are responsible for any other equipment you might need for a demonstration (including extension cords, etc.) If you plan to do a demonstration, be sure to arrange your apparatus so that it is easily moved into place for your presentation and out of the way when you are done without causing disruption to the proceedings.

You may make your overhead slides in the ECE department office. Transparencies are quite costly, so each group is limited to 15 without charge. Make draft viewgraphs on paper to use in rehearsals; practice with the final versions (and show them to your advisor) before making the actual transparencies.

Plan ahead; there will most likely be a long line on the last few days before presentation day.

C.6 Summary

Effective presentation skills come with practice; as your career progresses, you will gain more confidence in expressing your ideas to others. This MQP presentation is not meant to be a traumatic experience, but rather a chance to share the results of your work with the WPI community. Be sure to take full advantage of this opportunity by preparing a high-quality presentation.

Maintained by webmaster@wpi.edu
Last modified: September 20, 2006 15:50:36