Software apps and online services
Most of today's irrigation controllers are using outdated technology and there is a huge opportunity to introduce smart wireless connected technology into that market. Some companies are already in the market with connected drop-in replacement irrigation controllers, however, the market remains ripe for systems that are reliable and have a good user experience. And very few, if any, are designed intentionally to detect faults in the irrigation system.
Optimal water usage in today's drought climate is critical and loss of water through broken irrigation systems accounts for about 5% of all water usage. In addition, when an irrigation system is failing it often goes undetected for days or weeks causing damage to crops and wasted water. With this system, operators will know instantly through notifications that there is a problem in the system. Equally valuable is measurement of exactly how much water is applied, as opposed to estimating, so that over watering can be avoided.
This is an updated version from the hackathon demonstrator used last year. The packaging and wiring has been cleaned up and the water tub has new features where different faults can be inserted, such as leaks before the flow meter and after the flow meter. In addition, a master valve has been added along with current sensors on all valves. We switched from a 12VDC source for the valves to the traditional 24VAC supply so that the detection circuits can be integrated into legacy irrigation systems.
This project involves quite a bit of electronics and some tricky software as well. We have many ideas for improvements which will be included in the text where appropriate, but it works pretty well as is. There is only one computing engine and that is the Raspberry Pi. Some of the electronics are explicitly included for test purposes such as the LEDs, switches, and power resistors. Not only can leaking type faults be inserted but the hardware can also insert faults such as shorted and open valves. Also, relays are included so that the system can be put in a demonstrator mode where it turns on and off and runs continuously.
Using a Raspberry Pi was a choice made simply because of ease of use. The operating system provides convenient options such as, a file system, wireless connectivity, audio and camera. Python was used for the same ease of use reason including the ubiquitous free code base in the Python community. On the downside, the Raspberry Pi did drive the need to add hardware such as level shifters and A/D converters which we could have acquired by using different hardware such as Arduino, BeagleBone or Cypress PSoC. In addition, the Raspberry Pi is not very good for deterministic hardware sampling at fast rates, for instance to sample the 60Hz current sensors at 200Hz requires a 5ms sample rate. We had a difficult time getting consistent readings from the current sensors, which we solved in software. This is a problem which we have not yet identified the root cause. If one were to try to make this a marketable item, more complete systems engineering should be done to determine the optimal hardware and software solution.
Below are some screen shots of the Node-red instruments.