Design Document

Description

The design document communicates the complete and detailed design of your project. It is substantially more detailed than the proposal and prepares you for the assembly phase of the semester. A quality design document is the key to a successful project (sample document). Use the following format:

  1. Introduction

    • Problem and Solution:

      One to two paragraphs explaining the context of the problem to be solved by your project, including any relevant references to justify the existence and/or importance of the problem (i.e., the need or want for a solution). Justify the novelty of your solution or explain the expected improvements of your solution over previous results.

    • Visual Aid

      A pictorial representation of your project that puts your solution in context. Not necessarily restricted to your design. Include other external systems relevant to your project (e.g. if your solution connects to a phone via Bluetooth, draw a dotted line between your device and the phone). Note that this is not a block diagram and should explain how the solution is used, not a breakdown of inner components.

    • High-level requirements list:

      A list of three to four objective characteristics that this project must exhibit in order to solve the problem. These should be selected such that if any of these requirements were not met, the project would fail to solve the problem. Avoid vague requirements that can be interpreted a number of ways (e.g. "The radio subsystem should work reliably."). Each high-level requirement must be stated in complete sentences and displayed as a bulleted list.

  2. Design

    • Block Diagram:

      A general block diagram of the design of your solution. Each block should be as modular as possible and represent a subsystem of your design. In other words, they can be implemented independently and re-assembled later. The block diagram should be accompanied by a brief (1 paragraph) description of the critical subsystems and what they do.

    • Physical Design (if applicable):

      A physical diagram of the project indicating things such as mechanical dimensions or placement of sensors and actuators. The physical diagram should also be accompanied by a brief one paragraph description.

    • [Subsystem X]

      For each subsystem in your block diagram, you should include a highly detailed and quantitative block description. Each description must include a statement indicating how the block contributes to the overall design dictated by the high-level requirements. Any and all design decisions must be clearly justified. Any interfaces with other blocks must be defined clearly and quantitatively.

      Include any relevant supporting figures and data in order to clearly illustrate and justify the design. Typically a well justified block design will include some or all of the following items: Circuit schematics, simulations, calculations, measurements, flow charts, mechanical diagrams (e.g. CAD drawings, only necessary for mechanical components).

      You must include a Requirements and Verifications table. Please see the R&V page for guidance on writing requirements and verification procedures.

    • [Subsystem Y]

      ...

    • [Subsystem Z]

      ...

    • Tolerance Analysis: Through discussions with your TA, identify the block or interface critical to the success of your project that poses the most challenging requirement. Analyze it mathematically and show that it can be feasibly implemented and meet its requirements. See the Tolerance Analysis guide for further guidance.
  3. Cost and Schedule

    1. Cost Analysis: Include a cost analysis of the project by following the outline below. Include a list of any non-standard parts, lab equipment, shop services, etc., which will be needed with an estimated cost for each.
      • Labor: (For each partner in the project)
        Assume a reasonable salary
        ($/hour) x 2.5 x hours to complete = TOTAL
        Then total labor for all partners. It's a good idea to do some research into what a graduate from ECE at Illinois might typically make.
      • Parts: Include a table listing all parts (description, manufacturer, part #, quantity and cost) and quoted machine shop labor hours that will be needed to complete the project.
      • Sum of costs into a grand total
    2. Schedule:

      Include a time-table showing when each step in the expected sequence of design and construction work will be completed (general, by week), and how the tasks will be shared between the team members. (i.e. Select architecture, Design this, Design that, Buy parts, Assemble this, Assemble that, Prepare mock-up, Integrate prototype, Refine prototype, Test integrated system).

  4. Discussion of Ethics and Safety:

    1. Expand upon the ethical and safety issues raised in your proposal to ensure they are comprehensive. Add any ethical and safety concerns that arose since your proposal.
    2. Document procedures to mitigate the safety concerns of your project. For example, include a lab safety document for batteries, human/animal interfaces, aerial devices, high-power, chemicals, etc. Justify that your design decisions sufficiently protect both users and developers from unsafe conditions caused by your project.
      Projects dealing with flying vehicles, high voltage, or other high risk factors, will be required to produce a Safety Manual and demonstrate compliance with the safety manual at the time of demo.
  5. Citations:

    Any material obtained from websites, books, journal articles, or other sources not originally generated by the project team must be appropriately attributed with properly cited sources in a standardized style such as IEEE, ACM, APA, or MLA.

Submission and Deadlines

Your design review document should be uploaded to PACE in PDF format by the deadline shown on the course calendar . If you have uploaded a mock DR document to PACE, please make sure that it has been removed before DR.

Master Bus Processor

Clay Kaiser, Philip Macias, Richard Mannion

Master Bus Processor

Featured Project

General Description

We will design a Master Bus Processor (MBP) for music production in home studios. The MBP will use a hybrid analog/digital approach to provide both the desirable non-linearities of analog processing and the flexibility of digital control. Our design will be less costly than other audio bus processors so that it is more accessible to our target market of home studio owners. The MBP will be unique in its low cost as well as in its incorporation of a digital hardware control system. This allows for more flexibility and more intuitive controls when compared to other products on the market.

Design Proposal

Our design would contain a core functionality with scalability in added functionality. It would be designed to fit in a 2U rack mount enclosure with distinct boards for digital and analog circuits to allow for easier unit testings and account for digital/analog interference.

The audio processing signal chain would be composed of analog processing 'blocks’--like steps in the signal chain.

The basic analog blocks we would integrate are:

Compressor/limiter modes

EQ with shelf/bell modes

Saturation with symmetrical/asymmetrical modes

Each block’s multiple modes would be controlled by a digital circuit to allow for intuitive mode selection.

The digital circuit will be responsible for:

Mode selection

Analog block sequence

DSP feedback and monitoring of each analog block (REACH GOAL)

The digital circuit will entail a series of buttons to allow the user to easily select which analog block to control and another button to allow the user to scroll between different modes and presets. Another button will allow the user to control sequence of the analog blocks. An LCD display will be used to give the user feedback of the current state of the system when scrolling and selecting particular modes.

Reach Goals

added DSP functionality such as monitoring of the analog functions

Replace Arduino boards for DSP with custom digital control boards using ATmega328 microcontrollers (same as arduino board)

Rack mounted enclosure/marketable design

System Verification

We will qualify the success of the project by how closely its processing performance matches the design intent. Since audio 'quality’ can be highly subjective, we will rely on objective metrics such as Gain Reduction (GR [dB]), Total Harmonic Distortion (THD [%]), and Noise [V] to qualify the analog processing blocks. The digital controls will be qualified by their ability to actuate the correct analog blocks consistently without causing disruptions to the signal chain or interference. Additionally, the hardware user interface will be qualified by ease of use and intuitiveness.

Project Videos