Download Design Document

Flood Alert!
Sump Pump Monitoring System
Final Design Report
Design Team 3
Matt Boston
Derek Brooks
Aaron Nervi
Jason Ulbricht
Faculty Advisor: Dr. Malik Elbuluk
Senior Design Coordinator: Gregory A. Lewis
November 15, 2012
Table of Contents
1. Problem Statement .....................................................................................................2
1.1. Need ....................................................................................................................2
1.2. Objective .............................................................................................................2
1.3. Background .........................................................................................................2
1.4. Marketing Requirements ....................................................................................4
1.5. Objective Tree ....................................................................................................4
2. Design Requirements Specification ...........................................................................5
3. Accepted Technical Design .......................................................................................7
3.1. Hardware.............................................................................................................7
3.1.1. Non-invasive Current Sensors .........................................................................10
3.1.2. Water Level Sensor ..........................................................................................12
3.1.3. LCD and In-Home Speaker .............................................................................17
3.1.4. Test Button .......................................................................................................18
3.1.5. Battery Level Monitoring ................................................................................18
3.1.6. Hardware Theory of Operation ........................................................................19
3.1.7. Continuous Water Level Sensor Theory of Operation ....................................19
3.1.8. Hardware Design Modules ..............................................................................20
3.2. Software ..............................................................................................................22
3.2.1. Software Theory of Operation .........................................................................25
3.2.2. Software Design Modules ................................................................................25
3.2.3 Software Flow Diagrams ..................................................................................28
3.3. Communication ...................................................................................................34
3.4. Mobile Application Software .............................................................................39
3.4.1. Mobile Application Theory of Operation ........................................................43
3.4.2. Mobile Application Design Modules ...............................................................43
3.5. Power ..................................................................................................................43
3.6. Design Calculations ............................................................................................45
3.6.1. Battery Level Calculations ...............................................................................45
3.6.2. Voltage Divider Calculations ...........................................................................46
4. Parts List ....................................................................................................................47
5. Project Schedules .......................................................................................................48
6. Design Team Information ..........................................................................................53
7. Conclusions and Recommendations ..........................................................................53
8. References ..................................................................................................................54
9. Appendices.................................................................................................................55
i List of Figures
1.5.1: Objective Tree........................................................................................................5
3.1.1: Main Controller Block Diagram (Level 0) ............................................................7
3.1.2: Main Controller Block Diagram (Level 1) ............................................................8
3.1.3: Controller/ Hardware Diagram (Level 2) ..............................................................9
3.1.4: Connections to Arduino Mega 2560 ......................................................................10
3.1.5: Non-invasive Current Sensor .................................................................................11
3.1.6: Inner Circuit Design of Current Sensor .................................................................11
3.1.7: Ip/Vout Curve of Current Sensor ...........................................................................12
3.1.8: Pinout of the eTape Water Level Sensor ...............................................................13
3.1.9: eTape Sensor Output..............................................................................................14
3.1.10: Water Level Sensor Schematic ............................................................................15
3.1.11: Water Level Sensor Schematic (Empty) ..............................................................16
3.1.12: Water Level Sensor Schematic (Full) ..................................................................16
3.1.13: Connection between ATMega2560, LCD, Speaker ............................................17
3.1.14: Push Button Connection to Arduino ....................................................................18
3.1.15: Voltage Divider for Measuring Battery Level .....................................................19
3.2.1: Main System Software (Level 0) ...........................................................................23
3.2.2: Main System Software (Level 1) ...........................................................................23
3.2.3: Main System Software (Level 2) ...........................................................................24
3.2.4: waterLevel() method ..............................................................................................28
3.2.5: powerLevel() method .............................................................................................28
3.2.6: isOn() method ........................................................................................................29
3.2.7: waterAlarm() method .............................................................................................30
3.2.8: powerAlarm() method............................................................................................31
3.2.9: pumpAlarm() method ............................................................................................32
3.2.10: activateAlarm() method .......................................................................................33
3.3.1: GSM/GPRS Evaluation Board and SM5100B-D ..................................................34
3.3.2: SM5100B-D Block Diagram .................................................................................35
3.3.3: Communication UART Serial Connection ............................................................37
3.4.1: Mobile Application Block Diagram (Level 0) .......................................................39
3.4.2: Mobile Application Block Diagram (Level 1) .......................................................40
3.4.3: Communications between Android Device and SQL Server ................................41
3.4.4: Software Block Diagram/Flowchart for Mobile Application (Level 2) ................42
3.5.1: Main System Controller Power Supply (Level 1) .................................................44
3.5.2: Main System Controller Power Supply (Level 2) .................................................44
ii List of Tables
2.1.1: Design Specifications ............................................................................................6
3.3.1: Key Features of the SM5100B-D ..........................................................................36
4.1.1: Parts List ................................................................................................................47
4.1.2: Revised Material Cost............................................................................................48
5.1.1: Midterm Design Ghant Chart ................................................................................49
5.1.2: Implementation Ghant Chart .................................................................................51
9.1.1: Datasheet Links......................................................................................................55
iii iv Abstract
The Flood Alert! system will be a monitoring and alarm system for residential use sump pump
systems. The goal is to create a system that will help prevent flooding by alerting the homeowner
of critical issues with the sump pump system such as a power outage and the current water level.
The system will consist of a water level sensor placed inside the sump pump reservoir and
backup power supplies to power the entire system in the event of a power outage. Data from the
water level sensor and the power supplies will be relayed to a microcontroller. The
microcontroller will process the data to calculate the actual water level and the remaining power
levels, and display this to the homeowner via a physical display. An audible alarm placed in the
house will alarm the homeowner if a problem occurs. The homeowner will also have access to a
mobile application for Android devices which will display water level, power level, and pump
status. By providing multiple ways to alert the user of problems and providing them with detailed
information regarding their sump pump system, we hope to provide them with valuable time to
act on a problematic situation.
1 1
Problem Statement
1.1
Need: (By Matt)
Many homeowners rely on a sump pump system to remove water from their basements or crawl
spaces. When the systems lose power, or equipment fails, flooding can result. If the homeowner
is unaware that the system is at risk, they are unable to do anything to help the problem and
serious damage can occur.
1.2
Objective: (By Derek)
The Flood Alert! Sump Pump Monitoring System will warn the homeowner if there is a power
outage to the sump pump and if the water is overflowing. It will also warn the homeowner if the
water level is at a critical level even if the system has power. The user will be warned via an
alarm placed inside the house, and through the use of a mobile phone application; therefore the
user would get the message as soon as a problem arises. The system will also continue to
function under backup power when the power goes out. It will keep the user updated with data as
the water level and conditions change. This should allow the user time to act to attend to the
situation should a problem arise.
1.3
Background: (By Jason)
Sump pump alarms are not new to the homeowner market. The new proposed system, however,
will separate itself from other systems currently available because there is nothing that will send
a wireless signal to a remote device to alert the user that their sump pump is at risk of
overflowing. Also, current systems only produce an alarm when the level in the sump pump is
getting too high, not in the event of a loss of AC power to the device. An example of a system
currently available is described in patent number 6375430. Said patent describes an alarm unit
that mounts near the pump and emits both audible and visual alarms if the water level reaches a
specific height.
An example of a similar existing system that is aimed towards the industrial rather than home
market can be found in the article “Design of coal mine underground drainage pump monitoring
and controlling system based on PLC and touch screen.” The article focuses on the design of an
underground drainage pump for a mining environment that uses a control system to monitor it.
2 The main thing to be taken from the article is how the workers monitored the water levels in the
sump and designed a system that would alert them if water levels reached a critical point. This
alarm system is an important part in the design of the pump because it ensures that the sump
pump will not flood in the event of a power outage.
In order to differentiate this product from other products on the market it will be equipped with a
few extra features. As previously mentioned, this will target home users who require the use of a
sump pump in their basement or crawl space. For homeowners with sump pumps in their house,
power outages can be very scary. If the pump doesn’t have power, then there is a chance that
water could overflow the sump and flood the basement of the house. This system will attempt to
eliminate this hazard in a few different ways. First, the system will alarm the user whenever there
is a power outage. During the power outage, the system will rely on a backup battery system to
continue functioning. If the sump were to reach a high level during the power outage, the system
will detect the high water level and alert the user once again that there is a problem. The main
component that will set this product apart from others is that rather than the main unit simply
playing an audible alarm from where it is hooked up, this one will also communicate with a
mobile application on the homeowner’s phone. The mobile application will keep the user
updated with current water level readings. It will let the user know if their system has main
power, and provide information on the backup power.
One problem posed by this design is going to be designing a rechargeable battery that can charge
while the system is running off of AC power, and then power the system in the event of a power
outage. It is important to properly charge the battery while running off of main power so that it
doesn’t become overcharged or otherwise ruined. According to the Electrical Engineer’s
Reference Book; “All secondary batteries require a supply of direct current for recharging. The
method of charging is important in its effect on battery performance and service life.” (29/12)
There exist multiple systems in the sump pump market that contain a main pump connected
straight to 120VAC, and a smaller backup pump connected to a 12VDC battery. Our monitoring
system will utilize one of these currently available systems, but add the features described above.
3 1.4
Marketing Requirements: (By Aaron)
1. Easy to install
2. Easy to operate
3. Small
4. Accurate
5. Measure water level
6. Waterproof level sensor
7. Alarm the operator when the water level is high
8. Must know whether or not the sump pump has power
9. Alarm the operator when power fails
10. Full system continues working when power goes out
11. Keep user informed with information via physical alarm and mobile application
1.5
Objective Tree: (By Aaron)
The objective of this project is to design a system that will monitor different aspects of an in
home sump pump system. Fig. 1.5.1 shows a block diagram of key objectives for the system
based upon our marketing requirements in the previous section. The tree styled diagram takes
our marketing requirements and creates branches of related objectives. The numbers in each box
correspond to the importance we are placing on that objective out of a unit of one. Our main
three objectives are to make the system easy to install, alarm the operator of a power failure, and
to alarm the operator of different conditions that might arise with water level, such as a high
level, which could result in flooding.
4 Sump Pump Overflow Alarm
Alarm
Operator when
Power Falls
Easy to
Install
(0.25)
Alarm Operator
when Water
Level is High
(0.35)
(0.40)
Easy to
Operate
Know if Pump
Has Power
Measure the
Water Level
(0.50)
(0.50)
(0.75)
System
Continues
Working When
There is No
Main Power
Small
(0.25)
(0.50)
Accurate
(0.25)
Waterproof
Level Sensor
(0.25)
Continue to Update User With Information Via
Physical Alarm and Mobile Application
Fig. 1.5.1: Objective Tree
2
Design Requirements Specification
Table 2.1.1 provides a list of the design specifications/engineering requirements that the sump
pump alarm system will need to adhere to, in order for it to operate in an in-home environment
and satisfy the marketing requirements. The table lists the different engineering requirements
along with justifications for the requirements, as well as listing the associated marketing
requirements.
5 Marketing Requirements
1
10
2,11
8,11
4,6
1,2,9,11
7,9,11
9,10,11
7,9,11
4,5,7
1,3
Engineering Requirements
Justification
The system will be powered from a standard home 120V outlet.
System needs to continue to function Complete system should l ast at l east 3 during power outages to keep the area hours on backup power
from flooding and to alert the user.
Critical system data will be available to The e nd user should be able to view basic user through physical display and information about the pumps, water l evel mobile application
and power l evel.
The user should be able to view the remaining power l evel of the backup State of charge of backup power will be power supply, and the system needs to measured and displayed
know how l ong until complete power outage.
The water l evel sensor needs to l ast and Water l evel sensor must be non-­‐
corrosion could also i nterfer with corrosive
accuracy.
Mobile Application must consist of an The user must be able to e asily easy to use i nterface and run on a understand and navigate the i nterface, so mobile device.
as to know i f a problem i s occuring.
Mobile Application will alert user The application should get the user's through audible alerts and attention to alert them of any problems notifications i f a system malfunction, occuring at the site of their sump pump or critical e vent has occurred
system
The e nd user needs to continue to be System will provide network updated with i nformation during a power connection, e ven during power outage
outage.
Physical alarm will produce at l east The user needs to be able to hear the 70dB to be heard throughout the alarm i f he/she i s i n their home.
home.
Water l evel sensor needs to be The system needs to obtain accurate l evel accurate to within 3%
values for calculations.
Water l evel sensor must be no l onger The typical sump pump pump i s no l onger than 3ft i n l ength
than 3ft i n depth.
System must operate off of 120VAC
Marketing Requirements:
1. Easy to install
2. Easy to operate
3. Small
4. Accurate
5. Measure water level
6. Waterproof level sensor
7. Alarm the operator when the water level is high
8. Must know whether or not the sump pump has power
9. Alarm the operator when power fails
10. Full system continues working when power goes out
11. K eep user informed with information via physical alarm and mobile application
Table 2.1.1: Design Specifications
6 3
Accepted Technical Design
3.1
Hardware
The main controller (shown in Fig. 3.1.1) takes the information from the sump pump system and
transfers the desired information to an outside server to be used by a mobile phone application.
The controller runs off of 9 volts dc and takes in data from the water level sensor, the power
supply, current sensors from the main pump and backup pump, and a current sensor used to
determine whether or not the system has power. That information is then uploaded to a server to
be sent to the user’s phone. It is also sent to an LCD to display the needed information at the
actual site where the sump pump is located. The controller will also output an audible alarm
when the power goes out or the pump stops running.
Water Level
Sensor
Data to Server
Power Supply
Data
Main Pump
Main Controller
Data to LCD
Secondary
Pump
Alarm Speaker
9VDC Power
Fig. 3.1.1: Main System Controller Block Diagram (Level 0)
Figures 3.1.2 and 3.1.3 show the controller broken down into more detail than the level 0
diagram. All of the input data from the sensors will pass through the main hardware block.
The hardware block represents an Arduino Mega 2560 as shown in Fig. 3.1.3. The sensors
will all output voltage signals that will provide the status of the water level, the power
supply, and the main and secondary pumps. The software on the Arduino Mega will calculate
the water level, power supply level, and determine whether or not the pumps are currently
operating, and it transfer LCD signals to the LCD display as well as send a data string to the
GPRS. This GPRS will then output the data packet to the server. The data packet will include
data to be sent to the user such as the level of the water and the remaining life of the backup
pump/supply (when main power is out or the main pump is out).
7 Main Controller
Voltage from
Water Level
Sensor
LCD Display
Power Supply
Data
Primary Pump
Hardware
Data Packet
To Server
Secondary
Pump
Main Power
(Yes/No)
Primary Secondary Water
Pump
Pump
Level
Power
Supply
Ref
Voltage
GPRS
LCD
Signals
9VDC Power
Main Controller Software
Data String
Alarm Speaker
Fig. 3.1.2: Main System Controller Block Diagram (Level 1)
Figure 3.1.3 shows the final level of the system’s hardware design. This further detailed diagram
shows that the system will be utilizing an SM5100B-D GPRS module, as well as an antenna and
SIM card. Further information on these parts can be seen in the communications section. The
system will also consist of a test button. This button will allow the user to test the physical
speaker alarm. More information on the current sensors, water level sensor and LCD display is
provided throughout this section.
8 Test Button
Water Level Sensor
9V Power Supply
User Interface Control
9V
Main Power Current
Sensor
Variable Voltage
Backup Pump Power
Supply Level
Voltage
Voltage
Primary Pump
Current Sensor
Voltage
Arduino Mega 2560
ATmega2560
Alarm Speaker
Voltage
Secondary Pump
Current Sensor
SIM Card
Data
Data
GPRS Module
SM5100B-D
Display Driver
Antenna
Controlled Display
Output
LCD Display
Fig. 3.1.3: Controller/Hardware (Level 2)
Figure 3.1.4 shows the pins that the different components indicated in figure 3.1.3 will use on the
Arduino Mega 2560. The component blocks are broken down throughout the paper to show the
complete schematics.
9 12V Power Adapter (PS)
And 9V Battery (BT1)
Power
Barrel
Jack
Main Power
(CS1)
PWM
Secondary
Pump
Battery
Level Sensor
5V
(LS)
Test
Button
(SW1)
GND
Vin
Primary
Pump
(CS1)
GPRS
Module
(U2)
Secondary
Pump
(CS1)
U1
Secondary
Pump
Battery
Level Sensor
LCD
(DS)
Fig. 3.1.4: Connections to Arduino Mega 2560
3.1.1
Non-invasive Current Sensors (By Matt)
In order to fulfill the marketing requirement of knowing whether or not the sump pump system
has power and to determine if the sump pump is currently operating, current sensors will be used.
A current sensor will be placed on the power cord powering the main controller, as well as the
power cord of each pump. The current sensor (Part Number SEN-11005 from Sparkfun.com) is a
non-invasive current sensor that will encircle the wires attaching the devices to their power
source. An image of the sensor can be seen below in figure 3.1.5.
10 Fig. 3.1.5: Non-invasive Current Sensor from Sparkfun.com
The sensor can handle up to 30 amps which will be plenty as the sump pump uses only 13.33
amps on start-up. The test circuit for the sensor is shown below in figure 3.1.6 is the test circuit
found in the datasheet for the current sensor. The current transformer has 2000 turns, and the
built in resistance is 10 ohms.
I
A2
10Ω
GND
Arduino Mega 2560
k
l
CS
Fig. 3.1.6: Inner Circuit Design of Current Sensor and Connection to Arduino
The current sensor will output a voltage proportional to the current that it reads as shown in the
graph below from the sensor datasheet. This output voltage will be read from the control board to
determine if the board is being powered from the wall or not, thereby determining if there is still
11 power from the outlet. For instance, if the current sensed is the 13.3A start-up current, the
Arduino will see approximately 65mV based on figure 3.1.7. The current sensors attached to the
pumps will also relay a voltage back to the controller, in order to determine if either pump is
currently operating.
Fig. 3.1.7: Ip/Vout Curve from SEN-11005 datasheet
3.1.2
Water Level Sensor (By Derek)
The water level sensor is a simple sensor that we will be purchasing for our project. As can be
seen in Figure 3.1.10, the sensor we are getting acts as a potentiometer that is controlled by the
amount of water it is submerged in. The sensor we will be using is called eTape and was
designed by Milone Technologies. The sensor is 26 inches long, so it fits the constraint of pump
reservoir dimensions. Figure 3.1.8 shows the top end of the sensor and the 4 pins that are located
there. Pins 2 and 3 correspond to the sensor resistance. Pins 1 and 4 can be used as a reference
resistance. It will have a voltage that is sent across the sensor from the 5V out on the Arduino
board across pins 2 and 3 on the eTape sensor. The voltage that is sent to the system will need to
be referenced and compared to the voltage that is returned to the board after it goes through the
sensor resistance. After the voltages are compared, we can then calculate the water level in the
reservoir.
12 Fig. 3.1.8: Pinout of the eTape Water Level Sensor
As mentioned above, the eTape sensor acts like a potentiometer. The resistance varies depending
on the level of water in the tank it is located in. For this sensor, the lower level of water in the
reservoir, the higher the resistance outputted. Figure 3.1.9 shows a plot of water level vs.
resistance. As you can see from the plot, an empty reservoir yields 3000 ohms resistance and a
full reservoir (24 to 25 inches) yields around 300 ohms resistance.
13 Fig. 3.1.9: eTape Sensor Output: Water Level vs. Resistance Output from eTape Datasheet
Figure 3.1.10 shows the final schematic of the Milone eTape fluid level sensor connected to the
Arduino Mega 2560. Vw is the voltage supplied by the voltage divider with the variable resistor
(Rsense). Vref is the reference voltage supplied by the voltage divider with the reference resistor
(Rref). Rref will always be 3Kohms and is built into the resistor by using pins 1 and 4 on the
sensor. Rsense will vary between roughly 300 ohms and 3Kohms. R1 and R2 are both 2Kohm
resistors, and were chosen to keep the input voltages from exceeding 3.3V and potentially
damaging the Arduino. Unity voltage buffers will also be in place to match the impedance of the
Arduino.
14 R2
R1
Vs
A0
Vref
A1
Arduino Mega 2560
5V
GND
1
2
3 4
Rsense
WS
Rref
Fig. 3.1.10: Water Level Sensor Schematic
Figures 3.1.11 and 3.1.12 show the results of setting up the water level schematic in pSpice.
Figure 3.1.11 shows how the circuit will respond when the water reservoir is empty and Rsense
equals 3Kohms. When this is the case, the output voltage (Vs) should be 3V. Figure 3.1.12
shows how the circuit will respond when the water reservoir is full and Rsense equals 300 ohms.
When this is the case, the output voltage (Vs) should be 652mV.
15 Fig. 3.1.11: Water Level Sensor Schematic Empty
Fig. 3.1.12: Water Level Sensor Schematic Empty
16 3.1.3
LCD and In-Home Speaker: (By Jason)
For instances when the user is at home, they will be able to view critical system data using a 4
line by 20 character LCD display that will be wired directly to the microcontroller. In addition to
displaying important data, the microcontroller will also be wired to a small 8Ω piezoelectric
speaker. The speaker will alert the user in the event of a potential flood. Figure 3.1.13 below
shows how these two components will be wired to the Arduino board. The LCD must be
compatible with Hitachi HD44780 display controllers in order to be controlled by the Arduino
board. It will be wired in 4-bit mode, meaning only four of the eight data bits will be used, in
order to save on the number of digital outputs occupied on the Arduino board. The display will
draw power from the 5V source supplied by the microcontroller, and a 10kΩ potentiometer will
be wired between the 5V source and ground. The potentiometer will be connected to the Vo pin
on the LCD in order to control contrast. Register select (RS), enable (E), and digital bits 4
through 7 (DB4-DB7) will be connected to the digital output pins of the board in order to receive
and display the critical data values.
GND
LS (CVS-3108)
5V
Arduino Mega
ATmega2560
DIGITAL I/O
Rc
VCC
VSS
Vo
RS
R/W
E
DB0
DB1
DB2
DB3
DB4
DB5
DB6
DB7
LED+
LED-
DS
NHD-0420E2Z-FSW-GBW
Fig. 3.1.13: Connection between ATmega2560, LCD Panel and In-Home Speaker
17 3.1.4
Test Button (By Aaron)
The test button is the main component of the user interface for the main controller. When
pressed, it will activate a test alarm and send a signal to the in-home speaker. This is in place to
test the overall alarm function of the controller and help make sure it is operating correctly. The
push button will act as a switch and send a high signal to a digital pin on the Arduino when it is
pushed down and the switch is in the closed position. A pull down resistance of 10K ohms is
used to keep the input from floating when the button is not pressed. Fig. 3.1.14 shows the
schematic for the push button.
Arduino Mega 2560
D8
SW1
5V
GND
R6 = 10K
Fig. 3.1.14: Push Button Connection to Arduino
3.1.5
Battery Level Monitoring
In order to measure the remaining level on the backup battery connected to the backup/secondary
sump pump, we will use a simple voltage divider connected from the 12V DC battery to the
Arduino Mega 2560. Figure 3.1.15 shows the schematic for this voltage divider. The resistors,
R3 and R4, were chosen as 10Kohms and 3Kohms to limit the output voltage to less than 3V.
The unity voltage buffer is in place to match impedances. The theory is that as a battery drains, it
loses voltage. The Arduino will be programmed to use a hardcoded reference voltage and
compare the output voltage from the voltage divider to that reference voltage. From here it will
estimate the current percentage value of battery power remaining.
18 +
-
Backup Pump
Battery (12V)
BT2
Arduino Mega 2560
R3 (10K)
A5
R4 (3K)
GND
Fig. 3.1.15: Voltage Divider for Measuring Battery Level
3.1.6
Hardware Theory of Operation
The controller will act as the intermediary between the user and the sump pump system. The
controller will receive information regarding the voltage level of the batteries, the voltage from
the water sensor, as well as the main sump pump and the backup sump pump. The controller will
take the received information and transmit several items of interest to the user depending on the
state of the system. In the event of a system malfunction or a problem (such as high water level),
the controller will send a signal to an audible alarm at the local location as well as the mobile
location (user’s phone). It will also send data to the user’s phone regarding the life left on the
battery given a loss of main power and a continuous stream of the current water level through
GPRS.
3.1.7
Continuous Water Level Sensor Theory of Operation
The continuous water level sensor will monitor the water level inside the sump and output a
variable voltage based on the current level of the water. The sensor will have a battery input
voltage and will act as a variable potentiometer that is adjusted by the varying water level. The
sensor will then output a variable voltage based on the water level directly to the board. The
board will then be able to use the sensor voltage along with a reference voltage from the battery
to calculate the height of the water level as a usable number.
19 3.1.8
Hardware Design Modules
The following functionality tables show the details of the inputs, outputs, and functionality of
each module in the hardware design of the Flood Alert! Sump Pump Monitoring System.
Module
Designer
Inputs
Outputs
Main Controller (Arduino Mega 2560)
Matt Boston, Aaron Nervi, Derek Brooks
Water Level Sensor: V ariable voltage ( 0-­‐3V)
Main Power Sensor: Low voltage ( Dependent on current)
Backup Pump Power Level Sensor: Low volage ( Dependent on pump battery l evel)
Primary Pump Current Sensor: Low voltage ( Dependent on current)
Secondary Pump Current Sensor: Low voltage ( Dependent on current)
Test Button: Low or High Signal
9V: Power to power the board
Speaker: Alarm signal
GPRS Module: Data to be sent over network
LCD: Data to be displayed on physical display
Functionality
The main board will be powered by 9V DC, and i s backed up by a 9V battery. A l evel sensor is connected to transmit the water l evel i n the sump. The data f rom the sensor and power inputs will be used to determine system f ailure and potential f looding. An audible alarm will also sound to alert the user of the f ailure. The data will be pushed to the mobile application over a cellular network to an outside server. An on board LCD display will also inform the user of water and power l evels.
Module
Designer
Inputs
Outputs
Main Controller Power Supply
Matt Boston,Jason Ulbricht
120VAC to 9VDC Wall Adapter
9V to Controller
Functionality
The power supply will power the main board with 9VDC power. The module will consist of a relay switch, that will switch the system to using the 9V battery as power if a main power outage occurs.
20 Module
Designer
Inputs
Outputs
Functionality
Continuous Water Level Sensor
Derek Brooks, Aaron Nervi
5V: Power from Arduino Mega 2560
Vsense: V oltage ( 0-­‐3V) i ndicating water l evel
Vref: V oltage ( ~3V) to act as reference voltage
The Continuous Water Level Sensor will monitor the water l evel i nside the sump and output a variable voltage that i s representative of the current water l evel to the controller. This will be calculated using V sense and V ref.
Module
Designer
Inputs
Outputs
Functionality
GPRS Module
Aaron Nervi
Data: Data from Arduino through UART Serial Interface
5V: Power from the Arduino to Power the GPRS module
Antenna: Quad-­‐band Antenna
SIM: SIM card for network access
Data packet over cellular network
The GPRS module will function as an i ntermediary between the main controller and network server. The data will be transferred through the module and out over a cellular network. The module will also consist of a SIM card and antenna.
Module
Designer
Inputs
Outputs
Functionality
LCD Display Driver
Jason Ulbricht
Main Power Status
Water Level
Battery Level
Pump Status
Enable Bit: Enable The LCD
Register Select Bit: Select Read or Write Mode
DB4-­‐DB7: Data Bits to the LCD
The LCD Driver will i nput the critical system data such as battery charge, water l evel, and power source and convert the data to be sent to the LCD. Two pins will be used to enable and reset the LCD while four additional pins will transmit critical system data to the LCD.
21 Module
Designer
Inputs
Outputs
Functionality
LCD Display
Jason Ulbricht
5V: Power from the Arduino Board
RS: Register Select
E: Enable Bit
Vo: Contrast Control
DB4-­‐DB7: Digital Bits for Display Control
Visual Display
The LCD will be powered using the 5V DC ouput from the Arduino board. It will communicate with the board using 6 digital IO pins. Data from these pins will be displayed on the LCD. A potentiometer will be wired between V SS and V CC to control contrast.
Module
Designer
Inputs
Outputs
Functionality
User Interface (Test Button)
Aaron Nervi
Momentary push button
Hi-­‐Lo signal to Arduino Mega 2560
The user i nterface consists of one momentary push button. The button will act l ike a switch and i f i t i s pressed down, i t will send a Hi signal to the Arduino. The i n-­‐home speaker will sound an alarm when pressed.
3.2
Software
Figure 3.2.1 shows the main software for the monitoring system, which will accept five inputs
while handling three outputs. The five inputs will come from four main sources connected to the
system. The water level voltage and reference voltage will both come from the water level
sensor. The water level voltage will be a variable voltage that is received directly from the sensor
and represents the water level in the sump. The reference voltage will come from the power
source powering the sensor. The power level voltage will be received from the back-up battery
installed with the system. Finally, the operating status for the primary and secondary pumps will
come from each pump respectively. These two signals will be used to determine if each pump is
running, or if there is a fault that the user must be notified about. The three outputs will all output
to different devices on the board. The alarm control will connect to an audio device that will give
an audio alert under various conditions. The display driver will connect to an LCD that will give
22 visual cues and alerts. Finally the GPRS signal will contain all data necessary for the mobile
device and send it to a GPRS device to be transferred wirelessly to a server.
Water Level
Sensor
LCD
Reference
Voltage
Power Level
Sensor
System Software
Primary Pump
To GPRS
Alarm
Secondary Pump
Fig. 3.2.1: Main Controller Software (Level 0)
Figure 3.2.2 shows the level 1 block diagram of the main controller software. Here can be seen
the main outline of what the software will actually do. The controller will read in all five inputs
and make any necessary calculations. It will then check the water level and the power level and
decide whether or not any alarms need to be set. It then takes this information and outputs visual
and audio cues to the user along with sending all necessary data to the GPRS for wireless
transfer.
Main Controller Software
Water Level
Sensor
Reference Voltage
Power Level
Sensor
Calculate Water
Level
Check Water
Alarm States
Read Power
Level
Check Power
Alarm States
Alarm
Main()
Primary Pump
Secondary Pump
LCD
Read Pump
Signals
Fig. 3.2.2: Main Controller Software (Level 1)
23 GPRS
Figure 3.2.3 shows the final level of the main controller software that will be programmed into
the Arduino Mega 2560. This figure shows the main power sensor as a new input; it was
previously included with the power level sensor. The analog-to-digital converters (ADCs) will be
used to convert the voltages from the sensors into binary for use by the rest of the code.
Water Level
Voltage
Reference
Voltage
Power Level
Voltage
Primary Pump
Sensor
Secondary Pump
Sensor
Main Power
Sensor
ADC
waterLevel()
waterAlarm()
ADC
ADC
powerLevel()
ADC
isOn()
ADC
isOn()
ADC
Main()
activateAlarm()
Audio Alarm
sendToLCD()
LCD Driver
sendToGPRS()
GPRS Driver
isOn()
pumpAlarm()
powerAlarm()
Fig. 3.2.3: Main Controller Software (Level 2)
The Main() function will act as a continuous loop and will work with delays. It will call the
methods to calculate the current water level and backup power supply level, as well as the isOn()
functions which will determine whether or not the corresponding item is on or off. The Main()
method will then call the waterAlarm(), pumpAlarm(), and powerAlarm() functions to set any
alarm instances that need to be made. ActivateAlarm() will then be called and it will serve as a
function to check whether an alarm instance has been set. If an instance has been set, it will
activate the appropriate alarm. Different alarms will be associated with different conditions.
Section 3.2.3 gives flow diagrams of each method and explains the details further. The LCD and
GPRS modules will use the data gathered in the Main() loop to display and send critical data to
the corresponding devices. The following pseudo code shows the main loop and the order at
which it will call the different methods.
24 Main loop() { //Get water level waterLevel() //Get backup power supply level powerLevel() //Get current status of the pumps and main power isPrimaryOn() isSecondaryOn() isMainPowerOn() //Set any alarm flags necessary waterAlarm() pumpAlarm() powerAlarm() //Activate an alarm if necessary activateAlarm() } 3.2.1
Software Theory of Operation
The main system software will receive water level, power level and pump status data and
determine whether or not it is currently in a flooded state and whether or not there is an
immediate danger for future flooding. The software will directly control an audible alarm and
LCD on the board, and it will also control the flow of data that needs to be sent to the user’s cell
phone.
3.2.2
Software Design Modules
The following functionality tables show the details of the inputs, outputs, and functionality of the
different modules in the design of the software for the Flood Alert! Sump Pump Monitoring
System.
25 Module
Designer
Main Controller Software
Derek Brooks, Aaron Nervi
Inputs
Water Level Sensor, Reference V oltage, Power Level Sensor, Main Pump, Secondary Pump
Outputs
LCD Display, GPRS, Alarm Signal
Functionality
The sump pump controller will receive water l evel and power data to determine whether or not that l evel will yield a possibility of f looding. The controller will then send an output data signal to the user's phone that will give details about the water level and whether or not different parts of the system have f ailed. It will also output an audible alarm to l et the user know of a problem.
Function
Designer
waterLevel()
Derek Brooks, Aaron Nervi
Inputs
Outputs
-­‐ Water l evel voltage: The voltage from The Water l evel sensor
-­‐ Reference voltage: The Reference voltage sent through The Water l evel sensor
-­‐ Calculated water l evel: Height of the water l evel as a percentage
Functionality
The waterLevel() function will take the variable l evel voltage from the water sensor and the reference voltage from the sensor and use the two voltages to calculate the current l evel of the water. Function
Designer
powerLevel()
Derek Brooks, Aaron Nervi
Inputs
Outputs
-­‐ Power l evel voltage: The voltage from secondary pump's battery
-­‐ Calculated power l evel: Remaining amount of battery power i n percentage format
Functionality
The powerLevel() function will take the current voltage from the secondary pump's battery and use a hardcoded reference voltage to calculate the current power l evel of the battery. Function
Designer
isOn()
Derek Brooks, Aaron Nervi
Inputs
Outputs
Functionality
-­‐ V oltage: voltage outputed by the current sensors attached to both pumps and main power source to controller
-­‐ Set status flags i n memory
isOn() checks the voltage coming from both pump's and the main contollers current sensor and determines whether or not the associated pump or main power i s on, i t then sets the required status flags
26 Function
Designer
Inputs
Outputs
waterAlarm()
Derek Brooks
-­‐ Calculated water l evel: The current water l evel i n the sump
-­‐ Sets status flags i n memory
Functionality
The waterAlarm() function checks the current calculated water l evel against specified values and decides what status flags, i f any, need to be set
Function
Designer
pumpAlarm()
Derek Brooks, Aaron Nervi
Inputs
Outputs
-­‐ Water l evel: The current l evel of water i n the sump calculated from waterLevel()
-­‐ Main power status: Whether the system i s receiving main power
-­‐ Main pump status: Whether the main pump i s running
-­‐ Secondary pump status: Whether the secondary pump i s running
-­‐ Backup battery dead flag: Whether the backup battery i s dead
-­‐ Alarm signal: Specified alarm signal to the speaker
Functionality
The pumpAlarm() function takes the water l evel, and all the power statuses of the system and decides i f there i s a problem with e ither the main or secondary pump
Function
Designer
powerAlarm()
Derek Brooks
Inputs
Outputs
-­‐ Secondary Pump Battery l evel: The percentage l evel of the secondary pumps battery
-­‐ Sets status flags i n memory
Functionality
The powerAlarm() function checks the power l evel of the secondary pumps battery and decides which status flags, i f any, need to be set
Function
Designer
activateAlarm()
Derek Brooks, Aaron Nervi
Inputs
Outputs
Functionality
-­‐ Status Flags: Reads the alarm C5status flags from memory
-­‐ Alarm signal: Specified alarm signal to the speaker
The activateAlarm() function will check all the alarm status flags i n memory using a specified priority and output the alarm of the first status flag i t reads as activated
27 3.2.3
Software Flow Diagrams
Figure 3.2.4 shows the waterLevel() function of the main system software. The waterLevel()
function will take two voltages from the water level sensor. One voltage will be a reference
voltage that represents the sump when full while the other voltage is a variable voltage that is
dependent on the level of the water in the sump. It will take these two values and use them to
calculate a percentage water level and store it in memory.
Start
Wait
Read in Water Level
Voltage
Read in Reference
Voltage
Store Level % in
Memory
Calculate Water Level %
Fig. 3.2.4: waterLevel() method
Figure 3.2.5 shows the powerLevel() function of the main system software. The powerLevel()
function will take the voltage coming off of the battery and compare it to a hardcoded reference
value. It will calculate an estimated voltage level based on the two values and store it in memory.
Start
Read in Power Level
Voltage
Calculate Power Level
%
Wait
Store Level % in
Memory
Fig. 3.2.5: powerLevel() method
Figure 3.2.6 shows the isOn() function of the main system software. isOn() takes a voltage from
various sources after it has been converted to a digital signal by an ADC. The isOn() function
28 then checks the voltage and the current device status flag and decides whether or not the flag
should be set or reset.
Read in Voltage
Level
Start
Is Voltage >
0V?
N
Is Flag Set?
Y
Y
Y
Reset ON
Flag
N
Is Flag Set?
N
Set ON Flag
Fig. 3.2.6: isOn() method
Figure 3.2.7 shows the waterLevel() function of the main system software. The waterAlarm()
function takes the water level that was calculated by the waterLevel() function and uses it to
decide whether or not any alarm flags need to be set or reset. There are two different flags that
can be tripped for this function. The two flags are water level above 50% and water level above
80%. It will also reset the flags if it decides the specified alarm condition is no longer valid.
29 Start
Read Water
Level
N
Is Level
Above 50%?
N
50% Flag
Active
Y
Reset 80%
Water Level
Flag
Y
Reset 80%
Water Level
Flag
Y
50% Flag
Active?
Y
N
Set 50% Water
Level Flag
N
Is Level
Above 80%?
N
80% Alarm
Active?
Y
Y
80% Flag
Active?
N
Set 80% Water
Level Flag
Fig. 3.2.7: waterAlarm() method
Figure 3.2.8 shows the powerAlarm() function of the main system software. The powerAlarm()
function takes the backup battery level and decides whether or not any alarm flags need to be set
or reset. For the power alarm there will be three levels that can be tripped. These three levels are
tripped when the battery is less than 50%, 25% and completely dead. If the main power is on
then all alarm flags will be set to off.
30 Get Main Power
Status
Start
Reset All
Battery Flags
Y
Is Main Power
ON?
N
Get Current
Battery Level
N
Is Level <=
50%
Y
Is 50% Flag
Set?
N
Set 50% Level
Flag
N
Set 25% Level
Flag
N
Set Dead
Battery Flag
Y
N
Is Level <=
25%
Y
Is 25% Flag
Set?
Y
N
Is Battery
Dead?
Y
Y
Is Dead
Battery Flag
Set?
Fig. 3.2.8: powerAlarm() method
Figure 3.2.9 shows the pumpAlarm() function of the main system software. The pumpAlarm()
function checks the status of the two pumps to make sure they are working like they should. If
the water level rises above a certain point (25%), it will then check to see if the main power is
on. Depending on if the main power is on, it will then check either the primary or secondary
pump and if the pump is not running it will set the appropriate alarm flag.
31 Start
Get Water Level, Main
Power Status, Primary and
Secondary Pump Statuses,
and Backup Battery Level
N
Water Level
>= 25%?
Y
Is Main Power
ON?
Y
Y
Y
Is Primary
Pump ON?
N
Is Primary
Flag Set?
N
N
Is Backup
Battery Dead?
Set Primary
Flag
Y
N
Y
Is Secondary
Pump ON?
N
Is Secondary
Flag Set?
N
Set Secondary
Flag
Y
Fig. 3.2.9: pumpAlarm() method
Figure 3.2.10 shows the activateAlarm() function of the main system software. The
activateAlarm() function will run every couple of seconds and activate a specified audio alarm.
The main purpose of activateAlarm() is to prioritize the various audio alarms that the system
supports and output the highest priority alarm, that is currently activated, to the speaker. To do
this it will run through all the alarm flags in the system, starting with highest priority first, and
will sound the first active alarm that it hits.
32 Start
Water Level
80%?
Y
Sound Water
Level 80% Alarm
Y
Sound Water
Level 50% Alarm
Y
Sound Battery
Dead Alarm
Y
Sound
Secondary Out
Alarm
Y
Sound Battery at
25% Alarm
Y
Sound Battery at
50% Alarm
Y
Sound Primary
Out Alarm
Y
Sound Main
Power Out Alarm
Y
Sound Test
Alarm
N
Water Level
50%?
N
Dead Battery?
N
Secondary
Pump Flag?
N
Battery 25%?
N
Battery 50%?
N
Primary Pump
Flag?
N
Main Power
Off?
N
Is Test Button
Pressed?
N
Fig. 3.2.10: activateAlarm() method
33 3.3
Communication (By Aaron)
Communication is an important aspect of the Flood Alert! Sump Pump Monitoring System. It is
important that the data obtained by the system is available to the user by use of a mobile
application. Multiple steps are required for this to be possible. The Flood Alert! system will
make use of a GSM/GPRS shield to communicate over a cellular network. This device will be
powered by the Arduino Mega 2560 and therefore not require its own backup power supply. It
will also not require an in home network connection such as Ethernet or wireless. This will allow
the system to continue to send data to the network if a main power outage occurs. If it was
connected to a network via Ethernet or wireless, then for the system to work during a power
outage, the user would need to provide backup power to their router and modem. The
GSM/GPRS shield will create a more convenient user experience, and provide a more efficient
design. Fig. 3.3.1 shows the GSM/GPRS module and evaluation board we will be using for this
project.
Fig. 3.3.1: GSM/GPRS Evaluation Board and SM5100B-D GSM/GPRS Module
The SM5100B-D module has the ability of performing most of the same tasks as a normal
cellular phone. It requires an antenna, SIM card and power to operate. It also has audio in for a
microphone, audio out for a speaker, and the ability to connect an LCD and keypad to it. We will
not be using these features however. We are simply interested in the ability to send data over a
34 cellular network. Fig. 3.3.2 shows the block diagram of the SM5100B-D provided by
SENDTRUE. It shows the key components of the module. Table 3.3.1 lists the key features of
the module and gives information that will be needed when implementing the design.
Fig. 3.3.2: SM5100B-D Block Diagram Provided By SENDTRUE
35 Table 3.3.1: Key Features of the SM5100B-D Provided by SENDTRUE
The Atmega2560 and the SM5100B-D module will communicate using UART (Universal
Asynchronous Receiver/Transmitter) serial communication. The transmit pin on the Atmega2560
will be connected to the receive pin on the SM5100B-D, and the receive pin on the Atmega2560
will be connected to the transmit pin on the SM5100B-D. Fig. 3.3.3 shows the connections
between the two devices. The module will be powered by the 3.3V output on the Arduino.
36 Atmega2560
SM5100B-D
TX0(Pin 1)
RX
RX0(Pin 0)
TX
5V
Vin
GND
GND
Fig. 3.3.3: Connection between Atmega2560 and SM5100B-D Using UART Serial
Communication
In order for the SM5100B-D to make a connection to a cellular network, it requires an antenna
and SIM card. The antenna requires a SMA connection and an RF interface impedance of 50
ohms. The antenna we will be using is a quad-band cellular antenna. It will work on four major
cellular frequencies: 850, 900, 1800, and 1900 MHz. The GSM/GPRS protocol is used over 850
MHz and 1900 MHz. The evaluation board has a SIM socket which will house a standard 6-pin
activated SIM card. We will use an AT&T SIM card which operates on GSM850. Once the
activated SIM card and antenna are connected to the evaluation board housing the SM5100B-D
module, the system should be able to establish a network connection. At this point, the Arduino
will be able to send data to a server which will store the data in a SQL database. The server will
contain a script file which will accept connections from the Arduino, grab the sent data, and
parse it to the database. The following is pseudo code for the GPRS to establish a network
connection and send the data to the server side script file.
Initialize serial ports for communication
Set command to connect to correct cellular network
Main loop()
{
If (firstTime)
{
Establish network connection()
firstTime = false
}
Retrieve data to send()
Send data to cell network and server(data)
37 Delay 30 seconds
}
Establish network connection()
{
While (GPRS is not connected and not ready)
{
Read incoming response strings from cellular network
Check for successful connection
}
}
Retrieve data to send()
{
Get water level data
Get power level data
Get power on/off data
Get pump status data
Create string of all data to send to server
}
Send data to cell network and server(data)
{
Send ATCommand to configure TCP connection to server
Start TCP connection with server
Delay some amount of time
Send data to server
Close connection
}
The data packet is sent to a given IP address. In this case it would be the address of the TCP
server. The TCP server contains a script file as stated above that collects the data and stores the
information in a selected database. The following is the pseudo code for that process:
Open necessary ports on server
While(1)
{
Listen for incoming connections
Grab data from GPRS packet
Parse data
Establish connection to database
Send parsed data to database
}
38 The SQL database will store all the information that is gathered by the Arduino Mega 2560 and
sent over the network to the server. The data will be stored in a table, and as new data is
collected, it will simply be added to the existing table. Therefore, older data will be able to be
looked up if needed. Once the data is stored in the database, the mobile application will be able
to pull the data needed and display it to the user in a user friendly environment.
3.4
Mobile Application Software: (By Jason)
Figures 3.4.1 through 3.4.3 give details on how data will be received from the server and
interpreted by the mobile application. The mobile application will be used to provide the user
with critical details of their system from wherever they are.
Audio Alerts
Data
User Input
Mobile Application
Visuals
Fig. 3.4.1: Mobile Application Block Diagram (Level 0)
Figure 3.4.1 shows the inputs and outputs of the mobile application. The phone will receive data
packets from a server containing critical system information. The phone’s touch interface will be
utilized to allow the user to interact with the application. The application will provide the user
with visual readouts of the system information, as well as provide them with alerts when there is
a potential system failure.
39 Mobile Application
Data from
Server
Data Collection/
Parser
Water
Calculations
Backup
Power
Calculations
Sump Pump
Data
(Operating?)
Main Power
(Yes/No)
Visuals
Software Main
User Input
from Phone
User
Interface
Audio Alerts/Messages to
Phone
Mode
Selector
Fig. 3.4.2: Mobile Application Block Diagram (Level 1)
Figure 3.4.2 provides more information on how data will be processed in order to provide the
user with the needed information. Data will be received as a TCP/IP packet and will be separated
into individual data packets by a parser. The parser will provide the correct data to each class in
the code in order for the correct calculations to be made. Once the calculations are made and
checked against pre-defined tolerances, the data will be displayed to the user in an easy to read
fashion, and the necessary alerts will be made. The phone’s touch interface will be used to allow
the user to easily switch between pages of information and to acknowledge alerts.
40 Figure 3.4.3: Communications between Android device and SQL server
One of the most important aspects of the mobile application will be to retrieve the information
uploaded to the SQL server from the microcontroller. The information from the server will be
used to display data values and alerts the user. Figure 3.4.3 above shows how the mobile device
will communicate with the SQL server. The way the application will retrieve the data is through
the use of a PHP script. The application will send an HttpPost using Android’s HTTP protocol to
a PHP script that is hosted on the web server. The PHP script will perform a query on the SQL
server and retrieve the necessary information to send back to the device. Once the PHP script has
performed its query and obtained the data, it will organize the information into JavaScript Object
Notation (JSON) format and send it to the device. JSON format is a very simple notation that
will be easy for the application to parse through. The following is an outline of the code that will
be used to retrieve information from the server.
Android Code
try {
Create a new HttpClient
Create a new HttpPost to the location of the PHP script
Set entity to store the returned data to
Execute the HttpPost and store the response
Get the values from the entity
}
41 PHP Script Code
<?php
Connect to the SQL server by sending host name, username, and password
Select the correct database from the server
Query the database for necessary information
Save the contents to an output vector
Send the output in JSON format
Close the connection
?>
Fig. 3.4.4: Software Block Diagram/Flowchart for Mobile Application (Level 2)
42 Figure 3.4.3 shows a software flow diagram of how data will be interpreted by the application.
As stated above, data will be received by the phone and enter a parser where it will be divided
into separate values. These values will be checked against tolerances set in the code. If a certain
value goes above or below the pre-defined tolerance, the user will be alerted. All of this
information will be presented to the user with an easy to use GUI and will be controlled using the
phone’s touch screen interface.
3.4.1
Mobile Application Theory of Operation
The mobile application will be used to provide critical information to the user wherever they are.
The application will receive and interpret system information such as water level, remaining
battery charge, power status, and equipment status to display to the user. The mobile application
will be designed to work on an Android smart phone connected to a 3G network. The phone will
receive information containing the system data over the network and display it in a way that is
simple for the user to read. In the event of a system malfunction or a problem (such as high water
level), the phone will alert the user with a push notification.
3.4.2
Mobile Application Design Modules
Module
Designer
Inputs
Outputs
Functionality
3.5
Mobile Application
Jason Ulbricht
JSON Data from SQL Server, User Input
Audio Alerts/Messages to Phone
The mobile app will pull data from a SQL server holding the data from the pump system. The data will be displayed on the device screen, and allow the user to view critical system details such as current water l evel and battery charge. It will also play audio alerts i f a situation i s occuring that the user should be notified of. The i nterface will display visuals of the water and backup power l evels.
Power (By Matt)
Power outages are the primary reason for sump pump system failure. Battery operated backup
systems have become a popular solution to this problem. In addition to pump functionality, our
system also requires that the microcontroller stay on throughout a power outage. Figure 3.5.1
shows how this task will be handled.
43 Main Controller Power
Supply
120 VAC
120VAC to
12VDC
Power Supply
9V Battery
9V
To Main Controller
Fig. 3.5.1: Main System Controller Power Supply (Level 1)
The microcontroller requires a 7-12V DC power supply. While operating on main power, this
power will be provided by a 120V AC to 12V DC power supply connected directly to a wall
outlet. The power supply will be used to continuously charge a 9V NiMH battery as well as
power the controller. In the event of a power failure, the system will continue to operate from
power provided by the 9V NiMH battery. Figure 3.5.2 shows the process in which a power
outage will be detected and the system will switch to backup power.
Main Controller Power Supply
120 VAC
120VAC to
12VDC
Power Adapter
Vin
D
R5 = 50Ω
9V
Battery
BT1
GND
Fig. 3.5.2: Main System Controller Power Supply (Level 2)
In the event of a power failure, the controller will automatically switch from main power to
backup power provided by the 9V rechargeable battery. The Arduino will pull power from the
higher power source, so when the 12V supply is lost, it will start pulling from the battery. The
diode keeps the current from going back into the power adapter. The resistor will lower the
current across the battery and help keep from overcharging.
44 Arduino Mega 2560
PS
3.6
Design Calculations
Design calculations for power have been done using both a 1/3 hp sump pump as well as a ½ hp
sump pump as we have yet to determine which we will be using. It is most likely that we will be
using the 1/3 hp pump. A 1/3 hp sump pump typically uses 800 W while running and 1600 W
during start-up, while a ½ hp pump will use 1050 W running and 2100W upon start-up. Knowing
that the sump pump will take 120 V AC from the wall outlets, we can determine the amount of
current that our power supply and inverter must be able to handle. Calculations for the current
for the 1/3 hp pump (equations 1 and 2) are as follows:
𝐼!"##$#% = 𝐼!"#$"!!" =
!!"##$#%
!
!!"#$"!!"
=
=
!
!""!
= 6.6𝐴 (1)
!"#!
!"##!
!"#!
= 13.33𝐴 (2)
Calculations for current for the ½ hp pump (equations 3 and 4) are as follows:
𝐼!"##$#% = 𝐼!"#$"!!" =
3.6.1
!!"##$#%
!
!!"#$"!!"
!
=
!"#"!
=
!"##!
!"#!
!"#!
= 8.7𝐴 (3)
= 17.5𝐴 (4)
Battery Level Calculations
To determine the level of battery needed to supply the sump pump, we used Peukart’s equation
as equation 5.
(𝐶! = 𝐼 ! 𝑡) (5)
The equation can be rewritten in the following form as equation 6 to determine the rated capacity
of the desired battery/power supply:
!
(𝑡 = 𝐻(!")! ) (6)
This rearranged equation allows for calculation of the battery rating for amp hours given a
known output current. “T” represents the actual time for the battery to fully discharge, “H” the
rated discharge time of the battery in hours, “C” the rated capacity of the battery at that given
45 discharge rate, “I” the actual discharge current, and “k” Peukart’s constant. This equation gives
the relationship between the capacity of the battery in amp hours, the actual discharge rate, and
the actual time to discharge the battery. In general, it is not good practice to discharge a battery
until it is completely empty, so the time to discharge the battery 60% was used to determine the
desired amp hour rating of the battery/power supply. Knowing that the desired time for the
system to operate on battery power was 3 to 5 hours, 4 hours was divided by .6 to give the actual
time for battery discharge of 6.67 hours. Taking the fact that k=1.2 and that most batteries are
tested at 20 hours by the manufacturer, the resulting equation (equation 7) was:
!
(6.67 = 20( !.!
!"
)!.! ) (7)
Solving for C, it was determined that the chosen battery/power supply needs to be at least 53
amp hours tested at 20 hours.
3.6.2
Voltage Divider Calculations
To calculate the water level in our sump, we will be taking a variable voltage and a reference
voltage from the water level sensor. To give the board the ability to read these voltages we will
send them through a respective voltage divider. This can be seen in Figure 3.1.10, 3.1.11, and
3.1.12. The equation for a voltage divider is given by equation 8.
𝑉! = !!"#!"
!! ! !!"#!"
∙ 𝑉! (8)
The resistors Rsense and Rref are given by the water level sensor, but we control the values of
the resistors R1 and R2. To find appropriate values for R1 and R2 we first found the required R1
to get a V1 of 3.3v for a maximum and minimum value of Rsense using equation 9.
𝑅! =
!!"#!" (!! !!! )
!!
(9)
From this we found that 1,546 ohms should be the absolute minimum value for the resistor to keep the
incoming voltage within a safe range. We decided to round up and go with a 2k ohm resistor. Since Rref
is equivalent to Rsense at its highest value, we decided use the same resistance for R2 as well.
46 4
Parts List
The complete parts list for the project is given in Table 4.1.1. The Refdes column gives the
reference description for each component used in the technical drawings.
Qty.
1
1
1
3
1
1
1
1
3
1
2
2
2
2
2
2
1
1
1
2
2
1
1
2
Refdes
U1
U2
AE1
CS
SW1
WS
LS
DS
BT1
Rc
BT2
D
R5
R1, R2
R3,R6
R4
PS
Part Num.
DEV-11061
CEL-09607
CEL-00290
SEN-11005
PRT-10007
BWEL
COM-09190
PN-6573TC-24
CVS-3108
NHD-0420E2Z-FSWGBW
NH22NBP
EVU-F2MFL3B14
A000032
TU0159
PVC 07112 0600
PVC 00321 0800
24EP6
1N1115
PAC100005009FA1000
ERD-S2TJ202V
1-1625885-3
ERG-1SJ302
TOL-09442
PRT-09518
1
Description
Arduino Mega 2560 R3
Cellular Shield with SM5100B
Quad-band Wired Cellular Antenna SMA
Non-Invasive Current Sensor-30A
Arduino Stackable Header Kit
Basement Watchdog 1000 GPH Battery Backup Sump
Pump
Momentary Push Button Switch
24-inch (600mm) eTape Liquid Level Sensor
8-Ohm Piezo Speaker
Newhaven Display 4x20 LCD
Rechargeable 9V Battery from Energizer
Panasonic10 kΩ Potentiometer
Arduino Bread Board/Wire Kit
United Solutions 20-Gallon Plastic Tub
1-1/2” PVC Pipe 10’ Sections
1-1/2” PVC 45 Degree Fitting
Basement Watchdog 6hr Emergency Battery
D, 100V, 1.5A, DO-3
50 Ohm resistor
2k Ohm resistor
10K ohm resistor
3K ohm resistor
120V-12Vdc Power Supply
9V to Barrel Jack Adapter
AT&T Activated SIM Card $25/mo + $5/mo Data Pre-Paid
Plan
Table 4.1.1: Parts List
Table 4.1.2 shows the revised material cost for producing the Flood Alert! Sump Pump Monitoring
System. Much of the cost is associated with buying the sump pump system and batteries that will simulate
a current day backup sump pump system. The communication aspect is also expensive with the need of an
activated SIM card and cellular data plan.
47 Qty.
1
1
1
3
1
1
1
1
3
1
2
2
2
2
2
2
1
1
1
2
2
1
1
2
1
Part Num.
DEV-11061
CEL-09607
CEL-00290
SEN-11005
PRT-10007
BWEL
COM-09190
PN-6573TC-24
CVS-3108
NHD-0420E2Z-FSW-GBW
NH22NBP
EVU-F2MFL3B14
A000032
TU0159
PVC 07112 0600
PVC 00321 0800
24EP6
1N1115
PAC100005009FA1000
ERD-S2TJ202V
1-1625885-3
ERG-1SJ302
TOL-09442
PRT-09518
Description
Arduino Mega 2560 R3
Cellular Shield with SM5100B
Quad-band Wired Cellular Antenna SMA
Non-Invasive Current Sensor-30A
Arduino Stackable Header Kit
Basement Watchdog 1000 GPH Battery Backup Sump Pump
Momentary Push Button Switch
24-inch (600mm) eTape Liquid Level Sensor
8-Ohm Piezo Speaker
Newhaven Display 4x20 LCD
Rechargeable 9V Battery from Energizer
Panasonic10 kΩ Potentiometer
Arduino Bread Board/Wire Kit
United Solutions 20-Gallon Plastic Tub
1-1/2" PVC Pipe 10' Sections
1-1/2" PVC 45 Degree Fitting
Basement Watchdog 6hr Emergency Battery
D, 100V, 1.5A, DO-3
50 Ohm resistor
2k Ohm resistor
10K ohm resistor
3K ohm resistor
120V-12Vdc Power Supply
9V to Barrel Jack Adapter
AT&T Activated SIM Card $25/mo + $5/mo Data Pre-Paid Plan
Unit
Cost
$58.95
99.95
11.95
9.95
1.50
147.00
0.50
49.99
3.60
28.20
10.99
1.40
12.97
7.98
3.99
0.80
94.00
0.00
0.97
0.09
0.12
0.34
5.95
2.95
30.00
Total
Cost
$58.95
99.95
11.95
29.85
1.50
147.00
0.50
49.99
10.80
28.20
21.98
2.80
25.94
15.96
7.98
1.60
94.00
0.00
0.97
0.18
0.24
0.34
5.95
5.90
30.00
Total
$652.53
Table 4.1.2: Revised Material Cost
5
Project Schedules
In order to complete this project on time it is necessary to have a schedule planned out. To stay
on schedule, different parts of this paper and the final design will be completed by certain dates.
We have constructed a project ghant chart using Microsoft Project 2007. Table 4.1.1 shows our
48 midterm design ghant chart. This contains the schedule of our design process for the first
semester of senior design. During this time period, we are to come up with our design for how to
make our project work, and determine what parts we will need to achieve our goals. Figure 4.1.2
shows the implementation ghant chart, which indicates our schedule for next semester. The final
demonstration of our project will be April 12, 2013. This is the date we need to have the entire
system built and ready by, in order to demonstrate it to the school.
ID
Task Name
1
Sump Pump Overflow Alarm Design
Duration
Start
############ Fri 8/31/12
Finish
Predecessors
Resource Names
Wed 11/14/12
2
3
4
5
6
7
8
9
10
11
12
13
Prelim inary De sign Report
Problem Statement
Need
Objective
Background
Marketing Requirements
Objective Tree
Preliminary Design Gantt Chart
Block Diagrams Lev el 0 w / FR tables
Hardware modules (identify designer)
Softw are modules (identify designer)
14 days
Fri 8/31/12
Fri 9/14/12
14 days
7 days
7 days
7 days
7 days
7 days
14 days
7 days
7 days
7 days
Fri 8/31/12
Fri 8/31/12
Fri 8/31/12
Fri 8/31/12
Fri 8/31/12
Fri 9/7/12
Fri 8/31/12
Fri 9/7/12
Fri 9/7/12
Fri 9/7/12
Fri 9/14/12
Fri 9/7/12
Fri 9/7/12
Fri 9/7/12
Fri 9/7/12
Fri 9/14/12
Fri 9/14/12
Fri 9/14/12
Fri 9/14/12
Fri 9/14/12
Matt Boston
Derek Brooks
Jason Ulbricht
Aaron Nervi
Aaron Nervi
Jason Ulbricht
Matt Boston
14
System Software
7 days
Fri 9/7/12
Fri 9/14/12
Derek Brooks,Aaron Nervi
15
Mobile Application
7 days
Fri 9/7/12
Fri 9/14/12
Jason Ulbricht
16
17
Prel imi nary Desi gn Presentation 3:15PM ASEC 120
Fri 9/14/12 13
0 days
Fri 9/14/12
30 days
Sat 9/15/12
Mon 10/15/12
13 days
13 days
7 days
7 days
7 days
7 days
7 days
7 days
7 days
7 days
13 days
13 days
Sat 9/15/12
Sat 9/15/12
Fri 9/28/12
Fri 9/28/12
Fri 9/28/12
Fri 9/28/12
Fri 9/28/12
Fri 9/28/12
Fri 9/28/12
Fri 9/28/12
Sat 9/15/12
Sat 9/15/12
Fri 9/28/12
Fri 9/28/12
Fri 10/5/12
Fri 10/5/12
Fri 10/5/12
Fri 10/5/12
Fri 10/5/12
Fri 10/5/12
Fri 10/5/12
Fri 10/5/12
Fri 9/28/12
Fri 9/28/12
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Midterm Report
Design Requirements Specification
Midterm Design Gantt Chart
Design Calculations
Electrical Calculations
Wireless Communication
Mobile Device Computing
Control Systems
Power, Voltage, Current
Mechanical Calculations
Water Reservoir Dimensions
Block Diagrams Lev el 1 w / FR tables & ToO
Hardw are modules (identify designer)
Jason Ulbricht
Aaron Nervi
Jason Ulbricht
Derek Brooks
Matt Boston
Jason Ulbricht
32
Level Sensor
13 days
Sat 9/15/12
Fri 9/28/12
Derek Brooks
33
AC Power
13 days
Sat 9/15/12
Fri 9/28/12
Matt Boston
34
Battery Backup
13 days
Sat 9/15/12
Fri 9/28/12
Matt Boston
35
Alarm
13 days
Sat 9/15/12
Fri 9/28/12
Jason Ulbricht
36
Controller
13 days
Sat 9/15/12
Fri 9/28/12
Aaron Nervi
13 days
Sat 9/15/12
37
Softw are modules (identify designer)
Fri 9/28/12
38
System Software
13 days
Sat 9/15/12
Fri 9/28/12
Derek Brooks
39
Mobile Applicatioin
13 days
Sat 9/15/12
Fri 9/28/12
Jason Ulbricht
7 days
7 days
Fri 9/28/12
Fri 9/28/12
40
41
Block Diagrams Lev el 2 w / FR tables & ToO
Hardw are modules (identify designer)
Fri 10/5/12
Fri 10/5/12
42
Level Sensor
7 days
Fri 9/28/12
Fri 10/5/12
Aaron Nervi
43
AC Power
7 days
Fri 9/28/12
Fri 10/5/12
Matt Boston
44
Battery Backup
7 days
Fri 9/28/12
Fri 10/5/12
Matt Boston
45
Alarm
7 days
Fri 9/28/12
Fri 10/5/12
Jason Ulbricht
46
Controller
7 days
Fri 9/28/12
Fri 10/5/12
Derek Brooks
49 Aaron Nervi,Jason Ulbricht
ID
47
Task Name
Duration
Softw are modules (identify designer)
7 days
Start
Finish
Fri 9/28/12
Fri 10/5/12
Predecessors
Resource Names
48
System Software
7 days
Fri 9/28/12
Fri 10/5/12
Aaron Nervi
49
Software Flow Diagrams
7 days
Fri 9/28/12
Fri 10/5/12
Derek Brooks
50
Mobile Application
7 days
Fri 9/28/12
Fri 10/5/12
Jason Ulbricht
51
52
Block Diagrams Lev el N+1 w / FR tables & ToO
Hardw are modules (identify designer)
10 days
10 days
Fri 10/5/12
Fri 10/5/12
Mon 10/15/12
Mon 10/15/12
53
Level Sensor
10 days
Fri 10/5/12
Mon 10/15/12
Aaron Nervi
54
AC Power
10 days
Fri 10/5/12
Mon 10/15/12
Matt Boston
55
Battery Backup
10 days
Fri 10/5/12
Mon 10/15/12
Matt Boston
56
Alarm
10 days
Fri 10/5/12
Mon 10/15/12
Jason Ulbricht
57
Controller
10 days
Fri 10/5/12
Mon 10/15/12
Derek Brooks
58
GPRS
10 days
Fri 10/5/12
Mon 10/15/12
Aaron Nervi
59
LCD
10 days
Fri 10/5/12
Mon 10/15/12
Jason Ulbricht
60
Softw are modules (identify designer)
10 days
Fri 10/5/12
Mon 10/15/12
61
System Software
10 days
Fri 10/5/12
Mon 10/15/12
Aaron Nervi
62
Mobile Application
10 days
Fri 10/5/12
Mon 10/15/12
Jason Ulbricht
11 days
Mon 10/15/12
Fri 10/26/12
30.38 days
Mon 10/15/12
W ed 11/14/12
63
64
Proje ct Poste r
65
66
Final Design Re port
67
Abstract
68
Softw are Design
Modules 1…n
69
70
Mobile Application
Mon 10/15/12
Mon 10/22/12
21 days
Mon 10/22/12
Mon 11/12/12
21 days
Mon 10/22/12
Mon 11/12/12
13.63 days
Mon 10/22/12
Mon 11/5/12
Jason Ulbricht
71
Mobile Application Flow Chart
7 days
Mon 10/22/12
Mon 10/29/12
Jason Ulbricht
72
SQL Communication
7 days
Mon 10/29/12
Mon 11/5/12
Jason Ulbricht
73
PHP Script
7 days
Mon 10/29/12
Mon 11/5/12
Jason Ulbricht
74
System Software Pseudo Code
7 days
Mon 10/22/12
Mon 10/29/12
Derek Brooks
75
Software Flowcharts
7 days
Mon 10/29/12
Mon 11/5/12
Derek Brooks
76
Water Level Method
7 days
Mon 10/29/12
Mon 11/5/12
Derek Brooks
77
Power Level Method
7 days
Mon 10/29/12
Mon 11/5/12
Derek Brooks
78
Is Device On Method
7 days
Mon 10/29/12
Mon 11/5/12
Derek Brooks
79
Water Alarm Method
7 days
Mon 10/29/12
Mon 11/5/12
Derek Brooks
80
Power Alarm Method
7 days
Mon 10/29/12
Mon 11/5/12
Derek Brooks
81
Pump Alarm Method
7 days
Mon 10/29/12
Mon 11/5/12
Derek Brooks
82
Activate Alarm Method
7 days
Mon 10/29/12
Mon 11/5/12
Derek Brooks
14 days
Mon 10/22/12
Mon 11/5/12
83
Communications
84
GPRS Pseudo Code
7 days
Mon 10/22/12
Mon 10/29/12
Aaron Nervi
85
TCP Server Pseudo Code
7 days
Mon 10/29/12
Mon 11/5/12
Aaron Nervi
7 days
Mon 11/5/12
Mon 11/12/12
30 days
Mon 10/15/12
W ed 11/14/12
86
87
88
LCD Interfacing
Hardw are Design
Modules 1…n
Jason Ulbricht
30 days
Mon 10/15/12
W ed 11/14/12
89
Power Simulations
7 days
Mon 10/15/12
Mon 10/22/12
Matt Boston
90
Water Level Simulations
7 days
Mon 10/15/12
Mon 10/22/12
Derek Brooks
91
Battery Level Sensor Schematics
7 days
Mon 10/15/12
Mon 10/22/12
Aaron Nervi
92
AC Power Schematics
7 days
Mon 10/15/12
Mon 10/22/12
Jason Ulbricht
93
BatteryBackup Schematics
14 days
Mon 10/22/12
Mon 11/5/12
Matt Boston
94
Sump Pump Battery
7 days
Mon 10/22/12
Mon 10/29/12
Matt Boston
95
Power for Arduino Controller
14 days
Mon 10/22/12
Mon 11/5/12
Matt Boston
96
Schematics
7 days
Mon 10/22/12
Mon 10/29/12
Matt Boston
97
Rechargeable Battery
7 days
Mon 10/29/12
Mon 11/5/12
Matt Boston
98
Alarm Schematics
7 days
Mon 10/29/12
Mon 11/5/12
99
Speaker
7 days
Mon 10/29/12
Mon 11/5/12
Jason Ulbricht
7 days
Mon 10/22/12
Mon 10/29/12
Derek Brooks
30 days
Mon 10/15/12
W ed 11/14/12
Aaron Nervi
100
Controller Schematics
101
GPRS Board Schematics
Jason Ulbricht
102
Antenna
7 days
Mon 10/22/12
Mon 10/29/12
Aaron Nervi
103
SIM Card Information
7 days
Wed 11/7/12
Wed 11/14/12
Aaron Nervi
104
Connections to Arduino
7 days
Mon 10/15/12
Mon 10/22/12
Aaron Nervi
Jason Ulbricht
105
LCD Display Schematics
7 days
Wed 11/7/12
Wed 11/14/12
106
User Interface- Push button Info
7 days
Mon 10/29/12
Mon 11/5/12
30 days
Mon 10/15/12
W ed 11/14/12
107
Parts Request Form
Aaron Nervi
108
Microcontroller
2 days
Mon 10/29/12
Wed 10/31/12
109
GPRS Board
5 days
Wed 10/31/12
Mon 11/5/12
110
Antenna
2 days
Mon 11/5/12
Wed 11/7/12
111
UPS/Batteries
7 days
Mon 10/15/12
Mon 10/22/12
Matt Boston
112
Pumps
7 days
Mon 10/15/12
Mon 10/22/12
Jason Ulbricht
113
SIM Card
7 days
Wed 10/31/12
Wed 11/7/12
114
Reservoir
1 day
Mon 11/5/12
Tue 11/6/12
115
Level Sensor
7 days
Mon 10/22/12
Mon 10/29/12
Derek Brooks
116
Miscellanious Parts
7 days
Wed 11/7/12
Wed 11/14/12
Matt Boston
Wed 11/14/12
Jason Ulbricht
117
5 days
Budget (Estimated)
50 7 days
Fri 11/9/12
Derek Brooks
Aaron Nervi
Aaron Nervi
Jason Ulbricht
ID
118
Task Name
Duration
Construct Presentation
Start
Finish
7 days
W ed 11/7/12
W ed 11/14/12
Predecessors
Resource Names
119
Hardware Theory
7 days
Wed 11/7/12
Wed 11/14/12
Matt Boston
120
Software Theory
7 days
Wed 11/7/12
Wed 11/14/12
Derek Brooks
121
Communication
7 days
Wed 11/7/12
Wed 11/14/12
Aaron Nervi
122
Mobile Application
7 days
Wed 11/7/12
Wed 11/14/12
Jason Ulbricht
7 days
W ed 11/7/12
W ed 11/14/12
123
Implementation Gantt Chart
124
Hardware Implementation
7 days
Wed 11/7/12
Wed 11/14/12
Matt Boston
125
System Software Implementation
7 days
Wed 11/7/12
Wed 11/14/12
Derek Brooks
126
Wireless Communicaion Implementation
7 days
Wed 11/7/12
Wed 11/14/12
Aaron Nervi
127
Mobile Application Implementation
7 days
Wed 11/7/12
Wed 11/14/12
Jason Ulbricht
7 days
Wed 11/7/12
Wed 11/14/12
Derek Brooks
128
Conclusions and Recommendations
129
130
131
132
133
Final Design Pres entation Part 1 3:15PM ASEC 120
Final Design Pres entation Part 2 3:15PM ASEC 120
0 days
0 days
Our Final Presentation
Fri 11/16/12
Fri 11/30/12
0 days
Final Design Pres entation Part 3 3:15PM ASEC 120
0 days
Fri 11/16/12
Fri 11/30/12
Fri 11/30/12
Fri 11/30/12
Fri 12/7/12
Fri 12/7/12
Table 5.1.1: Midterm Design Ghant Chart
ID
Task Name
1
Revise Gantt Chart
2
Implement Project Design
3
4
Duration
Hardware Implementation
Finish
8 days
Mon 1/14/13
Tue 1/22/13
81 days
Mon 1/14/13
Fri 4/5/13
42 days
Mon 1/14/13
Mon 2/25/13
7 days
Mon 1/14/13
Mon 1/21/13
Breadboard Components
Predecessors
Week Resource Names
1 Aaron Nervi
5
LCD
7 days
Mon 1/14/13
Mon 1/21/13
Jason Ulbricht
6
Speaker
7 days
Mon 1/14/13
Mon 1/21/13
Jason Ulbricht
7
GPRS Wiring
7 days
Mon 1/14/13
Mon 1/21/13
Aaron Nervi
8
Water Level Sensor Wiring
7 days
Mon 1/14/13
Mon 1/21/13
Derek Brooks
9
Battery Level Wiring
7 days
Mon 1/14/13
Mon 1/21/13
Matt Boston
10
Layout and Generate PCB(s)
14 days
Mon 1/21/13
Mon 2/4/13 5
3
11
Assemble Hardware
Mon 2/11/13 10
5
7 days
Mon 2/4/13
12
Assemble Water Sensor
7 days
Mon 2/4/13
Mon 2/11/13
Derek Brooks
13
Connect GPRS Board Componnets
7 days
Mon 2/4/13
Mon 2/11/13
Aaron Nervi
14
Setup Current Sensors
7 days
Mon 2/4/13
Mon 2/11/13
Matt Boston
15
Connect LCD Display to main controller
7 days
Mon 2/4/13
Mon 2/11/13
Jason Ulbricht
16
Setup Speaker
7 days
Mon 2/4/13
Mon 2/11/13
Jason Ulbricht
17
Set up sump pumps
7 days
Mon 2/4/13
Mon 2/11/13
Matt Boston
18
Set up water reservoir
7 days
Mon 2/4/13
Mon 2/11/13
7 days
Mon 2/11/13
19
Test Hardware
Mon 2/18/13 12
20
Test Water Level Sensor
7 days
Mon 2/11/13
Mon 2/18/13
21
Test Communications
7 days
Mon 2/11/13
Mon 2/18/13
Matt Boston
6
Derek Brooks
22
GPRS
7 days
Mon 2/11/13
Mon 2/18/13
Aaron Nervi
23
Server Side
7 days
Mon 2/11/13
Mon 2/18/13
Aaron Nervi
24
Test Sump Pumps
7 days
Mon 2/11/13
Mon 2/18/13
Matt Boston
25
Test Battery Level Monitor
7 days
Mon 2/11/13
Mon 2/18/13
Matt Boston
26
Test Current Sensors for Power Readings
7 days
Mon 2/11/13
Mon 2/18/13
Matt Boston
27
Test LCD Display
7 days
Mon 2/11/13
Mon 2/18/13
Jason Ulbricht
28
Test Speaker
7 days
Mon 2/11/13
Mon 2/18/13
Jason Ulbricht
29
Test Push Button
1 day
Mon 2/11/13
Tue 2/12/13
Matt Boston
30
Revise Hardware
7 days
Mon 2/11/13
Mon 2/18/13 11
31
MIDTERM: Demonstrate Hardware
7 days
Mon 2/18/13
Mon 2/25/13 19,30
8
32
SDC & FA Hardware Approval
0 days
Mon 2/25/13
Mon 2/25/13 31
9
51 Start
ID
33
34
Task Name
Duration
Software Implementation
Develop Software
Start
Finish
49 days
Mon 1/14/13
Mon 3/4/13
28 days
Mon 1/14/13
Mon 2/11/13
Predecessors
Week Resource Names
35
Main System Software for Arduino
28 days
Mon 1/14/13
Mon 2/11/13
Derek Brooks
36
GPRS Software
28 days
Mon 1/14/13
Mon 2/11/13
Aaron Nervi
37
LCD Interfacing
14 days
Mon 1/14/13
Mon 1/28/13
Jason Ulbricht
38
Mobile Application
28 days
Mon 1/14/13
Mon 2/11/13
Jason Ulbricht
39
Server Script Files (Receive)
14 days
Mon 1/21/13
Mon 2/4/13
Aaron Nervi
40
Server Script Files (Query)
14 days
Mon 1/21/13
Mon 2/4/13
Jason Ulbricht
41
SQL Server
28 days
Mon 1/14/13
Mon 2/11/13
14 days
Mon 2/11/13
42
Test Software
Mon 2/25/13 35
Aaron Nervi
5
43
Test Reading Sensor Data
7 days
Mon 2/11/13
Mon 2/18/13
Derek Brooks
44
Test Communications (GPRS) to Server
7 days
Mon 2/11/13
Mon 2/18/13
Aaron Nervi
45
Test LCD Display
7 days
Mon 2/18/13
Mon 2/25/13
Jason Ulbricht
46
Test Mobile Application
7 days
Mon 2/18/13
Mon 2/25/13
Jason Ulbricht
47
Test Physical Speaker Alarms
7 days
Mon 2/18/13
Mon 2/25/13
Derek Brooks
48
Revise Software
7 days
Mon 2/18/13
Mon 2/25/13 43
7
49
MIDTERM: Demonstrate Software
7 days
Mon 2/25/13
Mon 3/4/13 48
8
50
SDC & FA Software Approval
0 days
Mon 3/4/13
Mon 3/4/13 49
9
32 days
Mon 3/4/13
51
System Integration
Fri 4/5/13 49,32
52
Assemble Complete System
14 days
Mon 3/4/13
53
Test Complete System
18 days
Mon 3/18/13
Mon 3/18/13
Fri 4/5/13 52
54
Revise Complete System
18 days
Mon 3/18/13
Fri 4/5/13 52
55
Demonstration of Complete System
0 days
Fri 4/5/13
Fri 4/5/13 54
10
13
56
57
58
Develop Final Report
W rite Final Report
93 days
Mon 1/14/13
W ed 4/17/13
93 days
Mon 1/14/13
W ed 4/17/13
59
Add to Hardware Section
93 days
Mon 1/14/13
Wed 4/17/13
Matt Boston
60
Add Any Necessary Calculations
93 days
Mon 1/14/13
Wed 4/17/13
Matt Boston
61
Add to Power Section
93 days
Mon 1/14/13
Wed 4/17/13
Matt Boston
62
Add to Software Section
93 days
Mon 1/14/13
Wed 4/17/13
Derek Brooks
63
Add to Communication Section
93 days
Mon 1/14/13
Wed 4/17/13
Aaron Nervi
64
Add to Mobile Application Section
93 days
Mon 1/14/13
Wed 4/17/13
Jason Ulbricht
65
Keep Organized
93 days
Mon 1/14/13
Wed 4/17/13
Aaron Nervi
66
Proof Read and Edit if Necessary
7 days
Wed 4/10/13
Wed 4/17/13
0 days
Wed 4/17/13
Wed 4/17/13 59
67
Submit Final Report
15 Aaron Nervi
68
69
Martin Luther King Day- Universityclosed
0 days
Mon 1/14/13
Mon 1/14/13
70
Spring Recess
6 days
Mon 3/25/13
Sun 3/31/13
71
Project Demonstration and Presentation
0 days
Fri 4/12/13
Fri 4/12/13
12
72
Faraday Banquet
0 days
Fri 4/26/13
Fri 4/26/13
15
73
Senior Design Expo
0 days
Wed 4/24/13
Wed 4/24/13
Table 5.1.2: Implementation Ghant Chart
52 15
6
Design Team Information
Matt Boston, Electrical Engineering. Hardware Designer
Derek Brooks, Computer Engineering, Software Designer
Aaron Nervi, Computer Engineering, Archivist
Jason Ulbricht, Computer Engineering, Team Leader
7
Conclusions and Recommendations
The Flood Alert! Sump Pump Monitoring System is unique in its features and has the ability to
bring a sense of ease to homeowners. Our goal is to make a monitoring system that is easy to
install and can provide homeowners with critical information regarding their sump pump systems
that current systems do not provide. This system could help reduce and even prevent the damage
caused by in home flooding. Homeowners will be able to view the current status of their system,
and if a problem, such as flooding, is occurring; we hope that this system will give them enough
notice to act on the situation.
53 8
References
[1] “Android SDK Example Application/Sample Code.” Internet: http://www.datasprings.com/
resources/articles-information/android-sdk-example-application-sample-code, [Oct. 21, 2012].
[2] “Building Your First App.” Internet: http://developer.android.com/training/basics/firstapp/
index.html , [Oct. 19, 2012].
[3] Eckert, L. Frey, K. Graham, S. (2002). US Patent No. 6375430. Washington DC: US
[4] “How Stuff Works ‘How Sump Pumps Work’.” Internet: http://home.howstuffworks.com/
home-improvement/plumbing/sump-pump.htm, [Sep. 20, 2012].
[5] “Http Client Android Developers.” Internet: http://developer.android.com/reference/org/
apache/http/client/HttpClient.html , [Oct. 23, 2012].
[6] “Karnold/Cellular_gps_tracker.” Internet: https://github.com/karnold/cellular_gps_tracker,
[Nov. 5, 2012].
[7] Laughton, M.A.; Warne, D.F. (2003). Electrical Engineer's Reference Book (16th Edition).
Elsevier. Online version available at: http://www.knovel.com/web/portal/browse/display?
_EXT_KNOVEL_DISPLAY_bookid=1712&VerticalID=0
[8] “Measuring Battery Voltage with an ADC.” Internet: http://www.microbuilder.eu/Tutorials/
Fundamentals/MeasuringBatteryVoltage.aspx, [Oct. 27, 2012].
[9] “My SQL Database Hello Android.” Internet: http://www.helloandroid.com/tutorials/
connecting-mysql-database, [Oct. 25, 2012].
[10] “SP Technolab Blog.” Internet: http://blog.sptechnolab.com/2011/02/10/android/androidconnecting-to-mysql-using-php/, [Oct. 18, 2012].
[11] “Step-By-Step LCD Wiring (4 Bit Mode) and Programming Examples for Arduino.”
Internet: http://www.instructables.com/id/Step-By-Step-LCD-wiring-4-Bit-Mode-andProgrammi/, [Oct. 23, 2012].
[12] “Tracking the Island Resident with Arduino.” Internet: http://www.imamuseum.org/blog/
2012/06/26/tracking-the-island-resident-with-an-arduino/, [Nov. 3, 2012].
[13] “Tutorial: Arduino and GSM Cellular-Part 1.” Internet: http://tronixstuff.wordpress.com/
2011/01/19/tutorial-arduino-and-gsm-cellular-part-one/, [Oct. 29, 2012].
[14] Wu Jing and Chen Guojie. “Design of coal mine underground drainage pump monitoring
and controlling system based on PLC and touch screen,” present at the Mechatronic Science,
Electric Engineering and Computer (MEC), 2011 International Conference, 2011
54 9
Appendices
Part
Arduino Mega 2560
SM5100B-­‐D GSM/GPRS
eTape Water Level Sensor
Current Sensor
Speaker
Secondary Sump Pump
LCD
Datasheet Link
http://www.atmel.com/Images/doc2549.pdf
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Cellular/SM5100B-­‐
D_HW_spec_V1.0.0.pdf
http://www.milonetech.com/uploads/eTape_Datasheet_12110215TC-­‐
24.pdf
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/Current/ECS1
030-­‐L72-­‐SPEC.pdf
http://www.cui.com/Product/Resource/DigiKeyPDF/CVS-­‐3108.pdf
http://www.basementwatchdog.com/pdf/Basement%20Watchdog%20Br
ochure%20AC%20&%20Backup.pdf
http://www.newhavendisplay.com/specs/NHD-­‐0420E2Z-­‐FSW-­‐GBW.pdf
Fig. 9.1.1: Datasheet Links
55