Lab GuideLab sections meet once a week for three hours, in Packard 130 (off the main atrium, across from Bytes Café). PrelabsThese are important. See our prelabs guide for more information. ReportsLab reports are due at the beginning of your lab section the following week. The exact deliverables for each report will vary with individual labs: check the lab handouts for details. In general, we will ask you to submit answers to questions in the handout, your Arduino code (if applicable) and some reflection comments on the lab. Lab partnersYou will work with a partner for each project. You can choose whether to make a copy of the project each (so that you can each keep one) or whether to make one between the two of you. In either case, you should submit a single joint lab report. You'll have a different partner for each of the four projects. SafetyWe don't work with any voltages high enough to shock you, but there are still hazards other than electrical ones. You should take common-sense precautions.
CleanupWith 140 people the labs carry a lot of traffic. Messy benches slow everyone down and quickly spiral out of control, so it's crucial that everyone plays their part in keeping our work environment tidy. Accordingly, your workbench must be clean when you leave. Here's a checklist of things that must be true before you go:
How long do they take?Our experience is that it can sometimes be a tight squeeze to finish the labs within 3 hours. If you don't finish within your section time:
ReschedulingIf you can't make your regular lab time, you must choose another section to attend and let both your TA and the TA of the other section know in advance. Your prelab is due 24 hours before your usual section, or 24 hours before the section you attend that week, whichever is the earlier. Your lab report is due before your usual lab section the following week. GradingMost projects comprise the prelab, in-lab component, style and a reflection. The weight given to each varies from lab to lab, based on the nature of the lab. StyleReal software and hardware projects often have a lifetime longer than just the first use. They often have to be modified, debugged, upgraded after they have been “completed”. As a result, good hardware and software designs need be more than something that just correctly functions; they also have to be built such that someone else (or you 6 months later) can understand what is going on. Also, since hardware exists in the “real world” how you build something will determine how robust it will be. As a result, your labs are graded “style” — the quality of the work you do — and not just on function. Each project will have a style rubric to give you a sense of what constitutes “good” and “not so good” for each project. We don't expect perfection (if you could do everything perfectly, you wouldn't belong in this class!), but we do want you to be aware of what good style is, and we want to help you develop skills to achieve it. ReflectionReflections are intended before for you to evaluate your own learning and to provide feedback to the teaching staff. We expect 2–4 sentences for each question that shows you've thought about the question and reflected on what you learned. Please be honest and upfront in your reflections. We discuss the feedback you write in your reflections in our weekly TAs meeting in order to improve our teaching practices. We grade reflections to reflect the importance we give to them. You can find examples of good and not-so-good reflections in this document. |