Introduction
For this project, you will design, build, program, and test a microcontroller based capacitive sensors reaction game. This game will produce an audible signal using a speaker, wait for two or more players input from capacitive sensors, decide who wins the round, and keep a record of points for each player using the LCD.
Groups
You are required to work in groups of three students. In order to work in larger/smaller groups or alone, you need the instructor authorization first. Groups can be formed with students from different sections. Once a group is formed, it must work together for the remaining of project 1.
Project Requirements
The project must include the following components and/or functionality:
- 8051 based Microcontroller System: For this project use the AT89LP51RC2 microcontroller. If you wan to use a different processor, you’ll need the instructor approval first.
- Sensor Capacitors: You’ll need to build at least a couple of sensor capacitors. The simplest way of building the sensors is by using aluminum foil between two sheets of transparency plastic. Try to make your sensor capacitors as robust as possible.
- A-stable Oscillators or similar: These oscillators will change their frequency with the capacitance variations of the sensor capacitors. You could use the 555 timer on an a- stable oscillator configuration for this purpose.
- Speaker and LCD: The game must use both the CEM-1028 mini speaker (or similar) and the LCD.
- Assembly programming: All programming for this project must be completed in assembly language.
- Sensititivity: The capacitive sensors should be able to reliably and quickly detect a hand on top of them.
- Suggested Game Rules (or make your own):
- The game will produce either a 2100Hz tone or a 2000Hz tone randomly usingthe CEM-1023 speaker.
- If the tone is 2100Hz, the first player to press its capacitor sensor wins a point.
- If the tone is 2000Hz, the first player that presses its capacitor sensor looses apoint.
- Use the LCD to display the points for each player.
- The first player to reach 5 points wins the game!
1
Project Evaluation
The evaluation of this project consists of a functional demonstration (worth 25% of the final mark) and a written project report (worth 5% of the final mark). In the project functional demonstration, your project is evaluated using the following criteria:
|
Mark |
The project: |
|
9.0-10 |
Is exceptional, did everything it was supposed to do well plus lots of additional functionality. |
|
7.5-9.0 |
Did everything required, circuitry / project well designed / some additional functionality. |
|
7.5 |
Did everything required. The project lacks originality, innovation, or extra functionality. |
|
7.0-7.5 |
Mostly worked, not entirely, not the greatest design. |
|
6.0-7.0 |
Didn’t really work, ok design but didn’t really come together. |
|
5.0-6.0 |
Didn’t work, not very good design. |
|
0.5-5.0 |
Didn’t work, poor design. (Pile of parts!) |
|
0 |
No project demonstrated. |
The project evaluation will be based on the Canvas submission. Upload a video (or link to the video) of your project showing ALL its functionality. Include with your submission the source code, pictures, data, etc. that you consider relevant for the evaluation of your project. Include also with your submission a “README.TXT” file with any instructions, information, and the name of the team members. Only one submission per team is required.
Team Self Evaluation
Similar to what has been done in previous years and other courses, the team members will determine the final mark distribution. There will be 100 total percentage points available per student. For example, if a group has three students, the total number of percentage points will be 300. The team will assign a portion of these points to each member, and the final individual mark will be computed by multiplying the group mark by this individual percentage. For example:
Project 1 Grade (out of 30%) = 20% (function) + 4% (report) = 24%
If the team is in disagreement about the individual percentage assignments, the individual percentage assignment will be determined by the course instructor and/or TAs by means of interviews and review of submitted work.
|
Student |
Points |
Grade |
|
Liu Kang |
120 |
28.8% |
|
Johnny Cage |
110 |
26.4% |
|
Goro |
70 |
16.8% |
|
TOTAL |
300 |
24% (mean) |
2
Project Report Format
The project report should be written for a reasonably expert reader such as a project manager (an engineer) in a company for whom you might have designed this prototype product. The project report should have sufficient detail that someone skilled in the art could reproduce or improve upon your results. The number of pages for the report should be ≤ 20 (not including the title page and appendices, double spaced, ‘Arial’ or ‘Times New Roman’ font size 12 for text, and ‘Courier New’ font size 8 or 10 for the source code, approximately one inch margin for the top, bottom, left, and right margins) and include the following sections:
1. Title Page – It should include the course name and number, instructor name, section, project name, group number, names and student number of the students in the group, the percentage contribution of every member in the group (with each student signature), and the date of submission. If the front page is missing any of this information, 2% will be deducted from the project report mark.
2. Table of Contents
3. Introduction – Design objective and specifications. Overview of the overall design approach including system block diagrams for both the hardware and software designs.
4. Investigation – This section must include the following subsections:
- Idea Generation – Describe how your group generated ideas and working hypotheses.
- Investigation Design – Describe how you group perform the design investigations involving information and data gathering, analysis, and/or experimentation.
- Data Collection – Describe how your group used appropriate procedures, tools, and techniques to collect and analyze data.
- Data Synthesis – Describe how your group synthesized data and information to reach appropriate conclusions.
- Analysis of Results – Describe how your group appraised the validity of conclusions relative to the degrees of error and limitations of theory and measurement.
5. Design – This section must include the following subsections:
- Use of Process – Describe how your group adapted and applied general design processes, accesses to design systems and components, or processes to solve open-ended complex problems as relevant for this project.
- NeedandConstraintIdentification–Describehowyourgroupidentified customer, user, and enterprise needs, and applicable constraints.
3
C. ProblemSpecification–Describehowyourgroupspecifiedadditionaldesign requirements based on needs and constraints presented in the point above.
- Solution Generation – Briefly describe potential design solutions suited to meet functional specifications. If possible, include even those that didn’t work!
- Solution Evaluation – Perform systematic evaluations of the degree to which several design concept options meet project criteria. Clearly explain why you choose the final design.
- Detailed Design – Explain how you applied appropriate engineering knowledge, judgment, and tools, in creating and analyzing design solutions. This has to be one of biggest parts of the report. In this section you must include the description and evaluation of each block (e.g. “A-stable Circuit”, or “Counter Initialization”): Describe the approach taken to design each block. For circuits, include a detailed circuit diagram and describe how it works. For programs, include the source code in the appendices, and refer to it while you describe it.
- Solution Assessment – Describe how you assessed the design performance based on requirements, needs, and constraints. This section must include an evaluation of the complete system by mean of tests you carried out including plots of performance, reproducibility numbers, tables, etc. as judged appropriate for this project. Describe how each relevant part of your design was tested and the testing results. Also in this section, the strengths and weaknesses of the design must be pointed out.
6. Live-Long Learning – Identify a specific learning need or knowledge gap. For example, did your learn something new by yourself? You didn’t take a course that would have helped with the project? You found that one of the courses you took was particularly useful for the project?
7. Conclusions – Summarize the design and functionality of your project. Summarize also the problems you encounter, and how many hours of work the project took.
8. References – A specific book, paper, datasheet, or website is referred to in the body of the report at the point at which you say something about it, by a numerically-ordered, square-bracketed number, the first one being [1]. Then, at the end of the Report in a section called REFERENCES located just before the Appendices section, the same square-bracketed number is followed by the Author List, Article Title, Journal or Book Title, Volume, Number, Pages, ISBN Number, Publisher, Date of Publication. Although the Reference list can be listed alphabetically by author, instead we do not recommend this for an Engineering Report. With an alphabetical listing, the location in the body where any particular reference is discussed is then hard to find, since the references are no longer in order of appearance. Examples of references are [1] and [2] (note that the numbers in the square brackets here refer to the appropriate numbers in the Reference list). The Reference list itself might look like:
4
REFERENCES
[1] Smith, J, and F. Jones, “Designing an universal logic circuit”, Journal of Impossibly Wonderful Electronic Circuits, v.3, n.1, pp. 21-35, March, 1910. [2] Jones, F and J. Smith, “Why universal logic circuits are impractical” , …
9. Bibliography – Items in a section at the end of a report called BIBLIOGRAPHY are NOT referred to in the body of the report. It is a list of appropriate background or additional reading and is located after the References section and before the Appendices section. The items in the Bibliography are usually ordered by last name of the first author. It is sometimes appropriate to have BOTH a Reference list and a Bibliography list. An example Bibliography looks like:
BIBLIOGRAPHY
• Sedra, A., and K.C. Smith, Microelectronic Circuits, 4th Edition, Oxford University Press, 1998.
1. Appendices – Supporting documents such as extensive theoretical analyses, mechanical drawings, and source code. Your source code should be properly documented and indented. Do not append datasheets, compiler manuals, or other already published material to the report.



