The E72 project is a project in which you can explore any topic
related to the class that interests you.
- You should pick a project that you think you can reasonably complete in
- You should discuss it with me before the proposal is due to make sure
scope of project is appropriate.
- You can come up with an idea of your own, or look
- Your budget is about $30 per person.
- Project groups can be from 1 to 4 people.
- Due dates for the project are on the moodle page.
- I will not be accepting any more labs after November 13 (I find that if
students are working on labs, they do not work on project).
Your project grade will be the combination of grades on four parts.
- 10% - Written project proposal - due November 14th
- 10% - Practice Oral presentation - December 2nd and 3rd (Saturday and Sunday)
- 30% - Final Presentation: in front of the class - December 4th, 6th and 8th.
- 50% - Project and report, including progress and conduct on project
throughout the weeks allotted to the project. - December 11th. You can also upload a video.
- The written project proposal is brief. It should be turned in as a pdf document
on the moodle page and will be penalized if late.. It includes:
- Title of project
- Students working on project
- A 1-2 paragraph description of project
- A basic block diagram (not much detail) showing major hardware
components and how they work together and a basic flow chart/diagram of any
- A week by week schedule showing major tasks to be accomplished
must be included:
Presentations of project will be on December 4, 6, 8, but you have until the 12th to tie up loose ends
and submit the written report.
- Nov 12-18: Order parts, start project
- Nov 19-25 (Short week - Thanksgiving)
- Nov 26-Dec 2
Details about presentations and report will follow closer to the end of the
Oral Project Report
Below are some things to keep in mind when preparing your presentation (these
are guidelines, it may be appropriate to break them):
- You have 4 minutes + 1 minutes per person. A single person group
has 5 minutes, two people have 6...
- Practice your talk at least once in the class room to make sure all
software/hardware works as you expect (especially if you are unfamiliar with
the A/V equipment in the room where your presentation is). Also - put a
local copy of your presentation on the machine in the room in case
network is down, or have it on a USB drive.
- The assumption is that you are the expert on the topic, you don't need
to prove this. Try, instead, to make everybody in the audience understand
what you did. In particular, try to make everybody in the room understand
the first 2/3 to 3/4 of the lecture. At the end you can get in to some of
the more esoteric (and interesting to you) topics. Remember you have been
working on this project for weeks, so all the details are obvious to you.
This is not true of your audience.
- Spend a little time on very general background before you get
into any details. In particular, make sure you have answered the question
"What was the main goal of your project, and why did you do it?" Spend 1-2
minutes on each slide you put up (5-10 slides for a 10 minute presentation).
- The text on the slide should be readable in 10-15 seconds at most - if
text is on the screen the audience will be reading it instead of listening
to you. The text is there more as a guide (e.g., bullet points) than for
large quantities of information. Corollary -- explain what is on the screen,
don't read it. If you want more text - put it up in a few stages, and not
all at once.
- Don't put anything up on the screen that you don't expect everybody to
explain to everybody until they understand. This probably means no (or only
very simple) schematics, program code... The only exception is to put up a
very complicated diagram/equation just for effect: "see what I did."
Otherwise, you should expect every thing on every slide to be understood by
Written Project Report
This report takes more of a traditional lab report format than have other
reports for this course. It should be
written as if the reader was another member of the class. S/he has some
familiarity with the topics covered in the course but perhaps not with the nitty-gritty
details of your chosen application/project.
With your report in hand s/he should be able to quickly reproduce what you did and
understand it well enough to add to it.
- Title page/Table of contents - project title, names of
participants, and a table of contents.
- Abstract - 1 paragraph describing what you did.
- Introduction - What is the goal of your project? What motivated
you? Why is it interesting?
- Background/Theory - What technical details does your reader need
- Completed Project Design - Start with a very high level description
of your project.
Get increasingly detailed in your description until you get to the level
of short sections of code/circuitry that are critical to the proper operation of
your project. Any comments in your code should be good enough that
somebody in the class could read and understand it, without having to
refer to any external references. This is the most substantial
part of your report.
- Results - How well did you achieve your goals? This
should include quantitative results (and perhaps qualitative).
- Discussion/Conclusion - What worked well? What didn't?
What are obvious extensions?
- Appendices as needed. The body of the report should only
contain short bits of code necessary to explain the project operation.
The appendix should contain complete code listings.
- The report will be in a single file that is uploaded to the moodle
site as a pdf document.
- If you have a video of your project, I'd love to get a link to it that I can post on the department website.