Project

# Title Team Members TA Documents Sponsor
25 Gas Stove Safety Alarm
Derek Cernek
Jared Trupp
Joey Sun
Bonhyun Ku appendix1.zip
design_document1.pdf
final_paper1.pdf
other1.sch
other2.kicad_pcb
other3.sch
other4.kicad_pcb
other5.sch
other6.kicad_pcb
other7.ino
photo1.JPG
presentation1.pdf
proposal1.pdf
video
video
Update for proper re-submission rather than just a comment. Not sure if comments don't count or not.

Student 1: Joey Sun (joeysun2) - Remote

Student 2: Derek Cernek (dcernek2) - In Person

Student 3: Jared Trupp (jaredt2) - In Person

**Title:** Gas Stove Safety Alarm

Idea Post Link: [https://courses.engr.illinois.edu/ece445/pace/view-topic.asp?id=65901](https://courses.engr.illinois.edu/ece445/pace/view-topic.asp?id=65901)

**Problem:** Every year, 172,900 homes burn down due to cooking-related fires. Sadly, as statistically shown, the leading cause is human negligence, or in other words, an unattended stove. Additionally, sometimes due to human negligence, pots boil over on the stove, putting the fire out and causing a dangerous gas leak. While many products have been made for electric stove safety, very few have been made for gas stoves, and the existing products require professional installation or risk gas leaking.

**Solution:** We believe the problem to be highly preventable and as such, we found the need to create a simple, easy-to-use device that could be used to help remind the user of a lit stove. The device, meant to be put near the stove, focuses on three things:

1. Is the stove on? If it is, the user will be reminded via a short, but punctual alarm beep that reminds the user.
2. Is the user nearby? If not, the user will immediately receive a more urgent alarm. This alarm also serves as a reminder. We can then use a smaller device kept on the user to deliver this alarm.
3. Is the fire still on? If not, the user will receive a very urgent alarm that the fire is out and gas may be leaking. This alarm is the only one that cannot be delayed, and will not stop until the fire is re-lit or the stove is turned off.

To accomplish this task, we need the following subsystems:

- Power Input
- Stove Knob Sensor
- Fire Detector
- Main Alarm
- User Distance Sensor
- User Held Alarm

## Subsystem 1: Power Input

The main device should be plugged into an AC socket. The power delivery must be highly reliable, as there is only one contingency for device failure, which is the user-held device's alarm notifying the user. The user's alarm can be powered by DC using small, store-bought batteries.

## Subsystem 2: Stove Knob Sensor

This system can be implemented using many methods, but one method that will work using any knob is a magnetic sensor and a small magnetic strip attached to the knob. When the magnetic strip and the sensor are aligned, we know that the stove is off, and vice versa. Additionally, the stove knob sensor supports a timer that sends a signal to chirp the alarm every once in a set interval if the stove is on. This can be implemented via a simple hardware countdown chip with a reset signal.

## Subsystem 3: Fire Detector

We could use a flame sensor, but out of concern for putting things close to the fire of a gas stove, we instead opt to detect the absence of flame while the stove is running. We know that gas stoves are powered by either natural gas or propane. To detect the absence of a flame, we can use a fan to intake ambient air, run it past methane and propane sensors. If either sends their positive signal, we know that the flame is out. This system should dispose of the methane and propane safely, ideally into the path of the kitchen fume hood.

## Subsystem 4: Main Alarm

This subsystem is a part of the main device that helps support the fire detector as well as taking input from the stove knob sensor. When the fire detector notes that there is no more fire, this alarm begins to sound. When the stove knob sensor's timer tells the alarm to chirp, the alarm lets out a short sound. This can be implemented using a simple, small speaker and some logic for sound.

## Subsystem 5: User Distance Sensor

This subsystem does not connect to the main alarm. Rather, it exists purely to service the user held alarm, emitting a signal for the user held alarm to process. The communication does not need to carry any meaningful data; all it needs to do is to serve as a reference point for the user held alarm. When the user held alarm detects the signal weakening below a certain threshold, the user held alarm knows that the user has walked a certain distance away.

## Subsystem 6: User Held Alarm

This subsystem is held by the user via a lanyard or kept in the pocket. When the user walks a certain distance away from the main device, the signal outputted will automatically weaken. The user held device will automatically sense the signal weakening, and signal the user held alarm to begin making a sound. The user may choose to "snooze" this signal through the push of a button, which will start a countdown timer. When the timer hits zero, the user held alarm will sound again. This will continue until the signal strength returns to an acceptable amplitude.

## Criterion For Success

Our main device must be able to:

- Sense the presence of methane or propane gas in the air
- Sense that a knob has been rotated
- Emit a distinct signal that can be picked up by a user held device.

Our user held device must be able to:
- Quantify the received signal strength of a signal emitted by the main device and compare it to a preset value.

## Addendum: Testing Protocols

A rightful concern brought up in the idea post was the fact that testing all of this is very unsafe, as we are testing on open flames and flammable gases. We will be attempting to perform as many tests as possible on mock-ups of the system. For instance:

The knob sensor can be tested on a dummy knob made of wood, or in a dire pinch, the cap of a Powerade bottle
The distance sensor can be tested trivially without the presence of a flame
The methane and propane sensor, however, will need an active source of these flammable gases. Obviously, eye protection and flame-resistant cotton lab coats will be necessary, but in the risk of an explosion of methane or propane, we will be testing live flames and methane/propane detection in a shielded environment. Ideally, we make a request to the chemistry department to utilize their fume hoods and glove boxes, the former of which provide adequate ventilation of dangerous gases, and the latter of which can be filled with nitrogen to drastically reduce the risk of combustion.

If the chemistry department denies our request, we have a box we can fill with nitrogen ourselves. We will test our methane/propane sensors downwind from ourselves after filling the box with nitrogen. This test will be performed on an empty parking lot, far away from any cars. To power our device, we could bring a battery-powered outlet.

During all live testing and flammable gas testing, we will also use a dry powder extinguisher, rated to extinguish Type A, B, and C materials, which includes flammable gases (propane and methane are specifically named), as well as extinguish electrical fires.

Low Cost Distributed Battery Management System

Logan Rosenmayer, Daksh Saraf

Low Cost Distributed Battery Management System

Featured Project

Web Board Link: https://courses.engr.illinois.edu/ece445/pace/view-topic.asp?id=27207

Block Diagram: https://imgur.com/GIzjG8R

Members: Logan Rosenmayer (Rosenma2), Anthony Chemaly(chemaly2)

The goal of this project is to design a low cost BMS (Battery Management System) system that is flexible and modular. The BMS must ensure safe operation of lithium ion batteries by protecting the batteries from: Over temperature, overcharge, overdischarge, and overcurrent all at the cell level. Additionally, the should provide cell balancing to maintain overall pack capacity. Last a BMS should be track SOC(state of charge) and SOH (state of health) of the overall pack.

To meet these goals, we plan to integrate a MCU into each module that will handle measurements and report to the module below it. This allows for reconfiguration of battery’s, module replacements. Currently major companies that offer stackable BMSs don’t offer single cell modularity, require software adjustments and require sense wires to be ran back to the centralized IC. Our proposed solution will be able to remain in the same price range as other centralized solutions by utilizing mass produced general purpose microcontrollers and opto-isolators. This project carries a mix of hardware and software challenges. The software side will consist of communication protocol design, interrupt/sleep cycles, and power management. Hardware will consist of communication level shifting, MCU selection, battery voltage and current monitoring circuits, DC/DC converter all with low power draws and cost. (uAs and ~$2.50 without mounting)