Smart Shower Project - University of San Diegocatcher.sandiego.edu/items/usdengr/SmartShowerCDR.pdf · Smart Shower Project USD i Abstract The ShowerMinder is an existing product

Smart Shower Project

A Critical Design Review Submitted by: Matt Gigli

Allison Harms David Hopkins Chris Steward

ELEC 492

March 22, 2011

Smart Shower Project USD i

Abstract

The ShowerMinder is an existing product that attempts to change behavior in water usage by making

people mindful of how long they are in the shower. Currently, the ShowerMinder lacks the ability to

perform experiments and record data to catalogue behavior change patterns. The Smart Shower project

aims to give the ShowerMinder the capabilities to record shower times and wirelessly transmit the data

to an online database that will process data into useful formats and be visible to those interested. It will

provide the ability to send timer programming instructions back to the Smart Shower system over the

wireless network, so that the Smart Shower administrator can control the timers to find the most

effective shower timer setting. By combining the ShowerMinder idea with wireless data transmission

capabilities, the Smart Shower can help customers not only save money in wasted water by shortening

shower times, but also help change the behavior of young adults to be more mindful of their habits and

help save the worlds most precious natural resource, water.

Smart Shower Project USD ii

Table of Contents

Abstract .......................................................................................................................................................... i

List of Figures ............................................................................................................................................... iv

List of Tables ................................................................................................................................................. v

1 Project Deliverables .............................................................................................................................. 1

1.1 Background of the Project ............................................................................................................ 1

1.2 Project Deliverables ...................................................................................................................... 1

2 Overall Smart Shower System ............................................................................................................... 2

2.1 Smart Shower System Description ................................................................................................ 2

2.2 Smart Shower Implementation Test ............................................................................................. 3

3 Subsystem Analysis and Results ............................................................................................................ 4

3.1 ShowerMinder Subsystem ............................................................................................................ 4

3.1.1 Mechanical Enclosure Component ....................................................................................... 5

3.1.2 Printed Circuit Board Component ........................................................................................ 5

3.1.3 Antenna Component ............................................................................................................. 8

3.1.4 CC2530 Software Component ............................................................................................... 8

3.2 Coordinator Subsystem ............................................................................................................... 10

3.2.1 Printed Circuit Board Component ....................................................................................... 10

3.2.2 Antenna Component ........................................................................................................... 11

3.2.3 CC2530 Software Component ............................................................................................. 12

3.2.4 Adruino Uno Software Component .................................................................................... 14

3.2.5 PHP Software component ................................................................................................... 15

3.2.6 Mechanical Enclosure Component ..................................................................................... 16

3.3 Data Display Subsystem .............................................................................................................. 17

3.3.1 Site Layout ........................................................................................................................... 18

3.3.2 Manage Groups ................................................................................................................... 18

3.3.3 Manage Showers ................................................................................................................. 18

3.3.4 Timer Setting ....................................................................................................................... 18

3.3.5 Export Data ......................................................................................................................... 19

3.3.6 Display Average ................................................................................................................... 19

3.3.7 Graphs ................................................................................................................................. 19

3.3.8 System Alert ........................................................................................................................ 19

Smart Shower Project USD iii

3.3.9 iPhone Application .............................................................................................................. 19

4 System Integration .............................................................................................................................. 20

5 References .......................................................................................................................................... 21

6 Acknowledgments ............................................................................................................................... 22

7 Appendices .......................................................................................................................................... 23

7.1 Complete Parts List ..................................................................................................................... 23

7.2 Technical Design Documents ...................................................................................................... 26

7.2.1 Overall System Design Documents ..................................................................................... 26

7.2.2 ShowerMinder Subsystem Design Documents ................................................................... 29

7.2.3 Coordinator Subsystem Design Documents ....................................................................... 40

7.2.4 Data Display ........................................................................................................................ 49

Table Name: showerdata ........................................................................................................................... 49

Table Name: showers ................................................................................................................................. 49

Table Name: showergroups ....................................................................................................................... 50

Table Name: dorms..................................................................................................................................... 50

Smart Shower Project USD iv

List of Figures

Figure 7.2.1.1-1: Overall System Block Diagram ........................................................................................... 3

Figure 2.2-7.2.1.1-1: System Layout Diagram ............................................................................................... 4

Figure 7.2.2.1-1: Original ShowerMinder ................................................................................................... 30

Figure 7.2.2.1-2:Original PCB of ShowerMinder ......................................................................................... 30

Figure 7.2.2.2-1: Modified ShowerMinder ................................................................................................. 31

Figure 7.2.2.4-1: PCB Shape Layout ............................................................................................................ 32

Figure 7.2.2.4-2: Bottom Layer ShowerMinder Schematic ......................................................................... 33

Figure 7.2.2.4-3: Top Layer ShowerMinder Schematic ............................................................................... 34

Figure 7.2.2.4-4: Top Layer of ShowerMinder PCB ..................................................................................... 35

Figure 7.2.2.4-5: Bottom Layer of ShowerMinder PCB ............................................................................... 36

Figure 7.2.2.4-6: Photovoltaic Cells Voltage Incorporated with Batteries ................................................. 36

Figure 7.2.2.4-7: Incorporated Sample Layout of Boost Regulator ............................................................ 37

Figure 7.2.2.5-1: LED Circuit Design ............................................................................................................ 38

Figure 7.2.2.8-1: Flow Chart of Software .................................................................................................... 40

Figure 7.2.3.2-1: Coordinator Schematic .................................................................................................... 42

Figure 7.2.3.2-2: Top Layer Coordinator PCB .............................................................................................. 43

Figure 7.2.3.2-3: Bottom Layer Coordinator PCB ........................................................................................ 44

Figure 7.2.3.2-4: Voltage Divider Schematic ............................................................................................... 44

Figure 7.2.3.2-5: Comparator Schematic .................................................................................................... 45

Figure 7.2.3.3-1: Side View of Coordinator Enclosure ................................................................................ 45

Figure 7.2.3.3-2: Top View of Inside of Coordinator Enclosure .................................................................. 46

Figure 7.2.3.3-3: "Fittable" Area Inside Coordinator Enclosure ................................................................. 46

Figure 7.2.3.5-1: Flow Chart of Coordinator Software ............................................................................... 48

Figure 7.2.4.1-1: Website Screenshot ......................................................................................................... 49

Figure 7.2.4.3-1: Manage Groups Flowchart .............................................................................................. 51

Figure 7.2.4.3-2: Manage Groups Code ...................................................................................................... 53

Figure 7.2.4.3-3: Manage Groups Screenshot ............................................................................................ 54

Figure 7.2.4.4-1: Manage Shower Flowchart .............................................................................................. 55

Figure 7.2.4.4-2: Manage Showers Code .................................................................................................... 59

Figure 7.2.4.4-3: Manage Showers Screenshot .......................................................................................... 59

Figure 7.2.4.5-1: Timer Setting Flow Chart ................................................................................................. 60

Figure 7.2.4.6-1: Export Data Script ............................................................................................................ 61

Figure 7.2.4.7-1: Display Average Flowchart .............................................................................................. 62

Figure 7.2.4.7-2: Display Average Code ...................................................................................................... 62

Figure 7.2.4.8-1: Graphs Flowchart ............................................................................................................. 63

Figure 7.2.4.8-2: Graphs Screenshot ........................................................................................................... 64

Figure 7.2.4.9-1: System Alert Block Diagram ............................................................................................ 65

Smart Shower Project USD v

List of Tables

Table 7.2.1.1-1: Website Specifications ...................................................................................................... 17

Table 7.2.1.1-1: Overall Parts List ............................................................................................................... 24

Table 7.2.2.3-1: ShowerMinder PCB Functional Specifications .................................................................. 31

Table 7.2.2.5-1: Power Estimates ............................................................................................................... 37

Table 7.2.2.6-1: Hardware Specifications for ShowerMinder ..................................................................... 38

Table 7.2.2.7-1: Software Requirements for ShowerMinder ..................................................................... 39

Table 7.2.3.1-1: Coordinator PCB Specifications ........................................................................................ 41

Table 7.2.3.1-2: Coordinator Hardware Specifications ............................................................................... 41

Table 7.2.3.3-1: Coordinator Mechanical Specifications ............................................................................ 45

Table 7.2.3.4-1: Software Specifications for Coordinator ........................................................................... 47

Table 7.2.4.2-1: Data Dictionary for "showerdata" .................................................................................... 49

Table 7.2.4.2-2: Data Dictionary for "showers" .......................................................................................... 50

Table 7.2.4.2-3: Data Dictionary for "showergroups" ................................................................................ 50

Table 7.2.4.2-4: Data Dictionary for "dorms" ............................................................................................. 50

file://ENGR225/ShowerMinder/ShowerMinder/CDR/CDR_Current%20(Repaired).docx%23_Toc288576913

Smart Shower Project USD 1

1 Project Deliverables

1.1 Background of the Project

Today, we find ourselves in a time where water conservation and waste awareness have become

prominent in everyday life and have led to the increasing need for conservation products. The Director

of Sustainability at the University of San Diego, Michael Catanzaro, has this need and wishes to conserve

water usage on USDs campus. San Diego is in the midst of a drought, which makes water a precious and

expensive natural resource. Mr. Catanzaro is working at conserving water at the university through

behavior modification of students living on campus to decrease their time spent in the shower. Mr.

Catanzaro wishes to display shower times and resulting water usage to the students so they can become

aware of how time spent in the shower affects the amount of water used. By addressing these needs,

there could be benefits for both the environment and the University of San Diego.

To address the needs of Mr. Catanzaro, the Smart Shower System has been designed. In the Smart

Shower system uses the ShowerMinder, an existing product that increases awareness of shower time

through the use of a five or eight minute stop light timer. The Smart Shower system will use the

ShowerMinder and add two-way communication to allow for shower time data collection, an online

data display to allow the students to see their water usage, and the capability to adjust the shower timer

on the ShowerMinder to increase the effectiveness of the overall product. Thus, through the Smart

Shower System, Mr. Catanzaros needs for water conservation and behavior modification can be

achieved.

1.2 Project Deliverables

The Smart Shower System intends to deliver a working system that promotes water conservation and

increases water usage awareness of USD students by May 6, 2011, the Engineering Open House. The

final Smart Shower System will include two ShowerMinders, the Coordinator, and the online Data

Display. At the Engineering Open House, we will showcase the two ShowerMinders talking through the

Coordinator to the Online Data Display by simulating the occurrence of a shower by tripping the

pressure switch manually since there are no showers located in Loma Hall. We will also showcase the

capability of changing the length of the LED, or light emitting diode, timer on the ShowerMinders

through the Online Data Display. Finally, we will show videos, pictures, and the resulting data collected

from when the Smart System was installed for the test run that will be conducted in April 2011 in one of

USD residential dormitories.

For the test run, the system will be set-up and tested in the South Missions B San Miguel Residential

bathroom in April 2011. The two ShowerMinders will be installed in each of the bathrooms two shower

stalls. Each of the ShowerMinders will be equipped with the adjusted PCB, or printed circuit board,

circuitry that enables the ShowerMinder to have two-way communication and an adjustable LED timer.

The Coordinator will be on the hallway wall. It will consist of an enclosed stacked PCB and Arduino Uno

board that enables two-way communication between the ShowerMinders and the Online Data Display.

The final component, the Online Data Display will have an administrator controlled version and a public

version that displays water usage of the two showers over the length of the test run and will be capable


of being accessed from anywhere with an online connection. The test run will be a vital component to

our presentation at the Engineering Open House to prove that the Smart Shower System will work

successfully installed on USDs campus.

2 Overall Smart Shower System

2.1 Smart Shower System Description

As mentioned before, the goal of the Smart Shower System is to add two-way communication to the

ShowerMinder product and to add additional functionality to promote water conservation during

showers taken on University of San Diegos campus. To accomplish this undertaking, the Smart Shower

System has been broken into three different subsystems, each which addresses specific specifications of

our system. A basic overall breakdown of the Smart Shower system and its subsystems is seen in Figure

7.2.1.1-1: Overall System Block Diagram. The first subsystem, the ShowerMinder Subsystem is the part

of the system that interacts with the user through a LED stoplight timer that displays the recommended

shower time for a particular group of showers, as well as collects shower time data. Through ZigBee

communication, the ShowerMinder Subsystem communicates shower data to the second subsystem,

the Coordinator. The Coordinator acts as an in between for the ShowerMinder Subsystem and the third

subsystem, the online Data Display. The Coordinator can communicate instructions from the online

Data Display back to the ShowerMinder through ZigBee communication. The Coordinator can also

communicate shower time data from the ShowerMinder through Wi-Fi to the online Data Display

Subsystem. The third subsystem, the Data Display acts as the users way to communicate instructions to

and read shower data from the ShowerMinder Subsystem through an online website. The Data Display

Subsystem is further broken down into two parts. One display can only be accessed by an administrator

and has the capabilities to adjust ShowerMinder settings and see all the incoming shower data. The

second display can be accessed by the public and will display shower usage and times on USDs campus

as controlled by an administrator. For more detailed descriptions of the subsystems, please refer to

Section 3: Subsystem Analysis and Results.


Smart Shower System

Wi-Fi/ ZigBee

Coordinator

Internet

Public Website

Administrator Website

Coordinator

ShowerMinder (ZigBeenode)

Data Display

ZigBee Communication

Wi-Fi/Internet Connection

Group A Group B

Subsystems

Figure 7.2.1.1-1: Overall System Block Diagram

2.2 Smart Shower Implementation Test

As described in Section 1.2 Project Deliverables, during April 2011, the Smart Shower System will be

implemented and tested in one of USDs residential bathrooms. In Figure 2.2-7.2.1.1-1: System Layout

Diagram is a layout of how the system will be implemented in South Missions B San Miguel residential

bathroom. As described before, two ShowerMinders will be installed in the two shower stalls in the

second floor San Miguel bathroom. The ShowerMinders will transmit and receive shower data through

ZigBee communication to the Coordinator located on the wall hallway corner. The Coordinator will be

powered from an outlet approximately 2 ft away and will be placed at a diagonal distance of

approximately 21 ft and 10 inches from the furthest ShowerMinder. From the Coordinator, the data is

transmitted to and received from the administrator controlled Data Display via Wi-Fi, and from there the

data can be accessed by any device that has access to the public website. For information on the

progress on all of these subsystems and development toward implementation please refer to Section 3:

Subsystem Design and Analysis.


Figure 2.2-7.2.1.1-1: System Layout Diagram

3 Subsystem Analysis and Results

3.1 ShowerMinder Subsystem

Overall Subsystem Description

The ShowerMinder Subsystem, as briefly described in the overall system description, includes the

physical ShowerMinder and LED display, the capability to record shower time, and the capability to send

shower data and receive instructions from the Coordinator Subsystem. In order to enable the

ShowerMinder to have these capabilities, many components, both hardware and software, have to be

added to the ShowerMinder.1 These critical components are described in the following subsections of

3.1 ShowerMinder Subsystem. Since there are many components involved in this subsystem, there are

many people who are responsible for its completion. The hardware components of the subsystem were

worked on by Chris Steward and Allison Harms. The software component was worked on by Matt Gigli.

The specifications and responsibilities of each team member are described in more detail in the

descriptions of the components. See Section 7.2.1.1 to see a sequence diagram describing the

sequence of events for the ShowerMinder Subsystem.

1 Note photos of the original ShowerMinder PCB design and casing can be seen in 7.2.2.1 Original

ShowerMinder.


3.1.1 Mechanical Enclosure Component Allison Harms is the lead for this component of the ShowerMinder Subsystem. For the ShowerMinder

Subsystem, a modified version of the original ShowerMinder casing will be used to enclose the

ShowerMinder PCB and provide the LED stoplight display. The original ShowerMinder case will work

almost completely with the new PCB design as long as two specifications are met, one that allows for

two-way communication and a second that ensures the modified PCB can be housed inside the original

ShowerMinder. A mechanical drawing of the modified ShowerMinder can be seen in 7.2.2.2 Mechanical

Drawings.

The first specification is accomplished by drilling a new 0.30 hole into the metal casing parallel to the

location of the yellow LED hole in order to allow an antenna to protrude outside of the metal casing.

The antenna must protrude out of the casing in order for the best range and effective communication

through ZigBee protocol. To keep the system waterproof, the antenna will internally be surrounded by

water sealant to ensure no water from the ShowerMinder can damage the PCB. For more information

on the antenna, please refer to 3.1.2 Antenna Component.

The second specification is for the board shape of the PCB to fit within the confines of the modified

ShowerMinder casing. This is accomplished by designing a PCB board shape to be 2.7x2.5 with a

circle of 1.16 diameter cut out of the center. This specific design shape allows not only for the PCB

board to fit in the ShowerMinder casing, but also allows for the PCB production through ExpressPCB

MiniBoardPro 4-Layer Service which is the cheapest service for a 4-layer PCB service. A silkscreen

layout of the board shape can be seen in 7.2.2.3 ShowerMinder PCB Specifications

Table 7.2.2.3-1: ShowerMinder PCB Functional Specifications

Functional Specification Design

Turn on LED in ShowerMinder Using MOSFET VN2222LL as a switch to amplify current on I/O port of CC2530 will turn on LED when output voltage goes High. Designed for low power by using PWM on output. 20% duty cycle yields 1.3 mA. MOSFET needed because when PWM is High, FET will conduct 6.5 mA. (IDC= IHI*20%). The I/O ports of the CC2530 are only capable of a maximum output current of 4 mA.

Supplying a Constant 3.3 V Voltage Boost Voltage Regulator, LTC3525D-3.3, used to boost 2.4V output of 2 AA Batteries to the operating voltage of 3.3V. A sample circuit was provided in datasheet and is being implemented in design.

PV Cells deliver to power to batteries

PV cells have the possibility to conduct current if they are not generating their own electricity. A blocking diode is used to ensure that the PV cells only delivered power to batteries. Diode is connected between the AA batteries to deliver more current.

PCB fits inside the ShowerMinder casing

The PCB is will be fabricated to have dimensions 2.5 in x 2.5 in. There will be a hole of 1.18 inches cut out of the middle. The PCB will also be fabricated such that the corners will fit in the round enclosure.


PCB Layouts and Circuit Schematics.

With regards to the current status of the completion of these specifications, one of the two

specifications have currently been met. The PCB shape has been designed to the size constraints. The

additional drilled hole has not yet been cut since the final version of the ShowerMinder PCB has not yet

been manufactured; thus, to ensure proper placement of this specification it must wait until the PCB

component has been completed.

3.1.2 Printed Circuit Board Component The PCB component of the ShowerMinder Subsystem was developed by both Chris Steward and Allison

Harms. Chris Steward took lead on the overall design of the physical PCB and circuitry, while Allison

Harms worked on the schematics and assisted Chris Steward in the design of the physical PCB and

circuitry. To see a list of the specifications of the ShowerMinder PCB, please see 7.2.2.3 ShowerMinder

PCB Specifications. For reference, the PCB and schematic files of the boards can be seen in 7.2.2.3

ShowerMinder PCB Specifications









PCB Layouts and Circuit Schematics.

The overall design of the PCB took a lot of consideration due to the size constraints previously

mentioned. Therefore, the size of this PCB was the biggest concern about this design. Much

consideration had to be put into where each component was placed. From Texas Instrument's (TI's)


website (1), files of the layout of the CC2531 were found which assisted in design of board layout. The

file referred to the CC2531, a USB Dongle that uses the CC2530. The layout of this component was

duplicated for the powering up and debugging of the ShowerMinders CC2530 . An additional

component, the Johanson's 2450BM15A0002 Impedance Matched-Balun-Low Pass Filter was found in

the TIs files. The Balun was implemented in our design because it replaces the seven components in

the matching network outlined in the datasheet of the CC2530 with one small and discrete packaged

part, thus saving board space. The specifications of this part and the Antenna can be seen in 7.2.2.6

Hardware Specifications for ShowerMinder.

Besides reducing components, reduction to the number of traces was also applied. This was

accomplished mainly by using a four layer board. It creates a layer for both power and ground, and

allows one to connect any component to power or ground by use of a small trace connecting the

component to a pad which is connected to one of the two layers. Another consideration was to reduce

electrical noise. To accomplish this, more paths to ground were provided by inserting two copper layers

on both the top and bottom layers of the PCB that were connected to the internal ground plane by

inserting pads around the board and making sure all three layers were connected. Proper grounding of

the board becomes very important with respect to the antenna and its performance. If there are not

enough paths to ground for the antenna, charge will build up around the base of our SMA connector.

This build of charge will look like a capacitor and will result in an impedance mismatch.

One last consideration had to be made with regards to the board. The initial design of the PCB was to

meet the size specifications and the center hole cut. The fabrication service, ProtoPro 4-Layer Service,

provided by ExpressPCB would produce four boards and cost $236.26. To reduce the cost and number

of boards received a different route was taken. The MiniBoardPro 4-Layer Service will be used. This

service returns three fabricated boards for the price of $130.77. Hence, after the three revisions made

on the design of the PCB, the board had to be altered one last time to use the MiniBoardPro service.

The current layout can be seen in 7.2.2.4 PCB Layouts and Circuit Schematics.

Besides the design of the physical PCB board itself, some circuit design was necessary in order to meet

power specifications, to ensure proper integration of the CC2530, and to make the overall PCB

component compatible. Three major circuit designs were made: a recharge circuit, a boost regulator,

and a modified LED display.

In the original ShowerMinder design by Water Smart Technologies, five photovoltaic panels were

installed in order to provide the capability to recharge the two AA batteries that at that time provided

power for the small microcontroller controlling the LED timer and the LEDs. In the Smart Showers

modification of the ShowerMinders original PCB, the photovoltaic panels were included to still provide

the recharge capability. The two main objectives in the design of how to incorporate the photovoltaic

panels were to make sure they never drew power and that they provided the maximum amount of

current possible. In order to accomplish this, the recharge circuit was designed through use of a

breadboard and a schematic can be seen in 7.2.2.3 ShowerMinder PCB Specifications










PCB Layouts and Circuit Schematics. In the recharge circuit, the photovoltaic cells are connected in

parallel so the current each delivers are added together. They are connected then to a diode, which

allows for them to deliver current to the batteries, but prevents them from drawing current from the

batteries. The diode is then connected in between the AA two batteries. The diode was placed here

because through testing, we noticed if we connected it after both the batteries, the cells would not

provide enough voltage to have current flow across the diode. By only having one battery after the

diode, the cells were capable of providing enough voltage to have current flow across the diode even in

ambient lighting. Through measurements, the current the cells were able to provide in ambient lighting

was about .130 mA, which is more than enough run the ZigBee CC2530 in sleep mode. Therefore, our

design of the recharge circuit provides maximum current to the rechargeable batteries as well as

ensures the photovoltaic cells do not draw any current themselves.

After the recharge circuit is the boost regulator design. The boost regulator is used to step-up the 2.4V

of the AA batteries to the specified operating voltage of 3.3V. This is done to ensure a constant voltage

supply to the CC2530. For this requirement, the LTC3525D-3.3, a step-up boost regulator, was chosen

to get our input voltage to the required 3.3V. The chosen regulator also is capable of providing the 3.3 V

output for as little as .85 V input, thus ensuring our system longest possible operating time. To properly

bias the regulator for the 3.3V, a sample circuit design provided on the products website was used. The

sample design circuit can be seen in 7.2.2.3 ShowerMinder PCB Specifications










PCB Layouts and Circuit Schematics. Since the circuit was already designed to our specifications, a demo

board kit was not purchased. The voltage coming out of the boost regulator circuit will be capable of

being tested on the ShowerMinder PCB.

Finally, the design of the original LED display had to be modified from the original ShowerMinder design

of the LED display. The LEDs need to be placed in the correct position on the board to ensure that they

will fit in the enclosure. The electronics in the ShowerMinder are designed to be low power. The input

voltage to the LED was tested with a 3.3V square wave at a 20% duty cycle. The apparent DC current

running through the green diffused LED is 1.543 mA. Therefore on the High output of the square wave,

the current running through the diode is 7.715 mA (1.543mA/20%). The I/O ports used to light the LEDs

on the CC2530 are only capable of giving 4mA. Similar results were found for the red and yellow LEDs as

well and can be seen in 7.2.2.5 Power Estimates of LEDs. To resolve this problem, circuitry needs to be

added to the board.

Therefore, to ensure enough current goes to the LEDs in the High cycle of the output signal a VN2222LL,

an N-Channel Enhancement MOSFET, is used as a switch. The I/O port of the CC2530 is connected to

the gate of the VN2222LL. When the output goes high, negligible current enters the gate terminal and

the FET turns on and lights the LED. When the output is low, the FET is off and nothing happens. To

look like constant high output is turning on the LED, the frequency of the pulsed output is fast enough

that the human eye cannot pick up on the flashing output. This configuration allows the necessary

current to turn on the LEDs. The MOSFET is a much more efficient switch opposed to a BJT since it

consumes less power.

To test the functionality of the PCB, Chris Steward and Allison Harms have been responsible for testing

every circuit on a breadboard excluding the boost regulator. The recommended mounting instructions


found in the boost regulator parts datasheet has been copied and placed in the PCB. With the rest of

the parts working on the breadboard, there is a high chance success of a successful PCB design.

Another test procedure has been for the risk associated with the success of having working Radio

Frequency (RF) circuitry on the ShowerMinder PCB due to size constraints limiting the RF circuitry

design. Rather than spend the extra money and go through the efforts of precisely cutting the

ShowerMinder PCB, extra space on the Coordinator PCB has been used to place an extra CC2530 and the

ShowerMinder RF circuitry has been copied. This sample circuit increases the likelihood of success of

the ShowerMinder PCB by allowing for testing and debugging of the RF design.

Finally, to ensure that the LEDs have been placed correctly and the board has the correct dimensions,

the layout created in ExpressPCB has been printed onto a piece of paper and placed in the

ShowerMinder. Based upon the position of the silk screen it has been verified that the parts are placed

in the correct position and that the PCBs dimensions meet the specifications. Currently, the Coordinator

PCB has been received, and once the testing of the Coordinator PCB is completed, the ShowerMinder

PCB will be ordered. To verify the functionality of the circuitry, a sample program will need to be loaded

onto the ShowerMinders CC2530. If we get the results we expect based upon how the program is set-

up, we will know the PCB has been designed correctly.

3.1.3 Antenna Component The antenna chosen for the ShowerMinder is the ANT-2.4-CW-RH-SMA manufactured by Antenna Factor

(2). This product was chosen because of its fully weatherized and compact design. The fact that it is

fully weatherized means that it can be sticking out of the mechanical enclosure and exposed to the wet

environment of the shower. Also, since it is small, it will not make the product aesthetically

unappealing. Some other characteristics are that it is a monopole antenna, which attributes to its

smaller size, and it is connected by an SMA allowing for wide versatility in testing the antenna.

This antenna has been tested with the CC2530 Development Kit (CC2530DK), or the CC2530

Development Kit, with it sticking out of one of the mechanical enclosures that we have. During testing

in Missions B San Miguel, it was found that we were able to communicate over a distance of 20 ft. If

transmitting and receiving becomes an issue once the PCB is installed in the ShowerMinder enclosure,

we will be able to use the PCBs SMA connector. We can connect coaxial cable from the SMA connector

to the antenna away from the enclosure. However, since we had successful transmission with the

CC2530DK, there is a medium level risk associated with the antenna.

3.1.4 CC2530 Software Component Matt Gigli took the lead on this component. For the ShowerMinder Subsystem software, there are four

major features. First, upon connecting to the ZigBee networks coordinator, the shower sends its unique

64 bit IEEE extended address as well as its network-unique 16 bit node address to the coordinator. This

information is used to insert this shower into the Smart Shower database as an active shower. It also

serves as a way of making sure that the node address that is saved in the database actually corresponds

to the specific shower that it means to. For example, if a ZigBee network goes down, when the network


is reformed, each shower may have a different node address than when it first was inserted into the

database, meaning that the node address in the database may no longer be correct. By sending the

extended address and its current node address every time it connects to its coordinator, the database

can check that the node address that corresponds to that particular extended address is still the same; if

it has changed, then the database knows to reflect this change in its records for that shower. This

function is a bit of a formality; it does not directly help to meet any particular specifications, but is

needed in order to maintain the integrity of the database of shower records so that specific showers do

not get mixed up.

The next feature for the ShowerMinder software is the most important: the shower. When the shower

turns on, it blinks the green LED to reflect the number of minutes that the timer is currently set for,

letting the user know how long their timer shower should be. Then it lights the green LED solid letting

the user know that the timer has begun, and it starts timing how long the shower actually lasts. When

there is 60 seconds left in the shower, the yellow LED is lit and the green LED is turned off. When the

timer runs out, the red LED flashes once per second letting the user know that the timer has expired.

When the water is turned off, the red LED is turned off and the length of the shower is calculated and

sent to the coordinator along with the node address and current timer setting of that shower head. The

shower head then enters sleep mode, preserving its batteries. This feature satisfies specifications 1-4 in

7.2.2.6 Hardware Specifications for ShowerMinder

Table 7.2.2.6-1: Hardware Specifications for ShowerMinder

Specification Design

Waterproof Antenna capable of TX/RX signals within 20 feet

Antenna, ANT-2.4-CW-RH-SMA, made by Linx Technology chosen because of fully weatherized and rugged & damage-resistant. Verified through testing with Development kit of TX/RX range of 20 feet. This is a monopole which has been chosen because it is smaller and makes for an aesthetically pleasing design.

Matched Impedance Between CC2530 and Antenna

IC by Johanson Technology Inc, 2450BM15A0002, found to replace passive network used in the CC2530EM. This part significantly reduced the number of components needed in design.


Software Specifications for ShowerMinder.

In addition to recording shower lengths and displaying the timer, the Smart Shower system allows the

administrator of the system to change the length of the timer in each shower. When the coordinator

sends an update timer message, the shower head receives the message and changes its timer, in

seconds, to the received length. It then calculates the number of minutes (rounded down), which is

used when the shower starts (described above). This feature meets specification 5 in 7.2.2.6 Hardware

Specifications for ShowerMinder








Software Specifications for ShowerMinder.

The last feature is a simple one, which may not really be necessary, but could be useful in some

instances and is included in the specifications. The system allows for the administrator to use the web

site or iPhone application to blink the green LED to check the timer setting for a particular shower. This

isnt particularly useful because if you have access to the website, you can see what each showers timer

is set for. This may be useful if you are trying to determine which shower in the database corresponds

to which physical shower, or to check to make sure that the database correctly reflects the timer setting

that a particular shower is actually set for. This feature satisfies specification 6 in 7.2.2.6 Hardware

Specifications for ShowerMinder








Software Specifications for ShowerMinder. The flow of data is described visually with a flow chart found

in section 7.2.2.6.

All testing at this point has been done using a CC2530DK Development Kit, which includes two

SmartRF05 boards and two CC2530EM Evaluation Modules.

To test the initialization step, the end device sends its extended address and node address to the

coordinator when it connects to the network, and the coordinator displays this information on its LCD

screen when it is received. Thus, this feature has been successfully tested using the development kit.

To test the shower feature, three LEDs on the SmartRF05 boards are used to represent the green, yellow

and red LEDs of the Shower Minder, and the joystick on the SmartRF05 is used as the trigger to signal

the beginning and end of a shower. To test, you push the joystick up to begin a shower (water turned

on) and down to stop a shower (water turned off). All specifications of this feature have been

successfully tested using the development kit.

The timer reprogramming feature has been tested by sending new timer values from the coordinator to

the end device, and having the green LED blink to indicate the number of minutes of the new timer.

Then you can use the joystick to start and stop the timer and, using a stopwatch, verify that the new

timer has been updated. This feature has been successfully tested using the development kit.

The timer check feature has been tested by blinking the green LED to indicate the number of minutes of

the current timer when a shower starts. It has not been implemented on the web site or the iPhone

application yet. However, the end device has been successfully programmed to blink its green LED for

the number of minutes of the timer, so this specification for the end device has been met.

For a better description of all transmitted messages for the ShowerMinder subsystem, refer to section

7.2.1.2. For a better description of all transmitted messages for the Coordinator Subsystem, refer to

section 7.2.1.2. All source code can be found at:

http://home.sandiego.edu/~mjgigli/smartshower/CDR%20Source%20Code/

3.2 Coordinator Subsystem


The Coordinator Subsystem, as briefly described in the overall system description, includes the physical

coordinator casing and accessories, the capability to send and receive shower data and instructions to

and from the ShowerMinders, and the capability to send and receive shower data and instructions to

and from the online Data Display. In order to enable the Coordinator to have these capabilities, many

components, both hardware and software, had to be designed. These critical components are described

in the following subsections of 3.2 Coordinator Subsystem. Since there are many components involved

in this subsystem, many people are responsible for its completion. The hardware components of the

subsystem were worked on by Chris Steward and Allison Harms. The software component was worked

on by Matt Gigli. The specifications and responsibilities of each team member are described in more



detail in the descriptions of the components. See Section 7.2.1.1 to see a sequence diagram describing

the sequence of events for the Coordinator Subsystem.

3.2.1 Printed Circuit Board Component The PCB component of the Coordinator Subsystem was worked on by both Chris Steward and Allison

Harms. Chris Steward took lead on the overall design of the physical PCB and circuitry, while Allison

Harms worked on the schematics and assisted Chris Steward in the design of the physical PCB and

circuitry. The specifications of the Coordinator PCB and the specifications for the hardware can be

found in 0


Coordinator PCB and Hardware Specifications

The PCB design for the coordinator included overall design of the physical PCB itself and some basic

circuitry design. For the physical PCB design, the Coordinator PCB has been designed to attach to the

Arduino Uno board through stackable headers. Since it connects to the Arduino as a shield, the PCB is

able to get a supply voltage of 3.3V from the Arduino. Furthermore to prevent from making additional

traces and saving space, the board was originally set up as a two layer board with copper layers on top

and bottom to serve as ground planes. The board layout was also duplicated from the layout provided

in the CC2531 files from TI like the ShowerMinder. And finally, the Coordinator uses Johanson's Balun

component, like the ShowerMinder PCB, to cut down on the number of parts used in total.

Also to be noted, there was a lot of extra space left on the left hand side of the Coordinator board. After

risk was identified with the RF circuitry of the ShowerMinder PCB, the Coordinator board was made into

a four layer board to allow for the left side of the board to have the copied CC2530 layout and RF path of

the ShowerMinder PCB. This provides a mean to test the functionality of the RF circuits on the

ShowerMinder PCB before ordering three PCBs of the ShowerMinder design.

Besides the physical PCB design, the circuitry design associated with the PCB component is to allow for

proper communication between the CC2530 and the Arduino Uno board. In order to makes these

compatible, two main circuits had to be designed. The first circuit design was a simple voltage division

using resistors to step down voltages for the MOSI, or master output slave input, and CLK, or clock,

signals for communication between CC2530 and Arduino via Serial Peripheral Interface (SPI)

communication. The step down circuit was required because the Arduino outputs a Logic High signal of

5V, and VIN_MAX of CC2530 is 3.6 V. Thus, the MOSI and CLK signals of the Arduino were stepped down

to prevent damage to the CC2530. The second circuit design was needed to step down the voltage of

the CS, or chip select, signal from the Arduino for communication between CC2530 and Arduino via SPI.

A step down in the CS voltage is needed because, like the MOSI and CLK signals, the Arduino outputs a

Logic High signal of 5 V, and the VIN_MAX of the CC2530 is 3.6 V. A simple voltage division through

resistors cannot be used, however, due to an internal pull-up resistor on the CS signal in the CC2530.

Therefore, the requirement is met by using a comparator (LM311N) to step down a Logic High from the

Arduino CS of 5 V to 3.3 V. The circuit designs of the voltage dividers and comparator can be seen in 0


Coordinator PCB and Hardware Specifications

Table 7.2.3.1-1: Coordinator PCB Specifications


Stack PCB on Arduino The size of the PCB is the same as the Arduino Wi-Fi Shield.

Supplying a Constant 3.3 V Voltage To supply 3.3 V to the CC2530 we will use the 3.3V power pin from the Arduino Header.

Step down voltages of MOSI and CLK signals for communication between CC2530 and Arduino via SPI

Arduino outputs a Logic High signal of 5V, and VIN_MAX of CC2530 is 3.6 V. The MOSI and CLK signals were able to be stepped down with a simple voltage divider.

Step down voltage of CS signal for communication between CC2530 and Arduino via SPI

Arduino outputs a Logic High signal of 5 V, and VIN_MAX of CC2530 is 3.6 V. Due to an internal pull-up resistor on the CS signal in the CC2530, a comparator (LM311N) is used to step down a Logic High from 5 V to 3.3 V.

Table 7.2.3.1-2: Coordinator Hardware Specifications


Stack PCB on Arduino Stacking Coordinator on Arduino required us to use the specific headers related to the Arduino. The same configuration used for the Arduino Wi-Fi Shield is replicated in the PCB design of Coordinator.

Antenna capable of TX/RX signals within 20 feet

Antenna, ANT-2.4-CW-HWR-SMA, made by Linx Technology chosen because of fully weatherized and rugged & damage-resistant. Since size is not an issue, a dipole has been chosen because it is ground plane independent. This allows for a cheaper PCB to be fabricated.



PCB Board Layout and Circuit Schematics. For further information on SPI communication, please see

3.2.3 CC2530 Software Component

All of the circuits involved in the Coordinator have been tested in the breadboards and are working.

Also, a sample board has been made to connect to the Arduino to simulate our board communicating

via SPI. ViaSat has soldered the surface mount parts on two of our Coordinator boards we have received

from ExpressPCB, and all of the through hole parts have been soldered. One board is set up to be the

Coordinator, and the other board is set up to be the ShowerMinder test board. To test the functionality

of the boards, we plan on loading simple software that communicates via ZigBee. Since the program has

not yet been able to test it as an end device, we have verified the functionality of the power. The

Coordinator side of the board successfully receives power from the Arduino and is grounded properly.

On the ShowerMinder side of the board, power and ground are successfully connected. Once the

CC2530 is correctly programmed the functionality of the RF circuitry can be verified.


3.2.2 Antenna Component The antenna chosen for the coordinator is ANT-2.4-CW-HWR-SMA manufactured by Antenna Factor (2).

This antenna is a dipole antenna and larger than the one used in the ShowerMinder. The Coordinator is

not restricted by aesthetic appeal because the antenna can be concealed inside of the mechanical

enclosure in this design. The benefit of using a dipole is that it is ground plane independent and has a

wider radiation pattern than a monopole. Chris chose this antenna because in theory it should be a

more reliable than the ANT-2.4-CW-RH-SMA used in the shower heads. If for some reason this part fails,

it is connected via SMA and the ShowerMinder antenna, the ANT-2.4-CW-RH-SMA, can be put in its

place with ease.

This antenna has not been brought down to Missions B yet and no range data can be presented for this

specific antenna. While using the CC2530DK, we have placed this antenna on the system and has

transferred data in lab. Therefore we know that the component actually works.

3.2.3 CC2530 Software Component Matt Gigli worked as lead on this component. The Coordinator software of the CC2530 controls the flow

of messages to and from the showers in the ZigBee network with the Arduino part of the Coordinator

system. Its major features are to initialize a new network group in the database upon startup, send

shower data (which consists of the showers node address, the duration of the shower, and that

showers current timer setting) via SPI, to send the initialization information of a shower when it joins its

network via SPI, to send a timer setting update to the appropriate showers in its network via ZigBee, and

to send a message to a specific shower via ZigBee to check its timer setting when it receives a message

from the website or iPhone app to do so.

In the Smart Shower system, each Coordinator is the center of a particular ZigBee network, on the data

display side, we call each ZigBee network a group, and the administrator is allowed to name a group

instead of referring to that network by its panID. When the Coordinator starts up and establishes a

network with a particular panID, it must send its panID to the database to make sure that it has a record

of that network, or group. Thus upon startup, the CC2530 of the Coordinator will copy its panID into a

buffer and set an output that is connected to the Arduino, called the dataReady pin. When the buffer is

set, the shift register of the DMA controller that is associated with the buffer is automatically set to send

the first byte in the buffer, and the DMA controller waits for the master to begin clocking data out on

the MISO, Master In Slave Out, line. This satisfies specification 3 in 7.2.3.4 Software Specifications for

Coordinator.

When a shower sends its shower data to the coordinator, the CC2530 of the Coordinator receives a

particular type of message so that the coordinator knows what type of information is contained in the

message. The information received is copied to a buffer, the messageID byte of the buffer is set to s to

signify that the message coming across contains shower data, and an output that is connected to the

Arduino (called the dataReady pin) is set high. When the buffer is set, the shift register of the DMA

controller that is associated with the buffer is automatically loaded and ready to transmit over its MISO

pin, but it must wait for the master to start the clock so that the data can be clocked out of its shift

register. When the SPI transfer is complete, it sets the dataReady pin low and goes back to sleep. By


sending the shower data from the ZigBee network on to the Arduino, this satisfies part of specification 1

in 7.2.3.4 Software Specifications for Coordinator.

When a shower joins a ZigBee network, it sends its extended address and node address to its

coordinator to either initialize that shower in the database or check to make sure that the node address

in the database correctly reflects that particular shower. When a shower sends its initialization

information, it sends it in a particular message so that the coordinator knows what kind of information is

contained in the message. The extended address and node address are loaded into a buffer and sent via

SPI in the same manner as the shower data, except that the messageID is set to i to signify that the

incoming data is initialization information. Although this does not directly relate to any of the

Coordinator specifications, it is essential in maintaining the integrity of the shower records kept in the

database.

A DMA in the CC2530 is set up to receive SPI data when the Arduino sends data across the MOSI pin.

When data is received via SPI, it is stored in a buffer, and the data in the buffer is parsed to extract the

panID, nodeAddr and the timer setting. If the nodeAddr is set to 0xFFFF, then the new timer setting is

sent to all showers in the network; otherwise, the new timer setting is sent in a ZigBee packet to the

node address given by nodeAddr. This satisfies specification 2 in 7.2.3.4 Software Specifications for

Coordinator.

Finally, the same DMA that is set up to receive SPI data can be used to receive a message to tell a

shower to blink to display its current timer setting. If this message is received via SPI, then the ZigBee

Coordinator will send a ZigBee packet with a messageID of c to the specified node address in the SPI

message, telling that specific shower to display its timer setting. This satisfies specification 5 in 7.2.3.4

Software Specifications for Coordinator. The flow of data is described visually with a flow chart found in

section 7.2.3.4.

Note that meeting specification 4 in 7.2.3.4 Software Specifications for Coordinator has proven to be

challenging. I have yet to determine the best way to check if a node is still connected to the network

without directly sending it a message and seeing if it replies, which would reduce battery life of the

shower head. I believe there is a way to retrieve the binding table of the coordinator, which would have

a list of all nodes bonded to that coordinator, but have not been able to figure out how to use it.

All testing at this point has been done using a CC2530DK Development Kit, which includes two

SmartRF05 boards and two CC2530EM Evaluation Modules.

To test all SPI communication from CC2530 to Arduino, I used the serial output of the Arduino to output

the data that was received via SPI. This corresponds to sending shower data and initialization data from

the CC2530 to the Arduino, and I have successfully verified that the SPI communication from CC2530 to

Arduino works properly. To verify that the SPI communication works from Arduino to CC2530, I used

the LCD screen on the SmartRF05 board to output the data that it receives via SPI, and I have

successfully verified that the SPI communication from Arduino to CC2530 works properly. This

corresponds to sending timer setting updates and check timer messages.


To test that the Coordinator can successfully receive and parse ZigBee packets from shower end devices,

I used the LCD screen on the SmartRF05 board to output the parsed data. I have successfully verified

that the CC2530 Coordinator can receive all shower data, as well as initialization data from shower end

devices.

To test that the Coordinator can successfully send broadcast packets to all end devices on its network, I

borrowed a SmartRF05 board and a CC2530EM from the Carpool Companion team and sent a broadcast

message to two end devices associated with the Coordinators network, verifying that the correct

message was sent using the LCD screen of the end devices. I also confirmed that I can send a message

to a particular end device on a network by sending a message and displaying that message on one of the

end devices LCD screen, and thus verifying that it was not received on the other end device associated

with the network. These tests correspond to sending a timer setting update to either every shower in a

network, or to a particular shower on a network. I have successfully verified that both broadcast and

unicast messages can be successfully sent.

For a better description of all transmitted messages for the Coordinator Subsystem, refer to section

7.2.1.2. All source code can be found at:


3.2.4 Adruino Uno Software Component Matt Gigli worked as the lead on this component. The Coordinator software for the Arduino Uno acts as

the liaison between the ZigBee network and the internet. It receives data from the ZigBee network via

SPI and sends it to the online database with HTTP GET requests. It also receives data from the online

database by running a local TCP server which accepts TCP sockets from the database. The database

sends the data through the socket, and the data is then sent to the CC2530 via SPI to be sent on to its

respective end device.

Upon startup, the Arduino connects to the internet via WiFi and then starts up a TCP server by listening

to a specific port for incoming TCP sockets. It waits for the CC2530 to establish a ZigBee network,

receives the panID of the network over SPI, and then sends the panID to the database to initialize its

network online. This satisfies specification 3 in 7.2.3.4 Software Specifications for Coordinator. It then

begins a never ending loop of checking if any data has been received via the TCP server, or if the CC2530

has any data to send it via SPI.

If data has been received from the TCP server, the Arduino then parses the data, first checking the

messages messageID. There are two types of messages: a timer setting update message and a check

timer setting message. If it is a check timer setting message, then the Arduino will send a message over

SPI to the CC2530 to tell the respective end device to flash its green LED to check the timer setting. This

satisfies specification 5 in 7.2.3.4 Software Specifications for Coordinator. If the message is a timer

setting update, then it parses the rest of the message, copies the node address and the new timer

setting into a buffer, and transmits the message to the CC2530 to be sent to its respective end device.

This satisfies specification 2 in 7.2.3.4 Software Specifications for Coordinator.



If the dataReady pin on the Arduino is high, that means that the CC2530 has data to be sent over SPI.

The Arduino then reads the first byte, which is the messageID byte. If it is an i, then the incoming

message is initialization information and the Arduino completes the SPI transfer and uses HTTP GET

request to send the data to the online database. If the messageID is s, then the incoming data is

shower data, and the Arduino completes the SPI transfer, packs all the necessary data into a buffer, and

also uses an HTTP GET request to send the data to the online database. This satisfies specification 1 in

7.2.3.4 Software Specifications for Coordinator.

The testing for the Arduino Uno has been done on the actual Arduino that will be used in the final

project, but the SPI communication has only been tested with a SmartRF05 board and a CC2530EM

Evaluation Module.

To test all SPI communications being received, I used the serial output of the Arduino to verify that all

messages received were equal to the messages sent. This applies to receiving shower data and

initialization data from the CC2530 over SPI. To test all transmit SPI communications, I used the LCD

screen on the SmartRF05 boards to verify that the message received by the CC2530 were equal to the

messages sent by the Arduino. I have successfully verified that all SPI communication to and from the

Arduino works satisfactorily, with occasional errors in message transmission.

To test that the TCP server is working properly, I used telnet to connect to the TCP server on the Arduino

and to send it messages, verifying that the messages received were equal to the messages I sent using

the serial output of the Arduino. I have successfully verified that the TCP server is working perfectly and

can receive data via TCP sockets.

For a better description of all transmitted messages for the Coordinator Subsystem, refer to section

7.2.1.2. All source code can be found at:


3.2.5 PHP Software component This component was designed by Matt Gigli. The Coordinator uses PHP Web Services to interface

between the Arduino and the online database. When shower data is sent to the online database, the

Arduino uses an HTTP GET request to send the data to a PHP Web Service, called insertToDatabase.php.

which then parses the incoming data and correctly enters it into the proper table in the database. When

initialization data is sent to the database, the Arduino uses an HTTP GET request to send the data to a

PHP Web Service called initialize.php which parses the data, checks if the init data is for a new shower or

if it is an update of an existing shower, and then makes the proper insert or update.

When the administrator changes the timer setting for a group or for an individual shower, the update is

sent to a PHP Web Service called timerSettingUpdate.php, which uses a function called sendNewTimer

that acts as a TCP client to connect to the Arduino and send the new timer setting.

There are also a couple of basic PHP Web Services that just pull shower groups and individual shower

information from the database and provides the data in JSON format to anything that requests that



data. These services, called showersTable.php and showerGroups.php, are used by the iPhone

application to display respective group and individual shower information. There is also one last PHP

Web Service, called iphoneUpdate.php, which takes an HTTP GET request from the iPhone to send a

new timer setting to the Arduino as well as to update the new timer setting in the database. Note that

all PHP Web Services can be found at:

http://home.sandiego.edu/~mjgigli/smartshower/CDR%20Source%20Code/PHP%20Web%20Services/

In order to test the PHP Web Services, you need to have an Arduino Uno programmed with the

Coordinator software, and it must be powered and running. I tested the database insert web services by

sending shower data from the Arduino to the respective web services, then checking the database to

see that the new data has been inserted. I have successfully verified that the insertToDatabase.php and

the initialize.php web services work properly.

To test the timerSettingUpdate.php web service, I used basic HTML forms to insert a panID, nodeAddr

and timerSetting and send this information to the web service, which then sends the data to the

Arduino and to the database. I verified that the data was correctly sent to the Arduino by outputting the

data to the serial output, and I verified the data was correctly entered into the database by checking

that the timer for the panID and node address specified was updated. I have successfully verified that

the timerSettingUpdate.php web service functions properly.

To test the showersTable.php and showerGroups.php web services, you can use your web browser to

navigate to sandiego.edu/smartshower/test/showersTable.php and /showerGroups.php, respectively,

and see that the data returned is the data from the showers and showergroups tables, respectively, in

the database. Note that both web services return data in JSON format, which is used by the iPhone. I

have successfully verified that these web services function properly.

3.2.6 Mechanical Enclosure Component The mechanical enclosure component of the Coordinator Subsystem was worked on mainly by Allison

Harms with assistance from Chris Steward in accessory selection. In 7.2.3.3 Mechanical Enclosures and

Coordinator Specifications, the three main specifications for the component are outlined.

The first specification for the mechanical component is to enclose the Coordinator PCBs which include

the original designed PCB, the Arduino Uno board, and the Wi-Fi shield. This was met by finding a

plastic enclosure of 4.380x4.280x2.155 with wall mount capabilities. A mechanical drawing of the

plastic enclosure can be seen in 7.2.3.3 Mechanical Enclosures and Coordinator Specifications. The

second specification to secure the PCBs inside the enclosure has been designed using a super strength

tacky called Uglu since the PCBs were not wide enough to screw into the provided PCB mounting holes.

The final specification was satisfied by purchasing two cords, one cord that connects from the wall

outlet to a second cord that has a converter which steps down 120 V input to 9 V DC output and

connects to the Arduino Uno board. To allow the board access to wall power, a 0.5x0.5 will be cut out

of the plastic enclosure.

http://home.sandiego.edu/~mjgigli/smartshower/CDR%20Source%20Code/PHP%20Web%20Services/


For this component of the Coordinator Subsystem, almost all of the specifications have been met. The

enclosure has been received and the accessories, the tacky and the cords, have been ordered. The only

design that has not yet been completed is the cutting out of the hole for the power cord to be able to

access the outlet power. This design will be completed once the final design of the stacked PCBs is

determined and the best location of the hole can be identified.

3.3 Data Display Subsystem


David Hopkins is the lead on the Data Display Subsystem. The Data Display System, viewable from any

web browser at http://www.sandiego.edu/smartshower, is the means by which users and the System

administrator interact with the Smart Shower system. System data is sent to and retrieved from a

MySQL database, the setup of which is outlined in Appendix 7.2.4.1 MySQL Tables Data Dictionary. From

the Data Display users can view the data that has been collected and stored in a MySQL database. In

addition the administrator can manage the system, updating the shower timers, and monitoring

showers and shower groups. A list of the Data Display specifications, as well as the design and current

status can be seen in Table 7.2.1.1-1: Website Specifications.

Table 7.2.1.1-1: Website Specifications

Specification Design Status

1. Site Layout: Create a site layout and design that is easy to navigate and has password protected page for system administrator

Install WordPress template and made page for administrator password protected

Complete

2. Manage Groups: Allow system administrator to name groups (showers on the same network), assign to dorm, and specify gender

Store data for each group in MySQL table and use an HTML form with PHP to print and submit changes

Complete

3. Manage Showers: Allow admin to name showers and view shower data including group and timer setting

Store data for each group in MySQL table and use HTML forms with PHP to print and submit changes

Completed

4. Timer Setting: Allow system administrator to set timer automatically or manually by individual, group, dorm or whole network

Use HTML form to allow administrator selection, use PHP to set ts in showers MySQL table

Partially Completed

5. Export Data: Provide access to administrator to all data in downloadable format

Use PHP to select all data from MySQL and output as .csv file

Completed, but not implemented on site

6. Display Average: Display average shower time by individual ShowerMinder, group (dorm or gender), or total network, display average at each timer setting

Use PHP to pull shower times and based on parameters and create average

Completed

http://www.sandiego.edu/smartshower


7. Graphs: Display water usage over time in line graph, compare group water usage in bar chart

Use PHP and html to pull data based on group and use Open Flash Chart to display data in bar chart

Completed

8. System Alert: System must alert admin if a ShowerMinder goes offline

Check MySQL showers table once a week to see if any showers are not connected and send e-mail to admin if any are offline

Incomplete

3.3.1 Site Layout The site layout was created by installing WordPress Content Management System (CMS) and did not require any coding. You can see the site layout in Error! Reference source not found. that the Manage Systems page has been password protected such that only the System administrator can access it.

This functionality of this deliverable can be viewed be seen by visiting

http://www.sandiego.edu/smartshower.

3.3.2 Manage Groups The Manage Groups page of the website allows the system administrator to name groups (showers on

the same network), assign to a dorm, and specify gender of the group in the MySQL table so that the

data will be changed accordingly. This has been accomplished using an HTML form with PHP coding

allowing the System administrator to update groups and have changes submitted to the MySQL

database. A flowchart of this process, the corresponding code, and a screenshot of the page can be seen

in Appendix 3.3.2 Manage Groups.

This page has been tested by updating the groups on the page and verifying that the corresponding

MySQL table was updated.

3.3.3 Manage Showers The Manage Showers page of the website allows the system administrator to name showers and view

which group they are assigned to. It also alerts the administrator if a shower is not connected to the

network. This has been accomplished using an HTML form with PHP coding allowing the System

administrator to update showers and have changes submitted to the MySQL database. A flowchart of

this process, the corresponding code, and a screenshot of the page can be seen in Appendix

This page has been tested by updating the showers on the page and verifying that the corresponding

MySQL table has been updated.

3.3.4 Timer Setting The Timer Setting page allows the system administrator to set timer automatically or manually by

individual, group, dorm or the whole network. The Data Display must update the MySQL table as well as

sending the settings to the coordinator. A PHP page has been created to do this but has not yet been

added to the site. The corresponding flowchart can be seen in 7.2.4.5: Timer Setting Flowchart.

http://www.sandiego.edu/smartshower


This deliverable is not yet fully completed. This page will be tested by using the Timer Setting to update

both the coordinator and the MySQL table.

3.3.5 Export Data The Export Data function allows the System Admin to download all data from the MySQL database to a

.csv file for whatever use he/she needs. This has been completed using a php script, but has not been

implemented on the site. The script can be seen in Appendix 7.2.4.6 Export Data Script.

This has been tested by using the function to create a .csv file and comparing it to the MySQL table. It

will be retested in the same manner from the site once this functionality has been added to the site.

3.3.6 Display Average This displays the average shower time by individual ShowerMinder, group (dorm or gender), or total

network. It has been completed using php code and modifying the group that is selected. The

corresponding flowchart and code can be seen in Appendix 7.2.4.7 Display Average Flowchart and Code.

To test this we have manually computed the average for groups and compared our results with the

results of the website.

3.3.7 Graphs Random data that has been generated in the MySQL table can be seen on the website in graphical form.

A line chart displays water consumption over time while a bar chart is used to compare dorm water

usage. This was completed using a plug-in called Open Flash Chart 2. A flowchart can be seen in

Appendix 7.2.4.8.

The graphs have successfully been populated from the MySQL table and can be seen on the website or

in Appendix 7.2.4.8.

3.3.8 System Alert The Data Display will check to see if all showers are online and send e-mail to the System administrator

if a ShowerMinder is offline. Currently the website alerts the Admin when he attempts to mange the

system but does not send an e-mail.

This will be tested by setting a shower to offline and seeing if the e-mail is delivered.

3.3.9 iPhone Application The iPhone application that is being developed will provide the user with most of the capabilities that

the web site offers, except in a compact, easy to use mobile format. There are three main views:

shower groups, showers, and shower data. The shower groups view allows the user to view the shower

groups that are online in the system, and allows the groups to be renamed. The showers view displays

all of the showers that are online in the system, organized by which group each shower belongs to. The

user can then select a specific shower and see all of its descriptive information, including its panID,

shower group name, node address, shower name, and timer setting. The user can also choose to

change that showers shower name or change its timer setting. The third view, the shower data view,


simply displays a number of graphs showing water use trends. These are taken directly from the web

site.

The iPhone application is not a project requirement, therefore there are no specifications. The iPhone

application is being developed by Matt Gigli. All source code and resources can be found at:

http://home.sandiego.edu/~mjgigli/smartshower/CDR%20Source%20Code/iPhone%20Application/Smar

tShower/

The iPhone application will be tested using the iOS Simulator provided with XCode. To test each of its

features, we will use the simulator to change shower group names, shower names and shower timer

settings and verify that the changes are reflected in the database and on the end devices, as well as view

the showers and shower groups that have been initialized in the databa