Bloggidy

I finally got the raindance project (see posts below) to a more-or-less complete state. The custom board (including the PIC, programming header, SitePlayer headers, ethernet transformer/jack, PSU, relay drivers and back-up battery was finished and stuffed, and slowly everything was taking shape. A lot of debugging was done to make everything work – the website, plain as it is, allowed configuration of all valves and device parameters, and the relay drivers themselves would activate at the scheduled times. Beautiful.

And then the f’ing SitePlayer up and died. I’m not sure what happened, though I suspect something went wrong with the power supply, but I can’t talk to the damn thing anymore – neither by UART nor by the network interface. As far as I can tell, the voltage supplied by the regulator (a simple full bridge rectifier, some caps, and a LM312-style device) is supplying 5V, but it also gets hot – hotter than it should, I think. But either way, ding, dong, the SitePlayer is dead. My dad (who designed and stuffed the hardware) has one more of the units in California, so we can try to swap it out. The problem, of course, is that now the longevity of the device isn’t really guaranteed.

After all the poking and prodding and comparatively poor documentation, my faith in the SitePlayer’s reliability was already shaken, but for it to just up and die for no reason really makes me think this was the wrong way to go for this project.

So, I’m using this as an opportunity to sketch out the hardware for the next revision of the device. Some features that I wanted on this device but was not able to implement:

1. E-mail notification after power outages, weekly summaries, etc.
2. Time Server communication to avoid having to set the time manually
3. Larger web site space
4. Communication with external sensors (soil moisture sensors, irrigation sensor)
5. SSL support

1 and 2 can be achieved if the device has a full TCP/IP stack available. Basically, it means that the next system should have a full ethernet interface, rather than just a limited web server as in the case of the SitePlayer.

3 can be achieved by adding sufficient amounts of nonvolatile storage, either permanent or removable.

4 requires external interfaces – preferrably some sort of wireless chip to communicate with remote sensors, along with the extra complexity in code and web site to configure such a system.

5 requires a beefy processor, or one with hardware support for cryptographic functions.

So far the mental sketch of this system leans on the NetBurner development kit. On this dev board is a Freescale ColdFire MFC5270 chip, which is a 32-bit 68000 core with an external memory bus as well as internal SRAM, an integrated ethernet MAC, and miscellaneous other features. Its big brother, the MFC5271, includes a cryptographic engine on-board. In addition, the following parts would be required:

1. SDRAM
2. Non-Volatile Storage with a NOR-like interface
3. RTC controller
4. Ethernet PHY

Obviously, the complexity of this system far exceeds that of the initial version of the hardware. Unfortunately, the price to pay for a full-fledged TCP/IP stack + webserver is a fairly beefy processor underneath, and those come with the necessity for external RAM etc.

On the other hand, since this processor has an external data bus, adding a second NV storage like a CF card would be quite doable! This means that the available storage size would be limited only by software constraints. Also, any I/O device with a standard NOR-like interface could be addressed, in particular wireless chipsets of various types. This would allow for some very advanced functionality in the future, for example:

• remote nodes that control extra valves
• remote rain sensors
• remote soil moisture sensors
• 802.11 wireless support (unlikely, but possible!)
• logical interconnection of these features, e.g. only turn on valve when it hasn’t rained in 3 days, only turn on valve if the soil moisture is less than some threshold, send notification when the soil moisture does not increase when a valve is opened (indicating a bad valve or blocked hose), etc.

One issue with this approach is the handling of power-down scenarios. The processor itself consumes much more power than a PIC, and the associated peripherals must be turned off in an intelligent way so as not to ruin the battery life in the event of a power loss. Furthermore, relevant data must be stored either in the internal SRAM or on non-volatile storage, unless the SDRAM should also remain powered during power loss. There are many potential pitfalls in this scenario, so it will require careful planning.

Of course, the software effort in such a system could be very significant, depending exponentially on the number of features and their interactions. On the other hand, the flexibility is enormous, and the device might serve substantially different functions depending on the software used.

I am nearing completion of my first actual brought-to-completion microcontroller project. The application: to control sprinklers and drip hoses in the back yard through a web interface, with multiple timers for each valve and power back-up. This was accomplished by creating a custom electronic platform, along with a dynamic website for the user interface.

Hardware
The hardware consists of a SitePlayer network module, a PIC 18LF2321, a 3V coin cell battery, and glue logic. The valves that control the waterflow are turned on and off with relays that switch 24VAC power. The relays themselves are driven from the PIC I/O pins using driver ICs. Twelve valves in total are in use for this project, the number being limited mainly by the memory of the PIC device selected.

The SitePlayer module implements all the handling of network devices. It includes a flash memory that stores all the web site files. In the files, strings of the form ^foo are replaced by the content of the variable ‘foo’, which is one of a number of data types, automatically when the website is served by the site player. A UART (RS232) link between the PIC and the SitePlayer allows the PIC to read and write the variables in the SitePlayer’s on-board memory.

Additionally, a serial I2C eeprom is available for logging events.

Software & Logical Design
The logical design of the device is as follows: the SitePlayer serves up a website with information regarding the current configuration of the system (current time, day, status of the valves, etc.). Most of the dynamic information is retrieved via AJAX. When the user makes a change to the web interface, a specially formatted string is written to the SitePlayer (again, using AJAX), and the SitePlayer module toggles an I/O pin, raising an interrupt on the PIC. The PIC notices this interrupt, reads the command string out of the SitePlayer, updates its internal parameters, and then updates the SitePlayer’s memory, reflecting the changes. Then, the SitePlayer propagates the changes back to the browser.

Furthermore, the PIC reacts to a timer interrupt generated every 2 seconds, and updates its internal clock. On every minute roll-over, it checks whether any valves need to be turned on or off.

There is a back-up battery, which makes sure all the settings (which are stored in PIC RAM) are preserved across power losses. In battery mode, the valves are not being activated, nor is the SitePlayer running. The PIC wakes up every 2 seconds, updates the internal time, and goes back to sleep, so minimal power is consumed. When power is restored, the SitePlayer is re-initialized with data, and can be accessed via the network again.