Solving a key farming problem: is it safe to harvest / spray / sow today? (+experiments with 'big' data in agriculture)

Similar projects worth following
In line with the 2015 'sustainability' theme, problems for many Australian farmers:
Australia has very hot summers & on high fire risk days they are prohibited (&responsible farmers dont even try anyway) to reap crops. (Usually grains harvest is around November December.) "Catastrophic" rated fireban days are more common now due to climate change.
Presently he has to drive extra early (eg 5am) & check paddock conditions. Factors in account: not just the forecast weather, but local conditions in each paddock; if local weather on the ground seems too dangerous, which can be prior to the latest official official forecast, they cannot proceed with reaping for the day.
All that driving works out to 100s km/week or more (+fuel, pollution), plus time.
This is just the start: ongoing data logging will feed into cropping practices, record chemical application data for gov regulations, and may produce unexpected and useful correlations!

System Overview & High Level Design


Sentrifarm is comprised of a network of energy harvesting sensor nodes, geographically distributed according to the topology of the farm, able to run on low power, and communicate over extended distances without relying on the mobile phone network.

(This Project Details along with linked material presently constitutes the top level System Design Document required for the finals. Other entry criteria are listed in various project logs)

Novel features include intelligent back end monitoring and data analysis, a shield-like system allowing the SX1276 radio to be connected to completely different embedded boards, a custom design intelligent rain gauge, and the ability for long range farm monitoring of multiple paddocks without requiring multiple SIM cards.

Operational Concept & User Scenario

Refer to the Operational Concept Github.

Benefits to Farmers

  • Timely information reporting
  • Improved safety & immediate Grass Fire Danger Index visibility
  • Improved knowledge of cropping
  • Reduced operating costs

System Requirements

  • Primary aim: immediate notification of conditions to farmer
  • Secondary aim: log as much data as possible at the farm base, including from sensors/data not normally recorded by farmers, for analysis and new discoveries
  • Long ranges (eventually exceeding 20 km / 12 miles ) to avoid telco fees
  • Intelligent: farm base calculates if conditions preclude reaping
  • Usability / UX: simple app (e.g. 6am alarm, RED for no good, GREEN for OK)
  • Inexpensive, robust, maintainable commodity components: farmers have enough expensive firmware upgrades for tractors &c to deal with
  • Can expand to share data with community / crowd sourced information web sites
  • Sensor nodes must be self sufficient for power
  • Provide ability for the farmer to "tap in" to local sensors via a mobile device when on site
  • Sentrifarm is also an experiment, designed to test various combinations of equipment and data collection protocols on a real farm

Initial Prototype

In the true hacker spirit, for the initial hackaday prize build much of the equipment (in particular, the various computing modules used to build the nodes) has been chosen due to being on hand, we have more important things to spend money on at this time :-) however, the design is such that they can be changed easily to more 'production' oriented modules in the future.

Components include SX1276 915MHz LoRa radios, Teensy-LC and ESP8266 modules, ATtiny powered rain gauge & wind gauges, and Raspberry Pi nodes.


Sentrifarm supports a variety of nodes:
  • Farm base station - aggregates and forwards data from other nodes to databases and monitoring applications, using an industry standard protocol (MQTT)
  • Paddock node - also called the Fencepost station, because the prototype nodes will be mounted on paddock fenceposts - a solar powered device with reasonable computing capability, able to record data from a wide variety of sensors including rain, wind, air temp, humidity, UV, frost, daylight and even advanced features such as imaging, security and equipment telemetry
  • Ground sensor - designed for collecting in-ground temperature and moisture, potentially in a mesh across a paddock. Depending on the situation may be wired to a Paddock node, or preferably wireless and solar or piezoelectrically powered

Note that paddock in this context may be between 4 and 100 acres or potentially larger...

Sentrifarm will have a database and monitoring system, linked to the Farm base station node(s).

Read more »

  • 1 × Teensy LC (option #1 paddock node)
  • 1 × ESP-201 ESP8266 (option #2 paddock node - demand wifi enabled)
  • 1 × Raspberry Pi (per central node) There will eventually be 2 of these
  • 1 × Carambola2 OpenWRT module (per Linux paddock node)
  • 4 × SX1276 LoRa module radio (1 per module) There will be eventually be one of these per module when the system is deployed

View all 21 components

  • Update

    pastcompute10/26/2015 at 13:50 0 comments

    Congratulations to all the top 10 finalists, you well deserved it!

    We've had a bit of a break, and will be progressing our experiments a little more leisurely for the next while.

    Next task is to deal with power issues. I need to do some repairs and design a more reliable power feed, so we can deploy a reliable operational sensor in time for harvest to see how it compares with actual working measurements. By the end of things we were having a lot of trouble with nodes crashing and having to drive out and cycle the power, yet working fine in the lab. I put it down to overloading the regulator in the USB converter, which was not really the best solution by a long shot, but we ran out of time to do it properly.

    As part of evaluating the microcontroller architectures we used, I may have a spin off soon too

  • SentriFarm Semifinal Video

    amanda_mcphee09/21/2015 at 19:23 0 comments

    The video entry for the semifinals for SentriFarm can be found on YouTube at the following location:

    SentriFarm Semifinal Entry

  • Artistic Impression & General Design Notes

    pastcompute09/20/2015 at 11:02 0 comments

    A friend of mine completed an artists impression as required for the semi final submission.

    Things to note:

    • The production system as envisaged, hides all the cabling within pipe work
    • The pipe work needs to be strong enough to withstand strong wind gusts
    • The far end could be the same, apart from the use of a Linux module internally; after all there is nothing to lose from logging conditions concurrently at the farm house. Although, the components may split as the antenna would likely be mounted on a radio tower or windmill to make range
    • We can run cabling down to measure soil temperature and moisture; although my ideal would be for those sensors to be wireless connected somehow

    An important factor not obvious from the picture is the need to protect the electronics from full afternoon sun in late summer on 40+C days.

    So using an enclosure that might be double insulated, reflective, and the addition of shaders, and placement relative to the solar panel helping with that.

  • Murphy, inevitably

    pastcompute09/20/2015 at 10:52 0 comments

    So right at the time when everything needs to work. everything goes wrong.

    • The one and only wind gauge self destructed as I was attempting to wire it up. This is especially frustrating!
      Where I live, I cant just hop in the car and buy another part like that, Jaycar are 45 minutes away and don't carry those specialised parts, and I would not have time to even try and reverse engineer their weather stations, nor pay the money. Nearest arrival time would be Tuesday if I stumped up for express post. So that means going into the semi final submission we will be having to simulate wind. I'll probably just feed in data from the BOM past data. Its also annoying because I spent a day making an i2c slave using a ATtiny85 to be the interface to the wind gauge so the node can stay asleep instead of pulse counting.
    • I also purchased metal boxes that were too small and didn't get enough of various adaptors for SMA to BNC for antenna feeds. So ended up repurposing enclosures, so the whole thing looks dodgey again.
    • While attempting to tidy up the circuitry I damaged the ESP-201 module that was to be used with the deployment, and couldn't get the spare flashed. (Luckily, it turned out because I wired a jumper wrong.) So I spent Saturday getting the TeensyLC version finished off instead and had that working perfectly by 1am, along with mounting the Carambola2 base station.
    • But during the night the TeensyLC stopped. And hasn't flashed its LED since. So I now have a dead teensy. I'll need to contact the Hackaday store for advice on that one. So I had to go to the ESP-201 spare instead which I did get working.
    • Except the ESP now ran out of room in its flash as I added final touches, so spend more hours debugging and tweaking things to fit.
    • The ESP-201 after running flawlessly for months is now experiencing hangs requiring a push button reset after coming out of deep sleep. The main suspect is the humidity sensor which had only been integrated yesterday. But I am now stuck with it, humidity is one of the three critical ingredients of the Grass Fire Danger index.

    In spite of all the above, last thing I wanted was to give up this close to the end so keep pushing through, and we have a working system at the moment, used to produce the "operating" video.

    So we have a 1km shot logging weather data out in the paddock. In the photo below, the trees on the horizon is "the other end". Just try not to look at all the cable ties...

    After switching power from the laptop to the solar charger, it was a nervous 10 minute drive back to the house to check the logs. I could see activity on the serial LED but had no idea if the sensor had crashed or not...

    And behold, we had a live feed!

    Thus, all the ingredients needed to calculate Grass Fire Danger Index - pending wind, after perusing online electronics retailers next week - plus additional information pertaining to cropping, including daylight progression and solar UV.

  • Up towers and through scrub!

    pastcompute09/14/2015 at 12:10 1 comment

    Having already achieved our goal of reception at the distant end of the large test paddock we went for a drive.

    So remember yesterday, I mentioned a scrub plot 2km distant...

    I could get a signal through this! (note:beacon time was offset ~09:48 behind local time) The range to the transmitter is 2100m.

    [DBUG] RX rssi_pkt=-100 snr_pkt=-14 stat=38 sz=37 ptr=38 hdrcnt=564 pktcnt=534
    [RX] 37 bytes, crc=0 rssi=-100 DATA=54582042
    TX BEACON   6658 13-09-2015 06:56:00

    Well, we just got a signal; the RSSI was just on the edge. But with digital thats all you need.

    Just down the road, we met these felllers:

    unfortunately, my phone camera is not high quality - those brown splodges near the fence are Kangaroos.

    And we kept driving. After driving north a while, we lost the signal, not unexpectedly. So we took a right turn. After moving back into the beam coverage, we had signal again at 4100m, and kept driving. At our furthest range, still from the car, we finally logged the last beacon at 6100m. All this time, the only elevation on the receiver was me holding my arm up and out the car window! Remember, the transmitter was only 1m above the ground as well.

    Beyond that range, we needed a bit more help. A mound at the local club gained us some height, perhaps 3m. And another signal. Range: 7000m!

    As the map shows, all our reception was roughly in the expected beam of the transmitter. Which is fine!

    Finally, this is Australia, so we did what we had to do. Well, our intrepid farmer did, anyway, and climbed up the tower at his place. It took a bit of fiddling, because at this range with directional antenna the sensitivity is quite fine.

    But finally, several meters up, he was able to receive the beacon. At a grand distance of 9300m. Woot!

    So, the day exceeded our expectations completely. I was expecting to have to tweak the radio settings (increase bit error correction, lower bit rate) and require more elevation of the transmitter to get beyond a couple of K's. So those little inAir9 modules pack a punch!

  • Great weather for Fox Hunting at last...

    pastcompute09/13/2015 at 13:22 0 comments

    So today the local weather skipped right over spring and surged into summer, the dial in the car showing 30C, so we picked a great day to finally get out and see how well these inair9 radios would really work.

    Kim had a 915MHz PCB Yagi in his stash.

    We deployed this with a Sentrifarm module with the firmware modified to be a TX beacon. In this case it was a carambola2 with no sensors (or enclosure for that matter :-)

    Take note on the horizon, the long dark green patch in the left half is a scrub block about 2km away...

    Then we got in the car, using a Sentrifarm leaf node powered from my netbook and recording receipt of the beacon with timestamps and radio SNR data. Kim had a GPS logging on his laptop.

    As we drive along we hold the antenna out the window.

    Before we left, while I was still mucking around with last minute firmware tweaks, Kim made a high gain directional Yagi from brass and scrap wood & tape. He's pretty good with antennas!

    So we drove around the test paddock. It turns out the radios perform pretty well. We had signal all along the far side of the test paddock, not just directly in front of the TX beam, which we would have hoped, but way off of the edges.

    That green clump just to the right of the middle is the TX beacon site. And we were receiving the beacon just fine at this point. This was already a great result, around 1200m from the beacon.

    We could have packed up and gone home right now, well satisfied...

  • Another short term pivot

    pastcompute09/11/2015 at 12:06 0 comments

    A secondary aim was to experiment with a distributed smoke / hydrocarbon sensor. This is still on the cards but has been deferred to some future time as we need to give further thought to power / operational execution.

    The MQ2 smoke / hydrocarbon sensor has a 'heater' which needs to run for at least 3 minutes before values settle. The present design for the leaf nodes wakes up from deep sleep, reads sensors, performs an MQTT transaction over the radio and goes back to sleep within 30 seconds. Therefore using the MQ2 in the current configuration will impact on the amount of power used by the node.

    For the MQ2 to be useful as some kind of fire alert sensor it would need to be checked continuously as well. Logging smoke/gas at (say) 15 minute intervals would be of academic interest in charting progression of dust / smoke from afar bushfires or pollution but less exciting.

    Of course in-house smoke alarms can run off a 9V battery for years so there are ways and means of solving this problem, it just doesn't have to be done to meet the next video submission deadline.

    We'll hopefully still put an MQ2 on the radio tower, given there will be sufficient power there, just to see how it works.

  • First 24 hours of data

    pastcompute09/07/2015 at 13:32 0 comments

    Not really that interesting yet, other than it shows the BMP180 sensor and the microcontroller operating correctly.

  • The elbow is connected to the wrist bone...

    pastcompute09/06/2015 at 14:04 0 comments

    Finally. After a bit of a frustrating slog I have managed to sort out a scalable data logging and visualisation solution.

    I started by at OpenHAB and then EmonCMS, which both promised a lot, but I wanted something a bit turnkey, having spent so much time in the past wasting time learning about how to build and deploy software when I just wanted to use it; and I don't know if I was looking at the wrong tutorials or what, but I couldn't get traction on either of those with an MQTT feed after spending a couple of hours... then I stumbled over Grafana.

    Grafana is a a cool browser based app that provides nice visualisations on top of a graphite/carbon logging infrastructure and whisper datastore. The whole thing runs in a docker instance making it easy to experiment with and maintain. Whats really good is ti can take in other feeds as well as exporting data out and can have alerting functionality integrated as required.

    So finally, we have an end to end software and hardware stack:

    Microcontroller and sensors -> MQTT-SN over inAir9 LoRa 915MHz -> Embedded Linux with MQTT-SN/MQTT broker -> farm central logging on graphite with a nice and very customisable and flexible but also easy to use web interface

    I couldn't wait for a few hours to get a more interesting graph... will need to post one soon though :-)

  • Backend

    pastcompute09/04/2015 at 14:32 0 comments

    Been working on sorting out the back end for collecting all the data. We were originally looking at OpenHAB but I'm now looking at something called EmonCMS which looks like it might be slightly quicker to make it do what we want with charts and logging from MQTT for the next project milestone. Note that doesnt mean we wont use openhab either in the future. Ideally, Sentrifarm will be able to send data to either system by virtue of using MQTT.

    Along the way, I discovered docker. I'm impressed at how, once an image is built, how fast it is to modify it. It does a very good job of caching all the dependencies previously downloaded. So I was able to add in, then remove, modules from an EcomCMS instance in seconds. Why haven't I used this before!

View all 56 project logs

View all instructions

Enjoy this project?



shad0wca7 wrote 09/10/2015 at 10:12 point

This is great, excellent to see some new hardware in this area. We've been running a smart-agriculture project in the UK, I think we would have some similar stories to share!

  Are you sure? yes | no

pastcompute wrote 09/11/2015 at 12:43 point

Thanks. I'm waiting for summer down here, because thats when the real testing will begin...

  Are you sure? yes | no

Mitch wrote 09/10/2015 at 05:51 point

Are you thinking about replacing the Pi backbone? some considerations.

Also being from a watermelon farm in Broome WA, you can pick my mind anytime we ran high pressure drip tape on 300h, water source was bore water and we fertilised through the pressure system. We set up auto valves that run on a time table, and used long range RF.

  Are you sure? yes | no

pastcompute wrote 09/11/2015 at 12:12 point

Hi from SA. I am experimenting with both Rasperry Pi and Carambola2 an OpenWRT based board. Neither needs a lot of CPU grunt because we relay the data into a "proper" server in the house. Something like the parallella is cool (I play with GPU in my day job) but a bit overkill until/unless we find processing that can be distributed out. Thanks for the idea though!

  Are you sure? yes | no

wifiwaves wrote 06/08/2015 at 02:43 point

And Mr.14 is doing it without optical assistance, too. Ah, to be young again!

  Are you sure? yes | no

pastcompute wrote 06/08/2015 at 12:43 point

I deliberately went no smaller than 1206 resistors and capacitors so I'd be able to see them!

  Are you sure? yes | no

wifiwaves wrote 06/13/2015 at 21:39 point "old guys" LOL

I drop something on the floor these's gone! When working on projects with tiny parts these days I allocate 10% for "droppers". I'm *so* much happier when I can just pick up another one and keep going.  =)

  Are you sure? yes | no

stormeporm wrote 05/22/2015 at 09:43 point

Have you considered using Mikrotik sxt's?

There dirt cheap and its easy to cover 20 km with it.

The versions with usb (I think all of them have it accept the lite versions) you can connect serial over usb.

And you can create wifi al over the place if you want.

It's not as cheap or lean as your current build, just wanted to let you know.

  Are you sure? yes | no

pastcompute wrote 05/23/2015 at 10:14 point

thx for that.
Part of our entry though is to not just get the price down but also the power usage, and using the LoRa module gets a long way towards that. And of course we need GPIO for sensors and I couldn't confirm OpenWRT support for that device either.

I do know of people using similar things from Ubiquity(?) for private wide-LANs though.

  Are you sure? yes | no

stormeporm wrote 05/23/2015 at 10:26 point

The power usage is certainly a lot higher on the sxt's (7w). Its possible to get the GPIO by using an arduino on the usb. It is possible to run openwrt on the mikrotik but in a virtual machine

Still not trying to convince you just letting you know ;)

  Are you sure? yes | no

srainsdon wrote 05/08/2015 at 05:57 point

if you went with linux at the stations you could do the mesh idea what is the distences your looking at.

  Are you sure? yes | no

pastcompute wrote 05/23/2015 at 10:15 point

The Carambola2 I am currently using runs openWRT linux :-)

As does the and we are also considering a build for Raspberry Pi

  Are you sure? yes | no

pastcompute wrote 05/23/2015 at 10:15 point

The Carambola2 I am currently using runs openWRT linux :-)

As does the and we are also considering a build for Raspberry Pi

  Are you sure? yes | no

Angeliki Beyko wrote 03/29/2015 at 17:42 point

Very interesting and specific real world problem you've chosen. The communication involved in this sounds challenging. Love it as an app idea.

  Are you sure? yes | no

pastcompute wrote 03/31/2015 at 10:32 point

Thanks! The RF will almost certainly be the hardest bit to get right, lots of fine tuning to maximse range

  Are you sure? yes | no

pastcompute wrote 03/21/2015 at 13:22 point

Thanks for that, I'm going to take a closer look

  Are you sure? yes | no

Eivol Ekdal wrote 03/20/2015 at 11:04 point

I am playing with ESP8266s as well and looking to power mine with this ready made module...

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates