Writing IP-1 Reports

General Writing Principles¶

Also see the Reporting Guidelines in Project Skills

Academic Approach¶

• Verifiable conclusions: All conclusions must be supported by adequate theoretical and/or experimental results.

• Clear purpose: Each report should inform readers about your findings, analysis, and design choices in a way they can understand and appreciate.

• Focused content: All material should contribute to the report’s purpose - no more, no less.

• Reader service: Help readers understand your message by discussing and interpreting results, placing them in context, and explaining notable information.

Content Quality Standards¶

• Quantitative over qualitative: Refer to clear numeric values and indicate their meaning.

• Equations over text: Describe operation and performance via equations when possible.

• Complete documentation: Provide sufficient detail for result verification, including assumptions, procedures, methods, and equipment.

• Result interpretation: Discuss, interpret, and contextualize all results (measurements, simulations, experiments).

• Proper citations: Correctly cite other work, ensure ideas are traceable, avoid plagiarism.

Layout and Formatting Standards¶

• Professional appearance: Sober, business-like style with appropriate fonts, margins, and spacing. The report should look groomed, but not particularly fancy.

• Numbered equations: Reference as Eq. (number) or (number).

• Proper captions: Include captions below figures and above tables. Include references to the figures and tables in the text.

• Clear graphics: Legible axes, labels, units, and legends; avoid low-quality bitmapped images.

• Consistent notation: All symbols clearly defined and unambiguous.

Standard Report Structure¶

All reports should contain:

1. Introduction A good introduction answers four key questions:

   • What is the system/problem?
     Give a brief description of the engineering task or objective.

   • Why does it matter?
     Provide context—real-world relevance, project motivation, or course topic.

   • What are the requirements?
     State constraints, performance targets, or functional specifications.

   • What will the reader find in this report?
     A short roadmap of the structure of the document.

   Goal: Let the reader understand what you are doing and why before seeing how you do it.

2. Main Body

   • Background & Theory: Optional but often useful

   • Design Methodology: General description of design procedure

   • Simulation / Modeling: If applicable, tools, procedures, results, and comparisons

   • Assembly / Implementation / Realization: Component choices and deviations

   • Measurements / Testing / Validation: Procedures, results, and comparisons

3. Discussion and Analysis

   • Interpretation of results and their significance

   • Comparison between theoretical predictions, simulations, and measurements

   • Analysis of discrepancies and potential sources of error

   • Technical limitations and constraints encountered

4. Conclusions and Recommendations

   • Short summary table of analytical, simulated, and measured results

   • Extent to which requirements were met

   • Strategies for improvement (technical focus)

5. References

   • IEEE citation style is preferred

   • Citations for why, what and how to cite

   • IEEE Citation Style for citation formatting style

6. Appendices
   A place for extended or supporting material that would be distractive in the main text. Main rules:

   • The body of the report must be self-contained and can be read and understood without needing the appendix.

   • All essential information stays in the body; all supporting material goes in the appendix (see Examples).

   • Appendices can offer additional insight for readers who want to dive deeper.

   • All appendices must be referenced in the main text at the relevant location.

   • All appendices have a short introduction that clarifies their purpose and content.

   • Appendices must be labeled sequentially using capital letters (like “Appendix A: Speaker Measurements”) and listed in the Table of Contents.

   Examples of Appendix Material

   • Long calculations

   • Additional plots

   • Simulation source files

   • Raw data tables

   • Code listings

Formatting Engineering Equations, Quantities and Symbols¶

Clear and consistent formatting of engineering equations and quantities is essential for professional technical writing.

Basic Rules¶

Always include a unit: Every physical quantity must have a unit (e.g., “10 kΩ”, not “10”).

Space between value and unit: Write “10 kΩ”, not “10kΩ”.

Use SI units and prefixes: Express quantities in convenient ranges (0.1 to 1000) using standard SI prefixes combined with the unit, like kΩ and pF.

Capitalize correctly:

• Unit symbols from person names are capitalized (V, A, Ω, Hz, W)

• Other units are lowercase (m, s, kg, cd, mol)

• Prefixes ≥ 10⁶ are capitalized (M, G); < 10⁶ are lowercase (m, k, µ)

• Example: “10 kΩ” (not “10 KΩ” or “10 kω”)

Values and Units¶

In text: “The resistor has a value of 47 kΩ.”

Equations: Show units explicitly. Two common approaches:

• Units throughout: $R$ = $V / I$ = (10 V) / (0.5 A) = 20 Ω

• Units only for result: $R$ = 10 / 0.5 = 20 Ω (where V = 10 V and I = 0.5 A are defined in text, see below)

Both approaches are acceptable; choose one and use it consistently throughout your report.

Tables/Figures: Include units in headers: “Resistance [Ω]” or “Frequency / Hz”

Defining Symbols¶

All symbols must be defined before use. Define symbols in these locations:

1. In the text (preferred for common symbols): “Let R denote the resistance in Ohms. The power dissipation is P = V² / R...”

2. Using the “where” clause approach: Equations can be followed by a “where” clause that defines all symbols:

where P is power (W), V is voltage (V), and R is resistance (Ω).

While not strictly before use, this approach is efficient for single equations or when symbols are used only locally. It keeps definitions close to the equation while maintaining readability.

3. In a legend or caption (for figures and diagrams): “Figure 1: Circuit diagram where R₁ = 10 kΩ, C₁ = 100 µF, and U = supply voltage.”

4. In a separate “Notation” or “Nomenclature” section: For complex documents with many symbols, create a dedicated section at the beginning or end listing all symbols, units, and brief descriptions.

Best practice: Define symbols where they first appear. Avoid leaving readers guessing what a symbol represents.

Roman vs Italic in Equations¶

Mathematical variables and symbols follow standard typographic conventions:

Italic (slanted): Mathematical variables and unknowns

• Variables: V, v(t), R, t, f

Roman (upright): Units, functions, and constants

• Units: Ω, V, A (or written as Ohm, Volt, Ampere)

• sin, cos, log, exp (trigonometric and logarithmic functions)

• Physical and mathematical constants: e (italic), π (roman pi symbol)

Example: Correct: R = 10 Ω (variable in italic, unit in roman) Incorrect: R = 10 Ω (unit should not be italic)

Most equation editors (LaTeX, MathType) apply these conventions automatically, but verify your formatting when using plain text or manual formatting.

Referencing Equations and Cross-References¶

When referring to numbered equations, figures, tables, sections and other numbered items, always capitalize the reference label. When referring to them without the number, don’t capitalize.

• Correct: ... and Equation 5 shows...", “From Figure 3, the topology is...”

• Incorrect: “equation 5”, “figure 3”, “table 2”, “section 3.2” (lowercase)

• Correct: ... the figure below shows...

• Incorrect: ... the next two Equations show...

Best practice: Use cross-reference commands in LaTeX (\eqref{}, \ref{}, \label{}) to ensure consistency and automatic updates when content is reordered.

Quick Checklist¶

• Every quantity has a unit

• Space between value and unit (10 kΩ, not 10kΩ)

• SI prefixes used (avoid 0.001 A; use 1 mA)

• Correct capitalization (“see Figure x ...”, 10 kΩ, 5 MHz, not 10 KΩ or 5 mHz)

• Consistent notation throughout document