Final Report

The final project report serves two ultimate purposes: to provide an introduction aimed at the general public; and to provide a description of the project and its final results aimed at electrical engineers. The report is not meant to be a description of the adventures taken during project development, rather a description of the final 'product', how it works, and how well it has met the original design objectives. By the end of the report, a reader should be able to understand how the system operates, how well it operated, and what improvements could be made. Given the desire, they should be able to construct the electronic hardware that forms the basis for your project. Write about the project as it stands at the time of writing: a report providing details about fictitious aspects/features/operation of the project will be poorly received. This document is to be no more than 8 pages in length (all items included). Please do not include your ID numbers anywhere in this document. A required document layout is described, below. Please use the following paper structure. This structure is consistent with the IEEE conference paper format, outlined below: Section Description Abstract The purpose of the abstract is to help a reader determine whether they need to read further, or, perhaps, to jog their memory with respect to previously read materials. Write the abstract such that it stands alone. A good abstract will contain not only the most important facts about the paper contents, but also an overview of the 'findings'. In the case of a hardware project description, the 'findings' may range from stating that all design goals are achieved, to an abbreviated list of specifications - the selection of which will depend on the nature of the design project. An abstract is typically very concise (and therefore short) by virtue of its intended use. Introduction The introduction section is used to orient the reader. This section will contain a description of the project that can be understood by almost any reader. Further subsections may be used to provide Background Information that will be relevant to the reader who chooses to read further. Sometimes, however, Background Information may also be found in a dedicated section that forms part of the technical content. The choice of which sectioning method to use is yours. The nature of the Background Information that is contained in the report is project-specific, and, of course, subject to the page limitation. Ensure that you include Background Information that one of your colleagues would require to understand the rest of your paper. Technical Sections The technical section(s) may include Background Information, as described above. You are free to structure the technical section(s) as you see fit, bearing in mind the page limit, and good document flow. The IEEE conference paper format encourages the placement of figures along with the text (although at the top or bottom of the page), and it is strongly suggested that you make use of this when structuring your document. One of the very first figures should be a system block diagram. This figure will fuel the technical discussion. Further detail will eventually be provided in the form of schematics. A full set of schematics is required , although repeated circuitry may be drawn only once and annotated with information relevant to duplication. In order to present the schematics logically and in-text, it will likely be necessary to break larger schematics into smaller, presentable pieces. Note that it is possible to have multi-column figures within the IEEE conference paper format: this may aid formatting. No PCB layouts are required in this document. Describing how the project operates will likely require a description of firmware. Use a figure with a flowchart if you have space. Source code does not need to be included in this document, but you are welcome to include snippets of relevant source to demonstrate key functionality. In order to communicate to the reader that the project works as desired, or to characterize why it does not work as desired, a portion of the technical section(s) should outline tests that are used to evaluate project performance, and the data associated with these tests. Conclusions and Future Directions This section reiterates the important findings of the documents and suggests to the reader how improvements could be made if future development is pursued. It is also sometimes in this section (if not in a technical section) that data found in the technical section is interpreted. References It is in this section that citations, made throughout the paper, are referenced. The course format for references and citations (described elsewhere on the course webpage) is consistent with the IEEE conference paper format. Only references that are cited should appear in this section. Additionally, the following items are to be submitted at the same time as the final report itself:      Electronic Media (see below)      Permission-to-Post form (see below)      Component Form and Reimbursement Request (if reimbursement has been approved) Document Format Papers are to be submitted using the IEEE two-column conference paper format described and demonstrated here: http://www.ieee.org/portal/cms_docs/pubs/confpubcenter/pdfs/samplems.pdf Again, the maximum length of the paper is 8 pages . A sample EE401 final report by Jordan Harrison, Annie Lam, Nelson Young, Jonathan Zacharko (Group 21, 2005-6) is posted here. Please note that report requirements evolve from year-to-year, and this sample of work was written to standards that differ from this year. Electronic Media Electronic media in addition to the PDF version of the final report is required. Please provide the following material in addition to the PDF version of the final report: final schematics (usually an Eagle .sch file); final PCB layout (usually an Eagle .brd file); final source code (.c, .asm, .h, .lnk, and makefiles); component data sheets of "unique" devices; and any other *electronic* documents or applications required to complete the final project. Permission-to-Post Form Photos of groups taken during final presentations and titles of projects are posted on the web in the course's project archives. Eventually, samples of final reports (in addition to that provided, above) will likely be made available. For the benefit of future classes we request permission to post these photos and details about your project. For us to publish your findings to the web, the Final Report needs to be accompanied by a statement from the team members that they consent to having their project information used in this manner. A form serving this purpose will be delivered to each group toward the end of the course. Please return this form even if you are not giving permission. Reimbursement Requests If you received authorization to purchase parts and otherwise qualify for reimbursement, provide a reimbursement request by the due date and time of the final report. The request will consist of an itemized list, original receipts, and, in the case of out-of-country purchases, a credit card statement showing the conversion rate of the purchase into Canadian dollars. See the Project Budget page for more information. Final Report Mark Allocation The grading of the report is carried out in both absolute and relative manners: marks allocated to a given category is absolute, but the marking that occurs within a section is relative to your peers' papers. Category Key Items Looked For Weighting Abstract Overview of project purpose. Findings are outlined. Length is appropriate. 10% Clarity/Readability Introduction is provided at a level understandable by most readers. Consistent verb tense used throughout. Correct grammar. Figures are placed in-text. Figures are readable: non-bitmapped and of appropriate size. Figures are referred to in the text. Figure captions are provided. Page limit is adhered to. 30% Technical Content A block diagram is provided close to the start of the technical documents and is used to drive the discussion. The block diagram is accurate and meaningful. Background information relevant to the project is provided. Schematics are provided: interconnection is simple to follow, part numbers, designators, and values are all provided, etc. Firmware design is related (if applicable, as it is in most cases). Future directions are outlined. 40% References All sources are cited. References are complete. An appropriate number of references are used. Reference sources are reputable. 10% Electronic File Submission/Other Required Documents All requested materials are received. Submission (if in electronic form) is on time. 10% Submission Deadlines and Late Work All parts of the submission are due by 4PM on the date noted in the syllabus. Paper items are to be submitted to the EE401 Lecture assignment submission box outside of the ECE general office, as described below. Please submit a single zip file containing a PDF version of the final report and all electronic materials using the EE Capstone Submission Facility. Submit the Permission to Post form to the EE 401 Course Sumbission box located outside the ECE General Office. Submit Reimbursement Requests (if applicable -- one per group, please) along with original receipts to the EE 401 Course Submission box located outside the ECE General Office. Late submissions will be penalized according to the method outlined in the syllabus. This penalty continues to be applied until all items, outlined above, are received.