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!

Illini Voyager

Cameron Jones, Christopher Xu

Featured Project

# Illini Voyager

Team Members:

- Christopher Xu (cyx3)

- Cameron Jones (ccj4)

# Problem

Weather balloons are commonly used to collect meteorological data, such as temperature, pressure, humidity, and wind velocity at different layers of the atmosphere. These data are key components of today’s best predictive weather models, and we rely on the constant launch of radiosondes to meet this need. Most weather balloons cannot control their altitude and direction of travel, but if they could, we would be able to collect data from specific regions of the atmosphere, avoid commercial airspaces, increase range and duration of flights by optimizing position relative to weather forecasts, and avoid pollution from constant launches. A long endurance balloon platform also uniquely enables the performance of interesting payloads, such as the detection of high energy particles over the Antarctic, in situ measurements of high-altitude weather phenomena in remote locations, and radiation testing of electronic components. Since nearly all weather balloons flown today lack the control capability to make this possible, we are presented with an interesting engineering challenge with a significant payoff.

# Solution

We aim to solve this problem through the use of an automated venting and ballast system, which can modulate the balloon’s buoyancy to achieve a target altitude. Given accurate GPS positioning and modeling of the jetstream, we can fly at certain altitudes to navigate the winds of the upper atmosphere. The venting will be performed by an actuator fixed to the neck of the balloon, and the ballast drops will consist of small, biodegradable BBs, which pose no threat to anything below the balloon. Similar existing solutions, particularly the Stanford Valbal project, have had significant success with their long endurance launches. We are seeking to improve upon their endurance by increasing longevity from a power consumption and recharging standpoint, implementing a more capable altitude control algorithm which minimizes helium and ballast expenditures, and optimizing mechanisms to increase ballast capacity. With altitude control, the balloon has access to winds going in different directions at different layers in the atmosphere, making it possible to roughly adjust its horizontal trajectory and collect data from multiple regions in one flight.

# Solution Components

## Vent Valve and Cut-down (Mechanical)

A servo actuates a valve that allows helium to exit the balloon, decreasing the lift. The valve must allow enough flow when open to slow the initial ascent of the balloon at the cruising altitude, yet create a tight seal when closed. The same servo will also be able to detach or cut down the balloon in case we need to end the flight early. A parachute will deploy under free fall.

## Ballast Dropper (Mechanical)

A small DC motor spins a wheel to drop [biodegradable BBs](https://www.amazon.com/Force-Premium-Biodegradable-Airsoft-Ammo-20/dp/B08SHJ7LWC/). As the total weight of the system decreases, the balloon will gain altitude. This mechanism must drop BBs at a consistent weight and operate for long durations without jamming or have a method of detecting the jams and running an unjamming sequence.

## Power Subsystem (Electrical)

The entire system will be powered by a few lightweight rechargeable batteries (such as 18650). A battery protection system (such as BQ294x) will have an undervoltage and overvoltage cutoff to ensure safe voltages on the cells during charge and discharge.

## Control Subsystem (Electrical)

An STM32 microcontroller will serve as our flight computer and has the responsibility for commanding actuators, collecting data, and managing communications back to our ground console. We’ll likely use an internal watchdog timer to recover from system faults. On the same board, we’ll have GPS, pressure, temperature, and humidity sensors to determine how to actuate the vent valve or ballast.

## Communication Subsystem (Electrical)

The microcontroller will communicate via serial to the satellite modem (Iridium 9603N), sending small packets back to us on the ground with a minimum frequency of once per hour. There will also be a LED beacon visible up to 5 miles at night to meet regulations. We have read through the FAA part 101 regulations and believe our system meets all requirements to enable a safe, legal, and ethical balloon flight.

## Ground Subsystem (Software)

We will maintain a web server which will receive location reports and other data packets from our balloon while it is in flight. This piece of software will also allow us to schedule commands, respond to error conditions, and adjust the control algorithm while in flight.

# Criterion For Success

We aim to launch the balloon a week before the demo date. At the demo, we will present any data collected from the launch, as well as an identical version of the avionics board showing its functionality. A quantitative goal for the balloon is to survive 24 hours in the air, collect data for that whole period, and report it back via the satellite modem.

![Block diagram](https://i.imgur.com/0yazJTu.png)