Running head: TAILWATER SYSTEMS ORP MODULE 1

Tailwater Systems Sensor Station

Matthew Mason and Heather McCabe

California State University Monterey Bay

CST499 Group Capstone

Dr. John Skardon, Dr. Eric Tao, Brian Robertson

June 13, 2017

TAILWATER SYSTEMS ORP MODULE 2

Executive Summary

Tile drainage is a type of agricultural drainage system that removes excess water from

below the surface, which can make too-wet land suitable for farming. It allows large gains in

agricultural productivity in the United States. This drainage oftentimes contains high levels of

nitrate that can have a negative impact on local ecosystems and well as livestock and humans.

This nitrate buildup comes from various agricultural sources such as fertilizers, animal manure,

and livestock feed. When large amounts of nitrate are released into local water systems it can

contribute to hypoxic conditions in waterways, leading to dead zones for aquatic and marine life.

Excessive nitrate in drinking water can also put humans at risk by making the body less effective

at oxygen absorption; children are especially vulnerable (Nitrogen and Water, 2017).

Tailwater Systems is an environmental company that designs, builds, and operates

compact high-performance bioreactors for agriculture. Their bioreactors contain colonies of

bacteria that perform bioremediation and denitrification, reducing nitrate levels in agricultural

drainage before it is released into local waterways. The primary goal of this project is to design a

system that increases the effectiveness of Tailwater Systems bioreactors. The Tailwater Systems

Sensor Station project involves the integration of sensors into a Raspberry Pi platform using

Python as the programming language. These stations will facilitate remote monitoring and

calibration of bioreactors.
TAILWATER SYSTEMS ORP MODULE 3

Table of Contents

Introduction 4

Goals and Objectives 6

Community and Stakeholders 7

Project Need 9

Feasibility 9

Functional Requirements 11

Design Criteria 12

Final Deliverables 13

Methodology 13

Legal Considerations 15

Ethical Considerations 15

Timeline 17

Budget 17

Usability Testing 18

Final Implementation 19

Conclusion 22

References 25

Appendix 26
TAILWATER SYSTEMS ORP MODULE 4

Introduction

Tile drainage is a type of agricultural drainage system that removes excess water from

below the surface, which can make too-wet land suitable for farming. It allows large gains in

agricultural productivity in the United States. However, there are concerns about water quality

resulting from pollutants in these systems. These pollutants can come from fertilizers, animal

waste, and other agricultural practices. One specific water quality concern is the concentration of

nitrate, a form of nitrogen that moves readily through the soil and is often present in agricultural

drainage waters. The water quality of our local streams, rivers, and lakes can be negatively

impacted by high concentrations of nitrate resulting from tile drainage.

On a large scale, nitrate in Midwestern agricultural drainage has been identified as a

contributor to the hypoxic zone (or Dead Zone) in the Gulf of Mexico. The hypoxic zone is a

region where the oxygen level of the water is too low for living aquatic organisms. High nitrate

levels can also have a negative impact to livestock as well as humans. One such effect from high

levels of nitrate in drinking water for humans and animals alike is the reduced efficiency of the

bodys ability to absorb oxygen. Infants are particularly vulnerable; this is known as blue baby

syndrome (Nitrogen and Water, 2017). To avoid problems like these, it is important to monitor

and treat nitrate levels in tile drainage.

Bioreactors are a solution this problem. Current agricultural bioreactor systems work by

filtering runoff into a trench filled with woodchips or a similar material. These systems use

naturally occurring microbes to breakdown nitrogen compounds. While these types of systems

are relatively inexpensive and easy to maintain they are only about 30%-50% effective, so there

is a need to improve and maximize efficiency (Coss, 2016). The bacterial colonies require a
TAILWATER SYSTEMS ORP MODULE 5

steady source of carbon in addition to the nitrate. The level of carbon must be monitored and

maintained.

Our client, Tailwater Systems, is a small company based in Salinas, California that

designs, builds, and operates compact high performance bioreactors for agriculture. The client

and their customers do not currently have a method of remotely monitoring or maintaining these

systems. Additionally, data heuristics may allow the client to improve the systems over time and

see larger patterns in water quality over a region.

In order to help monitor the operation and effectiveness of their clients bioreactors, we

designed a remote monitoring system for Tailwater Systems. These systems can have one to

three ORP probes (short for Oxidation-Reduction Potential), which measure dissolved oxygen in

the water. The data is collected, analyzed, and monitored using a Raspberry Pi 3 Model B board.

The primary software for this system is written using the Python language. The system also

connects to a PHP web server with a cloud-based MySQL database via a wireless connection for

easier monitoring of the collected data. Data reports include a timestamp and readings are taken

and stored locally every 15 minutes. The local data is backed up to the cloud database once every

24 hours. The system is be able to retain data locally for at least one week and the system clock

has a battery backup with a real time clock module. Multiple stations can be setup at more than

one site so each station has a unique system identifier. Each station also provides a local offline

wireless access system to change the operating parameters of the systems. The systems are

mounted in weatherproof enclosures so they are able to withstand the elements when left to run

outdoors.
TAILWATER SYSTEMS ORP MODULE 6

Goals and Objectives

The primary goal of the project is to provide Tailwater Systems with a system that will

allow them to accurately monitor the effectiveness of their bioreactors remotely. In the long term

it is intended that multiple systems will be setup at various areas at individual sites and more

broadly across all Tailwater Systems sites. With this in mind the team has set up the goal to

develop the system with cost and reproducibility in mind. For this to be a success the systems

needs to avoid unnecessary costs relative to overly expensive hardware. Additionally, the system

needs to be able to be replicated will little to no guidance and without the need for special

tooling. In order to achieve these goals the following objectives are to be accomplished:

In order to keep costs minimal the system will be built around a Raspberry Pi and Python

as the programming language; a more industrial option may be considered long-term.

To accommodate expandability the system will support up three sensors.

To accommodate multiple stations each station a method will be designed to support

assigning a unique ID to each station.

In order to keep the system versatile in a given location the system will accept AC or DC

power input.

The test system is expected to stay out in the elements for extended periods of time and

must be designed to fit inside of a weatherproof NEMA enclosure.

The test system will be designed to maintain data locally for up to one week.

To support robustness and dependability the system clock will have a backup battery in

the case of a power outage.

All data will be time stamped.

TAILWATER SYSTEMS ORP MODULE 7

The test system will support a range of periodic measurement times from one minute to

one hour.

The system will have local access to data and a local interface to change operating

parameters.

The system will support connection to a wireless network and upload data to a cloud

database using this connection.

The system will also focus on providing accurate measurements and valuable data with

the use of heuristics.

In order to accomplish these goals and objectives Tailwater Systems will provide the

sensors in which the project will be designed around as well as heuristics that will need to be

applied from the data received by the sensors. Tailwater Systems will also be providing water

samples as well as methods to manipulate contaminant levels in order to monitor the output

changes from the sensors while the systems are in development. After the system has been

proven effective within the lab environment it will be taken to a local bioreactor site for a live

demo and verification.

Community and Stakeholders

There are several stakeholders when it comes to the project, some are more directly

connected than others. Stakeholders that are directly connected to this project are the team

members who stand to gain valuable real-world experience in designing a real-world application.

Tailwater Systems, the project sponsor, will gain the collection of valuable data and analysis of

their bioreactors which will allow them to improve their overall system. However, with

Tailwater Systems name attached to this project if the team fails to deliver on its promise to
TAILWATER SYSTEMS ORP MODULE 8

provide accurate data and a reliable system then potential damage to the companys future

business may be at risk. The farms in which these sensor systems are deployed stand to gain

directly from this project as they will no longer have to perform manual testing of bioreactors

deployed on their land. They will also gain up-to-date, continuous data. The potential fallout

from a faulty system could lead to regulatory issues with the state of California if data is reported

inaccurately.

Indirect stakeholders from the deployment of this system are the local communities

surrounding the water systems in which agricultural drainage is deposited. As mentioned above,

excess nitrate in water can have a negative effect on humans by limiting the efficiency in which

the body absorbs oxygen. By deploying these stations and making the bioreactors more efficient,

the risk is lessened for the communities connected to these waterways. Other indirect

stakeholders are the aquatic ecosystems located downstream from which agricultural drainage is

dumped. As indicated before, this drainage contains contaminants that can wreak havoc on these

aquatic ecosystems by causing an unnatural rate of growth of aquatic plants and eventually

reducing the waters oxygen supply, making the water inhabitable for animal life. These effects

have been seen in the San Joaquin Valley, most notably Kesterson Reservoir in which selenium

deposits reached toxic levels from agricultural drainage causing bird death of up to 88% of the

local population and deformities (Kesterson Reservoir, n.d). By deploying sensor stations like

the one this team is developing tragedies like that at Kesterson Reservoir can be prevented.
TAILWATER SYSTEMS ORP MODULE 9

Project Need

We have previously discussed the harm that can be caused from excess nitrate in local water

systems. The dangers are wide ranging and have the potential to affect not only local marine life

but also life on land. We have discussed the potential of dead zones as seen in the Gulf of

Mexico as well as high levels of nitrate in drinking water affecting children and babies, known as

blue baby syndrome. It is because of these dangers that bioreactors like the ones produced by

Tailwater Systems are needed. It is also why the need to further enhance and monitor these

systems with technology like the ORP Module is needed. With the OPR Module the bioreactors

can be monitored 24 hours a day 7 days week and send notifications of any readings not within

acceptable ranges. This allows for better efficiency and performance as well as constant

monitoring.

Feasibility

Systems like these have been created for other purposes. Dr. John Skardon, owner of

Tailwater Systems, has a U.S. patent for a similar system that detects allergens in the air. His

sensor system takes these readings and uploads them to an allergen advisory system, which in

return relays warnings and provides allergen response advice to the asthma patient. These

systems are intended to be either a wired or wireless connection depending on availability. The

overall system turns into a network covering geographical areas such as zip codes to provide

relevant information. The Tailwater Systems Sensor Station is also expected to turn into a

network of stations relaying data from various points of a bioreactor, and can provide similar

response data with further development and analysis of collected data. When viewing the
TAILWATER SYSTEMS ORP MODULE 10

functionality of the two systems it does prove to be very similar only varying in application from

monitoring air to monitoring water (US Patent No. US 6,288,646, 1999).

Regarding bioreactor monitoring, a team for the University of KwaZulu-Natal in South

Africa has developed a similar method for monitoring bioprocesses and control. These

monitoring and control systems rely on a pH probe and temperature sensors with additional

mechanisms to adjust levels of each. This system also uses mix of PHP and mySQL for data

collection and storage. From this basis the team then expanded to create a network of nodes to

monitor and enhance the production of biofuel. This team is working towards the creation of a

cloud monitoring community of these nodes. This setup is very similar to the intended design

and implementation of the Tailwater Systems Sensor Station. The implementation matches that

of our sensor stations in that the intent is to improve the efficiency of the tile drainage

bioreactors. A major difference is that this project is not intended to control any aspects of the

bioreactor and only performs measurements (Kana, n.d.).

Another project similar to this one was done by a team at the University of Southern

California (USC). This team designed a bioreactor control and monitoring station using a

Raspberry Pi and Python. The implanted the monitoring of sensors using an EZO board which

uses the I2C communication protocol and relays information over the Pi GPIOs. The Raspberry

Pi communicates with a web server by sending and receiving JSON packets through GET and

POST commands and the HTTP communication was done with Requests Python library. The

overall hardware and implantation is likely very close to what the team will be using during the

development process of the Tailwater Systems Sensor Station. The major difference in our

project is that the USC team did not design around setting up multiple stations to monitor a large

area; they simply focused on their individual small scale bioreactor (Bioreactor Overview, 2016).
TAILWATER SYSTEMS ORP MODULE 11

Functional Requirements

There are two major pieces of this project which can be broken down into smaller chunks

and used to outline our functional requirements for this project. The first major piece of the

Tailwater Systems ORP module is the module itself and the second is the cloud storage and

remote support. For the module there are several requirements, the first and foremost

requirement is the ability for the module to take readings from the water within the bioreactor.

This can be done by implementing the use of an ORP sensor. The readings from the sensor are

the primary data in which the OPR module is being designed to gather. With this sensor the

client has requested the ability to the change to the polling interval within a range of 0 to 60

minutes. Adding this ability will allow the user to control the flow of data so that more data

points can be taken if needed as well as fewer points if the bioreactor system proves to be stable.

The OPR Module must also have the ability to be controlled locally. It is not feasible for the user

to connect a keyboard and monitor to the OPR module every time a change of settings is needed.

Thus, the team will be developing a method in which the user will have local access to the

module to change control parameters. The ORP Module will be required to connect to the

internet using WiFi already set up at the bioreactor sites. Finally, the customer has required that

the ORP Module be small enough to fit inside of a weather proof housing already located on site.

The cloud storage and remote support is the second major block of the project. This

requires the ability to manage and store data for multiple ORP modules connected to the internet

at any one time. For this we will have to enable the ability for each module to have a unique

identifier. Then using the identifier store the data within a database. From here the data will need

to be monitored for any measurements outside of acceptable levels and then reported to the client

and owner of the bioreactor. An authentication process and webpage will need to be created to
TAILWATER SYSTEMS ORP MODULE 12

control access to the data stored as well as allow Tailwater systems and their clients to view and

monitor data. Along with viewing of the data users will also need to have the ability to change

parameters of the module remotely, given this requirement an additional web page will need to

be developed to support this feature.

Design Criteria

Manufacturability: Tailwater Systems plans to place multiple sensors at any given site

and will be supporting multiple sites, the team will be designing the ORP module for ease

of duplication. We will be selecting easily accessible and well supplied parts. We will

also be providing drawing and wire diagrams for assembly of the ORP Module.

Cost: Tailwater Systems will potentially be placing multiple sensors across their various

bioreactor sites so the cost build and support the OPR Module will need to be minimal.

The overall design of the system will keep necessity over desire in mind. We have a goal

of keeping the cost to build and support one ORP Module under $500. This cost could

vary depending on the accuracy of the ORP probe. If the probe selected for the project

does not suite the overall needs then it is possible that the cost could increase due to the

need of a higher end probe.

Reliability: The ORP Module will have to be able to maintain data locally for up to one

week in the case that internet connectivity is not available. With this the ORP Module

will also need to be able to maintain a constant uptime and this also has been set for one

week without interrupted service.

TAILWATER SYSTEMS ORP MODULE 13

User Interface: The user interface will need to be intuitive as instructions may or may

not be readily available to the user. Additionally the user interface will be very minimal

to prevent changing of undesired parameters.

Final Deliverables

OPR Module: This will includes the ORP Sensor, a completely assembled case,

Raspberry Pi, fully set up image, and local interface via remote access point.

Web Interface: This includes the access of all module data uploaded to the database and

remote access to change parameters on any given module

Web Server: This include supporting the Web Interface as well as the database

Client Approval: The project will be presented to the client for final approval before

project completion.

Methodology

The sensor we will be using for this project will be an oxidation-reduction potential

(ORP) device. ORP devices measure electrical charges from ions and convert the charges to

positively or negatively charged millivolts. Different millivolts indicate different states and

levels of compounds in the water. ORP readings from these filtration systems should show a

millivolt level of +/- 50 mV. Higher readings indicate that there is too much carbon in the water;

lower readings indicate that there is not enough. Depending on the results of the probe reading,

the carbon levels will need to be adjusted in the pump system.

TAILWATER SYSTEMS ORP MODULE 14

We will begin with a relatively low-priced ORP probe and figure out how to interface

with it using a Raspberry Pi 3 and Python. We are starting with lower-priced components to

allow for mistakes in our set-up and testing. In our initial testing, we will examine the effects of

electrical noise on our readings. We will evaluate the need for noise filtering and/or signal

amplification in order to get clear readings from these systems that are operating alongside

pumps and wireless signals.

Once we are able to get reliable readings from our probe, we will evaluate methods to

store data on a cloud server. We will create some sort of an interface where the client and his

customers can review data from the sensors that is presented in an understandable and

informative format. This data may be accessed through a mobile device as well.

We also will need to look at ways of adjusting the operating parameters of this system

remotely. This could be through a physical keypad on the device or through a remote connection

that interfaces with a mobile or browser application. Access to the data and configuration of the

systems must be secure so as we develop the remote access interfaces we will build them with

security in mind from the ground up.

If all of that is completed with time to spare, we will look at more industrial systems than

the Raspberry Pi, more robust OPT sensors, a more polished user interface, and then potentially a

closed-loop feedback system for automatic carbon level regulation.

TAILWATER SYSTEMS ORP MODULE 15

Legal Considerations

There is a possibility that our client will use the product that we create for commercial

purposes. If we use any third-party code libraries for our sensors, we will need to carefully read

and consider associated licenses. For the purposes of the school-based project itself we will be

covered under Fair Use. However, if this product is sold or commercially used by a business

copyright and licensing considerations would apply. We also may need to work with our client to

develop a disclosure regarding the nature of the data that we are collecting and the way that we

are storing it.

Ethical Considerations

The primary ethical concern for this project is secure data processing and management.

We should be able to identify which bioreactor the data is from while protecting the personal

information of the customer. We can do this by anonymizing data, perhaps by assigning each

sensor station an ID that is associated with customers only after data transmission. We will also

look into methods of encrypting our wireless transmissions and establishing some method of

authentication. The connections between the sensor stations and the cloud will need to be secure

from third parties. We will keep these needs in mind as we investigate possible technologies and

services to use in our project. The sensor stations should enhance the customer experience, not

compromise their security.

Secondary ethical concerns are providing accurate and reliable data processing. A failure in

system performance and data reporting could lead to mismanaged systems, which in turn could

lead to environmental contamination from incorrectly treated water. The customers and our

partner need to know that the sensor stations are reporting correct data at all times, rain or shine.
TAILWATER SYSTEMS ORP MODULE 16

A failure on our part could lead to an expensive system malfunction at the least, and a

devastating localized environmental problem at worst. Our sensor stations need to do what they

are supposed to do at all times. We will add checks and repetition into our code as necessary to

insure that the stations have as close to 100% uptime as possible.

Knowing that the time frame is limited in which the team has to complete the project it may

be necessary to prevent deployment of the system if the risk is too great. The only way around

this is to perform as much testing as possible and get some real world evaluation prior to full

deployment. The team will attempt to run the system with a long uptime to confirm not fatal

errors as well as perform calculations and compare results.

Another issue in the design process will come to ease of design versus the ease of

replication. Because design time is limited, the capstone team will only be able to produce and

test one system. This means that any other additional systems will have to be built by the

customer. Knowing this we will have to design the product around this fact and provide

appropriate documentation to do so. However, the time to work on the Capstone project and

submit a working solution will mean that the team will need favor ease of design in some cases.

The team will have to balance what is best for completing the project for the grade and the ability

for the customer to build additional systems without support from the team upon completion of

the capstone. To work around this issue the team will need to keep in contact with the customer

and discuss these conflicts as they arise. If the customer knows of the situation and agrees to a

decision the ethical dilemma should be minimal.

Finally, ethical issues could occur if support is needed after Capstone completion. If a major

bug is found after deployment and the Capstone time period, ethically the team should provide

support, however, it is believed by the author that this is a potential risk when asking for outside
TAILWATER SYSTEMS ORP MODULE 17

help in design. The proper resolution for this would to simply remain in contact with the

customer and provide support if necessary, after all it is the right thing to do.

Timeline

For the first half of the project, we were in line with our proposed timeline. However,

around the midway point we ran into difficulties with getting our networking configured. Our

local offline network access required more research than we thought it would and AWS itself

was far more complicated and time-consuming than we anticipated. In general we did not

anticipate the complexity of the overall network structure that we ended up creating to support

secure communication with our database and sensor modules. This set us at least two to three

weeks behind. As of the last week of the course, we were unable to complete the feature that

would notify the customers if their sensor readings were outside of a specified range. Our failure

recovery is not as robust as we planned. We were also unable to perform field testing. We plan to

work with our client to finish these features and perform full field testing of the modules,

including simulated failures.

Budget

We set a goal that each module would cost less than $500. Our final cost breakdown is as

follows:

Raspberry Pi 3 Kit (includes SD card and power supply) $60.00

Real-Time Clock $16.99

ORP Probe $174.81

GPIO Header $6.30

TAILWATER SYSTEMS ORP MODULE 18

Case $19.84

Conformal Coating ~$2/unit $2.00

Total $279.94

Usability Testing

We have not yet had the opportunity to travel to Monterey County for full field usability

testing. In our home testing, we have verified that we can set up a new module and create an

associated customer account in the database. We have had a module running continuously for a

full week and verified that it records data locally every 15 minutes and uploads it to the cloud

database every 24 hours as scheduled.

In our upcoming field testing we will have several other points of verification:

Wireless Connectivity We will verify that the device operates reliably with unreliable

wireless coverage. The wireless coverage and signal strength will have to be handled on a

per-module basis as these modules may each be installed in very different environments.

However, we have designed our wireless set up to be as robust as possible. The Amazon

Web Services IoT Thing Shadows that we set up are designed to restore device states

to devices with unreliable connectivity.

Failure Recovery We will simulate a loss of connection during the scheduled upload

period and verify that there is a subsequent recovery. The device should continue to try to

connect every polling period until it has successfully uploaded.

We will also check for a loss of power. The device should retain its local data, resume on

schedule, and maintain its clock settings with its battery-backed RTC.
TAILWATER SYSTEMS ORP MODULE 19

Local Access We will verify that our client is able to access the modules locally and

change operating parameters.

Weatherproofing We will verify that our system box is water-proof and field

mountable.

Documentation We will go through all generated documentation with our client and

verify that he is able to reproduce these modules solely with the information contained in

the documentation.

Final Implementation

We used Amazon Web Services (AWS) to implement our cloud database. First, we

created a Virtual Private Cloud (VPC) with a public subnet and a private subnet. Within this

VPC, we installed an AWS Elastic Compute Cloud (EC2) Apache web server running PHP. We

also installed a MySQL AWS Relational Database (RDS) in the VPC. The RDS runs only on the

private subnet and the EC2 server runs on both the private subnet and the public subnet. This set-

up makes it so that we can better control access to the RDS, as all access must be funneled

through the EC2 server. We can connect to the EC2 server for development by using SSH and

SCP. See Figure 1.

On the EC2 server we created several pages using PHP that facilitate user authentication

and RDS data retrieval. User passwords are encrypted using the SHA512 algorithm with salting

built in using the PHP function password_hash(). The hashed password is stored in a RDS table

along with the customers email address. When the customer logs in, they enter their email

address and their password. We pull the hashed password from the RDS and compare the hash

string to the users input password using the PHP function password_verify(). If the hashed
TAILWATER SYSTEMS ORP MODULE 20

password and the users input password match we set a session ID with the users customer ID

and allow them access to the other pages. See Figure 2.

Most of the web interface is very basic and utilitarian. We aimed to implement the

functionality, not the design. The client can use the PHP scripts within his existing website with

his existing stylesheet. We have a page that allows access to the database. Data can only be

retrieved for sensors associated with the users customer ID. The data can be filtered by

minimum and maximum value, sensor ID, and date. We also allow the user to configure the

polling interval of the sensor through the web server.

The Raspberry Pi systems Raspbian operating system is configured to automatically use

the RTC to set the time when the system powers on. The Raspberry Pi systems run Python

scripts to get readings from the probe, store them locally, and upload them to the database. The

ORP probe and the RTC are wired to the I2C bus of the Pi. The orp_manager Python script takes

a reading from the probe, records it in the local database, checks if the data should be sent to the

cloud, and then sleeps for the duration of the polling interval. Then it starts again with a probe

reading. The data is stored locally in a simple CSV file.

The Raspberry Pi communicates with the RDS using the AWS IoT service. The IoT

service uses a pub/sub model for communication over MQTT. When it is time for data to be

uploaded, the orp_manager script publishes a topic titled DataUpload. The payload is a JSON

containing the sensor id, timestamp, and reading for each line of the CSV. The IoT service is

subscribed to the DataUpload topic. When it sees this topic, it launches an AWS Lambda that

runs on the private subnet within the VPC. The Lambda function parses the JSON and inserts the

entries into a data table in the RDS.

TAILWATER SYSTEMS ORP MODULE 21

AWS IoT also allows the utilization of Thing Shadows which are virtual representations

of the physical device. These shadows store parameters specific to each individual unit deployed

in JSON format and is accessed using the same pub/sub methods in which data is sent. We

utilized Thing Shadows in the design for their ability to maintain status even when the device is

not connected. The implementation of Thing Shadows involves the triggering of an update upon

connecting to the internet for the ORP Module, this causes the Thing Shadow to respond with a

delta between the reported and desired parameter setting. If a delta exists then the ORP module is

set to the desired parameter and reports the update back to the shadow to remove the delta. Thing

shadows are also implemented so that the user can interact with them as well. We have provided

access to these from both the web and local interface. In these interfaces the user is able to enter

the desired update and again events are triggered for providing deltas and responding with

updated settings.

A local interface was also created for the ORP Module using Python and a corresponding

micro framework call Flask. Flask supports small scale web applications and process requests to

the device using the Python language rather than setting up a server. The user can connect to this

local interface through a virtual access point which utilized the onboard wireless chip on the

Raspberry Pi. The user connects to the access point like any other wireless router and directs

their bowers to the default IP address. From here the user will be direct the web page in which

they can interact with the device. Setting such as updating ORP polling interval, wireless SSID

and password for internet connection, and getting a reading on the spot from the ORP sensor are

all accessible on the home page. A link is located on the home page to an advanced settings page.

This page allows access to parameters such as setting the device id and uploading security

certificates for the initial setup of the ORP module.

TAILWATER SYSTEMS ORP MODULE 22

We have also implemented a WiFi manager script on the Module that manages the

connection to the wireless router set from the local interface. This script interacts directly with

the parameters passed and attempts to connect to the internet. Upon connection loss the WiFi

script will attempt to reconnect. If settings wireless settings are changed this again triggers a the

manager in to action and it begins using the new settings.

This project did require some hardware design and forethought as well. Since the ORP

Module is expected to located around and operate in wet conditions the team had to keep this in

mind. To help combat against splash a Raspberry Pi case purchased which include covers for

unused ports. As a further precaution against moisture conformal silicon coating was also

acquired and is used to cover the bare pcb and electronic components. Some minimal wire is also

required within the case in order accommodate the connection between multiple probes and the

real-time clock. To support this we installed a terminal block which mounts to the case lid after

making some minor modifications. Finally a one half in hole is drilled into the case for the BNC

bulkhead mount connect that joins the ORP sensor the microcontroller.

Conclusion

As discussed previously, agricultural drainage can cause harm to the delicate ecosystems

in and surrounding our local water ways. This damage is a result of nitrates and other chemicals

used in fertilizers and pesticides. Tailwater Systems helps to combat high levels of nitrate

through there bioreactors and has requested a solution that will enable them to monitor their

systems remotely. The solution for this is an Internet of Things powered device, focusing on a

low cost solution a Raspberry Pi 3 B and a low cost ORP probe are what the device is designed

around. This device can be uniquely identified by the assigning of an identification number and
TAILWATER SYSTEMS ORP MODULE 23

supports multiple probes, if desired. Additionally, this solution will upload data automatically

through a WiFi connection that can be setup through a local network interface. The ORP Module

will also support the loss of internet connection and store data until a connection can be restored

and the data uploaded to the remote database.

This project is expected to impact local communities and ecosystems surrounding

waterways by making Tailwater Systems bioreactors more efficient over, time therefore reducing

the effects nitrites from agricultural drainage. There is also the added benefit to the customers of

Tailwater Systems since this data can be used meet regulatory testing requirements.

Because there will be large amounts of data stored remotely, there are concerns of

security and protection of the data as this is proprietary information for Tailwater Systems and

their performance. For this we are restricting access to Tailwater Systems and allowing them to

administer permissions to who want to view this data. Other ethical concerns included supporting

the project after completion, which we have agreed to do as there will likely be bugs upon full

deployment. There also concerns with ease of design over ease of assembly which were resolved

through the bring-up of the project. This was done through limited assembly, limiting direct

interface with the device itself, and the creation of an image which can be copied and distributed

as needed.

The overall implementation of the ORP Module relied heavily on the use of Amazon

Web Services (AWS). Services used in AWS include EC2 cloud computing for our web server,

AWS RDS host the MySQL database, IoT which enables the backend support for the ORP

modules, and Lambda which enable the linking of various AWS services. To interact with and

operate the ORP module we provide a web and local network interface. From the web the user
TAILWATER SYSTEMS ORP MODULE 24

can view data and is able to interact with the device at a limited capacity. The local network

interface allows more interaction and setup options.

Various issues and problems occurred throughout the design process, but none stand out

more than the numerous struggles the team experienced when learning and attempting to work

with AWS. AWS is an extremely powerful and customizable system which created a large

learning curve for the team. This fact couple with the lack of documentation supporting our

particular application forced the team to rely on trial an error for much of the design process

when engaging with AWS. However, through these struggles the team learned to rely on one

another and learned for each other experiences. We gained valuable experience in working with

AWS and what it takes to design, bring-up, and finally deploy a large scale project such as this.

The team does plan to continue to work on this project to include additional features that

were not enabled during the capstone. The first of the features is SMS messaging which sends

out alerts to Tailwater Systems and their customers if any ORP Module is returning data outside

of a given limit. Additionally, we would also like to implement charts and graph representations

of the data stored on the database for easer consumption and analysis.
TAILWATER SYSTEMS ORP MODULE 25

References
Bioreactor Overview. (2016). Retrieved from http://2016.igem.org/Team:UCSC/Hardware

Coss, K. (2016, Mar 9). Boosting Bioreactor Technology to Limit Farm Runoff. Retrieved

from https://inquiry.research.umn.edu/2016/03/09/boosting-bioreactor-technology-to-

limit-farm-runoff/

Kana, E. G. Sensing, Monitoring and Control of Microbial Processes in Homemade Bioreactors

Prospect of Enhancing Biofuel Production using Wireless Monitoring. Retrieved from

http://wireless.ictp.it/wp-content/uploads/2012/02/KANA.pdf

Kesterson Reservoir. (n.d.). Retrieved from http://www.watereducation.org/aquapedia/kesterson-

Reservoir

Pendo TECH Bioreactor Control System. (2008). Retrieved from

http://www.pendotech.com/bioreactor_control%20System_Spec_SheetA.pdf

Skardon, J. N. (1999, Aug 31). Patent Identifier No. US 6,288,646. Washington, DC: U.S. Patent

and Trademark Office. United States Geological Survey. (2017, Jan 17). Nitrogen and

Water. Retrieved from https://water.usgs.gov/edu/nitrogen.html

TAILWATER SYSTEMS ORP MODULE 26

Appendix

Figure 1. Deployment Diagram.

Figure 2. Database Schema.