Croatian engineers [Slaven Damjanovic] and [Marko Čalić] have developed a wireless system for farmers to monitor plant conditions and weather along their agricultural fields. The system uses an RFM95W module for LoRa communication, and devices are designed to be plug-and-play, battery-powered, and have long-range communication (up to 10km from the gateway).
It uses an ATMega328 microprocessor, and includes sensors for measuring soil moisture (FC28 sensor), leaf moisture (FC37 sensor), pressure (BME280 sensor), and air temperature and humidity (DHT22 or SHT71 sensor). The data is sent to a multichannel The Things Network gateway that forwards the information to an external database, which then displays the data through a series of graphs and tables.
The software for sending messages to the gateway is based on the LoRa MAC in C (LMIC) and LowPower libraries and was developed by [ph2lb].
The purpose for the plastic enclosure to not only aesthetic, but it also protects the temperature and humidity sensors from direct exposure to sunlight and rain, which could affect the readings and create water leakage into the device. The custom 3D-printed enclosure is water-proof and works as a solar radiation shield to protect eAgrar from direct and reflected solar radiation.
The goal of the project has been to help fight against climate change, which has had a negative effect on agricultural production due to weather shocks and a lack of predictability in information from fields. Farmers have had to rely on using pesticides and chemical agents to prevent the development of diseases, which in turn pollutes the environment. The team hopes that eAgrar will provide more information to predict the appearance of disease and help farmers reduce costs, reduce damages to their plants, increase their yields, and increase the quality of their crops over time, all while using chemical agents less frequently and in smaller quantities.
The device uses a real-time clock (RTC) as a wakeup alarm and is powered by a 3.7V Li-Ion battery with a life of one year, although there is also a 5V boost converter for powering up to four 5V sensors. Their custom PCBs from JLCPCB have rust-resistant pads and vias, and remain high quality even at high temperatures.
For the LoRa wireless sensor network, the system set up allows the devices to be controlled remotely even when they are not connect to the Internet. Settings such as sleep time and communication parameters can be modified without reprogramming the device.
Currently, the Dashboard remains in Croatian, but it offers a wealth of information such as last measurements, graphs of temperature and moisture measurements, a data table with all data from the start of the device life, and a calendar for the user to use for recording notes.
28 thoughts on “LoRa-Based Plant Monitoring”
Are there any “for dummies” level documentation about how to set up a basic LoRa gateway, and what can you do with it?
All I see is things like the things network stuff, which is built as a more or less opaque “platform” where you add this bob and plug in this library and magic happens and then you’re online – to their IoT platform.
I was hoping this was it. I *must* be missing something that’s obvious to those in the know cause I’ve had little effective success so far.
I had a low power Lora network to collect data from my car as I drove around. I ended up switching to GSM and finally plain WiFi with data upload to my WLAN when I got home.
Maybe that’s a topic for a Hackaday article: how to LoRa
This is important tech. The gateway seems to be the first sticking point because there’s all this application layer protocol backend stuff that is never explained anywhere beyond superficial bullet points on a powerpoint slide. Of course the IoT platform companies want to keep it obscure – after all, the cloud is just someone else’s server and if it was easy then everyone would have their own.
This is a great idea.
One of the things that’s been ignored by all the existing examples is how to deal with LoRa class A/C devices, like, if you have a gateway at your command then how do you push messages upstream to the devices and process them?
“Are there any “for dummies” level documentation about how to set up a basic LoRa gateway, and what can you do with it?”
Pretty straighforward: Set up a gateway, it will automatically connect to TTN. Then register your device in TTN. Done. maybe you need to setup your device via $interface with some parameters (e.g. AppKey).
But if you would like to have full control, you have to go the long path of setting up your own LoRa-Server. For exactly this reason and for the reason that LoRaWAN has huge packet-sizes due to the chunky header and the AES-approach (block-chiffre), we built our own LoRa-protocol which works quite nice even in large setups with several thousand nodes.
What can you do with it? Well – having a large sensor-network which YOU OWN with a range of several kilometers outdoor with the benefit of low-power battery-driven sensors with battery lifetimes of > 10 years. There exists nothing comparable to this.
But I have to say: it was a very expensive development. For the regular DIYer I would suggest LoRaWAN with TTN. If you want to have a more control: add your own LoRa server. If you want to have full control: setup your own protocol on top of LoRa.
“If you want to have full control: setup your own protocol on top of LoRa.”
Yeah, that’s the problem with LoRa IMO. Hasn’t this been done already as an open-source project? I don’t want to be chained to the TTN “Cloud”, and the LoRaWAN gateways are closed-proprietary and rather expensive.
Yes there are options. The RadioHead library can use LoRa modules like the RFM95. I am using the library with RFM69 for my home automation since I don’t need that much range.
On the software side, there are plenty of options to make your own server and not be dependent on a service.
LoRa(WAN) gateways are expensive because of the hardware. Not the software. The hardware has an Sx1301 or an Sx1301. Concentrator boards are available for at least 85$.ans that’s just the LoRa part. Additionally you need some SOC with Linux for the packet forwarder software or your own bit of software that communicates with the SX1301/8. Even with a Rpi Cm3 this adds costs of around 20$. And that’s just the basic parts. On top there is power, maybe wifi, ethernet and all this stuff. One could just use ready-made WRT54 boards from China which are cheap (like Draguino does) but there you have the software part which is a little bit more tricky. Thats the whole reason you cannot find a gateway for under 140$.
Alternatively you can build a SX1278/76 based gateway. But this is really more like a toy, due to having only one channel with one SF fixed datarate etc. This can be built very cheaply.
And by the way – as I said use your own lora server (e.g. Loraserver. Io). Then you are not chained to the cloud. TTN is just Loraserver.io as a service. Setting up your own Loraserver isn’t that hard. You could use docker. There is an image for everything.
The point is exactly that we don’t want to connect to TTN – but all the dummy level tutorials are based around these existing platforms that abstract the link layer away and assume you buy specific hardware and load it up with specific firmware.
That’s why we’ve been using SigFox, because while the network is proprietary the actual cloud system is just a message relay that can be directed anywhere. That, plus the 40 kilometer coverage is much better than setting up repeaters everywhere.
If I understand you correctly, it sounds like what you’re interested in is creating your own IoT framework from scratch which is more of the realm of web development. I.e. Full-stack web development: Creating a backend to handle the database and a front-end to display it to the user/handle the interfacing between the database and IoT device.
I completed such a project this summer because I too wanted to learn more about creating my own IoT framework from the ground up. I haven’t yet had a chance to finish writing up the tutorial series due to family commitments but you may be interested in it: https://engineerworkshop.com/2019/07/04/weather-station-project-esp32-with-lora-telemetry/
The thing is, if you want to do anything serious with the stuff, you can’t be relying on some platform like the TTN because they can go away just like that, or change their pricing, terms and conditions etc. and that will pull the rug from underneath your business or project.
That’s the problem with all proprietary and/or special networks – that’s why people still use SMS over GSM to control their home automation projects etc. because it’s probably going to be around for a few more years without anyone messing with it.
For a basic LoRa project, it would be enough to have the data in a file system that you can access, that you can own, and possibly send a JSON to something like Thinger to display it – but the primary issue is getting the data in and out of your devices and having it for yourself.
I’ve been wondering the same, but haven’t put much research time into it. Not really interested in using someone else’s infra, but seems like most writeups / tutorials lead that way, at least to some degree.
– Seems this may(?) be promising? – Looks like open-source gateway+server combo, that could run on a pi:
– I’d be curious if anyone else has experience to chime in on this or alternatives to running your own closed network, with an ‘all in one’ relatively simple gateway/server.
Hey, try Ursalink UG85. It’s an affordable comercial LoRaWAN gateway with friendly Web GUI and free embedded network server, which is perfectly suited for your PoC project!
Check Adreis Speiss’s YouTube videos. They’re at least a good primer.
Hi Luke what you see in the left picture is the concentrator iC880A-spi from IMST. You can buy it in their webshop
for 119Euro and find all information on their webside http://www.wireless-solutions.de. More simple is to buy a ready
made called Lite Gateway for 199Euro (combination of iC880A-spi and Raspberry Pi B+). Good luck!
Not an unreasonable project – mostly just packaging and glue code and network futzing.
Water will wick through the USB cable.
SMA connectors platings, as indicated are not suited for that environment.
That soil sensor has a low MTTF.
A singular system will not scale.
The data is the most valuable commodity for environmental and agricultural systems. If the data is not protected, all of the cool hardware and glue code.
About 19 months ago, we completed an agricultural monitoring project for two sites having a total of 1800 acres (over 7 square km) of growing fields and greenhouses. Three sensor boxes per greenhouse or one sensor box per acre, and 7 sensor channels per box. It works reliably because we did NOT do any IoT madness, or depend on any other ‘public’ infrastructure.
Ag stuff is requires two things – carrier-grade packaging and the ability to operate locally and/or stand-alone.
We did a similar thing, only, we were using public infrastructure. We had three field with about a hundred sensors per field. We had two types of sensors, one with a local infrastructure meaning a base station and repeaters in each field, and the other with a long range IoT network.
For deployment and practicality, the local solution was a real PITA. You had to set up the radio cells, which meant drilling antenna tower bases into the ground, erecting the towers, and lightning protection towers with grounding rods driven 6 feet into the soil – all that cost a surprising amount of money and man-hours. At first we didn’t bother with the lightning rod masts at all – then we lost a device to a lightning strike a month into the trial. Oops.
The “public” IoT network was much easier on the actual point of putting sensors in the field and getting data out. We just went in, planted the sensors and their transmitters, and left. That’s it. For the whole duration of the test, we lost at most 24 hours of data due to outages.
The local/standalone solution was not popular with the farmers. They really hated the radio masts because they have farming equipment with long beams, and tractors that do not turn on a dime, so we had to go in and pull down the masts whenever they wanted to do spraying or harvesting, which was again really costly because you have to schedule all these things and arrange people to come in – which is inconvenient for the farmer because they have to follow the weather and they may have to move really quickly to get things done. With field plots tightly placed with just narrow ditches separating them, there isn’t really any land to put these radio towers without somebody complaining about it.
The idea of setting up your own radio cell is attractive, but the practicality is another thing. If you can place the radio far away from the actual field, that solves many problems. If you cant do 5 miles reliably, that’s a no-go because you have to build and admin too much infrastructure.
Even a postage stamp solar cell would let this run forever. Another box penetration, I know, but they can be sealed to the case to very effectively cover their connections.
Depends on your postage stamp.
We got away with about 2 mW average power consumption for a remote sensor.
In the ideal case, you’d need about 1 square centimeter of solar cells for that. When we analyzed the situation, we ended up with a solar cell around 40×70 mm, because it has to be able to charge up more than one day’s worth in an afternoon and deal with all the inefficiencies and not being able to operate at the maximum power point etc.
“It uses an ATMega328 microprocessor, and includes sensors for measuring soil moisture (FC28 sensor), leaf moisture (FC37 sensor), pressure (BME280 sensor), and air temperature and humidity (DHT22 or SHT71 sensor).”
If it has a BOSCH BME280 for air pressure then why does it have a DHT22 or SHT71 sensor for measuring air temperature and humidity? The BME280 supports all three measurements: air pressure, air temperature, humidity, (and via a simple calculation, dew point) – and it does a very good job of it.
I noticed that, too. A BMPxxx (pressure and temperature, no humidity) would be cheaper than a BMExxx if only used for pressure measurements.
It is a bad idea to put sensors (air pressure, air temperature, and humidity) in a sealed enclosure. The proper way to do it is to use a double-louvered enclosure for the sensors that is open to the air but protected from the rain. This type of enclosure is called a “Stevenson Screen”:
Here are detailed plans for a double-louvered Stevenson Screen:
Not much different from Vinduino
Apart from remarks that already were made about the bme280 sensor, the leaf sensor will rot away in no time and that capacitive sensor is not protected from the sides and will soon show leakage
I’ve done something similar a bit more than a year ago… basically it was a replacement for existing system to enable the farmers to control various sprinklers in realtime at a central point (so it enables the possibility of having irrigation schedule for different sub-field making the water use more optimal), or set schedule, as well as aggregate data from the field.
Learned a lot about precision agriculture while working on that project … fun times!
Please be kind and respectful to help make the comments section excellent. (Comment Policy)