$25
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 astable 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 using the 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 a point.
Use the LCD to display the points for each player.
The first player to reach 5 points wins the game!
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.
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:.
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:
REFERENCES
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.
Jones, F and J. Smith, “Why universal logic circuits are impractical” , …
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.
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.