Wireless Sensor Network Design forMonitoring and Irrigation Control: User-centricHardware and Software Development

David Kohanbash1,3, George Kantor1, Todd Martin2,

and Lauren Crawford2

ADDITIONAL INDEX WORDS. nR5, remote, user interface, WSN

SUMMARY. Wireless sensor networks (WSNs) are increasingly becoming a critical toolfor growers and researchers. We describe how the technology has advanced, startingwith a commercially available WSN node and pushing the technology to make thedata more meaningful, actionable and to add advanced irrigation control func-tionality. User features such as spatial views, custom charts, real-time data access,remote access, irrigation control, alerts, and plant models help create an advancedWSN system that is user centric. Growers and researchers were involved in thedesign process by directly communicating with the design engineers, and contin-uously using and testing new features, resulting in a user-centric design andexperience. The results of this research are being rolled into a new line of commercialproducts and is continuously evolving based on user feedback and interaction.

Wireless sensor networks (Fig. 1)are an important tool formonitoring crops and con-

trolling irrigation (Angelopouloset al., 2011; Bauerle et al., 2013;Coates et al., 2012; Lea-Cox, 2012).A common issue with today’s WSNsystems is being able to understand thevast amount of collected data. Nextgeneration WSN systems need to helpthe user understand the data and makethe data actionable. One way to makethe data actionable is to control irri-gation. At the simplest level, users canlook at the current sensor data (vanIersel et al., 2013) and use it to decidewhen to irrigate. Tools that providereal-time data access and custom chartsmake it easy to identify soil moisturetrends, allowing the grower to sched-ule irrigation events that match cropwater needs with greater precision.Advancing remote irrigation controlto the next level allows the sensor nodethat is reading the data in the fieldto also control irrigation from anonboard solenoid control relay. Thisallows the grower to remotely apply

irrigation or modify the irrigationschedule based on the current condi-tions in the field. To further improveirrigation control, the software systemprovides ‘‘local’’ set point control,which makes irrigation decisions lo-cally at the node using attached sen-sors. In this mode, the grower sets thedesired volumetric water content andthe node will irrigate to that moisturelevel using feedback from attached soilmoisture sensors. Lastly, there are a setof customizable grower tools that al-low nodes to irrigate based on exter-nally derived data. This ‘‘globalcontrol’’ allows data from other nodesor grower tools to be used for control-ling irrigation. Global control bringsprecision irrigation to an entirely newlevel by allowing plant physiologicalgrower tool models to run in real timeand determine plant water require-ments (Kohanbash et al., 2012a).

Irrigation node developmentTwo data loggers (also referred

to as nodes) that are capable of read-ing sensors and controlling irrigationsolenoids were developed as part ofthis project (Fig. 2) (Kantor et al.,2012). They are both based on theEm50R data logger (Decagon Devices,

Pullman, WA). This data logger waschosen as it operates reliably in fieldconditions, has a long battery life (bat-tery life depends on frequency of sensordata collection. Typically 5 AA batterieslast a full growing season), and robustlong range (typically greater than 4 kmline-of-sight) radio telemetry in out-door environments. It can support upto five different sensors at a time, andthere are many different sensor typesthat the manufacturer provides thatprovide multifunctional use for thenode. By building on this solid plat-form, we are able to leverage the ex-isting commercial product to improvethe reliability of the new system thatallows for irrigation control and re-mote configuration of node settings.

The two nodes that were devel-oped include the nR5 (Decagon De-vices) node, which is capable ofcontrolling 24-V (alternating cur-rent) solenoids, and based on userfeedback the nR5-DC was developedthat can control 12-V (direct current)latching solenoids. Solenoids con-nected to the nR5-DC are poweredby the node, so growers do not needto distribute electrical wires for irri-gation solenoids, providing time andmoney savings for the grower. A newuser software interface called Sensor-web has been developed that allowsthe user to interact with the WSN andmake the data actionable.

In the transition from a nodethat only logs and reports data to anintelligent node that can control irri-gation, it was determined that a newunderlying application level commu-nications protocol needed to be de-veloped built on the serial radiointerface provided by the nodes radio.The decision to develop a new appli-cation level protocol for node packetsis based on the need to conservepower and for reliability. Standardtransport level communication pro-tocols (TCP/IP, 6LoWPAN, etc.) arenot suitable for a sensor network–basedcontrol system: they do not accountfor the need to have two-way commu-nications with nodes that are not alwaysawake, and they are bloated withpower-consuming features that are

UnitsTo convert U.S. to SI,multiply by U.S. unit SI unit

To convert SI to U.S.,multiply by

1.6093 mile(s) km 0.6214

This paper is part of a series of manuscripts describingthe research and development completed by theSCRI–MINDS (Managing Irrigation and Nutritionthrough Distributed Sensing) project. The authorsgratefully acknowledge funding and support from theUSDA–NIFA Specialty Crops Research Initiative;Award #2009-51181-05768.

1Robotics Institute, Carnegie Mellon University,5000 Forbes Avenue, Pittsburgh, PA 15213

2Decagon Devices, Inc., 2365 Northeast HopkinsCourt, Pullman, WA 99163

3Corresponding author. E-mail: dkohanba@cmu.edu.

• December 2013 23(6) 725

not necessary for this system. By de-veloping a custom protocol, we canfine tune performance and batterylife. The nodes use a 900-MHz radio(XSC; Digi, Minnetonka, MN) fordirect point-to-point communica-tions. To decrease node power usage,

the data packets in the new protocolhad to be 64 bytes or less so that thecomplete data packet would not getsplit into multiple packets for datatransmission. We chose to transmitbinary data instead of ASCII charac-ters for most of the communication

packet contents, which makes the rawpackets harder to read as a human butallows for more information to be putinto a 64-byte packet. This packingminimizes the number of packetsthat need to be transmitted to fur-ther increase battery life. Each packet

Fig. 1. Image of a basic wireless sensor network showing the remote access (Lea-Cox, 2012). Node supports up to five sensorsplus has one onboard relay/solenoid controller that can be used to control multiple solenoids simultaneously.

Fig. 2. Decagon Devices (Pullman, WA) nodes. The right image is an Em50R, which the new nodes are based on. The left imageis the interior of the new nR5-DC.

726 • December 2013 23(6)

SPECIAL SERIES

starts with a common character fol-lowed by the packet identification(ID) (Table 1), the node serial num-ber and a timestamp. After the headercomes the packet specific data fol-lowed by the footer. The footer con-tains a cyclic redundancy control(CRC) value for data integrity, thenumber of attempts that the nodemade to transmit the packet, and anend of packet character (Fig. 3). Ifthe data does not require the fullfield size, it is padded so that thepacket size for a given packet typeremains the same and can be prop-erly parsed. Every time the node isturned on and then again every24 h thereafter, the node publishesits current configuration. This helpsmake sure that the information in

the base station is always up to dateand also allows nodes to automati-cally be detected and added into thebase station.

When a packet is sent from thenode to the base station, the base stationtransmits a confirmation packet so thenode knows that the packet was receivedcorrectly. The confirmation packet al-ways has the attempt number and CRCvalue for the packet it is confirming.When the base station sends a newconfiguration packet to the node, thenode saves the settings and then sendsout a packet with the existing settingsthat the base station can verify. This isthen followed by the base sending aconfirmation packet as it does whenreceiving any packet from a node. Afterattempting to send a packet 10 times,

the sender will give up. Ten times waschosen as a balance between trying toget packets when there is poor radiocommunications and minimizing trans-missions to conserve battery life. Thisprocess is important for two reasons.The first is to insure that data andirrigation settings are correct, if thenode irrigates longer than commandedbecause of a bad packet that can causeproblems. The second reason is thatagricultural environments often havehills, valleys, trees, building, powerlines, and long distances that can leadto imperfect communication betweenthe node and the base station. Bytransmitting data multiple times, theprobability of having successful radiocommunications increase.

To conserve battery power, thenodes spend most of the time in a lowpower sleep mode and only awakebriefly to transmit data at a user-definedsensor measurement interval. One re-sulting challenge to having two-waycommunications between a base sta-tion that is typically connected toa com-puter in an office/shed and a node isthat the node needs to be awake toreceive commands from the base sta-tion. To solve this problem, the confir-mation packet from the base stationhas a field that can tell the node to stayawake for a few seconds. This way whenthe base station sends a confirmationpacket to a node it can request extratime before the node/radio goes tosleep so that it can follow up the confir-mation packet with another packet forchanging settings on the node. Usingthis strategy of embedding commandsinto the confirmation packet can beexpanded for any other parameter thatmust be sent regularly. Another exampleof this is the base station sends anirrigation enable/disable flag in theconfirmation packet that is used forglobal control irrigation to determineif irrigation is required or not. This letsus put commands in a packet that isalready be transmitted instead of usingpower to send additional packets forthat command.

WSN software developmentThe software and user interface

(Sensorweb) are critical for users to

Table 1. List of the various packets used to communicate between the nodes andbase stations. The identification (ID) field is the letter that is used within thepacket to identify what type of packet it is.

ID Packet name Sourcez Description

A Test N A test packet that the node can send outto verify connection to the base

B Data N Data packet sent from the nodeC Node configuration N/B Contains current general node settings or

can be sent by the base to change thenodes settings

D Location N/B Contains optional node locationinformation. This can also be sent fromthe base to configure the node settings

E Irrigation configuration N/B Contains current irrigation settings orcan be sent by the base to change thenodes settings

F Device status N Contains node statistics and reports anyerrors

G Control status N The node sends this out every time anirrigation event starts or stops. Thismessage tells the base how long theirrigation was and if there was anyerrors

H Control override B This message is sent by the base station toinitiate a manual irrigation event

X Base confirmation B The base station sends this packet asa response to any incoming packetfrom a node

Y Node confirmation N The node uses this packet as an extraverification step when irrigation eventsare scheduled

zN = node sends the packet, B = base station sends the packet, N/B = node and base station both send thepacket.

Fig. 3. Packet structure for radio packets from node to base station. The payload field varies significantly between packet types.

• December 2013 23(6) 727

get the full benefit of any WSN sys-tem. This software development alsoled to the design of an advancedinterface that was the result of a greatdeal of consultations and beta testingby the growers in the project withdirect communication to the soft-ware engineering team. Features wereadded to this system (and removed)based on user feedback and by ob-serving user practices. This web-basedsoftware allows for remote access overthe Internet in a familiar web-basedformat. This allows growers to mon-itor and control their irrigation fromanywhere where they can get an In-ternet connection. The interface isdesigned to work with both standardcomputers and mobile devices (suchas smart phones and tablets). Thereare four main software componentsto the WSN base station: the database,the node communication software, theuser interface, and the grower toolsystem.

Although all parts of the systemwere designed for direct user interac-tion, the interface is the one piece that

the user has the most exposure to.This means that the interface needs tobe well designed with intuitive fea-tures and easy to customize. One ofthe complexities in tailoring the userinterface to the grower is that everygrower is unique. The user interfaceneeds to be flexible enough to coverthe needs of as many differentgrowers and situations as possible,from field, to container-nursery togreenhouse environments. It is im-portant that the first thing a user seesprovides them with easily to under-stand and useful information. Aftera user logs into their farms’ password-protected website, the first screen thatis shown is a spatial view of the farm(Fig. 4) that is color coded based on auser-selected measurement. The usercan quickly get more data about thenodes at that location by moving themouse over the node (or tapping itwith a finger on a smart phone). Thehome page also has alerts that aregenerated by the system as well asuser-configurable alerts and a sectionwhere the user can make notes. If the

user chooses to delve into the data,they can view both real-time data(Fig. 5) and/or generate a chart ofhistorical data (Figs. 6 and 7).

Irrigation control using this WSNsystem is versatile and has multiplemodes (Kohanbash et al., 2012a).Users can manually send manual irri-gation commands, configure irrigationschedules, configure local set points,and configure irrigation based ongrower tools as outlined in Table 2.Within Sensorweb, irrigation groups(or zones) can be configured. Userscan assign nodes that share the sameirrigation settings to a group so thatwhen irrigation settings are changedall the nodes in the group have theirirrigation settings updated; the powerof WSN-based distributed irrigation isthat each node in the group will stillindependently control irrigation basedon its own sensors. This allows a scal-able solution for configuring manyirrigation nodes in one step while stillhaving the advantage of precise irriga-tion control within each node’s sole-noid. The design of the irrigation

Fig. 4. Screen capture of the Sensorweb home page showing the spatial view and pop up with real-time detail. Arrows next to thedata show real-time trends. Alerts in red (upper box) show possible issues with the system as well as user-defined alerts.

728 • December 2013 23(6)

SPECIAL SERIES

control page has challenges similar tothose of the home page in that eachfarm has very different irrigation re-quirements and Sensorweb needs tobe able to handle all these needs seam-lessly. For this flexibility, irrigationevents can be configured for dura-tions ranging from 1 s to 1 d. The dayis broken up into 288 sections of 5min each that can be scheduled fromwithin the irrigation tool (Fig. 8). If

irrigation is enabled within that 5 minblock, a pulse cycle is executed. Thepulse cycle is customizable: the usercan choose to have irrigation turnedon for any portion of the 5 min, with aresolution of 1 s. For example, irriga-tion can be switched on and off basedon some ‘‘micropulse’’ cycle that theuser defines (Fig. 9). This feature ofbeing able to configure pulse typeshas proven to be very valuable. Not

only does varying pulse types allowfor finer control, it also allows thesystem to leave time between irriga-tion pulses to let water percolatethrough the soil or substrate so thatthe sensors can react in a more timelyfashion to irrigation events. This helpsto avoid over irrigation. This is espe-cially true when microsprinklers areused with soilless substrates (Belaynehet al., 2013). Each irrigation method

Fig. 5. Screen capture of the Sensorweb data view page (some nodes are hidden to fit the page) showing the recent data from thenodes and grower tools. Clicking on a node name brings up the node configuration page. This example has irrigation controlnodes, sensor only nodes, and grower tools.

• December 2013 23(6) 729

has a different control methodology.Having the node control irrigation in‘‘local mode’’ is useful since if theconnection to the base station is lost(poor/no radio connection, loss ofpower, etc.), the node will continueto manage irrigation without inter-ruption. This is very important forsystem reliability (Majsztrik et al.,2013a); even if other nodes or thebase station have a fault, nodes con-tinue to operate independently. In thecase of global control where the basestation is the control point and makesthe irrigation decision the node willrevert to using just the local schedulestored on the node if the base stationfails. This dual control methodologyprovides a robust approach for theirrigation system so that nodes cancontinue irrigation if telemetry is lost.

The database is an SQLite3 file-based database. It is responsible forstoring all the settings and data for theWSN system. One of the reasons forchoosing SQLite3 as the database is

that it is file-based so writes are slowerbut reads are faster than a server-based database system. Within theWSN system, there are relatively fewinserts into the database, comparedwith the size of the search querieswhen the user is accessing the system(particularly when generating plots).Each node is assigned a unique ID inthe database. All data are associatedwith both that unique ID and thehard-coded serial number of the nodethat the data came from.

The node communication soft-ware and the grower tool system needto run continuously in the backgroundas opposed to the user interface whichis triggered by user activity, as theyaccess the interface from a web browser.The node communication softwareuses Perl (2013). Perl is widely sup-ported and has excellent databasesupport. Another big advantage ofusing a scripting language such as Perlis its built-in parsing functions thatmake working with data, disassembling

incoming data packets, validating thedata, and assembling new packetsmuch easier. Grower tools provideadvanced features to the user andmust be run in the background atpredefined schedules. Some examplesof grower tools include computingaverages, vapor pressure deficit, dewpoint, evapotranspiration, water sav-ings, and plant models. The growertool also monitors the current data forsending out user-defined alerts via e-mail or SMS text messaging as neces-sary. The grower tool software usesRake and Ruby (Ruby, 1995; Rubyon Rails [RoR], 2003). Rake is bun-dled with RoR, which is used for theuser interface. Although Ruby/Rakemight not be the first choice for manyscripting languages, it has very power-ful and easy to use database tools. It isalso tightly integrated with the RoRarchitecture allowing for the use offunctions within RoR in the rake script.In particular, there is a lot of code in theuser interface for converting data to

Fig. 6. Sample user configured dynamic chart with node data. Users can zoom in on the data in several ways includingselecting the data with the mouse (or finger), the slider bar, or preselected time scales). Yellow (light) and gray (dark)vertical bands signify day and night regions within the chart. Charts are generated using the Highstock library (Highsoft,Vik, Norway).

730 • December 2013 23(6)

SPECIAL SERIES

Table 2. Various irrigation modes and the benefits of using a wireless sensor network (WSN). The control point is where theirrigation decision takes place.

Irrigation mode Control point Description The WSN advantage

Manual commands User Allows the grower to send manualirrigation commands to the nodes

Irrigation can be determined remotelybased on sensor data and sent to thenodes. Irrigation nodes can also easilybe reconfigured and/or moved basedon the current crop

Schedule based Node Irrigation is based on a predefinedschedule that is stored in the nodes

Same as manual commands buta schedule controls irrigation so thereis less direct user involvement

Local ‘‘set point’’control

Node Uses the schedule but also looks at thecurrent soil moisture to determine ifirrigation is needed at that nodeslocation

Irrigation is determined at each locationfor precise irrigation control

Global control Base station This is used to control irrigation based onvalues external to the node. Examplesof global control can be a sensor ona different node, a computed valuefrom a growing tool, or from a plantscience model

This entire method of control iscompletely data driven and allows forfeed-forward predictive control

Pulse types This is a submode for the modes listedabove. With this option, irrigation canbe issued in pulses to allow sensors timeto react, increase precision, or allowirrigation lines time to recharge

The ability to do this on each node allowsfor localized irrigation control. Thiscan further improve the irrigationprecision by using commandingmicropulses of irrigation as needed

Fig. 7. Sample user configured dynamic chart with node data. Placing the mouse over a data point will show the actual values atthat point. The thin vertical lines represent irrigation applied and you can see corresponding jumps in the horizontal soilmoisture lines. The dark horizontal band in the middle of the plot is a user-defined region of interest.

• December 2013 23(6) 731

the proper units and validating datathat can be reused within the growertool scripts.

The grower tool system is de-signed to be modular so that it is easyto add new grower tools into thesystem (Kohanbash et al., 2012b).Adding a new grower tool to thesystem is a two-step process. The firststep is to add a line into the databasethat specifies what the name of thegrower tool is, what units the inputsand outputs of the grower tool shouldbe, and where the grower tool scriptfile is. The second step is adding thegrower tool script file. When it is timefor a grower tool to run (Fig. 10), astandard extensible markup language

(XML) input data file (Fig. 11) iscreated based on the configuration linein the database and the settings theuser selected when instantiating thegrower tool. The grower tool scriptfile then reads the input file, runs thegrower tool–specific code, and thenneeds to generate an output XMLfile (Fig. 12). The output XML fileis then read and the data are savedinto the database. Once it is in thedatabase, the users can view the data,control irrigation with it, or generatealerts.

ConclusionsThis WSN system has been in

use for several years at over a dozen

commercial and research sitesthroughout the United States andhas demonstrated its reliability by op-erating continuously at those sites andaccurately controlling irrigation. Us-ing this system has led to financialsavings/gains, labor savings, reducedcrop growth time, reduced chemicalapplication, and reduced disease/pestsfor growers that use this system. Fora complete discussion of the benefits,see Lichtenberg et al. (2013) andMajsztrik et al. (2013b). The systemis continuously evolving based onuser feedback and is gaining newfeatures to make WSNs even morevaluable and make the data evenmore actionable.

Fig. 8. Screen capture of the Sensorweb irrigation manager page. Blue (i.e., shaded) regions in the schedule are those selected forirrigation.

732 • December 2013 23(6)

SPECIAL SERIES

Fig. 9. Pulse type configuration page. This pulse type is showing a micropulse setup, where irrigation is turned on for 20 s,turned off for 20 s, and the cycle is repeated five times for a total irrigation length of 200 s.

Fig. 10. Grower tool process flow. Showing input file, processing, and output file for running any model using a standardinterface.

Fig. 11. Sample input file for a grower tool running a plant water use model in a commercial nursery.

• December 2013 23(6) 733

Literature citedAngelopoulos, C.M., S. Nikoletseas, andG.C. Theofanopoulos. 2011. A smartsystem for garden watering using wirelesssensor networks. Proc. 9th Assn. Comput-ing Machinery Intl. Symp. Mobility Man-agement and Wireless Access. p. 167–170.

Bauerle, T.L., W.L. Bauerle, M. Goebel,and D.M. Barnard. 2013. Root systemdistribution influences substrate moisturemeasurements in containerized ornamen-tal tree species. HortTechnology 23:754–759.

Belayneh, B.E., J.D. Lea-Cox, and E.Lichtenberg. 2013. Costs and benefits ofimplementing sensor-controlled irriga-tion in a commercial pot-in-pot containernursery. HortTechnology 23:760–769.

Chappell, M., S.K. Dove, M.W. van Iersel,P.A. Thomas, and J. Ruter. 2013. Imple-mentation of wireless sensor networks forirrigation control in three container nurs-eries. HortTechnology 23:747–753.

Coates, R.W., M.J. Delwiche, A. Broad,M. Holler, R. Evans, L. Oki, and L.Dodge. 2012. Wireless sensor network

for precision irrigation control in horti-cultural crops. Proc. Intl. Conf. Agr.Eng., Valencia, Spain, 8–12 July 2012.

Kantor, G.A., D. Kohanbash, and T.Martin. 2012. Next-generation monitor-ing and control hardware development.Proc. Irr. Assn., Orlando, FL, 4–5 Nov.2012.

Kohanbash, D., A. Valada, and G.A.Kantor. 2012a. Irrigation controlmethods for wireless sensor networks.Proc. Amer. Soc. Agr. Biol. Eng. Annu.Mtg. Paper No. 121337112.

Kohanbash, D., A. Valada, and G.A.Kantor. 2012b. Base station design andarchitecture for wireless sensor networks,Proc. Intl. Conf. Agr. Eng., Valencia,Spain, 8–12 July 2012.

Lea-Cox, J.D. 2012. Using wireless sen-sor networks for precision irrigationscheduling, p. 233–258. In: M. Kumar(ed.). Problems, perspectives and challengesof agricultural water management. InTechPress, Rijeka, Croatia.

Lichtenberg, E., J. Majsztrik, and M.Saavoss. 2013. Profitability of sensor-

based irrigation in greenhouse and nurserycrops. HortTechnology 23:770–774.

Majsztrik, J., E. Lichtenberg, and M.Saavoss. 2013b. Ornamental grower per-ceptions of wireless irrigation sensor net-works: Results from a national survey.HortTechnology 23:775–782.

Majsztrik, J.C., E.W. Price, and D.M.King. 2013a. Environmental benefits ofwireless sensor-based irrigation networks:Case-study projections and potentialadoption rates. HortTechnology 23:783–793.

Perl. 2013. The Perl programming language.28 Oct. 2013. <http://www.perl.org/>.

Ruby. 1995. Ruby: A programmer’s bestfr iend. 28 Oct. 2013. <https://www.ruby-lang.org/en/>.

Ruby on Rails. 2003. Ruby on Rails. 28Oct. 2013. <http://rubyonrails.org/>.

van Iersel, M.W., M. Chappell, and J.D.Lea-Cox. 2013. Sensors for improvedefficiency of irrigation in greenhouse andnursery production. HortTechnology23:735–746.

Fig. 12. Sample output file for a grower tool running a plant water use model in a commercial nursery. In this case, the model iscommanding 29.8 s of irrigation that the node will automatically deliver to the block of trees.

734 • December 2013 23(6)

SPECIAL SERIES