Some of my labs only require informal reports. Such reports generally consist of a commented listing of any software you developed along with a brief discussion of what you observed in the lab and the answers to any questions that are asked in the lab handout. If you are working with a partner you only need to hand in a single copy of the software, but each of you should write separate reports with your own discussion and your own answers to the questions.
Some of my labs require formal reports. The labs that require such reports will be announced ahead of time so that you can take that requirement into account while you are doing the lab. In this document I will describe in general terms what I'm looking for in my formal reports. This document applies to all my lab courses and so it may contain sections that are not relevant for a particular course. In addition, there may be other course-specific requirements for the reports that I will describe in the materials or lectures for that course.
Here are some points that I will look for in your reports. The points listed below are in no particular order.
A lab report does not need to be long. In fact, a short report that is concise (while still being complete) is better than a long winded attempt to sling BS. You should also realize that you can still get a good grade even if your results are poor. While good results help, I really want you to demonstrate an understanding of what is happening. If you do a good job of explaining why your results are bad, then your grade will reflect that.
Each report should either have an objective and a conclusion, or have an abstract. I generally require one or the other depending on the course. Otherwise, the precise sections required will depend on the particulars of the lab. In some cases I will let you decide on the sections. In other cases I may provide specific requirements.
For example, you may want to have the raw data, processed data, and discussion in separate sections. If your lab involves software, a section that describes the design and structure of that software would be appropriate. If there are questions to answer, then you could put the questions in a separate section. Often you do not need to have a "Procedure" section. The lab handout describes the procedure; there is no need to copy that. It may be appropriate, in some cases, to include the lab handout as an appendix of your report.
Schematics, graphs, program listings, and tables are all great but they do not stand alone. You must have a supporting thread of English text that starts at the beginning of your report and runs continuously to the end. For example, don't just plunk down a schematic followed by a table of data and expect me to know what it all means. Instead say
We constructed the circuit shown in Figure 1 and measured the voltage at the point A for various frequencies. The results are in Table 1.
Now you can plunk down your schematic and your table. After the table, the thread of discussion picks up again
We calculated load current using <formula here> for each frequency. The calculated results, along with the percent error from the measurements are in Table 2.
Then the table appears and the thread of discussion continues afterward. Remember: You are writing a report, not submitting lab notes!.
The conclusion should answer the objective. I should be able to read the objective, skip directly to the conclusion, and have it all make sense. In general, the objective raises a question and the conclusion answers it. For example
Objective: To measure the voltage gain, current gain, input impedance, and output impedance of a single stage transistor amplifier and compare the results with the theory.
Conclusion: The voltage and current gain measurements agreed with the theoretical results to within acceptable error. The impedance measurements did not agree with the theoretical results due to an error in our measuring technique.
Here is an example with software orientation
Objective: To build a TFTP client program that can retrieve a named file from a TFTP server and to measure the performance of the client program.
Conclusion: We successfully built a TFTP client program that can retrieve files from a TFTP server. Our program was capable of sustained transfer rates in the range of 250 KiB/s on a 10 Mb/s Ethernet. We believe the performance bottleneck in our case was due to the transit time over the local network and the stop and wait nature of the TFTP protocol.
Leave the discussion for the discussion section. Don't discuss in your conclusion. Instead get to the point as quickly as possible. Also don't make vague statements in your conclusion such as, "we learned a lot from this lab." While I certainly hope you do learn a lot from the labs, a formal report is not the place for personal statements of this nature.
If you write an abstract instead of separate Objective and Conclusion sections, your abstract should contain the information that would normally appear in both the objective and the conclusion.
Please take some pride in your work and submit a neat report. You should definitely use a document processing system of some kind to prepare your report. In many cases I require the use of LaTeX. Do not submit a handwritten formal report. However, using a word processor or other similar tool may not be enough. Be sure there are reasonable margins in your printout, that your fonts are appropriate, that your tables are uncluttered, and so forth. Imagine showing your report to a potential employer (you might want to actually do this) and prepare it accordingly.
Graphs take time to do right. Be sure that both axii are appropriately scaled and labeled. Be sure the graph has a title. Be sure the data points are clearly indicated. Avoid drawing a line through all of the raw data points! In general experimental results include some noise; the true values are some kind of average of your measurements and your line should reflect that. This point is of particular significance if you use a program to produce your graphs. Some programs have a bad attitude about drawing lines that touch each point.
Your graphs should be large enough and clear enough so that a reader can extract real, useful information from them. Good graphs show more than vague trends. They convey data as surely as a table does. Avoid fancy 3D or color effects. Make sure the data fills the graph's area. Make sure the actual data values are clear (particularly if they are obscured by the line). Make sure there are grid lines or sufficient tick marks on the axii to allow the reading of two significant figures from the graph.
Be sure that program listings are clear and readable. Don't let long lines wrap or get truncated. Use a constant width font. Leave enough spaces for margins. Be sure each file has an appropriate header at the top that specifies the file's name, your name, an appropriate date, and a brief description of the file's contents. These rules may impact how you write your programs (you need to be careful about long lines).
In a formal report you should avoid including long listings except, perhaps (and only when really necessary), as an appendix. In the report you should instead extract the relevant parts of your program into figures. The parts to display should be the critical parts of your code or parts that otherwise illustrate the main features and points of the lab. Displayed listings in the report should ideally not exceed half the page in length and should never be longer than a full page.
Although your reports will contain schematics, tables of data, and graphs, they are first and foremost written documents. It is the English text that makes the report something more than just a random collection of lab notes. Make an effort to write that text as well as you can. Although I will not specifically look for grammatical and spelling errors, if I notice them I may reduce your grade because of them---especially if they are glaring. Be aware that there are numerous campus resources to assist you with your writing. Let me know if you would like some references.
The passive voice is common in technical writing. I don't approve of it and strongly suggest that you avoid using it. You can recognize the passive voice because people use it whenever they are trying to avoid taking responsibility for something. For example:
The following circuit was constructed.
Just who constructed the circuit anyway? You can't tell. It sounds almost like you walked into the lab and the circuit was already constructed, perhaps by gnomes. That's the passive voice in action. Instead write the sentence like this
We constructed the following circuit.
If you did it, then say so. Take responsibility for your actions. If you are working alone, say, "I constructed the following circuit."
The lab handout that describes what you are to do in the lab will most likely be written in the present tense. This is because the handout is really a set of instructions. However, in your report you are describing what you did in the lab. Do not use the present tense in your report! Some students have a habit of just copying phrases out of the lab handout into their reports. If you do that, your report will be in the wrong tense and it will sound silly. Your grade may suffer.
Be sure you write your own reports. Naturally you will have the same data as your lab partner, but you should not copy your partner's words into your report as if they were your own. I consider that cheating. If you use a program to prepare your graphs, please run the program yourself to prepare your own version of the graphs. Do not simply copy your partner's files.
Do I have to use a word processor?
Yes. In today's world you should be fluent in some sort of document processing system. In many of my labs I require the use of LaTeX.
Do I have to include a procedure section?
Maybe. Normally I already know the procedure because I have a copy of the handout. I want your results, discussion, and conclusion, not a recap of information I already have. However, you will probably have to say something about the procedure in order for your report to hang together logically. Also if you had to deviate from the documented procedure you should talk about that. Finally in some of my labs, particularly in the more advanced courses, I intentionally leave the procedure partially unspecified so that you have to think about what steps are appropriate. In that case you will definitely need a procedure section in your report to explain what you eventually did.
Should I attach a copy of the lab handout to the report?
I don't require it, but it is not a bad idea to attach the lab handout to your report if you submit a paper copy of the report. That way you have all the materials for the lab together when you later want to refer to the lab. If you do attach the handout to your report, attach it the end of the report as if it was an appendix. Do not attach your report to the end of the handout!
Can I submit my report to you electronically?
Yes! I prefer materials submitted electronically. In some cases I will not only want you to submit your report but also your complete software so that I can test it. See my submission of materials page for more information.
Should I talk about problems we encountered?
Only if your results are bad. If you have good results, I don't want to know about all the bad scope probes or blown chips you went through to get them. However, if your results are bad, it would be nice if you could account for the bad results somehow.
When are the labs due?
The labs are due one week after the scheduled lab period.
How much are the labs worth?
It varies. Some labs are only worth 10 points, others might be worth 30, 40, or even more points. A typical lab is worth 20 points, similar to a homework assignment. In general labs requiring formal reports or that require multiple weeks to do are worth more than labs requiring only informal reports or informal demonstrations.
Do you give lab quizzes?
No. I don't give lab quizzes. However you should expect to see specific questions about the labs on homework assignments and, especially, on exams.
What is your policy regarding late labs?
I describe my late policy in the introductory document I hand out for each course. Please consult that document for the details. My policy sometimes varies from course to course so I can't put information about it into a general document such as this that would be applicable to all courses.