Transcription
Example logbook report for Apsc 1299:The Morse DecoderThis following pages contain an example logbook that a student might have written whileperforming an experiment, called the “Morse Decoder”, where they created code to translateMorse code digits into regular Arabic digits. This example logbook is particularly useful forseeing how to record your work while coding and while troubleshooting code that is notbehaving correctly.Note that you do not need to write your logbook exactly like this one in order to get full marks—there is quite a bit of flexibility in how an engineer can organize and record data in their logbook.However, this example should give you an idea of what level of detail you need to aim for, andwhat kinds of data are important to record.An engineer’s logbook can be used as a legal document to, for example, establish who owns anidea or innovation in the case of a patent dispute. For this reason, your logbook must be writtenin ink, and have each page signed (or initialed) and dated. Graphs may be done in pencil.Computer code should be permanently pasted or stapled into the book.Your logbook also needs to be a complete record of everything you did in the lab, so even yourmistakes and unwanted results should be documented fully. Never remove pages, and neverobscure information from the logbook. If you make a mistake, cross out the error with a singleline (so it can still be read), and write the correction nearby.When you join the work force, you’ll often be called upon to make an estimate on how long a jobwill take, or to bill your clients accurately for the time you spent on their project. For this reason,you’re required to record the current time in your logbook regularly. By getting into this habitnow, you’ll develop a good “feel” for how long certain tasks take, and will always have a recordof exactly how long you worked on a particular project.The annotations in this logbook will point out things an instructor would think the student didwell and things they would feel were lacking. Overall, however, this logbook displays good notetaking skills and would likely receive a very good grade.
Sign and dateevery pageStart a new experiment’swrite-up by recording theexperiment title and all theequipment and computerprograms you’ll use.Record the timeoften.The student takesnotes as she readsthrough themanual’s theory,recording all theimportant information in herlogbook.When she gets tothe tasks, she jotsthem down in pointform. This is aclear way to stateher experimentalobjectives.If you don’t recordthe time at leastonce per page,you’ll lose marks.
Consider puttingthe steps foroften-performedtasks in anappendix of yourlogbook. Thatway, you canrefer to it ratherthan re-writing thesteps.Record yourplans, roughwork, and thoughtprocesses as youprepare for atask.
Think of thelogbook as a realtime diary of yourwork. Recordwhat you do, asyou’re doing it.Notice how thestudent jots downnotes on everything she does,step by step.Here, the studentjots down somepseudo-code aspart of herplanning processfor the project.
Again, this is astep-by-step, realtime diary of whatshe’s doing, asshe does it.Someone couldtake the samecode she startedwith andreproduce herwork using onlythe notes in thislogbook, with nolab manual. Thisis the level ofdetail you shouldbe aiming for.
More diary of herwork, interruptedtwice when shepauses to figureout something.
A common erroris to not recordenough noteswhen things startto go wrong.Notice how thisstudent handlescoding problems:She notes everyerror message,including its codeand warning.Then, as shefigures out whatwent wrong, shenotes what theproblem was andhow to fix it.It’s implied, here,that she made thefixes she noted.This is okay forsimple problems.If a more complexsolution wasrequired, shewould haveneeded to addmore detailsabout what shedid.
Here sheencounters adifferent kind ofproblem: Herproject builtsuccessfully, butthe circuit is notbehaving asintended.She jots downnotes oneverything shedoes to fix theproblem, step bystep. This is thesame level ofdetail she usedwhen shedocumentedcreating her code.
When you’retesting ormeasuringsomething, recordall yourobservations fully.It’s not enough tosay somethingworked or didn’twork. Recordwhat youobserved that ledyou to thatconclusion.
Again, whentesting ormeasuringsomething, recordall yourobservations.
Again, record theobservations thatled you to believethe circuit or codeis working (or notworking) asintended.Always attach your code to your logbook. The level ofdetail you should aim for is that someone couldreproduce the experiment based only on your notes.They would need a copy of your code to do that.Before you print out, however, double-check whether youincluded enough commenting. Comments are one of theeasiest things to forget!
Code should haveenoughcommenting thatsomeone couldunderstand howthe programworks based onlyon the comments.In your opinion,does this codehave enoughcomments?
These were thecomments in theoriginal, suppliedcode.The studentprobably shouldhave changedthem, but sheincluded her owncomments afterher added code,so all thenecessaryinformation ishere.
logbook. When she gets to the tasks, she jots them down in point form. This is a clear way to state her experimental objectives. Record your plans, rough work, and thought processes as you prepare for a task. Consider putting the steps for often-performed tasks in an appendix of your logbook. That way, you can refer to it rather than re-writing the steps. Think of the logbook as a real-time .
