Rice is cultivated all over the world in fields known as rice paddies and it is one of the most maintenance intensive crops to grow. The rice paddy itself requires a large part of that maintenance. It is flooded with water that must be kept at a constant level, just below the height that would keep rice seedlings from growing but high enough to drown any weeds that would compete with the rice stalks for nutrients. This technique is called continuous flooding and a big part of the job of a rice farmer is to inspect the rice paddy every day to make sure the water levels are normal and there are no cracks or holes that could lead to water leakage.
This process is labor intensive, and the technology in use hasn’t changed much over the centuries. Most of the rice farmers in my area are elders with the approximate age of 65-70 years. For these hard working people a little bit of technology can make a big difference in their lives. This is the idea behind TechRice.
TechRice is a project that started as a collaboration between hackerfarm and Digital Garage in Japan. I was contacted by one of the heads of FutureLab, an internal R&D group inside Digital Garage and they were asking me about potentially interesting projects that could be done involving Internet of Things. I’m not particularly fond of the term “IoT” but there are many projects that could be done involving sensor networks that would be useful both in Japan and around the world.
We met up with Digital Garage at their main office in Ebisu to discuss some possible projects. I also ended up talking about hackerfarm, a hackerspace some friends and I set up in rural Japan to focus on agricultural technology and issues that affect the Japanese countryside. One project that came up was rice field monitoring using wireless sensor networks and it caught the attention of some of the members in FutureLab. That’s pretty much how the TechRice project started.
Rice Paddy Sensor Networks Make a Lot of Sense
The area around hackerfarm is a hilly rice growing community with many stepped rice terraces. Because of the terrain, the rice paddies can’t grow to be more than a few square meters, approximately enough size to feed one family for a year. There can be as many as thirty rice paddies in one square kilometer, each belonging to different families that own and work them.
The rice paddies are not adjacent to the farmers’ homes so the farmers must travel to the entrance of the rice terrace every day and walk uphill to their rice paddy to inspect it. If there are any problems, they also need to do maintenance on it. As the farmers age, going to the paddy everyday and making the uphill trek to their paddy becomes more difficult. As I discussed various problems in the local community, this stood out as a problem that can be solved with a bit of technical automation. The rough pieces to do this would be a water level sensor, a way to communicate that water level measurement to a server, and a way to visualize the data.
One Simple Board Does it All
The main sensor node uses a device called “Saboten” meaning “cactus” in Japanese. It’s a device I designed originally for monitoring water levels in large water storage tanks in the Himalayas and also for monitoring mangrove forests in Costa Rica. It consists of a modified Arduino platform based on the ATMega1284P microcontroller. I chose this MCU because it has 16kB of SRAM as opposed to the 2kB used in the standard Arduino MCUs. The RAM goes very quickly since we’re using a FAT32 file system to store data locally on an SD card, as well as assembling long text strings to send to the aggregator. The SD card serves as a local backup for sensor data as well as maintaining a system log for debugging and analysis when the system has issues. I also wanted to stay with the Arduino environment since it’s widely used with a great developer community.
Sensing Water Level in Outdoor Paddies
The main sensor is an ultrasonic acoustic range sensor called MaxSonar by MaxBotix.Acoustic sensors are often used in non-contact liquid level sensing because they don’t have the drawbacks that float or submersion sensors often suffer and won’t risk leaching chemicals into the water. The MaxSonar is essentially an amplified acoustic speaker with a horn attached to focus the ultrasonic chirp in a single direction. We’re also experimenting with building our own ultrasonic level sensor using a waterproof piezo actuator and a 3-D printed horn to see what kind of range we can get. For the rice paddy monitoring, we only need about two meters of range so anything around there would be fine. The MaxSonar has a range of around 10m which is overkill for this particular application.
The front end RF interface consists of a 900 MHz 802.15.4 wireless transceiver with a 500 mW power amplifier on the transmitter and an 8 dB low noise amplifier on the receiver. These were implemented to optimize the transmission range since many applications have the nodes separated by a few km. With proper antennas, it’s possible to send data over ten kilometers so its overkill for the rice terraces which have a diameter of approximately 2 km.
I also included a temperature compensated real time clock on Saboten to maintain an accurate alarm for periodic wake from sleep. In low power sleep mode, the MCU can only be awakened from a few sources, one of which being an interrupt on its IRQ lines. The real time clock can be programmed with an alarm that triggers an interrupt every millisecond, second, hour, day, week, etc. This is a valuable feature for low power applications since the only built-in way to have timed wakeups on the AVR is to use the watchdog timer with a maximum timeout of 8 seconds. This results in a lot of wasted power waking and then going back to sleep again if we desire something like a 4 hour sleep interval.
The RTC chip also has temperature compensation to reduce the amount of clock drift as the temperature varies. This is an important factor to consider when designing devices that will be deployed outdoors and need to maintain accurate time. For sensor networks, accurate timekeeping is essential because we need to align the data from each node and data alignment is usually done via timestamp.
Sipping from Batteries and Using the Sun
One of the biggest topics to consider when developing a wireless sensor node is the power consumption. Many people try to develop a design that has the absolute lowest power consumption possible but this usually requires tradeoffs and contortions to minimize consumption. The Saboten device goes down to about 300 uA in low power mode which is good enough to survive about 9 months on a standard 2000 mAh LiPo battery. Things could have been optimized for lower power consumption but it would require using expensive parts and increasing the complexity of the software, potentially increasing the chance of field failures. Instead Saboten has a built in solar charge controller that was fitted with a 100 mA, 5V solar panel. This is a fairly standard solar panel that can be purchased in the Shenzhen markets for less than a dollar. At an average current consumption of 1mA (active + sleep), a one hour charge in the sun with the panel would keep the system running for ~4 days. In other words, there’s more than enough charge capacity to keep the battery topped up, even if the sun is absent for months.
There are also some small features I added to help with analysis and system debugging, especially remotely. There is a voltage monitor on the battery voltage and also on the solar voltage. With these two pieces of information, it becomes possible to remotely see if the solar panel is charging the system properly, if the battery is going bad, or if the system is not sleeping as is intended. I like to send power system data along with sensor data so that we can predict when a node is about to go down and also see if there are any power aberrations that correlate with “strange” data. I also fitted the Saboten board to an IP65 weatherproof enclosure with all external cables going to cable glands to maintain the integrity of the weatherproof seal.
The Saboten sensor nodes send all their data to an edge router which is basically a Saboten with a 3G shield mounted on it. The 3G modem is usually powered off and is just turned on twice per day to upload data. It’s a huge consumer of power with a maximum current consumption of 2A at 5V (10W) when it’s just turned on and searching for base stations. We’re currently being very careful with the power consumption on that board but will hopefully be uploading more often as we properly size the solar panels and battery for it.
Firmware, REST, and Python
The firmware is basically vanilla firmware that implements power management and communications via the chibiArduino library. You can get an idea of how the power management and communication code is written by checking out my tutorial published a few years back for the Freakduino. The basic hardware subsystem is the same as my Freakduino boards so most of the code in this project is recycled. But the full device code is hosted on the Digital Garage Futurelab GitHub account.
In my opinion, the more interesting part of the software is the web backend. This part was done by Halfdan Rump at Digital Garage and introduced me to the wonders of Python as a web programming tool. We used Python Flask which makes creating a RESTful API ridiculously easy. The Flask framework also contains database plugins to handle most popular databases so interfacing is also quite simple.
The TechRice API Halfdan wrote is called the Satoyama API and handles standard CRUD operations in a RESTful way. The data is exchanged via JSON messages uploaded to a server housed on Heroku with a Postgre database. Data is collected by each of the sensor leaf nodes and sent to the aggregator node which is the edge router with the 3G modem. The 3G modem is fired up twice a day to upload the data via HTTP to the Satoyama server which will update the database entries. Once the data is in the database, the data is available to be consumed by either the mobile app or to be displayed on a web page.
Just a word of warning. The code and hardware is still a work in progress so it changes frequently and goes up and down all the time.
The Network Topology
Network topology is an interesting topic for people involved in sensor networks. I was originally a fan of meshing networks but since I’ve had a few real deployments already, I’ve come to prefer single hop networks. In this case, I’m using the chibiArduino wireless stack to implement a single hop link to the aggregator node. With the amplified RF front end, the range is no problem at around 1.5 km in mainly open field. In general, I prefer to stay with single hop links whenever possible and vary transmit power and antenna gain instead. Keeping the network simple means there’s less of a possibility of the network going down which also means I don’t have to keep going out in the field to troubleshoot network issues.
Literal Field Tests and Literal Debugging
The project was deployed this year during the rice planting season and we collected initial data which was successful but also pointed to some holes in our logic. There were some incorrect assumptions on the power management and we mainly need to make the system more robust. Out in the rice paddies, there are all kinds of insects that will happily crawl into any hole or crevice available which also includes the acoustic sensor’s horn. That’s one reason we’re experimenting with creating our own sensor which could also be made insect proof. Otherwise, it’s mainly an iterative process of improving the hardware, software, fixing bugs, and making the system robust enough that it can be deployed in more remote locations and have a high uptime.
From Monitoring Paddies to Tracking Wild Boar
We’re hoping to have the system fully online for next year’s rice planting and also extend it to other applications such as boar trap monitoring. Wild boar are an invasive species in Japan and are considered a huge pest since they can decimate a farm in a single night. Boar traps are set up around the area but many of the trappers are older and can’t police the traps all the time. We’re going to adapt the system to notify trap owners whenever a wild boar is caught.
We’re also working with a group called TechAguru in Balanga City in the Philippines. TechAguru is an offshoot of the Balanga makerspace in rural Philippines and their focus is on optimizing the rice farming process out there. John Auxilios, one of the founders of TechAguru, came out to hackerfarm this year to discuss their project and we’re planning to bring the system out there and collaborate with them on rice farming in the Philippines. Otherwise, we’re mainly hoping to get the system ready for primetime and do an open source release soon :)
The TechRice Team
The main TechRice team consists of a hardware engineer (Akiba), a firmware/embedded engineer
(Masa), a frontend/backend web programmer (Halfdan), a mobile/data visualization programmer (Yuta), and other engineers that assist with various tasks associated with the project. One of the complexities of the project is that wireless sensor network deployments require specialists from multiple domains. A lot of specialty hardware is needed to meet power and communications requirements, firmware to run the individual nodes, web backend programming to implement the web services and REST API, and front end data visualization for web and mobile presentation. I think we’re extremely lucky that between us, we have all the experience we need to implement a project like this.