NECAMSID Sponsored MQP Administrative Details

Prof. John McNeill

The MQP is a unique part of your WPI education. The opportunity for a faculty advisor and student team to work together on a "real world" engineering design project can be extremely rewarding for everyone involved. In order for the project to go smoothly, I have developed these guidelines for what I expect from the project team, and what the team can expect from me.

Project overview

A typical on-campus MQP should take three terms to complete, usually A, B, and C terms. All MQPs make a formal presentation to the ECE technical community on Project Presentation Day during D term. In addition, NECAMSID projects also present to sponsor representatives in poster sessions at the spring and fall meetings:

Fall Meeting: Wednesday, October 5, 2005

Spring Meeting: Wednesday, April 12, 2006

Expect to prepare a "dry run" presentation of your poster and lab demonstration materials one week before these meetings.

During the three terms, the progress of the project should (very roughly) be as follows:

1st term: Define the work

Write the proposal, complete preliminary design of critical components

2nd term: Do the work

Complete design, build the system, start testing

3rd term: Document the work.

Complete testing, write final report, identify future work

Note that this division of work is by no means a hard-and-fast rule; for example:

  • Externally sponsored projects are usually fairly well defined right from the start. Therefore, the "write the proposal" stage will take less than a full term, and some of the design completion or system building work should be pulled into the first term.
  • A project may rely on a critical component - for example, a low noise amplifier stage - for which the performance can only be predicted by building and testing the subsystem using the component. Therefore some of the "build the system" work may be pulled in to the first term, so the system design can proceed with confident knowledge of the critical component's performance.
  • Documentation of the work should proceed in parallel with other work throughout the entire project. The MQP final report will be a document of approximately 100 to 200 pages; writing material gradually as you go along is much more efficient (and less stressful!) than waiting until the last minute.

EE2799

Every team member must have received a passing grade in EE2799 to receive adequate preparation for the “process” part of the MQP. A further request that I make is that you be intentional about the design process in your MQP. Whenever possible, be explicit about drawing on your EE2799 background in carrying out the work in your project.

Weekly meeting

For most of the project duration, the primary vehicle by which the progress of the project will be assured and monitored is the weekly meeting. Each week, prior to the weekly meeting, your team should prepare a progress report.

E-mail a copy of the report to me on the day before the meeting, and bring a hardcopy of the report to the meeting.

This report should summarize the previous week's activity for each member of the team. The report should be clear and concise - a couple of paragraphs for each person would be appropriate; no more than one page per person is necessary. Although you may prepare your sections of the report individually, I strongly encourage you to get together to review the report as a team. This helps ensure that one of the "process" parts of the MQP - learning to work in a team - is addressed.

Items which should be included in your weekly progress report:

  • Minutes of the previous week’s meeting, including short term goals for the coming week
  • accomplishments of the past week
  • comparison of those accomplishments with goals from the previous week
  • interactions with other team members that will be required
  • any changes in long term goals
  • an agenda for the weekly meeting, including especially any questions or problems you wish to bring up.

Of course, you should feel free to keep me apprised of significant developments on a more frequent basis; in particular, if something is preventing progress, do not wait until the next meeting to seek assistance. You can contact me by phone (X5567) or e-mail (mcneill@ece) at any time.

A bonus feature of the weekly report is that portions can be pasted almost directly into your final project writeup. Although the weekly report itself need only be a couple of pages, feel free to include attachments of several pages. For example, if one of the week's accomplishments was to finish a block-diagram-level analysis of the system, your description of that accomplishment (and the process you went through to achieve it) would form part of the introduction to the block-diagram-level analysis section of your final report.

Communicating your results

Written reports

During the first term of the project, you are asked to develop a proposal in which the envisioned project is described. This document should include as much detail as possible regarding what the goals of the project are, and how you expect to meet them. In particular, it should include a schedule: a detailed timeline in which the anticipated progress for the remainder of the project is planned.

The project proposal, in turn, should form a skeletal document from which your final project report can be constructed at the end of the MQP. The project report is of great importance; please refer to the ECE Departmental Guidelines for MQP Written Reports for details. Because the final project report is a significant and archived document, I will typically work with you until it is of excellent quality. Accordingly, judgment of your efforts regarding the report will be based upon the initial drafts - if the final result reflects significant rewriting effort by your advisor(s), my grade will be good, but yours may not be!

For guidelines to presentation of data in technical writing, I encourage you to refer to the following documents:

ECE Sample Lab Writeup (attached)

Writing and Speaking in the Technology Professions. IEEE Press, 1991.

Better Technical Presentations. IEEE Press, 1992.

Edward R. Tufte, The Visual Display of Quantitative Information. Graphics Press, 1983.

Edward R. Tufte, Envisioning Information. Graphics Press, 1990.

Edward R. Tufte, Visual Explanations. Graphics Press, 1997.

(All of the Tufte books are in the WPI library)

Oral / Poster presentations

You are expected to prepare and deliver an oral project report near the end of the project, and poster presentations at the Fall and Spring meetings. This project report is also of great importance. Please refer to the ECE Departmental Guidelines for MQP Oral Reports for details.

In my experience, this has been an area where many students would have benefited from more preparation and practice in presentation techniques. There have been several MQPs that did outstanding work, but because of poor presentation skills the impression given was less than outstanding.

Therefore, I am helping my MQP students to practice their technique by requiring intermediate oral presentations. In each of the terms, there will be at least one "practice" oral or poster presentation required.

The oral presentations will use full presentation tools - typically PowerPoint slides (I will borrow a PC projector to use in the Analog Lab). Each student should plan to present for about 5 minutes (about 5 slides). These presentations will take place during the weekly meeting, and will not be open to the public - you can make mistakes without worrying about everyone else seeing you.

The poster presentations will require development of a "dry run" poster (typically, sixteen 8–1/2" x 11" sheets) accompanied by (if appropriate) lab demonstrations. The poster sessions at the sponsor meetings are two hours long, during which times the sponsors will be asking you about your project. Be thoroughly familiar with your project, and be prepared to discuss any aspects of your design!

The subject of the presentations might be as follows:

1st term

  • Proposal overview
  • Summary of 1st term accomplishments, goals for remainder of project

2nd term

  • Design challenges (solved / to be solved)
  • Summary of 2nd term accomplishments, goals for remainder of project

3rd term

  • Technical overview of design, test techniques, measured results
  • Practice final presentation

These are only suggested topics; the actual topics and scheduling will be determined according to what is appropriate for each project.

Evaluation

Each term you are registered for the project, you will receive a grade reflecting judgment of your accomplishments for that term. This grade usually will not be changed in the future, as it reflects only upon that term's efforts.

Upon completion of the project, you will receive an overall project grade. It is important to note that this grade reflects not only the final products of the project (for example: results, reports, etc.), but also the process by which they were attained. No amount of last-minute scrambling can turn a mediocre project effort into an A.

As a reminder, the available grades and their interpretations (from the Undergraduate Catalog) are as follows:

Aa grade denoting a consistently excellent effort, beyond the expectations of the advisor(s), and leading to successful results.

Ba grade denoting a consistently good effort, fully meeting the expectations of the advisor(s), and leading to successful results.

Ca grade denoting an acceptable effort, meeting most of the expectations of the advisor(s), and leading to partially successful results.

SPa grade denoting an effort sufficient for the granting of the credit for which the student is registered. This grade will normally not be used.

NRa grade denoting an effort insufficient for the granting of the credit for which the student is registered. Often a gift, because you could be instead receiving an

NACa grade denoting an effort which is unacceptable. Note that this grade is entered into the student's transcript.

One difficulty I have had in the past is with grading the MQP - especially unpleasant surprises at the end of the term. With a course, you know what your exam and homework grades have been; you can get an idea of what kind of a grade is coming. The relatively "squishier" grading of the MQP can lead to anxiety, confusion, and unnecessary stress.

To improve the grading situation, here's what I do:

  • At each meeting, we will agree on approximately 15 hours of work to be performed by each team member before the next meeting.
  • At the next meeting, we will agree on a grade for the work done in the previous week. The determination will use the grade interpretations above, and be based on the goal set at the previous meeting as well as "process" issues (such as teamwork) reported on in the weekly report.
  • At the end of the term, I will use the average of the weekly grades to determine the grade for that term.

This should prevent "surprises" at the end of the term, and also provide the additional benefit of continuous feedback during the term.

The “process” aspects of the MQP will be judged according to the “Expected Competencies” (attached, and also available on my MQP web site)

Also attached is a copy of a self-evaluation form I will ask each of you to fill out at the end of the project. This form helps me judge the "process" aspects of the MQP.

Analog Lab Procedures

An important resource that you will have for your MQP is The Analog Lab, room AK317b. You will find available in the lab just about any piece of equipment you could want for making any kind of measurement necessary for your MQP. There are also workstations and PCs loaded with design and analysis software tools, as well as a conference room for meeting, discussing your project, and practicing presentations.

You will also find in the analog lab other project groups and grad students trying to complete their academic requirements as well! So for peaceful coexistence, a few rules are in order:

Keys/Security

Each group should choose one person who will be responsible for a key to the lab. Once you have received your key from the ECE office, let me know and I will show you the security system and access code needed for opening and closing the lab. The lab access time policy is the same as the building access policy: any time AK is open to undergraduates, it's fine for you to be in the lab.

PC / Workstation Priorities

Since we may not have enough PCs and workstations in the analog lab for every MQP group and grad student to have a computer at the same time, the following is the priority policy for lab PCs and workstations:

(Note: In the following "project" refers to either MQP or MS/PhD thesis work in

the analog lab.)

Workstations:

  1. Project-related Cadence
  2. Project-related general use
  3. Course-related Cadence (by analog lab students only!)
  4. Course-related general use (by analog lab students only!)
  5. General use (by analog lab students only!)

PCs:

  1. Project-related, machine-specific software/hardware (PADS-PCB, GPIB instrumentation)
  2. Project-related general use
  3. Course-related general use (by analog lab students only!)
  4. General use (by analog lab students only!)

In all cases, computers are to be used only by analog lab students.

PC / Workstation Etiquette

Given the competition for PC/workstation time in the lab, here are procedures for use of machines in the analog lab:

If you are logged into a PC or workstation, and are going to be away from the machine for more than a few minutes, you should leave a note explaining that you will return soon.

If you are going to be away for more than an hour, you should log out unless you are running a large task (e.g. big chip simulation). If there is a task running, leave a note explaining the situation.

If you want to use a PC or workstation, and someone else is logged in:

  • if they have left a note, leave the machine alone!

If there isn't a note:

  • look around the lab to see if the person is there; let them know you'd like to use the machine, and work out which user has the higher priority task
  • if the person isn't there, then log them out before you log in! Don't do anything logged in from someone else's account!

In all cases, computers are to be used only by analog lab students.

Miscellaneous

General food and beverage policy

I have specifically not adopted the "no food and beverages" department policy for this lab, for a number of reasons. Primarily, I want The Analog Lab to be a place where you enjoy working, and to me the timely consumption of caffeinated beverages and unhealthy food is an essential part of the analog engineering experience.

BUT, this places a burden of responsibility on you!

1)There is expensive equipment in the lab that could be tragically damaged by an ill-timed or ill-placed spill. BE CAREFUL!

2)It's hard to enjoy working in a lab littered with empty cans, garbage, etc. CLEAN UP AFTER YOURSELF! If you're not going to take a can out of the lab to recycle it, then just throw it in a garbage can.

Fridge

The fridge is NOT a free soda machine.

Don't take anything out of the fridge that you didn't put in.

Don't put anything in that you don't intend to take out before it becomes hazardous.

Grad student cubicles

These are intended for the use of grad students or MQP teams as individual office space. They are NOT intended as general use recycling centers, coat racks, or any other purpose. If it's not your cubicle, don't put anything in it!

I hope these procedures will make life a little better in the analog lab. If you have any questions or suggestions, please let me know.

111/14/2018