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

i    

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

ii    

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

iii    

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

iv    

1    

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.

2    

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.

3    

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.

4    

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.

5    

Sump Pump Overflow Alarm

Alarm Operator when

Power Falls(0.40)

Alarm Operator when Water Level is High

(0.35)

Easy to Install

(0.25)

Easy to Operate

(0.75)

Small(0.25)

Know if Pump Has Power

(0.50)

System Continues

Working When There is No Main Power

(0.50)

Continue to Update User With Information Via Physical Alarm and Mobile Application

Measure the Water Level

(0.50)

Accurate(0.25)

Waterproof Level Sensor

(0.25)

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.

6    

Marketing  Requirements

Engineering  Requirements Justification

1 System  must  operate  off  of  120VACThe  system  will  be  powered  from  a  

standard  home  120V  outlet.

10Complete  system  should  last  at  least  3  

hours  on  backup  power

System  needs  to  continue  to  function  during  power  outages  to  keep  the  area  from  flooding  and  to  alert  the  user.

2,11Critical  system  data  will  be  available  to  

user  through  physical  display  and  mobile  application

The  end  user  should  be  able  to  view  basic  information  about  the  pumps,  water  level  

and  power  level.

8,11State  of  charge  of  backup  power  will  be  

measured  and  displayed

The  user  should  be  able  to  view  the  remaining  power  level  of  the  backup  

power  supply,  and  the  system  needs  to  know  how  long  until  complete  power  

outage.

4,6Water  level  sensor  must  be  non-­‐

corrosive

The  water  level  sensor  needs  to  last  and  corrosion  could  also  interfer  with  

accuracy.

1,2,9,11Mobile  Application  must  consist  of  an  easy  to  use  interface  and  run  on  a  

mobile  device.

The  user  must  be  able  to  easily  understand  and  navigate  the  interface,  so  

as  to  know  if  a  problem  is  occuring.

7,9,11

Mobile  Application  will  alert  user  through  audible  alerts  and  

notifications  if  a  system  malfunction,  or  critical  event  has  occurred

The  application  should  get  the  user's  attention  to  alert  them  of  any  problems  occuring  at  the  site  of  their  sump  pump  

system

9,10,11System  will  provide  network  

connection,  even  during  power  outage

The  end  user  needs  to  continue  to  be  updated  with  information  during  a  power  

outage.

7,9,11Physical  alarm  will  produce  at  least  70dB  to  be  heard  throughout  the  

home.

The  user  needs  to  be  able  to  hear  the  alarm  if  he/she  is  in  their  home.

4,5,7Water  level  sensor  needs  to  be  

accurate  to  within  3%The  system  needs  to  obtain  accurate  level  

values  for  calculations.

1,3Water  level  sensor  must  be  no  longer  

than  3ft  in  lengthThe  typical  sump  pump  pump  is  no  longer  

than  3ft  in  depth.Marketing Requirements:

1.            Easy to install2.            Easy to operate3.            Small4.            Accurate5.            Measure water level6.            Waterproof level sensor7.            Alarm the operator when the water level is high8.            Must know whether or not the sump pump has power9.            Alarm the operator when power fails10.    Full system continues working when power goes out11.    Keep user informed with information via physical alarm and mobile application

Table 2.1.1: Design Specifications

7    

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.

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).

Main Controller

Water Level Sensor

Power Supply Data

Main Pump

Secondary Pump

9VDC Power

Data to Server

Data to LCD

Alarm Speaker

8    

9VDC PowerMain Controller Software

LCD Display

GPRS

Hardware

LCD Signals

Data PacketTo Server

Main Controller

WaterLevel

PrimaryPump

SecondaryPump

Voltage from Water Level

Sensor

Power SupplyData

Primary Pump

Secondary Pump

Power Supply

Alarm Speaker

Data String

Main Power (Yes/No)

RefVoltage

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.

9    

Water Level Sensor

Arduino Mega 2560ATmega2560

9V Power Supply User Interface Control

9V

Display Driver

LCD Display

GPRS ModuleSM5100B-D Antenna

Alarm Speaker

Controlled DisplayOutput

Data

Test Button

Variable Voltage

Data

SIM Card

Backup Pump Power Supply Level Voltage

Primary Pump Current Sensor

Secondary Pump Current Sensor

Voltage

Voltage

Main Power Current Sensor

Voltage

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.

10    

GPRS Module

(U2)

5V

GNDVin

(LS)

PWM

Test Button(SW1)

Main Power(CS1)

Primary Pump(CS1)

Secondary Pump(CS1)

Secondary Pump

Battery Level Sensor

Secondary Pump

Battery Level Sensor

LCD(DS)

U1

Barrel Jack

12V Power Adapter (PS)And 9V Battery (BT1)

Power

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.

11    

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.

10Ω

CS

k

l

Ard

uino

Meg

a 25

60A2

GND

I

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

12    

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.

13    

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.

14    

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.

15    

5V

GND

Ard

uino

Meg

a 25

60

R1

R2

Rsense

Rref

1 2 43

Vs

Vref

WS

A0

A1

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.

16    

Fig. 3.1.11: Water Level Sensor Schematic Empty

Fig. 3.1.12: Water Level Sensor Schematic Empty

17    

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.

Arduino MegaATmega2560

DSNHD-0420E2Z-FSW-GBW

GND

5V

DIGITAL I/O

VS

S

VC

C

Vo

RS

R/W

EDB

0

DB

1

DB

2

DB

3

DB

4

DB

5

DB

6

DB

7

LED

+

LED

-

Rc

LS (CVS-3108)

Fig. 3.1.13: Connection between ATmega2560, LCD Panel and In-Home Speaker

18    

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.

5V

GND

D8

Ard

uino

Meg

a 25

60 SW1

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.

19    

GND

Ard

uino

Meg

a 25

60

R4 (3K)

R3 (10K)

A5

Backup Pump Battery (12V)

+-

BT2

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.

20    

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.

OutputsSpeaker:  Alarm  signalGPRS  Module:  Data  to  be  sent  over  networkLCD:  Data  to  be  displayed  on  physical  display

Functionality

The  main  board  will  be  powered  by  9V  DC,  and  is  backed  up  by  a  9V  battery.  A  level  sensor  is  connected  to  transmit  the  water  level  in  the  sump.  The  data  from  the  sensor  and  power  inputs  will  be  used  to  determine  system  failure  and  potential  flooding.  An  audible  alarm  will  also  sound  to  alert  the  user  of  the  failure.  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  levels.

Module Main  Controller  (Arduino  Mega  2560)Designer Matt  Boston,  Aaron  Nervi,  Derek  Brooks

Inputs

Water  Level  Sensor:  Variable  voltage  (0-­‐3V)Main  Power  Sensor:  Low  voltage  (Dependent  on  current)Backup  Pump  Power  Level  Sensor:  Low  volage  (Dependent  on  pump  battery  level)Primary  Pump  Current  Sensor:  Low  voltage  (Dependent  on  current)Secondary  Pump  Current  Sensor:  Low  voltage  (Dependent  on  current)Test  Button:  Low  or  High  Signal9V:  Power  to  power  the  board

Outputs 9V  to  Controller

FunctionalityThe  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.

Module Main  Controller  Power  SupplyDesigner Matt  Boston,Jason  UlbrichtInputs 120VAC  to  9VDC  Wall  Adapter

 

21    

OutputsVsense:  Voltage  (0-­‐3V)  indicating  water  levelVref:  Voltage  (~3V)  to  act  as  reference  voltage

FunctionalityThe  Continuous  Water  Level  Sensor  will  monitor  the  water  level  inside  the  sump  and  

output  a  variable  voltage  that  is  representative  of  the  current  water  level  to  the  controller.  This  will  be  calculated  using  Vsense  and  Vref.

Module Continuous  Water  Level  SensorDesigner Derek  Brooks,  Aaron  Nervi

Inputs 5V:  Power  from  Arduino  Mega  2560

 

Outputs Data  packet  over  cellular  network

FunctionalityThe  GPRS  module  will  function  as  an  intermediary  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 GPRS  ModuleDesigner Aaron  Nervi

Inputs

Data:  Data  from  Arduino  through  UART  Serial  Interface5V:  Power  from  the  Arduino  to  Power  the  GPRS  moduleAntenna:  Quad-­‐band  AntennaSIM:  SIM  card  for  network  access

 

OutputsEnable  Bit:  Enable  The  LCDRegister  Select  Bit:  Select  Read  or  Write  ModeDB4-­‐DB7:  Data  Bits  to  the  LCD

Functionality

The  LCD  Driver  will  input  the  critical  system  data  such  as  battery  charge,  water  level,  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.

Module LCD  Display  DriverDesigner Jason  Ulbricht

Inputs

Main  Power  StatusWater  LevelBattery  LevelPump  Status

 

22    

Outputs Visual  Display

Functionality

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  VSS  and  VCC  to  control  contrast.

Module LCD  DisplayDesigner Jason  Ulbricht

Inputs

5V:  Power  from  the  Arduino  BoardRS:  Register  SelectE:  Enable  BitVo:  Contrast  ControlDB4-­‐DB7:  Digital  Bits  for  Display  Control

 

Outputs Hi-­‐Lo  signal  to  Arduino  Mega  2560

FunctionalityThe  user  interface  consists  of  one  momentary  push  button.  The  button  will  act  like  a  switch  and  if  it  is  pressed  down,  it  will  send  a  Hi  signal  to  the  Arduino.  The  in-­‐home  

speaker  will  sound  an  alarm  when  pressed.

Module User  Interface  (Test  Button)Designer Aaron  Nervi

Inputs Momentary  push  button

  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

23    

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.

System Software

Water Level Sensor

Reference Voltage

Power Level Sensor

LCD

To GPRS

AlarmPrimary Pump

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.

Water Level Sensor

Power Level Sensor

Calculate Water LevelReference Voltage

Read Power Level

Check Water Alarm States

Check Power Alarm States

Read Pump Signals

Primary Pump

Secondary Pump

Main Controller Software

Main()

Alarm

GPRS

LCD

Fig. 3.2.2: Main Controller Software (Level 1)

24    

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.

ADC

ADC

waterLevel() waterAlarm()

ADC powerLevel()

isOn()

isOn()

Audio Alarm

LCD Driver

GPRS Driver

Secondary PumpSensor

Water Level Voltage

Reference Voltage

Primary Pump Sensor

Power Level Voltage

Main()

sendToGPRS()

sendToLCD()

activateAlarm()

isOn()Main Power

Sensor

ADC

ADC

ADCpumpAlarm()

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.

25    

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.

26    

Outputs LCD  Display,  GPRS,  Alarm  Signal

Functionality

The  sump  pump  controller  will  receive  water  level  and  power  data  to  determine  whether  or  not  that  level  will  yield  a  possibility  of  flooding.  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  failed.  It  will  also  output  

an  audible  alarm  to  let  the  user  know  of  a  problem.

Module Main  Controller  SoftwareDesigner Derek  Brooks,  Aaron  Nervi

InputsWater  Level  Sensor,  Reference  Voltage,  Power  Level  Sensor,  Main  Pump,  Secondary  

Pump

Outputs -­‐  Calculated  water  level:  Height  of  the  water  level  as  a  percentage

FunctionalityThe  waterLevel()  function  will  take  the  variable  level  voltage  from  the  water  sensor  and  the  reference  voltage  from  the  sensor  and  use  the  two  voltages  to  calculate  the  

current  level  of  the  water.  

Function waterLevel()Designer Derek  Brooks,  Aaron  Nervi

Inputs-­‐  Water  level  voltage:  The  voltage  from  The  Water  level  sensor-­‐  Reference  voltage:  The  Reference  voltage  sent  through  The  Water  level  sensor

Outputs -­‐  Calculated  power  level:  Remaining  amount  of  battery  power  in  percentage  format

FunctionalityThe  powerLevel()  function  will  take  the  current  voltage  from  the  secondary  pump's  

battery  and  use  a  hardcoded  reference  voltage  to  calculate  the  current  power  level  of  the  battery.  

Function powerLevel()Designer Derek  Brooks,  Aaron  Nervi

Inputs -­‐  Power  level  voltage:  The  voltage  from  secondary  pump's  battery

Outputs -­‐  Set  status  flags  in  memory

FunctionalityisOn()  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  is  on,  it  then  sets  the  required  status  flags

Function isOn()Designer Derek  Brooks,  Aaron  Nervi

Inputs-­‐  Voltage:  voltage  outputed  by  the  current  sensors  attached  to  both  pumps  and  main  power  source  to  controller

27    

Outputs -­‐  Sets  status  flags  in  memory

FunctionalityThe  waterAlarm()  function  checks  the  current  calculated  water  level  against  specified  

values  and  decides  what  status  flags,  if  any,  need  to  be  set

Function waterAlarm()Designer Derek  Brooks

Inputs -­‐  Calculated  water  level:  The  current  water  level  in  the  sump

Outputs -­‐  Alarm  signal:  Specified  alarm  signal  to  the  speaker

FunctionalityThe  pumpAlarm()  function  takes  the  water  level,  and  all  the  power  statuses  of  the  system  and  decides  if  there  is  a  problem  with  either  the  main  or  secondary  pump

Function pumpAlarm()Designer Derek  Brooks,  Aaron  Nervi

Inputs

-­‐  Water  level:  The  current  level  of  water  in  the  sump  calculated  from  waterLevel()-­‐  Main  power  status:  Whether  the  system  is  receiving  main  power-­‐  Main  pump  status:  Whether  the  main  pump  is  running-­‐  Secondary  pump  status:  Whether  the  secondary  pump  is  running-­‐  Backup  battery  dead  flag:  Whether  the  backup  battery  is  dead

Outputs -­‐  Sets  status  flags  in  memory

FunctionalityThe  powerAlarm()  function  checks  the  power  level  of  the  secondary  pumps  battery  and  

decides  which  status  flags,  if  any,  need  to  be  set

Function powerAlarm()Designer Derek  Brooks

Inputs -­‐  Secondary  Pump  Battery  level:  The  percentage  level  of  the  secondary  pumps  battery

Outputs -­‐  Alarm  signal:  Specified  alarm  signal  to  the  speaker

FunctionalityThe  activateAlarm()  function  will  check  all  the  alarm  status  flags  in  memory  using  a  specified  priority  and  output  the  alarm  of  the  first  status  flag  it  reads  as  activated

Function activateAlarm()Designer Derek  Brooks,  Aaron  Nervi

Inputs -­‐  Status  Flags:  Reads  the  alarm  C5status  flags  from  memory

28    

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.

Read in Water Level Voltage

Read in Reference Voltage

Calculate Water Level %Store Level % in MemoryWait

Start

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.

Read in Power Level Voltage

Calculate Power Level %

Store Level % in MemoryWait

Start

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

29    

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

Is Voltage > 0V? Is Flag Set?

Is Flag Set?

Reset ON Flag

Set ON Flag

N Y

Y

N

Start

Y

N

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.

30    

Read Water Level

Is Level Above 50%?

50% Flag Active?

Set 50% Water Level Flag

Is Level Above 80%?

80% Flag Active?

Set 80% Water Level Flag

80% Alarm Active?

Reset 80% Water Level

Flag

Y

N

Y

N

N

Start

Y

Y

N

50% Flag ActiveN

Reset 80% Water Level

FlagY

N

Y

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.

31    

Get Main Power Status

Is Main Power ON?

Get Current Battery Level

Is Level <= 50%

Reset All Battery Flags

N

Y

Is 50% Flag Set?

Y

Set 50% Level FlagN

Is Level <= 25%

Y

Is 25% Flag Set?

Y

Set 25% Level FlagN

Is Battery Dead?

Is Dead Battery Flag

Set?

Y

Y

Set Dead Battery FlagN

Start

N

N

N

Y

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.

32    

Get Water Level, Main Power Status, Primary and Secondary Pump Statuses, and Backup Battery Level

Water Level >= 25%?

Is Main Power ON?

Y

Is Primary Pump ON?

Is Backup Battery Dead?

N

Y

Is Secondary Pump ON?

N

Set Secondary Flag

Set Primary Flag

Is Primary Flag Set?N

N

Is Secondary Flag Set?N N

Start

Y

N

Y

Y

Y

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.

33    

Water Level 80%?

Water Level 50%?

Dead Battery?

Secondary Pump Flag?

Battery 25%?

Battery 50%?

Primary Pump Flag?

Main Power Off?

Sound Water Level 80% AlarmY

Sound Water Level 50% Alarm

Sound Battery Dead Alarm

Sound Secondary Out

Alarm

Sound Battery at 25% Alarm

Sound Battery at 50% Alarm

Sound Primary Out Alarm

Sound Main Power Out Alarm

Y

Y

Y

Y

Y

Y

Y

N

N

N

N

N

N

N

Start

N

Is Test Button Pressed?

Sound Test AlarmY

N

Fig. 3.2.10: activateAlarm() method

34    

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

35    

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

36    

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.

37    

 

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)

TX0(Pin 1)

RX0(Pin 0)

5V

GND GND

Vin

RX

TX

Atmega2560 SM5100B-D

38    

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 }

39    

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.

Mobile Application

Data Audio Alerts

VisualsUser Input

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.

40    

Software Main

Data from Server

Visuals

Data Collection/ Parser

User Interface

User Input from Phone Mode

Selector

Water Calculations

Backup Power

Calculations

Main Power(Yes/No)

Sump PumpData

(Operating?)

Audio Alerts/Messages to Phone

Mobile Application

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.

41    

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

}

42    

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)

43    

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

Outputs Audio  Alerts/Messages  to  Phone

Functionality

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  level  and  battery  charge.  It  will  also  play  audio  alerts  if  a  situation  is  occuring  that  the  user  should  be  notified  of.  The  interface  

will  display  visuals  of  the  water  and  backup  power  levels.

Module Mobile  ApplicationDesigner Jason  UlbrichtInputs JSON  Data  from  SQL  Server,  User  Input

3.5 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.

44    

9V Battery120VAC to

12VDCPower Supply

9VTo Main Controller120 VAC

Main Controller Power Supply

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.

120VAC to 12VDC

Power Adapter

120 VAC

Main Controller Power Supply

D 9V Battery

BT1R5 = 50Ω

PS

Ard

uino

Meg

a 25

60

Vin

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.

45    

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:

𝐼!"##$#% =  !!"##$#%

!= !"#"!

!"#!= 8.7𝐴 (3)

𝐼!"#$"!!" =!!"#$"!!"

!= !"##!

!"#!= 17.5𝐴 (4)

3.6.1 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

46    

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.

47    

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. Refdes Part Num. Description 1 U1 DEV-11061 Arduino Mega 2560 R3 1 U2 CEL-09607 Cellular Shield with SM5100B 1 AE1 CEL-00290 Quad-band Wired Cellular Antenna SMA 3 CS SEN-11005 Non-Invasive Current Sensor-30A 1 PRT-10007 Arduino Stackable Header Kit

1 BWEL Basement Watchdog 1000 GPH Battery Backup Sump Pump

1 SW1 COM-09190 Momentary Push Button Switch 1 WS PN-6573TC-24 24-inch (600mm) eTape Liquid Level Sensor 3 LS CVS-3108 8-Ohm Piezo Speaker

1 DS NHD-0420E2Z-FSW-GBW Newhaven Display 4x20 LCD

2 BT1 NH22NBP Rechargeable 9V Battery from Energizer 2 Rc EVU-F2MFL3B14 Panasonic10 kΩ Potentiometer 2 A000032 Arduino Bread Board/Wire Kit 2 TU0159 United Solutions 20-Gallon Plastic Tub 2 PVC 07112 0600 1-1/2” PVC Pipe 10’ Sections 2 PVC 00321 0800 1-1/2” PVC 45 Degree Fitting 1 BT2 24EP6 Basement Watchdog 6hr Emergency Battery 1 D 1N1115 D, 100V, 1.5A, DO-3 1 R5 PAC100005009FA1000 50 Ohm resistor 2 R1, R2 ERD-S2TJ202V 2k Ohm resistor 2 R3,R6 1-1625885-3 10K ohm resistor 1 R4 ERG-1SJ302 3K ohm resistor 1 PS TOL-09442 120V-12Vdc Power Supply 2 PRT-09518 9V to Barrel Jack Adapter

1 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.

48    

Unit TotalQty. Part Num. Description Cost Cost

1 DEV-11061 Arduino Mega 2560 R3 $58.95 $58.951 CEL-09607 Cellular Shield with SM5100B 99.95 99.951 CEL-00290 Quad-band Wired Cellular Antenna SMA 11.95 11.953 SEN-11005 Non-Invasive Current Sensor-30A 9.95 29.851 PRT-10007 Arduino Stackable Header Kit 1.50 1.501 BWEL Basement Watchdog 1000 GPH Battery Backup Sump Pump 147.00 147.001 COM-09190 Momentary Push Button Switch 0.50 0.501 PN-6573TC-24 24-inch (600mm) eTape Liquid Level Sensor 49.99 49.993 CVS-3108 8-Ohm Piezo Speaker 3.60 10.801 NHD-0420E2Z-FSW-GBW Newhaven Display 4x20 LCD 28.20 28.202 NH22NBP Rechargeable 9V Battery from Energizer 10.99 21.982 EVU-F2MFL3B14 Panasonic10 kΩ Potentiometer 1.40 2.802 A000032 Arduino Bread Board/Wire Kit 12.97 25.942 TU0159 United Solutions 20-Gallon Plastic Tub 7.98 15.962 PVC 07112 0600 1-1/2" PVC Pipe 10' Sections 3.99 7.982 PVC 00321 0800 1-1/2" PVC 45 Degree Fitting 0.80 1.601 24EP6 Basement Watchdog 6hr Emergency Battery 94.00 94.001 1N1115 D, 100V, 1.5A, DO-3 0.00 0.001 PAC100005009FA1000 50 Ohm resistor 0.97 0.972 ERD-S2TJ202V 2k Ohm resistor 0.09 0.182 1-1625885-3 10K ohm resistor 0.12 0.241 ERG-1SJ302 3K ohm resistor 0.34 0.341 TOL-09442 120V-12Vdc Power Supply 5.95 5.952 PRT-09518 9V to Barrel Jack Adapter 2.95 5.901 AT&T Activated SIM Card $25/mo + $5/mo Data Pre-Paid Plan 30.00 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

49    

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 Duration Start Finish PredecessorsResource Names1 Sump Pump Overflow Alarm Design ############ Fri 8/31/12 Wed 11/14/1223 Preliminary Design Report 14 days Fri 8/31/12 Fri 9/14/124 Problem Statement 14 days Fri 8/31/12 Fri 9/14/125 Need 7 days Fri 8/31/12 Fri 9/7/12 Matt Boston6 Objective 7 days Fri 8/31/12 Fri 9/7/12 Derek Brooks7 Background 7 days Fri 8/31/12 Fri 9/7/12 Jason Ulbricht8 Marketing Requirements 7 days Fri 8/31/12 Fri 9/7/12 Aaron Nervi9 Objective Tree 7 days Fri 9/7/12 Fri 9/14/12 Aaron Nervi10 Preliminary Design Gantt Chart 14 days Fri 8/31/12 Fri 9/14/12 Jason Ulbricht11 Block Diagrams Level 0 w / FR tables 7 days Fri 9/7/12 Fri 9/14/1212 Hardware modules (identify designer) 7 days Fri 9/7/12 Fri 9/14/12 Matt Boston13 Softw are modules (identify designer) 7 days Fri 9/7/12 Fri 9/14/1214 System Software 7 days Fri 9/7/12 Fri 9/14/12 Derek Brooks,Aaron Nervi15 Mobile Application 7 days Fri 9/7/12 Fri 9/14/12 Jason Ulbricht1617 Prel iminary Design Presentation 3:15PM ASEC 120 0 days Fri 9/14/12 Fri 9/14/12 13

1819 Midterm Report 30 days Sat 9/15/12 Mon 10/15/1220 Design Requirements Specification 13 days Sat 9/15/12 Fri 9/28/12 Aaron Nervi,Jason Ulbricht21 Midterm Design Gantt Chart 13 days Sat 9/15/12 Fri 9/28/12 Jason Ulbricht22 Design Calculations 7 days Fri 9/28/12 Fri 10/5/1223 Electrical Calculations 7 days Fri 9/28/12 Fri 10/5/1224 Wireless Communication 7 days Fri 9/28/12 Fri 10/5/12 Aaron Nervi25 Mobile Device Computing 7 days Fri 9/28/12 Fri 10/5/12 Jason Ulbricht26 Control Systems 7 days Fri 9/28/12 Fri 10/5/12 Derek Brooks27 Power, Voltage, Current 7 days Fri 9/28/12 Fri 10/5/12 Matt Boston28 Mechanical Calculations 7 days Fri 9/28/12 Fri 10/5/1229 Water Reservoir Dimensions 7 days Fri 9/28/12 Fri 10/5/12 Jason Ulbricht30 Block Diagrams Level 1 w / FR tables & ToO 13 days Sat 9/15/12 Fri 9/28/1231 Hardw are modules (identify designer) 13 days Sat 9/15/12 Fri 9/28/1232 Level Sensor 13 days Sat 9/15/12 Fri 9/28/12 Derek Brooks33 AC Power 13 days Sat 9/15/12 Fri 9/28/12 Matt Boston34 Battery Backup 13 days Sat 9/15/12 Fri 9/28/12 Matt Boston35 Alarm 13 days Sat 9/15/12 Fri 9/28/12 Jason Ulbricht36 Controller 13 days Sat 9/15/12 Fri 9/28/12 Aaron Nervi37 Softw are modules (identify designer) 13 days Sat 9/15/12 Fri 9/28/1238 System Software 13 days Sat 9/15/12 Fri 9/28/12 Derek Brooks39 Mobile Applicatioin 13 days Sat 9/15/12 Fri 9/28/12 Jason Ulbricht40 Block Diagrams Level 2 w / FR tables & ToO 7 days Fri 9/28/12 Fri 10/5/1241 Hardw are modules (identify designer) 7 days Fri 9/28/12 Fri 10/5/1242 Level Sensor 7 days Fri 9/28/12 Fri 10/5/12 Aaron Nervi43 AC Power 7 days Fri 9/28/12 Fri 10/5/12 Matt Boston44 Battery Backup 7 days Fri 9/28/12 Fri 10/5/12 Matt Boston45 Alarm 7 days Fri 9/28/12 Fri 10/5/12 Jason Ulbricht46 Controller 7 days Fri 9/28/12 Fri 10/5/12 Derek Brooks

50    

ID Task Name Duration Start Finish PredecessorsResource Names47 Softw are modules (identify designer) 7 days Fri 9/28/12 Fri 10/5/1248 System Software 7 days Fri 9/28/12 Fri 10/5/12 Aaron Nervi49 Software Flow Diagrams 7 days Fri 9/28/12 Fri 10/5/12 Derek Brooks50 Mobile Application 7 days Fri 9/28/12 Fri 10/5/12 Jason Ulbricht51 Block Diagrams Level N+1 w / FR tables & ToO 10 days Fri 10/5/12 Mon 10/15/1252 Hardw are modules (identify designer) 10 days Fri 10/5/12 Mon 10/15/1253 Level Sensor 10 days Fri 10/5/12 Mon 10/15/12 Aaron Nervi54 AC Power 10 days Fri 10/5/12 Mon 10/15/12 Matt Boston55 Battery Backup 10 days Fri 10/5/12 Mon 10/15/12 Matt Boston56 Alarm 10 days Fri 10/5/12 Mon 10/15/12 Jason Ulbricht57 Controller 10 days Fri 10/5/12 Mon 10/15/12 Derek Brooks58 GPRS 10 days Fri 10/5/12 Mon 10/15/12 Aaron Nervi59 LCD 10 days Fri 10/5/12 Mon 10/15/12 Jason Ulbricht60 Softw are modules (identify designer) 10 days Fri 10/5/12 Mon 10/15/1261 System Software 10 days Fri 10/5/12 Mon 10/15/12 Aaron Nervi62 Mobile Application 10 days Fri 10/5/12 Mon 10/15/12 Jason Ulbricht6364 Project Poster 11 days Mon 10/15/12 Fri 10/26/12

6566 Final Design Report 30.38 days Mon 10/15/12 W ed 11/14/12

67 Abstract 7 days Mon 10/15/12 Mon 10/22/12 Jason Ulbricht68 Softw are Design 21 days Mon 10/22/12 Mon 11/12/1269 Modules 1…n 21 days Mon 10/22/12 Mon 11/12/1270 Mobile Application 13.63 days Mon 10/22/12 Mon 11/5/1271 Mobile Application Flow Chart 7 days Mon 10/22/12 Mon 10/29/12 Jason Ulbricht72 SQL Communication 7 days Mon 10/29/12 Mon 11/5/12 Jason Ulbricht73 PHP Script 7 days Mon 10/29/12 Mon 11/5/12 Jason Ulbricht74 System Software Pseudo Code 7 days Mon 10/22/12 Mon 10/29/12 Derek Brooks75 Software Flowcharts 7 days Mon 10/29/12 Mon 11/5/12 Derek Brooks76 Water Level Method 7 days Mon 10/29/12 Mon 11/5/12 Derek Brooks77 Power Level Method 7 days Mon 10/29/12 Mon 11/5/12 Derek Brooks78 Is Device On Method 7 days Mon 10/29/12 Mon 11/5/12 Derek Brooks79 Water Alarm Method 7 days Mon 10/29/12 Mon 11/5/12 Derek Brooks80 Power Alarm Method 7 days Mon 10/29/12 Mon 11/5/12 Derek Brooks81 Pump Alarm Method 7 days Mon 10/29/12 Mon 11/5/12 Derek Brooks82 Activate Alarm Method 7 days Mon 10/29/12 Mon 11/5/12 Derek Brooks83 Communications 14 days Mon 10/22/12 Mon 11/5/1284 GPRS Pseudo Code 7 days Mon 10/22/12 Mon 10/29/12 Aaron Nervi85 TCP Server Pseudo Code 7 days Mon 10/29/12 Mon 11/5/12 Aaron Nervi86 LCD Interfacing 7 days Mon 11/5/12 Mon 11/12/12 Jason Ulbricht87 Hardw are Design 30 days Mon 10/15/12 W ed 11/14/1288 Modules 1…n 30 days Mon 10/15/12 W ed 11/14/1289 Power Simulations 7 days Mon 10/15/12 Mon 10/22/12 Matt Boston90 Water Level Simulations 7 days Mon 10/15/12 Mon 10/22/12 Derek Brooks91 Battery Level Sensor Schematics 7 days Mon 10/15/12 Mon 10/22/12 Aaron Nervi92 AC Power Schematics 7 days Mon 10/15/12 Mon 10/22/12 Jason Ulbricht93 Battery Backup Schematics 14 days Mon 10/22/12 Mon 11/5/12 Matt Boston94 Sump Pump Battery 7 days Mon 10/22/12 Mon 10/29/12 Matt Boston95 Power for Arduino Controller 14 days Mon 10/22/12 Mon 11/5/12 Matt Boston96 Schematics 7 days Mon 10/22/12 Mon 10/29/12 Matt Boston97 Rechargeable Battery 7 days Mon 10/29/12 Mon 11/5/12 Matt Boston98 Alarm Schematics 7 days Mon 10/29/12 Mon 11/5/12 Jason Ulbricht99 Speaker 7 days Mon 10/29/12 Mon 11/5/12 Jason Ulbricht100 Controller Schematics 7 days Mon 10/22/12 Mon 10/29/12 Derek Brooks101 GPRS Board Schematics 30 days Mon 10/15/12 W ed 11/14/12 Aaron Nervi102 Antenna 7 days Mon 10/22/12 Mon 10/29/12 Aaron Nervi103 SIM Card Information 7 days Wed 11/7/12 Wed 11/14/12 Aaron Nervi104 Connections to Arduino 7 days Mon 10/15/12 Mon 10/22/12 Aaron Nervi105 LCD Display Schematics 7 days Wed 11/7/12 Wed 11/14/12 Jason Ulbricht106 User Interface- Push button Info 7 days Mon 10/29/12 Mon 11/5/12 Aaron Nervi107 Parts Request Form 30 days Mon 10/15/12 W ed 11/14/12108 Microcontroller 2 days Mon 10/29/12 Wed 10/31/12 Derek Brooks109 GPRS Board 5 days Wed 10/31/12 Mon 11/5/12 Aaron Nervi110 Antenna 2 days Mon 11/5/12 Wed 11/7/12111 UPS/Batteries 7 days Mon 10/15/12 Mon 10/22/12 Matt Boston112 Pumps 7 days Mon 10/15/12 Mon 10/22/12 Jason Ulbricht113 SIM Card 7 days Wed 10/31/12 Wed 11/7/12 Aaron Nervi114 Reservoir 1 day Mon 11/5/12 Tue 11/6/12 Jason Ulbricht115 Level Sensor 7 days Mon 10/22/12 Mon 10/29/12 Derek Brooks116 Miscellanious Parts 7 days Wed 11/7/12 Wed 11/14/12 Matt Boston117 Budget (Estimated) 5 days Fri 11/9/12 Wed 11/14/12 Jason Ulbricht

51    

Table 5.1.1: Midterm Design Ghant Chart

ID Task Name Duration Start Finish PredecessorsResource Names118 Construct Presentation 7 days W ed 11/7/12 W ed 11/14/12119 Hardware Theory 7 days Wed 11/7/12 Wed 11/14/12 Matt Boston120 Software Theory 7 days Wed 11/7/12 Wed 11/14/12 Derek Brooks121 Communication 7 days Wed 11/7/12 Wed 11/14/12 Aaron Nervi122 Mobile Application 7 days Wed 11/7/12 Wed 11/14/12 Jason Ulbricht123 Implementation Gantt Chart 7 days W ed 11/7/12 W ed 11/14/12124 Hardware Implementation 7 days Wed 11/7/12 Wed 11/14/12 Matt Boston125 System Software Implementation 7 days Wed 11/7/12 Wed 11/14/12 Derek Brooks126 Wireless Communicaion Implementation 7 days Wed 11/7/12 Wed 11/14/12 Aaron Nervi127 Mobile Application Implementation 7 days Wed 11/7/12 Wed 11/14/12 Jason Ulbricht128 Conclusions and Recommendations 7 days Wed 11/7/12 Wed 11/14/12 Derek Brooks129130 Final Design Presentation Part 1 3:15PM ASEC 120 0 days Fri 11/16/12 Fri 11/16/12131 Final Design Presentation Part 2 3:15PM ASEC 120 0 days Fri 11/30/12 Fri 11/30/12132 Our Final Presentation 0 days Fri 11/30/12 Fri 11/30/12133 Final Design Presentation Part 3 3:15PM ASEC 120 0 days Fri 12/7/12 Fri 12/7/12

ID Task Name Duration Start Finish PredecessorsWeek Resource Names

1 Revise Gantt Chart 8 days Mon 1/14/13 Tue 1/22/13 1 Aaron Nervi2 Implement Project Design 81 days Mon 1/14/13 Fri 4/5/133 Hardware Implementation 42 days Mon 1/14/13 Mon 2/25/134 Breadboard Components 7 days Mon 1/14/13 Mon 1/21/135 LCD 7 days Mon 1/14/13 Mon 1/21/13 Jason Ulbricht6 Speaker 7 days Mon 1/14/13 Mon 1/21/13 Jason Ulbricht7 GPRS Wiring 7 days Mon 1/14/13 Mon 1/21/13 Aaron Nervi8 Water Level Sensor Wiring 7 days Mon 1/14/13 Mon 1/21/13 Derek Brooks9 Battery Level Wiring 7 days Mon 1/14/13 Mon 1/21/13 Matt Boston10 Layout and Generate PCB(s) 14 days Mon 1/21/13 Mon 2/4/13 5 311 Assemble Hardware 7 days Mon 2/4/13 Mon 2/11/13 10 512 Assemble Water Sensor 7 days Mon 2/4/13 Mon 2/11/13 Derek Brooks13 Connect GPRS Board Componnets 7 days Mon 2/4/13 Mon 2/11/13 Aaron Nervi14 Setup Current Sensors 7 days Mon 2/4/13 Mon 2/11/13 Matt Boston15 Connect LCD Display to main controller 7 days Mon 2/4/13 Mon 2/11/13 Jason Ulbricht16 Setup Speaker 7 days Mon 2/4/13 Mon 2/11/13 Jason Ulbricht17 Set up sump pumps 7 days Mon 2/4/13 Mon 2/11/13 Matt Boston18 Set up water reservoir 7 days Mon 2/4/13 Mon 2/11/13 Matt Boston19 Test Hardware 7 days Mon 2/11/13 Mon 2/18/13 12 620 Test Water Level Sensor 7 days Mon 2/11/13 Mon 2/18/13 Derek Brooks21 Test Communications 7 days Mon 2/11/13 Mon 2/18/1322 GPRS 7 days Mon 2/11/13 Mon 2/18/13 Aaron Nervi23 Server Side 7 days Mon 2/11/13 Mon 2/18/13 Aaron Nervi24 Test Sump Pumps 7 days Mon 2/11/13 Mon 2/18/13 Matt Boston25 Test Battery Level Monitor 7 days Mon 2/11/13 Mon 2/18/13 Matt Boston26 Test Current Sensors for Power Readings 7 days Mon 2/11/13 Mon 2/18/13 Matt Boston27 Test LCD Display 7 days Mon 2/11/13 Mon 2/18/13 Jason Ulbricht28 Test Speaker 7 days Mon 2/11/13 Mon 2/18/13 Jason Ulbricht29 Test Push Button 1 day Mon 2/11/13 Tue 2/12/13 Matt Boston30 Revise Hardware 7 days Mon 2/11/13 Mon 2/18/13 1131 MIDTERM: Demonstrate Hardware 7 days Mon 2/18/13 Mon 2/25/13 19,30 832 SDC & FA Hardware Approval 0 days Mon 2/25/13 Mon 2/25/13 31 9

52    

Table 5.1.2: Implementation Ghant Chart

ID Task Name Duration Start Finish PredecessorsWeek Resource Names

33 Software Implementation 49 days Mon 1/14/13 Mon 3/4/1334 Develop Software 28 days Mon 1/14/13 Mon 2/11/1335 Main System Software for Arduino 28 days Mon 1/14/13 Mon 2/11/13 Derek Brooks36 GPRS Software 28 days Mon 1/14/13 Mon 2/11/13 Aaron Nervi37 LCD Interfacing 14 days Mon 1/14/13 Mon 1/28/13 Jason Ulbricht38 Mobile Application 28 days Mon 1/14/13 Mon 2/11/13 Jason Ulbricht39 Server Script Files (Receive) 14 days Mon 1/21/13 Mon 2/4/13 Aaron Nervi40 Server Script Files (Query) 14 days Mon 1/21/13 Mon 2/4/13 Jason Ulbricht41 SQL Server 28 days Mon 1/14/13 Mon 2/11/13 Aaron Nervi42 Test Software 14 days Mon 2/11/13 Mon 2/25/13 35 543 Test Reading Sensor Data 7 days Mon 2/11/13 Mon 2/18/13 Derek Brooks44 Test Communications (GPRS) to Server 7 days Mon 2/11/13 Mon 2/18/13 Aaron Nervi45 Test LCD Display 7 days Mon 2/18/13 Mon 2/25/13 Jason Ulbricht46 Test Mobile Application 7 days Mon 2/18/13 Mon 2/25/13 Jason Ulbricht47 Test Physical Speaker Alarms 7 days Mon 2/18/13 Mon 2/25/13 Derek Brooks48 Revise Software 7 days Mon 2/18/13 Mon 2/25/13 43 749 MIDTERM: Demonstrate Software 7 days Mon 2/25/13 Mon 3/4/13 48 850 SDC & FA Software Approval 0 days Mon 3/4/13 Mon 3/4/13 49 951 System Integration 32 days Mon 3/4/13 Fri 4/5/13 49,3252 Assemble Complete System 14 days Mon 3/4/13 Mon 3/18/1353 Test Complete System 18 days Mon 3/18/13 Fri 4/5/13 52 1054 Revise Complete System 18 days Mon 3/18/13 Fri 4/5/13 5255 Demonstration of Complete System 0 days Fri 4/5/13 Fri 4/5/13 54 135657 Develop Final Report 93 days Mon 1/14/13 W ed 4/17/1358 W rite Final Report 93 days Mon 1/14/13 W ed 4/17/1359 Add to Hardware Section 93 days Mon 1/14/13 Wed 4/17/13 Matt Boston60 Add Any Necessary Calculations 93 days Mon 1/14/13 Wed 4/17/13 Matt Boston61 Add to Power Section 93 days Mon 1/14/13 Wed 4/17/13 Matt Boston62 Add to Software Section 93 days Mon 1/14/13 Wed 4/17/13 Derek Brooks63 Add to Communication Section 93 days Mon 1/14/13 Wed 4/17/13 Aaron Nervi64 Add to Mobile Application Section 93 days Mon 1/14/13 Wed 4/17/13 Jason Ulbricht65 Keep Organized 93 days Mon 1/14/13 Wed 4/17/13 Aaron Nervi66 Proof Read and Edit if Necessary 7 days Wed 4/10/13 Wed 4/17/1367 Submit Final Report 0 days Wed 4/17/13 Wed 4/17/13 59 15 Aaron Nervi6869 Martin Luther King Day - University closed 0 days Mon 1/14/13 Mon 1/14/1370 Spring Recess 6 days Mon 3/25/13 Sun 3/31/1371 Project Demonstration and Presentation 0 days Fri 4/12/13 Fri 4/12/13 1272 Faraday Banquet 0 days Fri 4/26/13 Fri 4/26/13 1573 Senior Design Expo 0 days Wed 4/24/13 Wed 4/24/13 15

53    

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.

54    

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/android-connecting-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-and-Programmi/, [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

55    

9 Appendices

Part Datasheet  LinkArduino  Mega  2560 http://www.atmel.com/Images/doc2549.pdf

SM5100B-­‐D  GSM/GPRShttp://dlnmh9ip6v2uc.cloudfront.net/datasheets/Cellular/SM5100B-­‐D_HW_spec_V1.0.0.pdf

eTape  Water  Level  Sensorhttp://www.milonetech.com/uploads/eTape_Datasheet_12110215TC-­‐24.pdf

Current  Sensorhttp://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/Current/ECS1030-­‐L72-­‐SPEC.pdf

Speaker http://www.cui.com/Product/Resource/DigiKeyPDF/CVS-­‐3108.pdf

Secondary  Sump  Pumphttp://www.basementwatchdog.com/pdf/Basement%20Watchdog%20Brochure%20AC%20&%20Backup.pdf

LCD http://www.newhavendisplay.com/specs/NHD-­‐0420E2Z-­‐FSW-­‐GBW.pdf

 Fig. 9.1.1: Datasheet Links