STREAM DEPTH GAUGE:
FINAL REPORT
4/23/2012
Stream Depth Gage
Team Members
John Henderson
Curt LaBarge
Greg Pearson
Yixin Qiao
Client/Advisor
Steve Holland
(ISU Canoe and Kayak Club Adviser)
Table of Contents
Introductory Material ............................................................................................................................................... 4
Executive Summary............................................................................................................................................... 4
Acknowledgment................................................................................................................................................... 5
General Problem Statement ............................................................................................................................... 5
General Solution approach ................................................................................................................................ 5
System Summary ................................................................................................................................................... 5
Operating Environment........................................................................................................................................ 5
Intended Users ....................................................................................................................................................... 5
Assumptions and Limitations ................................................................................................................................ 6
Assumptions List................................................................................................................................................. 6
Limitations List ................................................................................................................................................... 6
Expected End Product and Other Deliverables .............................................................................................. 6
Approach and Design .............................................................................................................................................. 6
Market Survey ....................................................................................................................................................... 6
Design Objectives ................................................................................................................................................. 7
Functional Requirements ...................................................................................................................................... 7
Non Functional Specifications: ............................................................................................................................ 7
Work Distribution:................................................................................................................................................. 7
Project Schedule:................................................................................................................................................... 8
Personal Effort Requirements ............................................................................................................................. 9
Risks and Mitigations:.........................................................................................................................................10
Resources and Costs: ..........................................................................................................................................11
Cost of prototype and testing: ....................................................................................................................11
Cost of final product:.....................................................................................................................................11
Design Constraints: .............................................................................................................................................12
System Analysis: ..................................................................................................................................................12
Water level sensing: ......................................................................................................................................12
Wireless Modem: ...........................................................................................................................................12
Microcontroller: ...............................................................................................................................................12
Temperature Sensing: ....................................................................................................................................12
Power ...............................................................................................................................................................13
System Description ..................................................................................................................................................13
Hardware Description:.......................................................................................................................................14
2
RWLS Final Report
Software Description:.........................................................................................................................................16
Standards .................................................................................................................................................................16
JTAG Standard ...................................................................................................................................................17
UART Standard ...................................................................................................................................................17
C Standard ..........................................................................................................................................................18
GSM Standard ....................................................................................................................................................18
FCC Certification.................................................................................................................................................19
System Testing and Implementation ....................................................................................................................19
Hardware Test ....................................................................................................................................................19
Test the battery self-discharges ..................................................................................................................19
Test the power supply of Solar Panel ........................................................................................................19
Test if all the components can survive under -20C/-4F ..........................................................................20
Test if the pipes can survive through winter under water ......................................................................20
Pressure sensor and differential amplifier ................................................................................................20
Software Test ......................................................................................................................................................20
Test if the cell module can work properly .................................................................................................21
Test if the microcontroller can read values from pressure sensor correctly ........................................21
Test microcontroller wake up from sleep every 24 hours ......................................................................21
Test information transporting between microcontroller and cell module ............................................21
Full System Test ...................................................................................................................................................21
Test condition 1: temperature below 32F .................................................................................................21
Test condition 2: temperature above 32F .................................................................................................22
Implementation ....................................................................................................................................................22
Hardware: .......................................................................................................................................................22
Software: .........................................................................................................................................................22
Preliminary Testing Results: ...............................................................................................................................23
Temperature Sensor Testing: ........................................................................................................................23
Pressure Sensor Testing: ................................................................................................................................23
Cell Modem Testing: ......................................................................................................................................24
Prototype Testing................................................................................................................................................25
Operational Manual: ..............................................................................................................................................25
Parts Included: .....................................................................................................................................................25
Installation: ...........................................................................................................................................................25
Underwater Housing: .....................................................................................................................................25
3
RWLS Final Report
Installation Continued: ........................................................................................................................................26
Monitoring System:.........................................................................................................................................26
Initial startup processes: ................................................................................................................................26
Closure Material ......................................................................................................................................................27
Conclusions and Lessons Learned: ....................................................................................................................27
Future Work: ........................................................................................................................................................27
Client Information ...............................................................................................................................................27
Student Team Information .................................................................................................................................28
Introductory Material
Executive Summary
The Remote Water Level Sensor (RWLS) will be created for easy monitoring and trending of water
levels around the state of Iowa. Some rivers are currently monitored by the United States Geological
Survey (USGS) but these gauges only monitor a limited number of streams due to their high
maintenance costs. The lack of river gauges in the state of Iowa presents a challenge to paddlers who
need flow data to plan trips.
The Remote Water Level Sensor will overcome the challenges presented by the current gauging
system used by the USGS by providing a system that is affordable, accurate, and capable of being
deployed practically anywhere in the state. The final product will provide river flow data to anyone
who has access to a cell phone, allowing paddlers to accurately plan trips and allow local towns to
prepare for possible floods. Furthermore, the RWLS will have a low maintenance cost and will not
need servicing for a minimum of one year.
The prototype will consist of three main components. The first component is the water level sensor and
is intended to be placed directly under a water source where flow data is to be collected. The second
item is the wireless transmitter and microcontroller set intended to be installed along the bank of a
river or stream near the location of the water sensor. Finally, a power management system consisting
of a battery and solar cell will be used to extend battery life to of the system to one year.
It is expected that the type of sensor used to measure flow will be a differential pressure sensor;
however, an ultrasonic sensor could be used and will be considered as backup. The primary difficulty
of this project will be designing a device that will measure water pressure with an air pressure sensor.
Ultimately, a prototype consisting of a water level sensor, wireless transmitter, microcontroller, and
power management system will be delivered. These deliverables will be used to gauge the success of
the product.
4
RWLS Final Report
Acknowledgment
We would like to acknowledge Steve Holland, our advisor and client, for technical advice and
oversight. We would also like to acknowledge Lee Harker for his help purchasing our parts and
passing helping us when we needed technical advice.
General Problem Statement
Flow levels in Iowa’s streams and rivers can vary dramatically from day to day. Paddlers need to
know this information in order to adequately plan trips. Currently, these levels are measured by the
United States Geological Survey but the gauges they use can only cover a limited number of rivers
and are under constant threat of cancelation due to their high costs. Further, damage caused by the
Cedar Rapids flood of 2008 was exacerbated by a lack of warning due to inadequate gauging.
Because of these factors, the Iowa State University Canoe and Kayak Club have asked team
SDMAY1223 to design and build a low cost stream flow gage.
General Solution approach
Our solution to this problem is to build a system that will be able to take water depth measurements
of a river or stream and wirelessly send them to the user via text message. The system is intended to
sit next to a river during all four season of the year and will be designed to withstand all of Iowa’s
extreme weather conditions. Further, the system will manage its power such that it will not need any
maintenance or a new battery for at least one year.
System Summary
Our system will turn on once per day in order to send the river water height to its user. In order to do
this, the micro controller will awaken from sleep mode and check the water pressure. It will then
convert that pressure reading into a water column level and format it into a message to be sent out.
Then it will turn on the Cell module and wait for cell signal. Once the cell module has signal, the system
will send the formatted message to its user. If everything functions properly, the microcontroller will
systematically shut everything down and then fall once again into sleep mode.
Our System will not send data if the temperature is below 0˚ Celsius, as water will have either frozen
or began to freeze, and data is not useful to our intended users.
Operating Environment
The intended operating environment of our system will be completely outdoors. This includes any
environment which can be found near any streams or rivers located in Iowa. The system will be
waterproof and designed to withstand a very wide range of weather conditions including high winds,
rain, sleet, snow, extreme temperatures, etc. The goal is for us to be able to mount it to a tree in order
to keep it off the ground and make it less vulnerable to flooding. We have rated the system for the
following temperatures and humidity from -40˚ to 50˚ Celsius with 90% humidity.
Intended Users
Some of the intended users of the system are the staff of environmental agencies around Iowa.
However, the data it collects and transmits can be accessed by anyone via text message. Therefore,
other users could be considered anyone who would like access to the data through their cell phone. It
is mainly expected that canoers and kayakers will be the main users of the system for the purpose of
5
RWLS Final Report
planning trips. The system could also be used by the environmental agencies as a way to monitor and
trend yearly water levels.
Assumptions and Limitations
Assumptions List
1. The device will not be tampered with after it has been installed except by the owner
2. The device will be installed in an area that has good cell coverage
3. The device will be installed such that the solar panel is place in an area with a fair
amount of sunlight rather than an area that is mostly shaded
Limitations List
1. The system will not perform during or after a natural disaster
2. The system will not operate properly if the solar panel is placed in a shaded area
3. The system will not be able to transmit data properly if it is placed in an area with
poor cell coverage
4. The accuracy of our water measurement is accurate to within 1 inch
5. The team has a limited budget of $500
6. The team has limited time for implementation due to other course studies
Expected End Product and Other Deliverables
The deliverables for this project is a system that is capable of transmitting river water height to an
online data base through a wireless signal. The system will be capable of withstanding all of Iowa’s
extreme weather conditions, allowing it to be placed outside all year. Further, the system will be able
to maintain its power such that it can run for an entire year without needing a new battery.
Approach and Design
Market Survey
Similar products to the RWLS are produced by the USGS and used
in large rivers throughout the United States. These products are
created by digging a stilling basin next to the river and then joining
the basin and river with intake tubes. Above the well, a shack is built
to shelter the float inside of the basin, thereby measuring the river
water column. Figure 1 shows a schematic of a typical USGS water
gauge that is installed in many Rivers throughout the United States.
The main difference between the USGS’ sensor and the sensor we
are building is price. Our client, the ISU Canoe and Kayak Club,
wanted a product that could be built at a significantly lower price
and yet maintain the same level of accuracy as the USGS’ product.
To do this, we had to look at the design for our product in a
completely different manor than the USGS.
6
RWLS Final Report
Figure 1: Typical Gauge produced by USGS
http://ga.water.usgs.gov/edu/streamflow1.html
After talking to our client, The ISU Canoe and Kayak Club, our team has learned much about how our
system should operate. Because our client will have no need of the water level during the cold winter
months, we will only be measuring the water height when the temperature is above 0˚ Celsius. We will
also be sending out the measurements we record to our users, every day at noon, so that they can use
the information on a daily basis.
While doing research for the project, we also found that although the ISU Canoe and Kayak Club are
our clients, several other organizations are interested in our product. This means that other than
notifying small craft enthusiasts about potential “canoeable” rivers in Iowa, our product could also be
used for research into wildlife movements and flooding notifications. Through talking to our client, we
were able to narrow our research into the different components we would want to use in our device.
Design Objectives
1. Design the pressure sensor with an accuracy of no less than 1 inch
2. Design the power circuit such that it can power the entire system for a minimum of one year
3. Program the microcontroller such that depth measurements can be recorded and transmitted
wirelessly through a cell modem
4. Design a case for the system that can withstand all of Iowa’s extreme weather conditions
5. Include a solar cell in the design that is weather proof and can provide a minimum of 5 Watts
Functional Requirements
1. Total price of materials is less than $500
2. Measure water level accurately to within 1 inch
3. System will transmit data at least once per day within readable season
a. Data will not be collected during winter months to conserve power
4. System will consume very low amount of power
a. System will not need a new battery or manual recharging for at least one year
5. System will be able to withstand all of Iowa’s extreme weather conditions including:
a. Extreme weather conditions include Rain, sleet, snow, hail and high winds.
b. System will continue to operate within functional requirements throughout these
conditions.
Non Functional Specifications:
1.
2.
3.
4.
5.
Withstand Iowa seasons which include ice formations, river debris, -40 degree C temperatures
Our system will have very low maintenance levels
Our system can survive recreational users
Working Temps for all components up to -5 C (23 F)
Survival Temps for all components up to -40 C (-40 F)
Work Distribution:
Based on the various core classes and focus areas of our majors we have a member that has
knowledge of each major component of the system.
John Henderson is assigned to:
1. Maintaining the Team’s website
7
RWLS Final Report
2.
3.
4.
5.
Researching and designing the system’s power circuitry
Calculating the system’s power budget
Supporting other tasks as they become a priority
Designing the system’s Printed Circuit Board
Greg Pearson is assigned to:
1.
2.
3.
4.
Working on software code used for system
Designing underwater chamber used to detect pressure.
Putting together weekly reports to be submitted.
Helping out in other areas as they become a priority
Curtis LaBarge is assigned to:
1.
2.
3.
4.
5.
Team leader
Assigning team tasks
Researching and designing system
Design and implement hardware integration
Support other team members with tasks
Yixin Qiao is assigned to:
1. Designing state machine code for the project
2. Testing software components to make sure they work
3. Helping others when they are in need.
Project Schedule:
8
RWLS Final Report
Personal Effort Requirements
The requirements needed for this project are broken down into two main sections. These sections are in
documentation and design and implementation. Each of these sections can be divided into subtasks
that must be accomplished in order to complete the project. The tables below represent how our tasks
will be split between members and includes an estimated cost of labor.
Documentation Labor
Team Member
Project Plan Design
Document
Presentations
Final documentation Total
John Henderson
15
15
10
10
50
Curt LaBarge
15
10
5
20
50
Greg Pearson
20
20
5
10
55
Yixin Qiao
10
10
5
10
35
Total
60
55
25
50
190
Design and Implementation Labor
Team
Member
Research
Parts
Selection
Power
Circuit
PCB
Programming
Testing
Total
John
Henderson
20
25
20
70
0
20
85
Curt LaBarge
30
30
20
0
0
20
100
Greg Pearson 20
20
0
0
15
30
85
Yixin Qiao
25
0
0
20
25
95
25
9
RWLS Final Report
Total
95
100
40
70
35
95
435
Risks and Mitigations:
The team’s largest risk is that our pressure sensor will not be able to measure the water level
accurately enough. This could be due to tubing getting damaged when frozen over winter or pressure
leaking from the pressure chamber, or another problem could come from the resolution of our
microcontroller’s ADC not being large enough. To mitigate this risk we have chosen a backup way of
measuring the water level. This way if the pressure sensor doesn’t work, we will not have to start from
scratch.
Another Risk is that our components will not work to their specified ability as stated in their data sheet.
To account for this we have put in wiggle room for things such as power consumption and cold
weather. This way, even if things don’t work as well as their datasheets specifies our project should
still work as intended.
Our next risk deals with power. Having a battery out in the wilderness during winter will hinder the
batteries ability to maintain charge. This means that our system will struggle to maintain power
throughout winter. To mitigate this risk we have found batteries with high tolerant to cold weather and
have a high amount of amp hours that will allow us to maintain power throughout the winter.
The final big limitation is time. To be able to test how our system works in the real environment we will
have to wait till the spring thaw to deploy it. This means that if things do not work out, we will have a
limited amount of time to fix the problem and resume testing. To deal with this we are trying to test
our product in the most realistic ways we can short of setting it up outside. We are also striving to
have a finished prototype by spring thaw, giving us as much time to fix any errors that may occur.
10
RWLS Final Report
Resources and Costs:
Since different water sensors are already in use in many bigger rivers whose cost is in the thousands
of dollars, one of our top goals in this project is to replicate said technology in a cheap, yet equally
efficient way. This is why our budget for this project is at 500 dollars, and here is the breakdown of
the different hardware and raw material and their associated costs for the project:
Cost of prototype and testing:
Table 1: Hardware in US Dollars
Component
Price in Dollars
Pressure sensor
5
Temperature sensor
5
Cell modem and
200
accessories
Prepaid sim card
10
Microcontroller and
10
evaluation board
PCB and
10
components
Solar cells
45
Battery
0
Charging circuit
25
Total
310
Table 2: Raw Material in US dollars
Material
Price in Dollar
Pelican Case
0
Metal Compartment
150
Pipe/tube
50
Total
200
Pressure sensor
Temperature sensor
Cell modem and
antenna
Prepaid sim card
Microcontroller
PCB and
Components
Solar cells
Battery
Charging circuit
Total
5
5
90
10
10
10
45
20
25
220
Table 4: Raw Material in US dollars
Material
Price in Dollar
Pelican Case
75
Metal Compartment
150
Pipe/tube
50
Total
275
Grand Total - $495
Grand Total - $510
Cost of final product:
Table 3: Hardware in US dollars
Component
Price in Dollars
11
RWLS Final Report
Design Constraints:
1. Power consumption
a. The system is limited to components which have very low current draw while
inoperative.
2. Experience
a. The team has limited design and implementation experience
b. Parts have to be hand solderable
3. Time
a. Deliverables due in May 2012
b. Team has other time-consuming obligations
4. Cost
a. Budget is $500
The above design constraints lead to special hardware having to be used that would minimize the
power budget, these parts could not have any lead time, and needed to come in packages that could
be hand soldered. Our budget put constraints on the parts we could use as well; we needed to know
exactly how much power would be required from our solar panel and batteries. This allowed us to
size our parts exactly and eliminates higher cost parts.
System Analysis:
Water level sensing:
The component that we researched the most was a device that would be able to detect the height of
water level in an economical and accurate fashion. We determined that ultrasound and pressure
differentiation were our best options. After further review, it was determined that using a differential
pressure sensor would be the best option and are basing our prototype off of our findings. However,
our team has found an ultrasonic range sensor that could be purchased in the event the team finds an
unanticipated issue with the pressure sensor.
Wireless Modem:
The next component that we researched was the wireless modem. We ran into issues with having
wireless modems that were compatible on carrier’s networks because carriers have strict restriction of
what they allow on their networks. We decided that using a prepaid SIM card was the best way to
get cellular service to our system. We chose AT&T’s network because we were able to find a wireless
modem that has been evaluated on their network and they provided many prepaid SIM card
packages.
Microcontroller:
When researching a microcontroller we knew that we would have to have an ADC for our analog
sensors to connect to along with a UART interface for our wireless modem to connect to. Other than
the interfaces for our sensors and modules we did not have many requirements for the microcontroller
so we decided to use a general 8-bit microcontroller.
Temperature Sensing:
To find out whether or not the environment is suitable to take a water level height, we use our
temperature sensor to find out if is above freezing. This part was simple to find as there are many
different temperature sensing devices on the market.
12
RWLS Final Report
Power
Power management is a high priority and ultimately decides whether or not our project is successful. In
order for the system to provide enough power for an entire year without a recharge, the system
needs to consume as little power as possible. Our team has decided to use a solar cell to keep the
batteries charged. Since the system will be deployed outside during all weather conditions, our team
also has to choose a battery type that can perform in extreme temperatures. Finally, our system will
use voltage regulators to provide a constant voltage to the other components in the system.
Battery:
We chose a 12V Lead Acid battery as our power source because of its compatibility with solar cells.
Lead acid batteries are easier to charge and will not be greatly affected by the differences in
charging voltages caused by the solar cell. We did consider lithium ion batteries however, these
batteries are extremely sensitive to charging conditions and could explode due to the differences in
charging conditions caused by the solar cell.
Solar Panel:
The power budget for this system is based upon the power rating of the solar panel used in our
system. The team has planned for a 5W solar cell to be used in the system. Therefore, the components
must consume as little current as possible, especially when they are in a shutdown state.
Voltage Regulator:
We will be regulating our voltage from the battery to each of the loads (microcontroller, wireless
modem and sensor) to keep the input voltages within their operating ranges. We have separate
voltage regulators for each of the major components mentioned above.
Level Shifters:
These devices help to change the voltage levels between the cell modem and the microcontroller logic
high and low.
Charging Circuit
The charging circuit is required to safely charge our two 6 Volt batteries without damaging any of our
system hardware.
System Description
Our system will turn on once per day in order to send the river water height to its user. In order to do
this, the micro controller will awaken from sleep mode and check the water pressure. It will then
convert that pressure reading into a water column level and format it into a message to be sent out.
Then it will turn on the cell module and wait for cell signal. Once the cell module has signal, the system
will send the formatted message to its user via text message. If everything functions properly, the
microcontroller will systematically shut everything down and then fall once again into sleep mode.
Our System will not send data if the temperature is below 0˚ Celsius, as water will have either frozen
or began to freeze, and data is not useful. Below is the schematic showing how components are
interconnected:
13
RWLS Final Report
Figure2: Block diagram of system
Hardware Description:
All hardware was integrated together according to the schematic shown below. The file can also be
downloaded from the out team’s website under “PCB Files” in the documents section. In order to open
the file, you must first have Eagle software installed on your computer.
14
RWLS Final Report
Figure3: Hardware schematic of printed circuit board system
RWLS Final Report
15
Software Description:
The software we use will be designed based off of the following flow chart:
Figure 4: State Machine Flow Chart
These are the different states that our device will be able to enter and the functions they will
call in each state to perform what needs to be accomplished in each state. The two deviations of the
circular state machine are when it is too cold to take height measurements and when the cell modem
fails to lock on to our carrier’s service. For the first situation, the machine will go right back into sleep
mode and wait until it is warm enough again. In the second situation, the machine will go straight to
turning off the cell Modem and then it will continue from the beginning of the state machine the next
day.
Standards
Through designing our system we found that industry standards made it easier for us to communicate
with modules made by different manufacturers and to interface with third party networks. Without this
integrating all of our modules together would probably not be possible, unless they were are
16
RWLS Final Report
manufactured by the same company. Our system includes various types of standards to interface with
different modules and different types of networks. As we reviewed the standards that we used while
integrating our system together we found a few that were the most helpful, these were the JTAG
standard, C standard, UART standard, GSM standard, and FCC standards. We will provide a
summary of each of these standards and how we used them within our system.
JTAG Standard
Joint Test Action Group (JTAG) was formed in 1985 and was standardized as IEEE 1149.1. It was
originally developed to test printed circuit boards for soldering defects using boundary scan. We are
applying the JTAG standard with our system’s printed circuit board. Below is the pin out of the JTAG
interface to multiple chips on a printed circuit board. All JTAG connections are daisy chained together
giving the JTAG interface access to all devices on the printed circuit board. We are using JTAG to
debug the software we created to run on our microcontroller. We are also using the JTAG standard
to burn our software code onto our microcontroller’s flash memory. This allows us to reprogram our
microcontroller at any time we would like and apply software updates.
Figure 5: JTAG Hardware Flow
TDI (Test Data In)
TDO (Test Data Out)
TCK (Test Clock)
TMS (Test Mode Select)
TRST (Test Reset) optional.
UART Standard
Universal Asynchronous Receiver/Transmitter (UART) is a asynchronous transmission and receiving
standard. It can be transmitted over different mediums such as RD-232, RS-422, and RS-485. Once
17
RWLS Final Report
one bit of data is received in a UART shift register, it will take one bit of data in one format and send
the data out in a special framing that can be read on the receiving end. A picture of the framing of
the encoding of each character that is sent
using UART is below.
Figure 6: USART byte Framework
UART will show a busy flag while sending or receiving a character. For this reason we will use buffers
so that we can deposit more than one character into a register for transmission at a time. At the
receiving end UART works at a clock signal that is at a multiple of the data rate. It will look at the
incoming signal waiting for the start bit of each frame. After the start bit each bit is sampled and
stored into a receiving shift register until a stop bit is received. UART will also resynchronize on each
change of data that is more than one-half bit wide to make sure it is staying reliable.
We are using the UART standard to integrate our Telit cell module with our ATMega128
microcontroller. This allows you to send the data that we collect with our differential pressure sensor
and convert it using our microcontroller before we encode and send the data out using the cell
modem.
C Standard
The C programming language is a procedural implementation language. It was designed to be
complied using very simple compliers to provide low-level access to memory and to make the
language map efficiently to binary code. The C programming language is a stripped down version
of the program language “B”. This makes the language and complier very light weight and gives it
wide spread applications especially in embedded systems. All of our software that is being used to
control and run our measurement system is wrote according to the C programming language standard.
The C programming language is the closest language to binary code available making it very
efficient and fast.
GSM Standard
GSM primarily operates in the 900 Mhz and 1800 Mhz frequency bands within the United States. It is
based on full-duplex channels, and the signal is modulated using Gaussian minimum-shift keying
(GMSK) which smooth’s the signal using Gaussian low-pass filter prior to being fed to the modulator
that helps to eliminate interference. Each frequency is divided into timeslots which allows for 8
channels per frequency and they are grouped into a TDMA frame. The data rate of each frequency
is 270.83 kbit/s. This means that the voice codecs used for GSM had to have low bandwidth; this was
accomplished by using Enhanced Full Rate (EFR) which utilizes 12.2 kbit/s per channel. With our
limited carrier selection that would support third party cell modems on their network, we needed to
communicate with the carrier network using the same standard and technology that they supported.
We found that AT&T would support third party devices, but their network was built using GSM
standard. We utilize GSM to send out a text message of our converted measurement via our cellular
modem.
18
RWLS Final Report
FCC Certification
Our cellular modem is certified to meet FCC Class II permissive changes. This means that the device
can increase its radio frequency emissions. These guidelines are all set forth in Section 2.1043 of FCC
OET Bulletin NO. 62. To be certified by the FCC this device had to pass many verification processes
certifying that the device is safe to operate, measures radio frequency energy that are radiated by
the device in open air, and that the device will not have any interference problems.
System Testing and Implementation
Hardware Test
Test the battery self-discharges
Charge the battery to 100%. Measure the power of the battery several times with the time line listed
below using a voltmeter.
Table 5: Battery Discharge Testing Table
Power left
After 2 hours
After 10 hours
After 1 day
After 3 days
Test the power supply of Solar Panel
Set the solar panel outside in the sunshine. Covering the panel with snow under different scenarios
listed below. Measure the output of the panel with power meter.
Table 6: Solar Panel Testing Table
0.5 inch 1 inch
2 inch
When 20% of the surface covered by snow:
When 40% of the surface covered by snow:
When 60% of the surface covered by snow:
When 80% of the surface covered by snow:
When 100% of the surface covered by snow:
19
RWLS Final Report
Test if all the components can survive under -20C/-4F
Set all the components outside in a pelican case during winter for one day. Collecting them back and
testing if they can function properly.
Test if the pipes can survive through winter under water
Bury several different types of tubing into a stream before winter. In spring, collect these pipes and
pick up the one with best condition.
Test Case
Pre-condition
Steps
Possible Result
Test to shut down the
cell module
Test to make the
device set the right
speed and character
The cell module has
been turned on
The cell module has
been turned on. This
is an initial
Send command
AT#SHDN
Send command AT
Response with OK
-Response with OK
-Timeout after 200ms
Pressure sensor and differential amplifier
Another important part of the testing process is to make sure our pressure sensor is accurate enough to
meet our functional specifications of 1inch of water depth. The way we handled this was to set up a
differential amplifier with a gain of 500 so that our 10bit ADC on the microcontroller would be able
to see the change with enough accuracy. What we had to test here is the noise that came with the
gain so that we could calibrate our code with by subtracting the noise from the outcome.
Software Test
20
RWLS Final Report
format of the serial
port
Test the network
status
command
The cell module has
been initialed and
SIM is present
Send command
AT+CREG?
Test to setup the SMS
mode
The cell module has
registered on a
network.
The cell module has
registered on a
network and been
set as SMS mode
Send command
AT+CMGF=1
Test to send a new
SMS
-Send command
AT+CMGS=”PHONE#”
-Type in the text after
“>”
-end command with
CTRL-Z
-Response with CREG: x,1,
which means registered on the
home network
-Response with CREG: x,2, or
x,3, or x,4, or x,0, failure to
register on any network
-Response with OK
-Response with OK
-Response with ERROR
-Response with +CMS ERROR:
1, which means unassigned
phone number
-Response with +CMS ERROR:
331, which means no network
Test if the cell module can work properly
Test if the microcontroller can read values from pressure sensor correctly
To test the accuracy of the pressure sensor, we got a two-liter bottle of water that we stuck a hose
into at varying depths. This allowed us to see that we could measure the water difference with enough
accuracy that we met our functional requirement.
Test microcontroller wake up from sleep every 24 hours
Since it is impossible to put the microcontroller in constant sleep mode for 24 hours without an external
wake up, the way we implemented this is by having the microcontroller wake up every 10 seconds
and then go right back to sleep. To test to make sure this is what’s happening, we had the
microcontroller light up and sleep for 2 minutes in this fashion. Once we could do that, it was only a
matter of changing a variable to make it sleep longer.
Test information transporting between microcontroller and cell module
Before starting the test, we need to make sure that the cell module has passed the previous individual
test so that it can work properly. To make sure the Cell modem can transmit a message, we sent it a
message and told it to text one of our phones. Our phone received that text.
Full System Test
This test is to find out if all the components can work together properly. Precondition is all previous
tests passed. The test process will be same as the software flow chart.
Test condition 1: temperature below 32F
-Read temperature.
-Switch to sleep mode
-Wake up after 24 hours, read temperature.
21
RWLS Final Report
Test condition 2: temperature above 32F
-Read temperature
-Turn on ADC and the pressure sensor and read the output
-turn off pressure sensor and ADC
-Turn on the cell modem
-Check network on the cell modem
-Cell modem sends out the message
-Turn off the cell modem
-Microcontroller switches to sleep mode
-Wake up from sleep after 24 hours
-Repeat…
Implementation
Hardware:
When most of our parts were received we wanted to construct as much of our system using
breadboards first to confirm that our theoretical calculations for resistor values, voltage and current
losses were within our limits. This helped us as we were designing our printed circuit board for our
final product. Along the way, through our prototype testing on breadboards and evaluation boards,
we found that we needed to change our design from semester one. All of our major components did
not have any issues; we found all of our design changes in our power management circuits. Our first
design’s voltage regulators did not meet the minimum requirements for our cell modem and
microcontroller because we incorrectly calculated our first power budget. We needed to replace
these regulators with ones that would be able to handle higher currents during operation.
We also needed to select logic level shifters because our cell modem and microcontroller have
different values for logic high and logic low. The logic high for the Atmega128 microcontroller is 5
Volts and the logic high for our Telit cell modem is 3 V. The level shifter shifts the voltages between
the two devices so they are able to communicate correctly.
Once we made these changes to the parts that we were using in our integration we were able to
connect all of our components together and operate them within the recommended ranges according
to the manufacturer’s datasheets. Our ATMega128 microcontroller integrated with our cell modem
using UART without any issues. The ATMega128 was also able to receive readings from our pressure
sensor and instrumentation amplifier via the analog ports without any problems.
After we had prototyped the system using evaluation and bread boards we were able to confirm our
printed circuit board configuration. We did need to make some changes to this board to take into
account heat dissipation and spacing configurations. We also needed to add additional components
to the printed circuit board such as toggle switches, battery terminals, and needed to find all parts in
the 1206 package so that we would be able to solder the printed circuit board by hand.
Software:
Our software design is based on a state machine. We had a total of four states at the end of the
design process. The first state checked to confirm that the temperature was high enough for us to take
a reading. If we passed our first state we would power on all of our components and take a
differential pressure reading and convert the measurement into inches. Our third state would then
22
RWLS Final Report
send a text message to a specified phone number. Our fourth state would then power down all
components and put the microcontroller into sleep mode. All software was written in C for efficiency
and simplicity.
Preliminary Testing Results:
The first thing we did when we received each of our components was to test them separately so that
we could measure their accuracy and make sure they functioned as intend and within our
specifications.
To display the values, a program to light up LEDs on the evaluation board as a binary number was
implemented. The function of this program:
First, it will light up the first and second LED. The number of times these two LEDs blinked
indicates the number of digits of that variable.
Secondly, it will display each digit from the least significant digit to most significant digit.
Between each digit, it will light up all LEDs to indicate the end of displaying current digit.
This function provided invaluable help when measuring values from the temperature sensor and
pressure sensor via the ADC.
Temperature Sensor Testing:
A temperature chamber was used to achieve the desired temperature of 32 F. Feeding the
temperature sensor 5V with Voltage Generator we were able to power the device inside the
temperature chamber. Then we inserted the temperature sensor into the camber, and connected the
output pin of the sensor with ADC port on Micro-controller. Finally we turned on the temperature
chamber.
Result:
The output value was decreased along with the temperature in the chamber. It indicated that the
circuit has been setup correctly, and the chamber temperature was affecting the output correctly.
Since we only needed to find the freezing point voltage output at 32 F, we recorded the value when
it reached that point.
Pressure Sensor Testing:
Since we are using a differential pressure sensor, an instrumental amplifier was needed to obtain the
difference between the two outputs. First, we needed to test each component separately.
Instrumental Amplifier Testing:
To implement the instrumental amplifier, a circuit needed to be built with a reasonable gain.
To test the implementation of the instrumental amplifier, two 2.5V power supplies were used
as the inputs, and a multimeter was used to measure the output. After the circuit setup, we
adjusted the input voltage.
23
RWLS Final Report
Result:
We used a gain of 1500, so that when the difference between the two inputs was 0.3mV, the
value displayed on the multimeter was .45V. The limitation of the output is the supply voltage
of the amplifier. Since we were using a 5V supply voltage for it, the output displayed on the
multimeter could not be higher than 4.4V. We also found that the Differential amplifier could
not display output voltages below .6V, instead showing the floor value of .6 V What this
means, is that our final project will have to take any measurement below 6 inches and display
this as zero.
Sensor Testing:
Since the temperature sensor and pressure sensor are both use ADC, and we have tested the
ADC function of the micro-controller in previous stage, we assumed that the micro-controller
will work properly here. Using the same circuit for the instrumental amplifier we hooked the
outputs from the pressure sensor to the inputs of the amplifier, and read the output of the
amplifier with the micro-controller. We then connect one of the ports on the sensor with tube.
Result:
The value gradually increased as the tube was going down into the water. We recorded the
depth of the tube, and the values read by the micro-controller. We obtain the calibration
function based on this data.
Cell Modem Testing:
Step 1:
Here we used the USB port to test the Cell Modem to find out whether the command for
initiating the cell modem is work properly. We found that the following command can be used
to initiate the cell modem and sent out the message:
#AT
// to check connection, returns OK
#AT+CREG?
// to check the network. If it returns “x,1” or “x,5”, we can continue
#AT+CMGF=1
// set the message type, returns OK
#AT+CMGS=”PHONENUMBER”
// set target of the sending message, returns “>”
>
// then, we can enter the message
Clt Z
// the end of the message, returns OK
AT#SHDN
// to turn off the modem
Step 2:
To test the USART output from the micro-controller, a device named UB232R was used. This
device reads the signal from micro-controller and sends that to computer via USB port. The
message was displayed correctly on Realterm.
Step 3:
Since the cell modem can only read 3V USART signal and the output from micro-controller is
5V, a level shifter was needed. The micro-controller is able to read 3-5V as high. Therefore,
24
RWLS Final Report
the message from micro-controller to cell modem needed to go through the level shifter, but it
does not have to in the opposite direction.
During testing, we found that the message may not be sent out successfully at the first time,
even the cell modem is under good network coverage. We modified the program so that it
will try 60 times to check the network signal in 60 seconds. Once it finds a network and sends
out the message, it will wait 6 seconds for the “OK”, otherwise, it will continue checking the
network.
Prototype Testing
With all modules individually tested we needed to perform a complete test from our pressure reading
to sending the data via text message. We prototype tested with two liter bottles and five gallon
buckets to conduct our initial tests. We were able to successfully read height of water with our
prototype system in a controlled lab environment. With a successful test we were provided with a
complete prototype to provide for our demo. We just needed to connect all modules together
according to our hardware schematic in figure3. We still used evaluation and bread boards to
complete the prototype, but confirmed that the voltage regulators will output the correct voltages.
Operational Manual:
The Remote Water Level Sensor is a complete system, as the only assembly needed is connecting
power and mounting the system. After receiving the water level measuring system, follow the steps
below to get the device operational and complete the recommended testing to confirm the system is
working correctly.
Parts Included:





Steel underwater housing for silicon pressure tubing
20 ft. Silicon pressure tubing
Two 6 Volt batteries
System printed circuit board
Pelican case with mounted solar panel and pre drilled hole for pressure tubing
Installation:
Underwater Housing:
1.) Insert silicon pressure tube into sidewall hook of underwater housing until approximately one
inch from top of housing
2.) Place provided pump tube inside underwater housing
3.) Secure the underwater housing in the middle of the body of water that you are monitoring
4.) Bury one inch lip of underwater housing with sand
5.) Use provided pump to create air pocket within underwater housing by pumping water out
6.) Once approximately a 1-2 inch air pocket is created pull out pump tubing out
25
RWLS Final Report
Installation Continued:
Monitoring System:
1.
2.
3.
4.
5.
6.
7.
8.
Place printed circuit board inside pelican case
Place both 6 Volt batteries inside pelican case
Connect positive (red) terminal of battery one to negative (black) terminal of battery two
Connect negative (black) terminal of battery one to positive (red) terminal of battery two
Connect positive (red) terminal of solar panel to positive (red) terminal of charging circuit
Connect negative (black) terminal of solar panel to negative (black) terminal of battery one
Connect charging circuit to positive (red) terminal of battery one
Connect positive (red) terminal of battery two to positive (red) terminal of system printed
circuit board located in the pelican case
9. Tighten screw of positive (red) terminal on the printed circuit board to secure positive wire
10. Connect negative (black) terminal of battery two to the negative (black) terminal of system
printed circuit board
11. Tighten screw of negative (black) terminal of system printed circuit board to secure negative
wire
12. Route pressure tubing from underwater housing through pre drilled hole in pelican case
13. Place rubber grommet around pressure tubing and secure in pre drilled hole to prevent leaks
14. Connect silicon pressure tubing from under water housing to port one of pressure sensor
mounted on system printed circuit board
15. With power connected, turn power toggle switch on printed circuit board to “on”
The target cell phone or server for your depth readings will be preprogrammed before the system is
sent to the customer. The system is configured to immediately send a depth reading to the target cell
phone or server as soon as the system performs its initial startup processes. This first depth reading
should be received within 10 minutes. The depth system is by default to send out a reading once
every 24 hours to the target server or cell phone.
Initial startup processes:
As the depth system boots up after a reset or after its initial startup the device performs several selftests to determine proper network signal strength, and system states. The system has a built in buzzer
that is used to provide the user with the network signal strength. The user will be provided with a
buzz for each level of signal strength for all levels 1-5. The system will also test charging of the
batteries from the solar panel and provide the user the results to their target cell phone or server.
26
RWLS Final Report
Closure Material
Conclusions and Lessons Learned:
We found this project to be more intense than we first expected. There are many components that we
used in this system in which none of us had any previous experience with before or even knew existed.
We all realized that there is a gap between academics and industry that can only be closed with
experience in both fields. We also realized how big small changes to a system can be if they are not
included in the original design and we needed to be able to make corrections and additions to the
design to allow for these changes. Our group as a whole feels better prepared to make an entrance
into industry and hope that our experiences from this project with help us become better engineers in
the future.
Future Work:
Our group thought future improvements could be made to the system, including using a TCP/IP
connection from the sim card to provide the system an IP address which would open many
opportunities for the project. Remote monitoring, maintenance, and updates of the system could be
performed from anywhere with an internet connection. We also thought that by using the TCP/IP
connection we could transmit the depth results to a database, which would allow anyone to create a
web interface for users to view depth history and trends. This might also make the device more
appealing to the USGS. We do know that use of the TCP/IP stack is available with the current cellular
modem that is being utilized in our system. To provide these capabilities to our system would involve
modifying our source code to allow the system to send the results to an IP address and make the
system available remotely.
Client Information
The client and advisor for this project is Steve Holland who is the advisor for the Iowa State University
Canoe and Kayak club. His contact information is shown below:
Title:
Assistant Professor
Dept:
Aerospace Engineering
Office:
2331 Howe Hall
Ames, IA 50011-2271
515-294-8659
515-294-7771 fax
Email:
sdh4@iastate.edu
27
RWLS Final Report
Student Team Information
Our team website is located at http://seniord.ece.iastate.edu/may1223/. This site has been updated
as the school year progressed. The team members are:
John Henderson
Iowa State University
Electrical Engineering
Johnh169@iastate.edu
Curt LaBarge
Iowa State University
Electrical Engineering
clabarge@iastate.edu
Greg Pearson
Iowa State University
Computer Engineering
gpearson@iastate.edu
Yixin Qiao
Iowa State University
Computer Engineering
qiaoyx@iastate.edu
28
RWLS Final Report