Design Document Check

updated Fa 2020

Description

The Design Document Check (DDC) is intended to aid your team as it prepares its Design Document. The DDC focuses narrowly upon providing feedback on the preparation of historically problematic Design Document elements. If these elements fall short during your Design Review the following week, precious time is lost.

What are the course staff looking for? i) Evidence that the overall idea of the design is sound; ii) A check of a small subset of required components indicates that the project is on the right track.

Below is a checklist of things to have ready for the design document check. Refer to the design document page and grading rubric for a full description of each item.
  1. Introduction
    1. Start with a brief summary (30 sec) or elevator pitch following this template:

      I will build ___A___ (my core product) for ___B___ (my core customer: the person who pays my company or uses the product).

      My customer has a problem ___C___ (describe the problem your customer has)

      My product solves my customer’s problem by ___D___ (how do you solve the problem?)

    2. Be expected to explain further what the problem is, what’s your idea to solve it, and why your idea is novel.
  2. Visual Aid
  3. High-level Requirements
    1. HL requirements are derived from the problem you are trying to solve (put yourself into the customer's shoes). HL requirements should be the essential features that your customers/users really care about. These features distinguish your product from others (e.g. ones available in the market or previous 445 designs). Be abstract (no tech details, you may come up with different design due to other constraints but still solve this problem), quantifiable (no words like continuously, accurately, etc), and unambiguous. HL&RV slides(P.5) has a good example.
    2. We will look at your HL requirements and check if they are what your customers/users really care about. Be prepared to defend your requirements, so that when you get challenged, you can give a well thought out explanation.
  4. Block Diagram
    1. Block Diagram slides
    2. We will check whether this design appears to solve your problem. 
    3. We will check if formatting is clear (lines, legends, etc). Extra caution is needed as students often make mistakes here (but you shouldn't!).
  5. Requirements & Verification Tables
    1. HL&RV slides: from P. 1-17
    2. Block Module Requirements: Break down your HL requirements into block level requirements. These are the requirements in the RV table (they are not the specs of the parts you have chosen).
    3. Verification: A step-by-step approach allows another 445 student to test if the BL requirement is satisfied. This is like an instruction for your module's unit test (with some surrounding dummy modules, a.k.a, mock object(s)
    4. We will review one piece of it. Show us an important one.
  6. Plots
  7. Circuit Schematics
  8. Tolerance Analysis
    1. Identify an important part that you need to perform some quantitative analysis on. This part should have quantitative values critical to the design and require you do calculations and make trade-offs in order to achieve your best design.
    2. Common mistake: Many students do calculations for tangential parts to pad the space.
  9. Safety & Ethics
  10. Citations

During the DDC, your team will have 5-8 minutes to present an example of each of these elements. Expect to share the 30-minute DDC session with two other design teams. Come prepared to learn from their work - both the good and bad.

Your task is to prepare and upload the above elements in a single PDF document to the course website. During your DDC session, you will present directly from your submission, which will be projected for all to see.

The focus of the DDC is not on the details of your design but rather on the details of your formatting; the design of your project will be covered in-depth during the Design Review. Organize your submission in accordance with the Design Document guidance and the example Design Document.

The course staff will focus on providing feedback on the format of your sample DDC elements - the very limited available time will not afford detailed feedback on your design. Please go to office hours for further guidance.

Requirements and Grading

Upload your DDC submission to your project page on PACE (i.e. ECE 445 web board) before arriving at your DDC session.

As in your Design Document, number pages after the title page in your DDC submission.

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.

The course staff at the DDC will assign individual grades to each student based on:

Submission and Deadlines

Sign-up for the Design Document Check on the ECE 445 course website - specifically at the Sign up for Team Presentation item on the PACE tab. Sign-up will open the Monday one week prior to the DDCs.

Upload your DDC submission (.pdf format) to the ECE 445 course website before your DDC session - specifically at the My Project item on the PACE tab.

While you will not complete peer reviews during the DDC, you are expected to actively contribute to the discussion.

Tech must-know and FAQ for design

Here is the link of "Tech must-know and FAQ for design" which is accessible after logging into g.illinois.edu.

Over semesters, ECE445 course staff have encountered repeated mistakes from students. The document above is designed to provide students with the essential knowledge needed in order to have a good design. Spending 5 min reading it might save you 15 hours later. Also, there might be some quiz questions in your DDC or Design Review. Please help us improve this document. We value your feedback!

Coffee Bean Freshness Tracker (CO2ffee)

Nathan Colunga, Joshua Meier, Abrar Murtaza

Coffee Bean Freshness Tracker (CO2ffee)

Featured Project

Team Members:

- Joshua Meier (joshua51)

- Abrar Murtaza (abraram2)

- Nathan Colunga (colunga4)

# Problem

Many coffee connoisseurs care about using freshly roasted beans, as it gives you the best coffee and depth of flavor! However, when you buy coffee from a roastery, they only give you an estimated date for when you should use them (typically within a month). This means those picky with their coffee quality don’t know exactly when their beans are no longer considered “fresh”. To solve this issue, we want to make a custom coffee container that detects how fresh beans are and tells the user when they need to replace their beans. This way, the user can always make sure they are using fresh beans to get good coffee!

# Solution

For our design, we plan to create a container to track the amount of CO2 remaining in the coffee beans as this directly correlates with the freshness of coffee beans. This is based on the weight of beans that were added as well as the detected concentration of CO2 that builds up in the container over time. This would work by when the beans are first added to the container the user would add them and utilize a mobile interface to indicate new beans were entered and specify the type. The container would then detect the weight of beans that were added and the original concentration of CO2 in the container which should be approximately 420 ppm (atmospheric). Every hour from then on the container would update the current CO2 concentration and utilize that as well as the calculated volume of the container and mass of the beans when first put into the container. The system will calculate the milligram of CO2 that was released per gram of beans. Using this calculated CO2 release and comparing it to the type of beans that were added to the container which would be inputted by the user, the system will calculate the approximate percentage of CO2 remaining in the beans at any given time. For reference, we plan to utilize the data collected in this study to determine the approximate CO2 content of each type of roast: https://pubs.acs.org/doi/10.1021/acs.jafc.7b03310. It is also worth noting that we will be assuming that 100% of the CO2 is still contained in the beans upon being placed in the container. We will be assuming this because the expected use case is beans will be added almost immediately after being bought making the time since the roasting is extremely short and the escaped CO2 negligible.

# Solution Components

## Subsystem 1 - Peripheral Devices (i.e. Sensors, Inputs, and Motors)

There will be three main sensors integrated into this subsystem. The weight sensor determines the amount of beans in the container by mass which will be used to calculate the carbon dioxide released per gram. The carbon dioxide sensor which determines the ppm of the carbon dioxide in the closed container is also used in the CO2 per gram calculation. There will also be a button to open and close the container as well as a motor that will be used to rotate the lid on a hinge to open and close it. The motor will also be engaged every time the concentration builds up too much so that the CO2 sensor is not overwhelmed by the concentration of CO2 within the container. For the CO2 sensor, we will most likely be using the Infineon PASCO2V15 sensor as it supports I2C and has a fairly reasonable CO2 concentration range. The weight sensor would most likely be made up of a few load cells and connected to the microcontroller via an HX711. For the motor, we plan to utilize the Miuzei Waterproof Servo Motor because of its small design and price.

## Subsystem 2 - Microcontroller

This subsystem consists of most likely an ESP32-WROOM-32E-H4 microcontroller with wireless communication capabilities and I2C for peripheral device connections. The microcontroller will read data from the CO2 and weight sensors to perform calculations for the percentage of CO2 remaining in the coffee beans. Based on this measurement, data will be output to the mobile interface via a wireless connection module, reporting as the freshness report of the coffee beans. The push button input and motor outputs are also connected, so on each press, the microcontroller can send data to the motor to begin opening or closing the lid, alternating.

## Subsystem 3 - Wireless Connection Module and Mobile Interface

The wireless connection module is built into the ESP32 microcontroller and this will allow data communication between the mobile interface and microcontroller. On this mobile interface, there will be an input to indicate which type of coffee beans have been entered into the container. Based on this input, our system will be able to estimate the initial amount of CO2 stored in the beans. Through the mobile interface, the freshness of the beans will be reported as the approximate percentage of CO2 remaining in the beans.

## Subsystem 4 - Power System

For power, we plan to utilize a couple of rechargeable batteries along with a power controller board. The power controller board will manage the power being taken in from a USB port to recharge the batteries and also manage the output power to all sensors and the microcontroller. We will most likely utilize double A rechargeable batteries and design our own power board in this subsystem.

## Materials

Most of the body will be made using 3D-printed PLA material with the coffee itself contained in a metal bin that can be removed. To create air-tight seals on the container the lid will be fitted with silicone edges to decrease gas escaping.

# Criterion For Success

There are a few goals we will try to meet for this project:

- Able to create a wireless connection to a phone for the user interface

- Able to create a rechargeable battery system that correctly powers the rest of the system

- A reasonably accurate measure of the CO2 lost by the beans while in the container which can be cross checked with manual measurements of weight

- Have the ability to adapt the calculation to various bean roast types that are inputted by the user

Project Videos