设计我最赞的博客

Precision irrigation control is now a reality.Thomas ’s irrigation timer with advanced planning (ITAP) is a truly novel irrigation control system. The easy-to-use system, which directs user interaction into a standard web browser, provides useful information such as watering schedules and zone activity.

Electronics are supposed to simplify our lives, but all too often, the reverse is true. While researching irrigation timers, I was struck by how the evolution from an electromechanical design to an electronic design had actually made the device less usable. Early irrigation timers were based on the simple rotary motor design still popular in plug-in appliance timers. A geared motor slowly turned a wheel with on/off pins. If you wanted water at 6 A.M. in zone 2, you simply pushed in the pins for zone 2 and 6 A.M. The wheels and pins also served as crude analog gauges. A glance at the wheel would give you a pretty good idea of when things would next turn on and for how long.

In the electronic age, the wheels and pins are gone. They have been replaced by a tiny LCD and a small keypad. The electronics have added significant new capabilities,but at the cost of requiring significant data entry with a tiny keypad. The visual feedback about what you ’ve programmed is also gone. To ensure that you have not accidentally programmed a 4-h flood, you need to page through identical screens, taking note of each setting.

Photo 1—This is the completed circuit board. The WIZnet WIZ810MJ is the red board with the RJ-45 connector. A solenoid valve connected to a manifold is to the left of the circuit board.

As you can see in Photo 1, I designed an Irrigation Timer with Advanced Planning capability (ITAP). The challenge was to incorporate modern functionality,yet keep the design as simple to use as the old electromechanical design. Because the biggest problem was entering and displaying large amounts of data, I selected a web browser for the user interface. I considered various USB-based ways of connecting to a browser,but they invariably required some type of installation on a host PC. Around that time, I saw the WIZnet iEthernet Design contest 2007 announcement and decided to build my timer design around the WIZnet WIZ810MJ network module.

A potential design trap in a network-enabled device is the temptation to do too much with the network. An irrigation timer should be a simple device. It is, after all,just a timer and some solenoid valves. The network interface is present in the design because it is the best way to connect to a web browser. I have always been drawn to simple, low-cost designs, so I used the network interface to save money by eliminating an LCD and keyboard.Others might use the network interface as an excuse to jam in seldom-used features and boost the end product ’s price. Once I started building a web browser interface, I realized that this was a good opportunity to show that web technologies, which are normally associated with large enterprise deployments, can also be used effectively on micro devices.

ITAP DESIGN
The design philosophy was to not consider the ITAP as a networked or web-enabled device, but rather to use the network as a better serial line. Conceptually,the ITAP has two boxes.Box one is a headless control unit that mounts in the garden and is hard-wired to zone solenoids. It also has an internal calendar and timer that run the watering schedule. Box two is a fancy LCD and keyboard that plugs into box one whenever a change of schedule is required. Box two, of course, is really a laptop with a web browser.


The hardware box represents the headless control unit (see Figure 1).A microcontroller maintains a data model in EEPROM that is used by the timer-control firmware to determine when to turn on and turn off solenoid water valves. A WIZ810MJ network module is used by the web server firmware to accept requests from a standard web browser. The browser pages provide data entry and display capabilities of the watering schedule, as well as calendar-based planning tools. The entire design is self-contained. There are no extra files, scripts, or drivers that need to be installed on a PC.

An irrigation timer is not something you reprogram often. After an initial period of fine-tuning, the unit is expected to work, unattended, for the rest of the season. I did not need to add any daily reporting, only a minimal status page. This emphasizes the design point that the network connection is only there for reprogramming the device. Fancy reports and real-time status pages are engaging for the first few weeks of ownership, but then for most people the excitement of watching the grass grow begins to fade.

The long periods of time between reprogramming make it so you don ’t have to install any information on a PC. It is usually not a problem to pop in an installation CD when you first buy a product.Assuming there are no missing drivers or system conflicts, the first install is easy. The problem comes six months later,after you have upgraded your PC and cannot find the installation CD. For the same reason, it is important that all HTML pages live on the device and not on a PC. If the device requires a PC installation, it stops being a stand-alone device and becomes yet another peripheral ready to break when you modify your PC.


HARDWARE
The hardware was designed to include the fewest number of parts.The essential parts are an Atmel ATmega168, a WIZ810MJ network module, and a ULN2803 Darlington array (see Figure 2). I do all of my development work in Linux. The excellent AVR toolchain available for Linux is one of the reasons I prefer Atmel microcontrollers. With Linux command line tools, I can do all of my firmware development at my desk,not hunched over the lab bench. An old laptop sits on the lab bench and serves as a network-to-USB gateway for the in-circuit programmer. I chose the ATmega168 largely because of its 16 KB of flash memory and because it is easily available in a DIP package, simplifying prototyping.Timer 2 is used with an external 32-kHz crystal in real-time clock mode. The SPI master controls the WIZ810MJ. Other than a handful of I/O lines, none of the microcontroller ’s other features are used.Although it seems like a shame to use so few features, it would be pointless to complicate the design.

The WIZ810MJ is a network module that takes care of most of the complexity of adding TCP/IP networking to a design. In SPI mode,only a handful of the 56 pins are needed. The rest can be left as no connects. The version of the module that I worked with has a known problem in that it continues to drive the SPI lines even when its *SS is unasserted. The work-around is to drive the module pin SPI_EN low,which will free up the other SPI lines. The ATmega168 uses the SPI lines for serial programming, so I had to do the SPI_EN trick even though there are no other SPI devices. The WIZ810MJ draws a fair amount of current, so I did not want to leave it powered up continuously.I toyed with the idea of adding circuitry to power the module on and off. Because the network link LED status is available on a module pin, I could periodically power on the module, check for an active link,and turn it off. In the end, I just put in a toggle switch, which was crude but effective.

A ULN2803 is used as the solenoid driver. It is an eight-driver package with internal clamping diodes.The inputs are logic-level and were connected directly to port pins on the microcontroller.Each driver can sink 500 mA, which is ample for a typical irrigation solenoid valve drawing about 200 mA at 12 VDC.The solenoids are 24 VAC,but are quite content running on 12 VDC. Conveniently,inputs and outputs are on opposite sides of the DIP package, making layout much easier on a single-sided board.The only user feedback from the hardware are the WIZ810MJ ’s two network status LEDs and an LED driven by the microcontroller. The microcontroller-driven LED blinks out either a hint at the IP address or an indication of solenoid status.

DATA MODEL
There are a number of ways to organize a watering schedule. Several vendors have agreed on a single model, which is the one used here.First, there are zones, which correspond to a physical run of pipe controlled by a solenoid valve. Then there are programs, which indicate which days of the week and at what time of the day to start an action. Make a table and put the zones in the rows and the programs in the columns. At the intersections,decide if and for how long a zone should be on for each program. This can get somewhat complex, but it provides a good deal of flexibility for things like long,slow soakings and for following community odd/even watering restrictions.

The ITAP ’s internal data model consists of an array of program structures that keep all of the specifics for a program, including start times and run length times, for each zone. All times are kept in minutes rather than hours and minutes. Internally,this simplifies storage and comparisons.A running count is kept of the day of the year in addition to the day of the month. The former is used for computing every N day cycles. The latter is used for odd/even days of the month.

SOFTWARE
The software divides into microcontroller support, network code,data model access, file storage, and timer logic. The microcontroller support code is minimal. The only interrupt is the Timer 2 overflow,which is configured as a 4-Hz RTC.Everything else is done by polled I/O. Every couple of seconds the main loop checks if the WIZ810MJ has been powered up. A simple read of the last byte of the IP address is performed. If the module is off, the byte will read as 0xFF. If the byte matches the expected value stored in EEPROM, the WIZnet module is assumed to be present and it is reinitialized.

The ATmega168 ’s PORT D connects pin for pin to the ULN2803 solenoid controller. Thus, pin zero of PORT D corresponds to solenoid zero, pin one to solenoid one, and so on. At each program step, there is the possibility that you might request all zones to switch on. To limit current inrush problems, the software sets the values bit by bit with a small delay in between.In a similar software rather than hardware role, the WIZ810MJ ’s reset line is controlled by a port pin rather than RC logic. In addition to parts savings, this allows for a full part reset.

The network code is designed for the specific task of communicating with the one browser that it expects to find on a private network. The main loop polls the WIZnet sockets for a page request. Only HTTP GET requests are honored. The request can be for either a file stored in the flash memory file system or for a data page built on the fly. Changes to the data model are accomplished with arguments of the page request.

In a system where a browser request causes some action, such as writing EEPROM or switching on a sprinkler, minimize the chance that a user unintentionally repeats the action by clicking the REFRESH button.The method used here is to clean up the location line by returning a 307 REDIRECT result code.With no arguments to the page request, pressing REFRESH will simply reload the page with no additional actions.

When using the WIZ810MJ as a web server, there is a potential trap if the pages being served are complex.The W5100 can support a maximum of four simultaneous connections.If the HTML page rendered by the browser has more than four subelements (e.g., or tags), the browser will likely issue simultaneous requests.If a WIZnet socket is in LISTEN state, it will accept a connection. If the browser attempts a connection for which there is no listening socket, the browser will get a connection-refused error.Depending on the browser,this could result in either a reported error or a noticeable delay before a retry. The workaround is to keep the pages simple, with few subelements. Newer chips, such as the WIZnet W5300, support up to eight sockets.

An early design trade-off in a project like this is deciding how much flash memory to devote to storing HTML page data. It would have been easier in many ways to just wire in a 1-GB SD flash memory card and fill it with the output from a web site builder tool. However, this would have negated the strong desire I had to show by example that an attractive,useful, and feature-complete UI could be implemented on a smallfootprint device.

Accepting the limitations of finite storage, the question was how to stay as small as possible. Early in the design process, I considered keeping HTML templates in some sort of compressed form. The plan was to decompress the templates, fill in the actual values, and then serve this modified data to the browser. The final design is better in every way.If the pages are not modified but instead have static content, they can be highly precompressed with the gzip utility and simply copied,unmodified, from flash memory to the network. No compression code is needed. The pages are just a payload.Modern browsers already accept gzipped data, so nothing additional is required.

Using JavaScript makes static content possible. The JavaScript language has constructs for dynamically building pretty much anything that can be done with HTML. All of the ITAP tables and forms are dynamically built. The data needed to fill in the tables and forms is formatted using JavaScript Object Notation (JSON) and resides in a separately loadable JavaScript file. The file is built on the fly each time a server request is made for  “pdata.js.” In a larger system, data would likely be passed as XML. XML is a bulky format intended for data exchange between unrelated systems. XML really has no place in point-to-point micro applications. The nice thing about using JSON is that it is automatically parsed as it is read by the browser. Additional parsing is not required.

Another important benefit associated with putting all of the UI building code in JavaScript is that there is a clean separation between the UI view and the data model. The data model is maintained by the ITAP firmware. The firmware knows nothing of UI layout. A change to the UI does not require a firmware change.


COMPRESSED FILES
Looking through the WIZnet sample code, I noticed copyright notices around the code that accesses flash memory-based files. Thus, I thought it would be useful to show my standard tools approach to compiling files into flash memory (see Listing 1).This Linux shell script takes each file, compresses it, converts it to ASCII hexadecimal, and wraps the result in a data declaration ready for a C language #include statement.

Photo 2—The irrigation schedule is the main browser page. Four solenoid valves are represented by zones a–d. The three different programs determine at which time and on which days the zones will be active.

USER INTERFACE
Photo 2 shows the ITAP ’s main schedule page. To keep the size small, only standard buttons and standard fonts were used. The schedule page is implemented as one large HTML FORM. Inside the FORM is a TABLE built dynamically with JavaScript. Only a small bit of HTML is used to define the basic table and headings. Each page in the UI contains the same first line:


This code loads the current program and zone data. Based on the number of programs and zones, columns and rows are dynamically added and populated with their values. JavaScript functions take care of details like converting between minutes and hour and minute values. There are three programs and four zones in Photo 2. The empty fields indicate that the corresponding zone is off during that program.

To keep the main schedule page from getting too cluttered, only a summary of the program values is shown, and they are all read-only.Clicking an Edit button brings up a program edit page (see Photo 3). Both program tables are generated by the same JavaScript code. A flag tells the JavaScript to hide or desensitize certain fields in read-only mode.

The basic program interval can be set to either a fixed number of days or odd/even days. The check box by day of week is just an aid. It is no different than selecting a one-day interval. The days of the week check boxes are used to modify the basic interval. In an earlier design, I had two rows of check boxes, one for days when the program should run and a second for days when the program should not run. This was not necessary because a  “not Friday ”program is logically the same as selecting every day except Friday.There is always a trade-off between convenience and UI clutter. The Program active check box is used with the planning tools. To see what a particular program contributes to the overall totals, it can be temporarily disabled.

As you can see, there is plenty of flexibility, but also plenty of opportunity to make a mistake. The planning tools are a simple, but effective innovation that gives a glimpse into the future. Based on the currently active programs, the firmware runs the clock forward to determine how much water each zone will get each day. This summary data is used to construct the calendar page (see Photo 4). Each day in the calendar contains a small bar chart. The letters and colors of each column correspond to a zone from the main schedule page. For simplicity, the height of the bar is limited to one of four discrete steps. The bar graph is not a GIF or JPEG image. Instead, it is implemented in JavaScript as a four-row table with variable ROWSPAN elements. As with the rest of the UI, the firmware reports only the data. The JavaScript makes all display and layout decisions.

The final page is the Day page,which drills down from a calendar bar chart to show when (during the day) the water will run (see Photo 5).Each tick mark corresponds to a 15-min. interval. The tick marks are constructed from TABLE rows with a small white border to highlight the individual tick. Together the Day and Calendar pages make for accurate “what if ” planning.

I did not originally plan to have status view or zone on/off override buttons because I did not expect to have the network connected except during reprogramming. I later added these features mainly for debugging and demonstration purposes. The status and override are implemented with the JavaScript XMLHttpRequest()facility, the cornerstone of AJAX.

IMPROVEMENTS
The ITAP was a fun project to build.It was much more of a software project than a hardware project. The design has proven to be simple to use and easy to explain to others. There is still a learning curve to understand what zones and programs are all about, but this knowledge is also required for any timer. The fact that there is no expensive LCD sitting idle in the garden is continuously comforting.

One serious drawback with the current design is having a static IP address for the ITAP. I did not want the ITAP to get its address by DHCP,because I expect to have a laptop plugged into the ITAP while standing in the garden. A reasonable alternative would be for the ITAP to play DHCP server for a laptop client.

WIZnet has released two additional modules, the WIZ830MJ and WIZ812MJ. I have not worked with either, but both appear to be better choices for new designs. The WIZ830MJ has the W5300 chip. The WIZ812MJ is a redesign of the WIZ810MJ. Both new modules have 2.54-mm headers.

PROJECT FILES
To download code, go to ftp://ftp.circuitcellar.com/pub/Circuit_Cellar/2009/224.

SOURCES
ATmega168 Microcontroller
Atmel Corp. | www.atmel.com
WIZ810MJ Network module and W5100/5300 Ethernet controller
WIZnet, Inc. | www.wiznet.co.kr/en/

Editor’s note: This project won First Place in the 2007 WIZnet iEthernet Design contest. For more information about this design and the other winning projects, go to www.circuitcellar.com/wiznet.

Thomas Bereiter (itimer@micaview.com) has written software for everything from microcontrollers to huge distributed systems. He has a B.S. in computer science from the University of Illinois. Thomas currently designs prototype systems in Umbria, Italy.