Stream Depth Gauge: Final Report

4/23/2012 Stream Depth Gage

Table of ContentsIntroductory Material............................................................................................4

Executive Summary...........................................................................................4Acknowledgment...............................................................................................5General Problem Statement..............................................................................5General Solution approach................................................................................5System Summary..............................................................................................5Operating Environment.....................................................................................5Intended Users...................................................................................................5Assumptions and Limitations.............................................................................6

Assumptions List.............................................................................................6Limitations List...............................................................................................6

Expected End Product and Other Deliverables..................................................6Approach and Design............................................................................................6

Market Survey....................................................................................................6Design Objectives..............................................................................................7Functional Requirements...................................................................................7Non Functional Specifications:...........................................................................7Work Distribution:..............................................................................................7Project Schedule:...............................................................................................8Personal Effort Requirements............................................................................9

2RWLS Final Report

Client/AdvisorSteve Holland

(ISU Canoe and Kayak Club Adviser)

Team MembersJohn Henderson

Curt LaBargeGreg Pearson

Yixin Qiao

Risks and Mitigations:........................................................................................9Resources and Costs:......................................................................................11

Cost of prototype and testing:......................................................................11Cost of final product:....................................................................................11

Design Constraints:..........................................................................................12System Analysis:..............................................................................................12

Water level sensing:.....................................................................................12Wireless Modem:..........................................................................................12Microcontroller:.............................................................................................12Temperature Sensing:..................................................................................12Power............................................................................................................13

System Description.............................................................................................13Hardware Description:.....................................................................................14Software Description:......................................................................................16

Standards............................................................................................................16JTAG Standard..................................................................................................17UART Standard................................................................................................17C Standard.......................................................................................................18GSM Standard..................................................................................................18FCC Certification..............................................................................................19

System Testing and Implementation..................................................................19Hardware Test.................................................................................................19

Test the battery self-discharges...................................................................19Test the power supply of Solar Panel............................................................19Test if all the components can survive under -20C/-4F................................20Test if the pipes can survive through winter under water............................20Pressure sensor and differential amplifier....................................................20

Software Test...................................................................................................20Test if the cell module can work properly.....................................................20Test if the microcontroller can read values from pressure sensor correctly.21Test microcontroller wake up from sleep every 24 hours.............................21Test information transporting between microcontroller and cell module.....21

Full System Test..............................................................................................21

3RWLS Final Report

Team MembersJohn Henderson

Curt LaBargeGreg Pearson

Yixin Qiao

Test condition 1: temperature below 32F.....................................................21Test condition 2: temperature above 32F.....................................................21

Implementation...............................................................................................21Hardware:.....................................................................................................21Software:......................................................................................................22

Preliminary Testing Results:............................................................................22Temperature Sensor Testing:.......................................................................23Pressure Sensor Testing:..............................................................................23Cell Modem Testing:.....................................................................................24

Prototype Testing............................................................................................24Operational Manual:............................................................................................25

Parts Included:.................................................................................................25Installation:......................................................................................................25

Underwater Housing:....................................................................................25Installation Continued:.....................................................................................25

Monitoring System:.......................................................................................25Initial startup processes:..............................................................................26

Closure Material..................................................................................................27Conclusions and Lessons Learned:..................................................................27Future Work:....................................................................................................27Client Information............................................................................................27Student Team Information...............................................................................28

Introductory MaterialExecutive SummaryThe 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.

4RWLS Final Report

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.

AcknowledgmentWe 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 StatementFlow 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.

5RWLS Final Report

General Solution approachOur 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 SummaryOur 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 EnvironmentThe 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 UsersSome 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 planning trips. The system could also be used by the environmental agencies as a way to monitor and trend yearly water levels.

6RWLS Final Report

Assumptions and LimitationsAssumptions 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 coverage3. 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 List1. The system will not perform during or after a natural disaster2. The system will not operate properly if the solar panel is placed in a

shaded area3. The system will not be able to transmit data properly if it is placed

in an area with poor cell coverage4. The accuracy of our water measurement is accurate to within 1 inch5. The team has a limited budget of $5006. The team has limited time for implementation due to other course

studies

Expected End Product and Other DeliverablesThe 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 DesignMarket SurveySimilar 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.

7RWLS Final Report

Figure 1: Typical Gauge produced by USGS http://ga.water.usgs.gov/edu/streamflow1.html

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.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 Objectives1. Design the pressure sensor with an accuracy of no less than 1 inch2. Design the power circuit such that it can power the entire system for a

minimum of one year3. Program the microcontroller such that depth measurements can be

recorded and transmitted wirelessly through a cell modem4. Design a case for the system that can withstand all of Iowa’s extreme

weather conditions5. Include a solar cell in the design that is weather proof and can provide a

minimum of 5 Watts

Functional Requirements1. Total price of materials is less than $5002. Measure water level accurately to within 1 inch3. System will transmit data at least once per day within readable season

a. Data will not be collected during winter months to conserve power4. 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:

8RWLS Final Report

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. Withstand Iowa seasons which include ice formations, river debris, -40

degree C temperatures2. Our system will have very low maintenance levels3. Our system can survive recreational users4. Working Temps for all components up to -5 C (23 F)5. 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 website2. Researching and designing the system’s power circuitry3. Calculating the system’s power budget4. Supporting other tasks as they become a priority5. Designing the system’s Printed Circuit Board

Greg Pearson is assigned to:1. Working on software code used for system2. Designing underwater chamber used to detect pressure.3. Putting together weekly reports to be submitted.4. Helping out in other areas as they become a priority

Curtis LaBarge is assigned to:1. Team leader2. Assigning team tasks3. Researching and designing system4. Design and implement hardware integration5. Support other team members with tasks

Yixin Qiao is assigned to:1. Designing state machine code for the project2. Testing software components to make sure they work3. Helping others when they are in need.

9RWLS Final Report

Project Schedule:

Personal Effort RequirementsThe 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 50Greg Pearson 20 20 5 10 55Yixin Qiao 10 10 5 10 35

10RWLS Final Report

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 25 0 0 20 25 95Total 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.

11RWLS Final Report

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.

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:

12RWLS Final Report

Cost of prototype and testing:Table 1: Hardware in US DollarsComponent Price in DollarsPressure sensor 5Temperature sensor 5Cell modem and accessories

200

Prepaid sim card 10Microcontroller and evaluation board

10

PCB and components

10

Solar cells 45Battery 0Charging circuit 25Total 310

Table 2: Raw Material in US dollarsMaterial Price in DollarPelican Case 0Metal Compartment 150Pipe/tube 50Total 200

Grand Total - $510

Cost of final product:Table 3: Hardware in US dollarsComponent Price in DollarsPressure sensor 5Temperature sensor 5Cell modem and antenna

90

Prepaid sim card 10Microcontroller 10

PCB and Components

10

Solar cells 45Battery 20Charging circuit 25Total 220

Table 4: Raw Material in US dollarsMaterial Price in DollarPelican Case 75Metal Compartment 150Pipe/tube 50Total 275

Grand Total - $495

13RWLS Final Report

Design Constraints:1. Power consumption

a. The system is limited to components which have very low current draw while inoperative.

2. Experiencea. The team has limited design and implementation experienceb. Parts have to be hand solderable

3. Timea. Deliverables due in May 2012b. Team has other time-consuming obligations

4. Costa. 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

14RWLS Final Report

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.

PowerPower 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 CircuitThe charging circuit is required to safely charge our two 6 Volt batteries without damaging any of our system hardware.

15RWLS Final Report

System DescriptionOur 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:

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.

16RWLS Final Report

17RWLS Final Report

Figure3: Hardw

are schematic of printed circuit board system

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.

18RWLS Final Report

StandardsThrough 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 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 StandardJoint 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)

19RWLS Final Report

TCK (Test Clock)TMS (Test Mode Select)TRST (Test Reset) optional.

UART StandardUniversal 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 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 StandardThe 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.

20RWLS Final Report

GSM StandardGSM 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.

FCC CertificationOur 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 ImplementationHardware TestTest the battery self-dischargesCharge 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 TablePower left

After 2 hours

21RWLS Final Report

After 10 hours

After 1 day

After 3 days

Test the power supply of Solar PanelSet 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 Table0.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:

Test if all the components can survive under -20C/-4FSet 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 waterBury several different types of tubing into a stream before winter. In spring, collect these pipes and pick up the one with best condition.

Pressure sensor and differential amplifierAnother 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

22RWLS Final Report

with the gain so that we could calibrate our code with by subtracting the noise from the outcome.

Software TestTest Case Pre-condition Steps Possible Result

Test to shut down the cell module

The cell module has been turned on

Send command AT#SHDN

Response with OK

Test to make the device set the right speed and character format of the serial port

The cell module has been turned on. This is an initial command

Send command AT -Response with OK-Timeout after 200ms

Test the network status

The cell module has been initialed and SIM is present

Send command AT+CREG?

-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

Test to setup the SMS mode

The cell module has registered on a network.

Send command AT+CMGF=1

-Response with OK

Test to send a new SMS

The cell module has registered on a network and been set as SMS mode

-Send command AT+CMGS=”PHONE#”-Type in the text after “>”-end command with CTRL-Z

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

23RWLS Final Report

Test microcontroller wake up from sleep every 24 hoursSince 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 moduleBefore 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 TestThis 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.

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…

ImplementationHardware: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

24RWLS Final Report

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

25RWLS Final Report

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.

26RWLS 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 messageClt Z // the end of the message, returns OK

27RWLS Final Report

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, 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 TestingWith 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.

28RWLS Final Report

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 housing3.) Secure the underwater housing in the middle of the body of water that

you are monitoring4.) Bury one inch lip of underwater housing with sand5.) Use provided pump to create air pocket within underwater housing by

pumping water out6.) Once approximately a 1-2 inch air pocket is created pull out pump tubing

out

Installation Continued:Monitoring System:

1. Place printed circuit board inside pelican case2. Place both 6 Volt batteries inside pelican case3. Connect positive (red) terminal of battery one to negative (black) terminal

of battery two4. Connect negative (black) terminal of battery one to positive (red) terminal

of battery two5. Connect positive (red) terminal of solar panel to positive (red) terminal of

charging circuit6. Connect negative (black) terminal of solar panel to negative (black)

terminal of battery one7. Connect charging circuit to positive (red) terminal of battery one8. Connect positive (red) terminal of battery two to positive (red) terminal of

system printed circuit board located in the pelican case9. Tighten screw of positive (red) terminal on the printed circuit board to

secure positive wire10. Connect negative (black) terminal of battery two to the negative

(black) terminal of system printed circuit board

29RWLS Final Report

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 self-tests 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.

30RWLS Final Report

Closure MaterialConclusions 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 InformationThe 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 ProfessorDept:

31RWLS Final Report

Aerospace EngineeringOffice:2331 Howe HallAmes, IA 50011-2271515-294-8659515-294-7771 faxEmail:sdh4@iastate.edu

Student Team InformationOur 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 HendersonIowa State UniversityElectrical EngineeringJohnh169@iastate.edu

Curt LaBargeIowa State UniversityElectrical Engineeringclabarge@iastate.edu

Greg PearsonIowa State UniversityComputer Engineeringgpearson@iastate.edu

Yixin QiaoIowa State UniversityComputer Engineeringqiaoyx@iastate.edu

32RWLS Final Report