ECE497 Project - Grainbin Monitor

Jump to: navigation, search

thumb‎ Embedded Linux Class by Mark A. Yoder

Team members: Thad J. Hughes

Grading Template

I'm using the following template to grade. Each slot is 10 points. 0 = Missing, 5=OK, 10=Wow!

00 Executive Summary
00 Installation Instructions 
00 User Instructions
00 Highlights
00 Theory of Operation
00 Work Breakdown
00 Future Work
00 Conclusions
00 Demo
00 Late

Score: /100

(Inline Comment)

Executive Summary

This will monitor the level on grain bins so a farmer can see how much more room there is remotely, and will also alert them (via text, phone call, or push notification to a smartphone) if overflow is imminent. It is cost-effective (sub-$100) and portable as opposed to other solutions which are permanent installation and quite costly.

Code repository:


This has ended up being a proof of concept for a unit which is POE connected (since grain bins are effectively faraday cages, Wi-Fi onboard will likely not work), dust-proof, and magnetically attached with a steel tether for retrieval. This will focus on the electronics and software side.

Error creating thumbnail: File with dimensions greater than 12.5 MP
Overall view of the device

Code Installation Instructions

Put the code from the repo into /root/granular/, and then run the script. Reboot the bone.

User Instructions

Plug the device in with power-over-ethernet. Connect with the Blynk app. Set the alarm threshold, and arm notifications.


The Blynk app/view

- Live reading of data - Running-average filter for distance readings - Push notifications for alarms - Adjustable alarm threshold

Theory of Operation

This will use an ultrasonic or laser distance sensor (or a few of them) to measure distance from the unit to grain. From this and a known (user-specified) bin diameter, the bushels left can be approximated (with angle of repose being roughly the same as the bin's roof). Notifications could be accomplished with SMS systems, and monitoring with Blynk; other implementations also exist.

A MB7092 XL-MaxSonar-WRMA1 sensor is used, with serial (RS-232) communication. This sensor is cheap, available, weather-resistant, and measures up to 25 feet (not the full height of a grain bin- but it measures the range that is of interest).

`The baud rate is 9600, 8 bits, no parity, with one stop bit.`

This means it must be setup as: `stty -F /dev/ttyO1 cs8 -parenb -cstopb`

However this is RS232 "from 0 to Vcc", not TTL. So this isn't quite so plug-and-play, but can be easily made to work with an inverter- and it does!


The inverter was prototyped with an NPN transistor. This seems to work well in receiving serial data from the sensor. The sensor is a little "wonky" but it does detect large surfaces rather well.

I made a protoboard with the relevant components on it- the inverter circuit, and current-limiting resistors for LEDS- that plugs into the P9 header of the bone.

Schematic of breakout board
Breakout board for Beaglebone

I also made an enclosure for the device. Whatever material I made it out of doesn't mill very well... nylon would have been a better choice, but that's what I get for dumpster diving.

The device is wired up such that it takes power-over-ethernet (at 6-25VDC). This way it can be wired like typical Ubiquiti devices which many farms use as their networking solution of choice. The POE is unregulated (bumped down to 5V at the device) because with long CAT5 cable runs there can be very high voltage drops.

Regulator and heatsink used for POE

After wiring the POE, I'm starting to have my bone spontaneously shut off after a minute of uptime. This could be related to the power regulator, since the 7805 chip was not heat-sunk and upon investigation, was getting quite hot. After heat-sinking the 7805 chip, everything seems to be OK.

I wired up a Ubiquity airRouter to act as a wireless bridge- and this works with the RHIT-OPEN network, but needs to be re-connected at every location since it connects to networks based not on SSID but by broadcast ID (a transmitter-specific ID). The ethernet worked out-of-the-box with no further setup necessary.

I wrote a python script that uses threading - the main thread handles Blynk communication, and a separate thread polls the sensor and filters its readings. These readings are pushed automatically to the Blynk server, and if the threshold is ever met, a notification is sent out.


Ultrasonic sensors are kinda weird things. But this is definitely viable! The sensor selected is good at detecting large objects- but this is exactly what we need. I've left the device to run for a day, which shows that it will work.

Blynk has its limitations for a very generic application- perhaps running my own Blynk server and using the API and writing an android app would be a better route for rich (and intrusive) notifications.

thumb‎ Embedded Linux Class by Mark A. Yoder