BASEMENT MONITOR DESIGN REPORT

By Jordan Marabello, Kai Imery, Riya Deokar, and Jeffrey Zhang

College of Engineering

Boston University

7 December 2021
Executive Summary:

The purpose of this final report is to go through the process of designing a monitor for

residential basement use that triggers the buzzers and LEDs in the presence of gas or water.

There were many trials that led us to creating the additions that we did to our design and

extracting means we had originally considered. We began the process with a problem statement,

objectives and metrics, pairwise comparison chart, constraints and means, glass box, function of

means, and bill of materials. Then we moved on to the physical modeling aspect of the project in

which we built a circuit and utilized code to test out our water and gas sensors. We created

different trials with the values that our code obtained to determine the restrictions and additions

our design needed. Finally, we designed our physical enclosures and placed the circuits and extra

components to fulfill our client’s needs.

Introduction and Problem Statement:

The topic of this report is to present a working prototype of a Basement Flood and Gas

Monitor to fulfill the problem statement, “The goal is to design a device to monitor a basement

for floods and the presence of dangerous gasses and notify the homeowner to allow for an

immediate response and allow time for the correct protocols/authorities to be put in place.” To

achieve these specific constraints, metrics and objectives were chosen based on the hurricane

situation that the client presented to us (Table 1 and 2). Along with having a functional prototype

that satisfies the problem statement, and other constraints, metrics, and objectives stated, the

purpose of this report is to allow others (i.e the client, supervisor, or other engineers) to

understand our product in a manner that they can be instructed to reproduce the system with the

given specifications and information of this report.

 Objective Metrics

Notified outside of his home Notified within 30 seconds, and within 30 ft

Detect flooding Should be triggered by 1cm of flooding

Detect gas leak CO (~1 to 70 ppm), Ammonia (~1 to 1700

ppm), Ethanol (~10 to 500 ppm), H2 (~1-100
ppm), Methane/Propane/Iso-Butane (~1000++
ppm)

Be durable IP67, Solvent proof

Be affordable Under $100

Require low maintenance Needs a change of batteries a minimum of

every 6 months

Long lasting Last 10 years

Portable Should be no bigger than a 6in x 6in cube

Power independent Battery powered no need for wall electricity

Table 1: Objectives and Metrics that final design was centered around.

Constraints Metrics

Financial Constraint Must be less than $100

Must be simplistic Must easily fit into a 6in x6in box

Time Must be completed before December 7th

Power consumption limitations due to Large enough battery voltage to power device
unavailable wall plug

Table 2: The constraints that were imposed or created in the creation of the final prototype.

Design Alternatives Considered:

Throughout the process of creating our prototypes various design alternatives were

considered but ultimately not used due to the fact that they did not meet the objectives or were

not the optimal method of implementation. During the Preliminary Design Phase, we decided to

use a water sensor and gas sensor, instead of a floating actuator and catalytic sensor (means) in
our prototype's ability to trigger an alert when the presence of water or gas was detected. These

choices were created based on the metrics of our objectives, as the water sensor used was more

accurate in low level water environments than a floating actuator which tends to need a larger

volume of water to be effective. Also the pre-programmed gas sensor would allow for a

component that was pre-coded in measuring the gasses we were trying to observe, rather than a

self coded catalytic sensor that is triggered by the natural atmosphere and not just the gasses in

question, thus decreasing the accuracy of the system and causing for a higher possibility of

mistakes in the code. Along with this in the Preliminary Design Phase the process of examining

the data to determine if one of the desired conditions was detected was also investigated. The

method we chose to use was to compare the sensor values obtained by the analog voltage reading

to a stored value that was directly implemented into the code. This was chosen over the

alternative method of using machine learning to identify a condition since the machine learning

model was deemed as more complex than necessary and was unneeded if the bounds of the

desired ranges were known.

In the Conceptual Design Phase, alternative methods of humidity control were modeled

and tested. The initial method of preventing humidity from triggering the device (function) was

to solely use Silica Packets (means) to reduce the humidity in the chamber's environment, yet in

our testing it was revealed that this was not solely enough to meet the desired function. Thus a

fan was added to the enclosure to not only improve the drying of the water sensor, but to also

help reduce the humidity accumulating inside the enclosure. The fan coupled with the silica

packets were able to meet our objectives and was favored over the alternative airtight container

that was considered, as it was deemed unrealistic due to the amount of openings the enclosure
needed along with the fact that the water sensor must be openly exposed to the environment for

maximum accuracy.

Overarching in the Preliminary and Conceptual Design were the means of fulfilling the

function of communication between the sensors and the handheld wireless receiver of the client.

The means that were in question were:Bluetooth, Wifi, and Radio wave Transmission, yet the

radio wave transmission appeared to be the most viable. Due to the fact that the scenario given to

us by the client was that he was experiencing a hurricane, we deemed the Wifi communication as

unreasonable as it relies on the home to not lose power, which is highly likely in a hurricane.

Additionally, a bluetooth connection was deemed insufficient as its range would be unable to

fulfill the desired metrics. Ultimately the Radio Wave transmitter and receiver were deemed as

the most suitable option as they allowed for sufficient and reliable communication over the

desired range, and were not susceptible to failure if the home’s power went out.

Basis for Design Selection:

In the basis of our design selection we want to assure that our design fulfills the restrictions and

functions of our basement monitor more than the design alternatives considered. During our

trials some flaws that were pointed out about our design were our water sensor’s failure to dry

and susceptibility to yield a false response due to a humid environment. The trials led us to the

addition of a fan, because we measured a proportional relationship between airflow and the

ability of the sensor to procure data values closer to a fully dry water sensor. Assuming wall plug

power is unavailable, one of our objectives was a power-independent device, we decided a 9V

battery would be sufficient for all our components. However, in our manufacturing process we

decided to use a 5V fan instead of a 12V fan because we noticed we weren’t receiving much

airflow, which was an important component necessary to keep our water sensor accumulation
controlled and equipped to detect flooding. Another aspect of the basis of our design selection

came from the results our sensor collected when we decided to simulate a humid environment

with a spray bottle. After measuring the water sensor’s response to humidity, we decided to

utilize silica packets because we did not want humidity to trigger a false flood reaction. Overall,

we placed a lot of consideration into preventing humidity or any excess water from triggering

our device, because we wanted to assure that the device will only be triggered when there is a

prominent sensing of concerning water presence. Our trials also led us to the conclusion that our

receiver and transmitter should be facing one another, in order to accelerate communication time

between the modules. Later on when testing out our design we came to the conclusion that our

3D printed enclosure was impeding the signals between the systems, prompting us to create a

hole for the transmitter to have closer access to the receiver. Our experience with the two

systems and their response times highlighted the importance of the construction of hardware. We

came to the decision of using separate systems in order to allow for the alert signals to be

transmitted to a safe location outside of the basement in the case of flooding or gas detection in

the basement. In the basement, we use two different enclosures in order to maximize coverage of

gas detection. Due to the fact the gasses that are dangerous to humans have different densities,

we have two seperate gas detectors. One is located in the flood enclosure on the ground and

another is in its own enclosure located that is to be put on a high shelf or upper stair location in

order to detect less dense gasses.

Evaluation of Results:

When comparing our final results to our initial objectives and metrics almost all of them

were met, yet some objectives had to be discarded. The objective that was discarded was

durability. In the creation of our prototype we deemed that waterproofing the entire enclosure
was not only beyond our abilities, but was unnecessary as it was low on our PCC (Appendix C).

It was deemed as unnecessary due to the fact that in the scenario given the home-owner is home

in a hurricane, and thus since our system was successful in all other objectives the homeowner

would have more than enough time to go to his basement and assess the situation before the

basement flooded to 6cm, which is how far the electrical components are off of the ground. Yet,

although this objective was discarded almost all other objectives were met. For the notification

of the homeowner, our system was able to communicate within five seconds for a length

upwards of the desired thirty feet (Figure 4)

Figure 4: This data shows the serial monitor of the receiver system at max distance. Max distance was
found to be 57ft between the two systems, and as seen by the data it was the furthest the two systems could
be separated while still having continuous outputs.

The max range of the system varied, but always exceeded the thirty foot standard, with its

maximum value being 57ft for one successful test. In all cases our system over achieved its

desired metrics. As previously mentioned the system achieved its ability to detect flooding when

at least 1cm of water was present as the desired metric states (Figure 3).
Figure 3: Voltage vs Time graph created by the water sensor as it underwent depth fluctuation. The depths
were adjusted in increments of one centimeter from a range of zero centimeter to four centimeters.

Also the voltage output of the sensor was also able to directly correlate depth with a higher

voltage value allowing for the bounds within the notification code to be easily found and

implemented. Along with this the objective of being portable was met as the system's largest

enclosure was a 12 cm cube. The objective of being power independent was met for our initial

prototype as the system was powered by four 9V batteries, but this complete power

independence will change in potential future designs as our objective of requiring low

maintenance was drastically undermet. The metric for requiring low maintenance is that the

batteries should last 6 months without being changed yet this is not met as the 9V batteries

would die in 7 days at the current usage. To fix this in future designs we would change the

batteries to rechargeable AA lithium-ion so that the system could be plugged in at all times that

the power of the home was not out and then if it went out it would still monitor the home for 7

days after. Also our final cost ended up being $17 slightly over our desired $100 metric.
Appendix:
A: Sketch and Specifications of Water Enclosure

B:Sketch and Specification of Gas and Receiver enclosures

C:Pairwise Comparison Chart

D: Arduino Code for Water Enclosure E: Code for Gas Enclosure

F: Code for Receiver System

References:
Electronic Materials:
[1]: How to Communicate Using 433MHz Module. [Online]. Available:
https://create.arduino.cc/projecthub/MisterBotBreak/how-to-communicate-using-433mhz-modul
es-9c20ed .[Accessed Nov 16, 2021]
[2] RF virtual wire sending string issue. [Online]. Available:
https://forum.arduino.cc/t/rf-virtual-wire-sending-string-issue/368017 . [Accessed Nov 16, 2021]
[3] Adafruit MiCS5524 CO, Alcohol and VOC Gas Sensor Breakout. [Online].
https://www.adafruit.com/product/3199?gclid=CjwKCAjwwsmLBhACEiwANq-tXJd5B6VMna
qZdWDzCRQ18I48UQ_m04edm_L3J8HDnY6_X6El5LjPKBoCotAQAvD_BwE [Accessed
Nov 2, 2021]