Team 13 Final Presentation Report1

Abstract— Everybody needs water. Most of don’t consider access to water in our everyday lives, but for many people around the world, not having clean water, or travelling to gather some, dominates their day.  Solving water scarcity is far beyond the scope of an SDP project, but we hope to provide a short-term, decentralized aid in the economic water scarcity crisis: Maji Safi. Maji Safi is a distributed system with two basic parts: a bubble-like device built to be deployed in unimproved water sources, and a web application. The bubble consists of a microprocessor connected to a series of water quality sensors and a GSM chip, encased in a spherical container. The web application includes an SMS query service for water-gathering users, a mobile site for device administrators, and a web interface for public data acquisition.

I. INTRODUCTION

very year, women around the world spend 40 billion hours collecting water. [1] On any given day, a woman in Africa or Asia will walk an average of 6

km to gather water for her household. [1] In large parts of the world, this is not due to a physical lack of water; instead, it is due to economic water scarcity, which occurs when there is enough actual water, but there is not sufficient infrastructure for the population to utilize it. Most of the world’s economic water scarcity occurs in Africa [2], where many people only have access to unimproved water sources. Examples of unimproved water sources include hand-dug wells, standing water and unprotected springs; examples of improved water sources include protected wells, piped water connections and rainwater collectors.

E

Currently, groups like NGOs introduce outside resources to improve the water sources themselves, building wells or other

infrastructure to solve the problem. Unfortunately, many communities don’t have the internal resources or training to maintain improved water sources.

Optimally, every community would have access to reliable, sustainable improved water sources and sanitation. We can only hope one day this will be true. In the interim, people in communities with unimproved water sources need solutions to alleviate their water-gathering load and help them make safer choices about their water. Therefore, we based our idea for a solution on the premise that people will continue using the same sources they always have. We aimed to build a cheap, maintainable tool that gave them more information about those sources, which they could check without travelling to each source. In addition, our device will provide useful data on water quality and usage patterns to people interested in implementing more permanent, infrastructure-based solutions. There are currently no products on the market quite like ours. Other water monitoring devices require professional installation, and are not designed for remote use.

II.DESIGN

A. OverviewMaji Safi consists of a remotely controlled data-collecting

device (rectangular block in Fig.1) and a cloud-server application (cloud block in Fig. 1). The data-collecting device consists of data sensing, communication and storage subsystem. The sensing subsystem is tasked with recording various water parameters (such as pH, turbidity, temperature, etc.) upon request received via on-board GSM module that communicates with a cloud-server application. The data-collecting device will be battery powered and might contain electro-mechanic subsystems that will collect water samples

for analysis

(implementation not considered yet). The sensors and GSM module are controlled by two microcontrollers whose code we write will enable remote data collection. One microcontroller will be used to manage command traffic between the cloud application and the physical device. The

J. Arble from Holyoke, MA (email: jarble@umass.edu) K. Menzie from Reading, MA (email: kmenzie@umass.edu)P. Balkam from Sandwich, MA (email: pbalkam@umass.edu) M. Tran from North Andover, MA (email: minht@umass.edu)

Maji SafiJason Arble, EE, Peter Balkam, EE, Kaitlin Menzie, CSE, and Minh Tran, CSE

Figure 1: Block Diagram

Team 13 Final Presentation Report

remaining microcontroller arbitrates the commands received from the cloud server via the GSM module. The following sections to come discuss the components of the block diagrams in detail. Figure 1 shows a block diagram of our device. Figure 2 shows a rough sketch of our completed system.

Figure 2: Device Sketch

Table 1: System Specifications

B. Block 1: Power SupplyOne of the most important requirements of the Maji Safi

System is power efficiency. For a long-term deployable device to be possible, there must be a portable power supply that is capable of delivering power for long periods of time. This specification not only requires a long-lasting battery, but a renewable resource to recharge the battery.

When selecting and designing the components for our system, we had to be constantly aware of the total power consumption of our device. Table 2 shows the power consumption for each component used. At this point we do not have the power supply built.

A renewable power source is a key feature of our device. Without one, our device cannot operate remotely nor can it sustain itself for extended periods of time. The best choice for a renewable supply is a solar panel. This is because sub-Saharan Africa has the highest solar radiance in the world.

For CDR, we had a functioning power supply. This included a 2 watt solar panel, a battery charger, two 2500mAh Lithium Ion  and a DC-DC boost converter. The

two 3.7V batteries are connected in parallel to combine their capacities. With 5000mAh of capacity, the batteries can power the whole system for 18.5 hours at peak load. The current at peak load is 270mA. The batteries and the solar panel  are connected to the charger. The charger is able to use the fluctuating current of the solar panel to charge the batteries in a controlled manner. The output of the charger is 3.7V which is too low to power the system which requires 5V. To solve this problem, a DC-DC boost converter is used. The output of the charger goes to the input of the converter which steps up the voltage to 5V with 90% efficiency. The efficiency of the solar panel is 15%.

Table 2: Power RequirementsComponent Power Consumption (mW)Water Sensor 0.125Microcontroller (LPC1768) 700GSM Module 500pH Sensor 50Turbidity Sensor 100Temperature Sensor 3Total 1353

C.Block 2: GSM ModuleThis device will be deployed and left operational in a

setting that is too remote and beyond the range of Bluetooth and Wi-Fi protocol. Our choice to utilize a GSM module was prompted by the widespread use and availability of cellular networks countries (900/1800 MHz band) in third world and by the enormous range over which GSM communication can occur.

The GSM2 Click [8] was our chosen GSM module due to its low cost, broken-out form factor, extensive support for data and voice services (in addition to SMS), and low power requirement. Another advantage of this device is its community support. The GSM Arduino Library () is compatible with this device, allowing us to focus on the device feature requirements and saving us the time of writing code to interface with the module. Device users will need to provide the module with a SIM card with a 3G-service plan from a cell provider. This enables the device to be remotely controlled using our software and data and communication protocol.

The Arduino Uno [18] was chosen as the device controller due to the module’s dependency on the Arduino GSM library. The use of a controller enables flexibility in the overall system design, enabling future implementation of cloud-server-to-device trafficking of commands such as a command priority scheme and multi-cloud server access. Our group will provide C++ libraries that will be used on the Uno to parse commands from the cloud server and communicate with another microcontroller over a UART port.

D.Block 3: Microcontroller and Data StorageThe microcontroller our team settled on was the Atmega

328 or Arduino UNO. We are using the Arduino to communicate with the GSM module and sensors. Each sensor and the GSM module has been responsive and we were able

2

Team 13 Final Presentation Report

to send commands to the Arduino to have the sensors take measurements and report data back over SMS to the web app. We can also sample data on the Arduino and decide what time intervals we would like to sample at. Once this sample rate is determined we can choose a rate to send messages out to either the server or the user.

We looked into multiple methods of data storage with this project as well. Several options exist for local data storage, depending on data capacity requirements. For light storage (0-64GB), we will equip the microcontroller with an SD card reader. If high capacity storage is desired (250 GB+), then we will transmit data from the device to a raspberry pi zero (Raspberry Pi zero, Raspberry Pi, UK) connected to a Hard Disk Drive or Solid State External hard drive using a short-range radio frequency transmitter (nRF24L01, Nordic Semiconductor, Skoyen, Norway). Data will be formatted and saved in a text file stored on the external drive. An application interface will be written on the raspberry pi zero to provide access to drive.

E. Block 4:Water Detection SensorAn important feature of the Maji Safi System is the ability

to sense if there is water at all. This is very important for the water-collecting users because with this feature they can collect water more efficiently. A lot of time is wasted by women in Africa traveling to well to collect water that is not there [1].

There are a few key requirements of the water sensor. The sensor must be capable of giving a binary status: is there water in the well or not. The sensor also must not yield any false positives. False positives were most difficult hurdle to design around. It was easy to create a sensor capable of triggering for water, but triggering only for water was a challenge. Our initial design, shown in Figure 3, would have had digital output read by the microcontroller. The output was designed to be a digital “1” for the absence of water and a digital “0” for the presence of water. The main issue with this design was that it is not very accurate. The output changed for false positives. This design is fairly power efficient with maximum power absorption of 75 mW

The revised design, shown in Figure 4 is much simpler. It involves a simple voltage divider, with one 200kΩ resistor and a set of probes. The medium between the two probes acts a second resistor. In this design, the microcontroller reads the output voltage as an analog signal. Water, with or without various contaminants, has a specific range of resistances across the one-centimeter gap between the probes. Therefore, there is a specific range of output voltages as result of water being between the probes. The microcontroller reads the output voltage and checks if it is in the specified voltage range. If it is between 1 and 2 volts, there is water, if it is greater than 2 volts or less than 1 volt there is no water. This range was found by experimenting with water with various contaminants. The results of this experiment are shown in Table 3. The advantages of this design are that it is more accurate and uses less power. This design will use a maximum of 0.125 mW.

Figure 3: Original Water Sensor

Figure 4: Current Water Sensor

Table 3: Water Sensor TestSubstance Impedance (1 cm) Output Voltage

Tap water 86 kΩ 1.50 VSugar Water 99 kΩ 1.65 VOatmeal Water 75 kΩ 1.36 VGarlic Salt Water 65 kΩ 1.23 VRice Water 90 kΩ 1.55 VMud 4 MΩ 4.76 V

F. Block 5: pH SensorDetermining the pH of water is important for assessing the

potability of water. In the United States the standard for potable water is 6-9 pH.

The pH meter used is a three-pin device that returns an analog voltage corresponding to a pH value. It operates on a 5-volt supply, as it was important that all of the sensors be able to share the same power bus. The microcontroller will take this analog voltage and convert it to a pH value. This design requires an understanding of the pH scale as well as proper handling and storage of pH probe. The user should also have some experience using analog pins on a microcontroller.

G.Block 6: Turbidity SensorOur design included the turbidity meter because

environmental scientists often want to study adaptations of an organism to ecological changes over time. In our case, we want the scientist to be able to relate turbidity measurements

3

Team 13 Final Presentation Report

to conditions that is conducive to growth of E.Coli and Coliforms; harmful bacterial species often found in improperly maintained dug wells [3], [5].

Turbidity is a measurement of the opacity of water resulting from some quantity of suspended particulates, referred to as a water sample’s Total Suspended Solids (TSS). Commonly, it’s measured by sampling, filtering, and evaporating water and weighing remaining solids. Techniques have been developed to indirectly quantify turbidity, which are necessary in applications requiring real-time, in situ measurements and efficiency. Data from these sensors possess no intrinsic physical, chemical or biological significance [16]. So it is important to note that while turbidity can be a subjective measurement that require empirical correlation between the measurement device and environmental conditions, achieved through field calibration, the results can be still be accurate and helpful [16], [17] when context of the data is taken into account.

Current marketed turbidity meters appropriate for water monitoring purposes costs upwards of 1000 USD. Due to budget constraints and lack of understanding of the instrument’s measurement methodology, we initially chose a 5 USD TSW-10 [9] washing machine turbidimeter as a substitute for preliminary testing. Consisting of a phototransistor, LED Diode Emitter pair and outputting wide range of NTU output range, the sensor was expected to deliver reasonable estimates during basic testing of the sensor. Our experiment involved submerging the TSW and recording data from tap water, tap water with dissolved sugar, and tap water that became murky after dissolving rice, oatmeal, and garlic salt powder. Sensor data showed that the TSW was consistent in measuring the cloudiness of water but with too high offset value error. Subsequent research invalidated the TSW-10 for measuring surface turbidity since it relied on a measurement methodology that is affected by color of the particulates [17]. Though we were able to demonstrate consistency in the measurement of the TSW by MDR, we were unhappy with the resolution, lack of documentation for the device, and have decided to look into building our own turbidity meter. Figure 5 shows how we implemented our turbidity meter.

Figure 5: Turbidity Meter

We researched image-processing techniques to count the number of particulates and correlate them to a particulate-concentration estimation [4]. This requires an additional controller and camera to support microscopic imaging but gives us a valid statistical approach to TSS estimation of water from a well. As an alternative, we are also working with the UMass Amherst’s Civil Engineering Department to

develop a turbidity meter to be used in a submersible (though different in application, we hope to adapt the design to our application). Additionally, we investigated an open source solution [6] which demonstrates accuracy in testing for a reasonably cost assembly (100 USD).

The design of a custom turbidity meter requires knowledge of optics, sensor measurement error, and linear regression methods. The physics of light optics is needed to understand the interaction between light and the particles with which it interacts to produce a backscatter pattern. Regression calculations must be implemented as data is collected initially for sensor zeroing and calibration to receive sensible data. Details of the calculation are provided online for the open source solution [6].

H.Block 7:Temperature SensorOne of the more important values for determining water

quality is temperature. Temperature is an important value for use because it affects the growth of bacteria (Figure 6). By recording the temperature of the water we give users a look into what type of bacteria could be growing in the water source.

The temperature sensor we chose to use is a TMP36GZ [9] a three pin analog device that we wire into a 5-volt supply, ground, and an analog pin. We take in the reading as an analog voltage and use the microcontroller to convert it to a reading in degrees Celsius.

Figure 6: Bacteria Growth Temperature Dependence

I. Block 8:Web App and User InterfacesThe web app was built in Node.js [10] using the Express

framework [11] and Sequelize ORM [12].  For the most part, it is a simple CRUD app with the models developed in Sequelize, and the controller consisting of Express routes. The app was built in a pattern similar to Model-View-Controller, but it is not pure MVC, because some of the views are nontraditional and had to be built into the controller. The authentication was built using Passport.js.    The app has three user interfaces: an SMS number, powered by Twilio, [13] that allows users to text their locations and receive a list of recommendations for the optimal devices to visit in their area (based on proximity and water quality), a website designed for mobile devices that allows administrators to see the status and change the settings for the devices they control, and a full website to allow the

4

Team 13 Final Presentation Report

public, especially scientists, engineers, and other interested organizations, to access anonymized data from users and devices.     The websites have a single home page(figure 7), and are built using HTML, CSS, JavaScript and jQuery. [14] In reality, these two are one website; however, the pages meant for administrators are optimized for mobile, while the pages for public data viewers are- optimized for viewing lots of data at once (on a PC).

J. Block 9: Mobile App and SamplingWe developed an Android application for the project as

well. This app allows administrators to send various formatted text messages to the device. The app features many buttons including a button the sends the device a text ‘User’ which tells the device to return all of the values along with an explanation of what the values are. ‘C Sample Rate, Message Rate,’ this tells the device to change the rate in which it takes samples, and the rate in which to send out the averaged data. There is another button labeled “STOP” and this will inform the device to stop sending out the sampled data.

Figure 6: Mobile App

 Figure 7: Web App

K.Block 10: PCBOne of the goals for every project was to have a PCB manufactured. For our device we used a double sided PCB that accounted for the microcontroller and all needed clock circuitry. The GSM module and all sensors were also mounted to this board. We included break out pins for two additional sensors and all available digital pins with the intent of keeping this project modular with the option of expansion.

Figure 8: PCB

L. Block 11: Device EnclosureOne of the final steps in this project was to construct a device enclosure. The main initial requirements (proposed at MDR) for this enclosure are that it has to: contain every component except for the battery and the solar panel, be buoyant and stable, and be waterproof. Our initial enclosure shown in Figure 9A presented at CDR failed to meet these requirements but exceeded others. It was able to contain every component of the device including the solar panel and battery. This was due to the fact that the battery and solar panel were smaller than originally specified. However, this enclosure was not waterproof, stable or buoyant. This enclosure consisted of a 4-inch PVC pipe capped at one end with a solid cap and a screw cover on the other. Holes were

5

Team 13 Final Presentation Report

drilled in the solid cap for the sensors. The solar panel was bracketed to the screw top. Seals were made using silicone caulking. The silicone seals around the PVC seams and sensor holes did not hold. Foam tubing was used to add buoyancy and stability but failed to be adequate enough.

We made major improvements to our enclosure by FPR so that it satisfied all our requirements. We added a larger volume of foam as shown in Figure 9B. This made the device buoyant and stable. We also removed the silicone caulking and replaced it with JB Weld WaterWeld putty around the sensors and PVC cement at the PVC seams. Additionally, we sprayed Rust-Oleum LeakSeal on the inside of the enclosure. With these modifications, this enclosure met all of our requirements.

After our updated enclosure was complete, we wanted to fulfill one more specification: aesthetics. We realized this could be done with a 3D print. The final print is shown in Figure 9C. The design was taken from [19]. Initially, a 3D print was not something we considered due to cost constraints. However, our project was under budget so this was no longer an issue. Due to time constraints however, we were unable to properly waterproof the 3D print. However, this new enclosure proves that we can contain our device in clean and professional manner.

Figure 9: Enclosures A,B,C

M. Block 12: DatabaseFor our backend, we chose to use a relational database,

using Postgresql [15] as our RDBMS. We have six primary tables and one junction table. Our primary tables are Administrators, Devices, Tests, TestResults, UserRequests and DeviceRecommendations. Administrators manages the login and meta data for the device administrators; since we want to restrict access to the device test suites and settings, and we used a local authentication scheme, we need to manage the administrator credentials. Devices stores the metadata about each device, including its phone number, location, and settings. Tests is just a table relating the test ids to their names, which allows us to search results by test name and add tests without modifying the overall schema. TestResults stores each result received from a device, as well as the time it was received and the device id it originated from. UserRequests records each time user texts for device recommendations, and metadata about that request, including a hash of the user’s phone number, which can be used to determine how many users are asking for data. DeviceReccomendations also records when a user texts the app, but it instead records which devices are recommended and in what order. This data will allow us to see long-term trends about water sources. Our junction tables are AdminDevice. AdminDevice describes which devices a given administrator has privileges for. It can also show us which administrators are responsible for a given device (i.e. to email all of them if the device is malfunctioning). See Figure 8 for a graphical depiction.

Figure 10: Database

6

Key:Jason (Yellow)Peter (Green)Kaitlin (Blue)Minh (Red)

Team 13 Final Presentation Report

III. PROJECT MANAGEMENT

We have met all of our FPR goals. Our device is currently able to read pH and temperature. The turbidity is implemented, but should be calibration. The temperature sensor can accurately measure air and water temperature. The water sensor can accurately detect the presence of water. These four parameters: pH, turbidity, temperature and water status can be sent to the GSM module. The GSM module is able to send these parameters through SMS to both any cellphone and the server. The GSM is able to send this data via a text when it receives a text from the server or the cellphone. The microcontroller is able to take samples of sensors and generate an average over time. The entire physical system currently sits on a solderless breadboard.

Overall we have had a good group dynamic. There were some conflicting ideas among members for both implementation and motivation of the Maji Safi System at first. These issues have since been resolved. Our group has two electrical and two computer systems majors. This made progress slightly slower early on since the early parts of the project were software intensive. This was less of a problem in the later months because we focused more of our attention to the more physical aspects of the project such as the power supply and the device enclosure. Our team has maintained constant communication throughout the semester, by email, text and in-person. We have met in person on a weekly basis. We have also met with our advisor, Professor Siqueira.

We split responsibilities of the team in the following way. Minh, CSE, implemented the turbidity meter and assisted with the GSM module. Peter, EE, worked on the GSM module, the temperature sensor and the pH sensor. He put together the main program that ran on the Arduino. He also programed the mobile app for administrators to use. Kaitlin, CSE, created the web application, configured the database and created the user interfaces. Jason, EE, designed the water sensor, worked on both the LPC1768 and Arduino Uno programming. He also assisted with the GSM module. Table 4 shows our individual responsibilities over the duration of

the project. Figure 7 shows our device we these components broken up.

Figure 7: Device Components

IV. CONCLUSION

We created a device with end to end functionality meeting all stated system specifications and project goals. Our device is able to accurately sample and measures while floating in the water. The information is able to be collected at a data base on the Internet. Users can locate this database with device information just by typing in their address, or texting the server with their address. Administrators can edit device settings both on the website and using the mobile app.

7

Table 4: Gantt Chart

Team 13 Final Presentation Report

REFERENCES

[1] UN, "Gender and water", Un.org, 2016. [Online]. Available: http://www.un.org/waterforlifedecade/gender.shtml. [Accessed: 26- Jan- 2016].

[2] 2016. [Online]. Available: http://news.bbc.co.uk/2/shared/bsp/hi/pdfs/21_08_06_world_water_week.pdf. [Accessed: 26- Jan- 2016].

[3] Drinking Water and Groundwater Bureau, New Hampshire Water Well Board. “Causes of Positive Bacteria Results in Water Samples.” Environmental Fact Sheet. New Hampshire Department of Environmental Services. Sep. 2010. Retrieved from chrome-extension://oemmndcbldboiebfnladdacbdfmadadm/http://des.nh.gov/organization/commissioner/pip/factsheets/dwgb/documents/dwgb-4-2.pdf

[4] V. Lempitsky, A. Zisserman, “Learning to Count Objects in Images”, Visual Geometry Group, University of Oxford, 2010.

[5] Michigan Department of Environmental Quality. “Coliform Bacteria & Well Water Sampling.” DEQ Fact Sheet. Michigan Department of Environmental Quality Office of Drinking Water & Municipal Assistance.

[6] Kelley, C.D.; Krolick, A.; Brunner, L.; Burklund, A.; Kahn, D.; Ball, W.P.; Weber-Shirk, M. “An Affordable Open-Source Turbidimeter”. Sensors 2014, 14, 7142-7155.

[7] Tortora GJ, Funke BR and Case CL. 2007. Microbiology: An Introduction. Pearson Benjamin Cummings, San Francisco

[8]“GSM2 Click - Board in mikroBUS™ form factor that features Quectel M95 GSM/GPRS module,” GSM2 Click - Board in mikroBUS™ form factor that features Quectel M95 GSM/GPRS module. [Online]. Available at: http://www.mikroe.com/click/gsm2/. [Accessed: 24-Jan-2016].

[9] “TMP35/TMP36/TMP37,” - Analog Devices Inc. [Online]. Available at: http://www.digikey.com/catalog/en/partgroup/tmp35-tmp36-tmp37/10726. [Accessed: 24-Jan-2016].

[10] N. Foundation, "Docs | Node.js", Nodejs.org, 2016. [Online]. Available: https://nodejs.org/en/docs/. [Accessed: 26- Jan- 2016].

[11] Expressjs.com, "Express 4.x - API Reference", 2016. [Online]. Available: http://expressjs.com/en/4x/api.html. [Accessed: 26- Jan- 2016].

[12] Docs.sequelizejs.com, "Sequelize | The Node.js / io.js ORM for PostgreSQL, MySQL, SQLite and MSSQL", 2016. [Online]. Available: http://docs.sequelizejs.com/en/latest/. [Accessed: 26- Jan- 2016].

[13] Twilio.com, "Twilio Cloud Communications - APIs for Voice, VoIP, and Text Messaging", 2016. [Online]. Available: https://www.twilio.com/docs/api. [Accessed: 26- Jan- 2016].

[14] jquery.org, "jQuery API Documentation", Api.jquery.com, 2016. [Online]. Available: https://api.jquery.com/. [Accessed: 26- Jan- 2016].

[15] Postgresql.org, "PostgreSQL: Documentation", 2016. [Online]. Available: http://www.postgresql.org/docs/. [Accessed: 26- Jan- 2016].

[16] Campbell Scientific, Inc. (2014, May). OBS-3+ and OBS300 Suspended Solids and Turbidity Monitors. In Instruction Manual. (Rev. 5/14) Retrieved from http://s.campbellsci.com/documents/us/manuals/obs-3+.pdf

[17] Kemker, Christine. “Measuring Turbidity, TSS, and Water Clarity.” Fundamentals of Environmental Measurements. Fondriest Environmental, Inc. 5 Sep. 2014. Web. < http://www.fondriest.com/environmental-measurements/equipment/measuring-water-quality/turbidity-sensors-meters-and-methods/>

[18] Model Atmega328PPU; Atmel, San Jose, CA, USA

[19] Open Source Ocean Data Buoy Project (May 4, 2015) https://opensourceoceanweatherbuoy.wordpress.com/

8