Lab Notebook
Video Lecture
 |
Video, Slides |
Description
Keeping a professional lab notebook is a requirement of the course. If maintained properly, lab notebooks serve as an official and legal record of the development of the intellectual property related to your project. It also serves as a way to document and track changes to your design, results of all tests performed, and the effort you have put into your project. A well-kept notebook will simplify writing of all required documentation for this course (design review, final paper, etc) as all of the information in those documents should already exist in your notebook. Finally, keeping a notebook is simply good engineering practice and likely will be required by future employers, so it is a good idea to get in the habit of maintaining one now.
The Book: Any notebook with permanent bindings designed for laboratory record keeping is acceptable. Those with pre-numbered pages are required. Ideally, it should have graph rulings on alternate pages, or else quarter-inch square grid on all pages. We will not accept normal spiral-bound notebooks, as these are not permissible in court since pages can be easily replaced. While most of you probably won't be taking your design to court, we want to teach you to get into the habit of keeping legally acceptable records. Some of you may decide you do want to patent your project, so it will be very beneficial to have given yourself the legal advantage from the start.
We will allow you to keep your notebook on a computer, but entries will still need to be printed out and attached to a physical notebook for weekly meetings. Keep in mind also that it may be easier in the long run to scratch out rough graphs and equations on paper, so try to plan ahead. If you know you'll have a lot of graphs, equations, etc., don't make more work for yourself than you need to. Do NOT email your notebook entries to your TA unless he or she specifically requests that you do so.
Notebook entries: Each complete entry should include:
- Date
- Brief statement of objectives for that session
- Record of what was done
The record will include equations, diagrams, and figures. These should be numbered for reference in the narrative portion of the book. Written entries and equations should appear on the right-hand page of each pair. Drawn figures, diagrams, and photocopies extracted from published sources should be placed on the left-hand side, which is graph-ruled. All separate documents should be permanently attached to the notebook. All hand-written entries must be made in pen.
Overall, the book should contain a record that is clear and complete, so that someone else can follow progress, understand problems, and understand decisions that were made in designing and executing the project.
What to include:
- The main ideas from your project proposal.
- Bibliographic references for any materials that are used as sources. Many of these references will be needed in the written report, later.
- Diagrams, schematic, and/or block diagrams for any hardware which is designed and/or tested. There should be an accompanying discussion explaining the principle design problems and decisions. Proposed tests should be described as well.
- Equations and formulas used in the design process, along with a reference to their sources. If derived by you, sketch enough of the development so that someone can follow the idea from your notes.
- Documentation of the testing and debugging process. This includes notes of what is being checked, test set-up diagrams, and non-routine results. Difficulties should be noted with particular care.
- It is wise to note anything of any conceivable importance when dealing with debugging problems. Test-signal amplitudes, waveforms, frequencies, modulation types and amounts, test connections, meter scale settings and readings, sketches or printouts of waveforms from precisely identified points in the circuit, and power supply values, are examples. Consider everything you would need to know to reproduce your test and results.
- Analysis of, and proposed solutions for, any debugging problems. Include all revisions of diagrams and test setups and any new equations, etc.
- Documentation of the new tests, as before.
- Documentation of final performance tests and design verification.
- Topic outlines for oral and/or written reports can reasonably be included.
There is always something to record:
Suppose you are only "kicking around" design ideas for the project with someone, or scanning library sources. Your objective is what you're hoping to find. The record shows what you found or what you decided and why, even if it isn't final.
One of the most common errors is to fail to record these seemingly "unimportant" activities. Down the road, they may prove crucial in understanding when and where a particular idea came from.