Close

Does this project spark your interest?

Become a member to follow this project and don't miss any updates

Honeybee Hive Monitoring

Recording weight, hive temperature, and weather data toward better management and understanding of honeybees.

19 60 45
Enjoy this project?
Share on twitter   Share on Facebook

This project was created on 07/03/2014 and last updated 20 hours ago.

Description
The goal of this project is to build a system that records data from a beehive at roughly 5 minute intervals for later analysis. Data will include temperature, humidity and weight of a beehive as well as temperature, rainfall and other data from a weather station.

This data will be used primarily to track nectar collection to let me know when the bees need additional boxes for honey storage. I'm also hoping that patterns in the measured data will correlate strongly with problems like diseases, hive swarming or the death of the laying queen that could allow me to take quick action to correct problems in the future.
Details

Motivation

I have four little kids and a full time job, so I don't get out to the apiary as often as I'd like. I keep the hives healthy, but they do occasionally fill up most of their available space with nectar and slow down collection before I can get out there to add more boxes. This problem isn't unique to me -- any beekeeper with remote apiaries has to weigh the possibility that a sudden, strong nectar flow has filled up their hives against the time it takes to drive out and make an inspection. Measuring weight alone will eliminate this problem as I'll know exactly how much nectar is coming in and I can make a quick trip to add supers (honey collection boxes) when the nectar is flowing fast while spreading out my trips when the nectar is coming in slowly.

Additionally, NASA has a HoneyBeeNet program that relies on volunteers to manually record the hive weight every day so the local nectar flows can be correlated with satellite measurements of climate change and land use changes. Unfortunately, my hives are all installed at remote apiaries, and I can't visit them every day. 

I want to contribute to NASA's HoneyBeeNet program, save myself unnecessary trips out to the apiary, and frankly, I want to collect gobs of data from the hives to see what I might learn about easily detectable signs that something might be wrong.

First Prototype

I tried to document a lot of my work over the last couple years on my blog, hackerbee.com, although I'll repeat a more concise (and uninterrupted) version here with the massive benefit of hindsight.

First, I purchased a range of scales and started ripping them apart to see how I could get them to meet my needs. I was very new to hacking electronics at this point, so I thought it would be easier to connect to a cheap scale than to try to build a scale from scratch. Unfortunately, I ran into kept running into black potted chips on anything cheaper than the ADAMS CPWplus 200, which costs $163 at Amazon.

If I knew everything I've learned in the past 3 years, I would have gone a much different route from the start, but I finally settled on an CPWplus 200 scale. While it has a easily hackable serial interface, I found that the scale is designed to tare (zero) on powerup, and since I need to run the system at a remote apiary on a battery with solar, I badly wanted to turn off the scale between measurements!

Eventually, I gave up on turning off the scale and simply oversized the solar panel and battery to make up the difference. I added an Arduino Fio with XBee to stream the data back to Thingspeak.com over a nearby internet connection.

I successfully streamed data from a beehive to Thingspeak.com for about a week last spring before my buggy coding of the wireless connection started getting interrupted. Unfortunately, I didn't have the foresight to add an SD card to backup the data, and between life and work, I didn't have time to get it working again last year.

I knew that the load cells would be significantly sensitive to temperature, and this original data was quite noisy as I hadn't yet been able to calibrate the scale for temperature. Here's a sample of some data I collected while the system was working. I removed the temperature sensitivity with a regression analysis after the fact, so this data is somewhat questionable, but it shows what I expect to see once I've got a properly calibrated scale working.


Beehive Monitoring System Design

Here's my plans for the current beehive monitoring system. Instead of trying to rely on firmware that was designed for a postal scale and doesn't allow easy power management, I'll measure the load cells directly with a 24-bit ADC. The output of the HX711 ADC board will be read by the Apitronics Bee unit and, along with a temperature sensor inside the bee hive, sent to the Apitronics Hive that saves the data. I'll also be streaming the logged data to a cloud service so I can monitor my hives in real time!

I've chosen 200 kg (440 lbs) as a load limit for...

Read more »

Project logs
  • Foiled by Drivers!

    20 hours ago • 0 comments

    I've got everything ready to integrate. I should be able to just slip the HX711 board into a Apitronics Bee enclosure, and bogde has written a lovely, open source HX711 driver with examples here, but the Apitronics Bee firmware has drivers that simplify programming a bit TOO much. Back when I was taking C++ classes, this wouldn't be a problem, but I've forgotten too much to just slip a new sensor into the BeeCore firmware (even sloppily).

    That's not the end of this project! I'm sure the Apitronics folks will help me get it working when they have time, and I could probably figure it out within 2-3 weeks on my own, but this might be as far as I get by a week from now, September 29, the Semifinal deadline for the Hackaday Prize.

    I'm going to keep plugging away, and I'll update the rest of this project page to reflect my current progress.

    In case anybody wants to help with the programming on short notice, I'll describe what I think needs to happen.

    In the HX711 example (here) I want to use the function "scale.get_units(10)" to get the average of 10 measurements from the HX711 board. I think this function needs to be written into a driver, along with the definition of HX711.DOUT and HX711.PD_SCK using this function, "HX711 scale(A1, A0);"

    The firmware on the Apitronics Bee will be a modified "BeeCore" and the HX711 driver needs to follow the form of the other sensors, for example the WeatherPlug.

    The current code is as follows from BeeCore (I'll want to add a 3rd sensor, the HX711):

    Sensor * sensor[] = {&onboardTemp, &batteryGauge};
    Sensorhub sensorhub(sensor,NUM_SENSORS);
    #define NUM_SENSORS 2

    Finally, here's the code in void loop() that actually samples the sensors. It's been so simplified by the drivers that I can't just slip in a number at the end of an array. I really appreciate the programming work here, I'm just over my head trying to learn or re-learn (sometimes it's hard to tell which) how to modify it to do what I want.

    //this if statement just samples
    if( clock.triggeredByA1() || buttonPressed || firstRun){
    Serial.println("Sampling sensors");
    sensorhub.sample(true);
    clock.setAlarm1Delta(0,15);

  • Modifying the HX711 Breakout Board for 3.3V operation

    6 days ago • 0 comments

    I had a great project update ready this weekend, but when I stopped working on it for a while to attend to real life, my computer decided to reboot (even though I have it set to manual update only!). I suppose that's the price for using an alpha service like this that doesn't allow draft updates!

    Anyway, I'll give an abbreviated update (and I'll probably add some more minor updates instead of trying to write out complete little articles). 

    As I mentioned before, the HX711 breakout boards I've found work at 5V. That's fine for many applications, but the Apitronics Bees run at 3.3V, and for the prototype, I don't want to mess with other voltages. This will cut the resolution of the system since the signal from a load cell scales linearly with the excitation voltage whereas the noise floor is likely to stay roughly constant. However, adding a higher voltage (probably 10-12V just to energize the load cell presents another set of complications. The resolution is technically going to be higher, but without really careful engineering, the temperature sensitivity could get out of hand if the 10V regulator drifted relative to the 3.3V regulator in the Apitronics Bee, or worse, the 1.25V voltage reference in the HX711 chip. 

    I'd rather lose sensitivity in my early prototype than have additional complex temperature coefficients, so I'm going to just drop the HX711 excitation voltage to 3.3V for now.

    Another, less temperature-sensitive method would be to run the board at 5V (the HX711 chip can't take more than 5.5V) and simply use a level shifter board to get the signal back to the Apitronics Bee, but again, if I can manage to do this prototype without adding more regulators and breakout boards, I'll keep it simple at the expense of some resolution.

    Here's a picture of my breakout board showing the resistor that needs to be swapped out with a 12k resistor to drop the excitation voltage (E+ to E-) from 4.35V down to around 3.1V (at least 0.1V below the input voltage of 3.3V). This is based on the equation in the HX71`1 datasheet that gives voltage as VAVDD=VBG*(R1+R2)/ R1. Note that this equation in the datasheet is wrong and gets the simple voltage divider backwards -- R1 and R2 should be swapped either in the equation or in figure 1 (!) to get near the measured 4.35V  rather than well under 2V.

    A quick calculation (with the error corrected) shows that swapping the 20k Ohm resistor (R12 on the board and on the schematic here) with a 12k Ohm resistor should drop the voltage to 3.1V. I pulled out my trusty soldering iron and Voila, the voltage dropped to 3.14V, just as expected!

    Another quick note: while this breakout board is usually marketed as a 5V board (mainly due to the values of R12 and R13, there's no reason it won't work at 3.3V since the HX711 is well within specification at that voltage. I'll admit, it's possible there's something I haven't thought of that will cause a problem when I hook it up to the lower voltage, but I'll give it a quick test with a protected voltage supply before hooking it up to the Apitronics Bee.

  • Choosing the HX711 over the MCP3551

    a month ago • 0 comments

    Frankly, the choice of high resolution ADC was primarily due to my having trouble with PIC programming! I had a program that was very close to what I needed, and I could trigger the MCP3551 to take a measurement and verify that the data was being sent back to the PIC with a logic analyzer, but I just couldn't get the PIC to read the data, and I didn't have the hours of dedicated debug time to find the solution.

    Here's a video showing the board I designed in KiCAD to hold a PIC microcontroller and the MCP3551 (as well as various regulators and connectors) along with the HX711 board I am ultimately working with now.

    https://www.youtube.com/watch?v=KBpizvyYi9U

View all 8 project logs

Discussions

lister wrote a month ago null point

If you're concerned about noise, there's a shielded version of the ebay HX711 breakouts too, about $1 more. Not sure if it will improve your measurements though.

Have you considered getting rid of the arduino and just using another BBB to simplify? This is the route I ended up taking since it's cheaper and simpler. The logic supply wifi adapters work well w/ bbb are cheap and you can use directional antennas. I hope to read the HX711 from BBB, but have not set this up yet, there is some github code using the RPi though.

I'm using a $20 Amazon Ravpower 5V supply w/ the bbb and get about 4-5 days of runtime blinking some leds. This pack can be charged while discharging too - solar panel should work fine. The cells are easily replaceable samsung 18650's
I know nothing about bees, so these suggestion may not work for your setup.

Are you sure? [yes] / [no]

Ken Meyer wrote 5 days ago null point

I looked at that shielded version, and it looks like they just added a little metal box over the board. Frankly I don't expect electrical noise to dominate the error, and if it does, the 4 wires leading to the load cell will act as much better antennas as anything directly on the board! There are filter caps on the load cell power and signal lines, so I suspect a little metal box won't change much. In terms of noise, I'm mainly talking about the signal to noise ratio. The chip is a 24-bit ADC, but I don't expect to get more than 18-20 bits of useful resolution due to noise -- partly avoidable with really good engineering, but partly unavoidable thermal noise.

The BBB eats up WAY too much power, hundreds of milliamps vs. the handful of milliamps the Apitronics Bees consume in normal (sleep-heavy) operation. It's absolutely possible to oversize the solar panels to handle that, and I'm sure there are tricks that could reduce the BBB power consumption somewhat, but for remote applications on solar panels, I think the BBB is a bad choice unless you absolutely need the computational power for some reason.

The 5V supply you talk about could last nearly forever powering the Bees, except that it will freeze in the winter and be destroyed during charging. Worse, those supplies usually have a minimum current draw of around 50mA, so while the capacity could power a Bee for weeks or months, in reality, it would just turn off after a few seconds assuming that nothing was plugged in!

Are you sure? [yes] / [no]

Christoph wrote a month ago null point

Congratulations! You made it!

Are you sure? [yes] / [no]

Greg Kennedy wrote a month ago null point

Your most recent project log video is set to private : (
http://youtu.be/dTJbZSmWTlI

Are you sure? [yes] / [no]

Ken Meyer wrote a month ago null point

Thanks for pointing it out! I had some trouble last night getting the file uploaded, and while I fixed the link in the project links, apparently I forgot to fix the project log!

Here's the correct link: https://www.youtube.com/watch?v=KBpizvyYi9U

Are you sure? [yes] / [no]

Christoph wrote a month ago null point

Hey Ken, I just read your project log about getting good data from the scale, and how the operating environment might impact them. A long-term drift measurement in an environment with changing temperature would certainly not be hard to to set up, but very enlightening. Couldn't sorting this out in a separate project be very useful to others as well, not just beekeepers?

Are you sure? [yes] / [no]

Ken Meyer wrote a month ago null point

Hey Christoph!

First, I want to comment on your terminology. Long term drift IS a major concern because the load cell will subtly deform over long periods even within its rated load (if overloaded, it will also "drift" but the drift may be less subtle). Load cells are specified at a maximum drift over 30 minutes, but since I'll be using them for years, this could become a major factor in long-term reliability. Practically it won't affect my ability to see when honey is coming in, but if I want accurate measurements, it may require monthly (or weekly?) calibration. I'm hoping that the drift slows and nearly stops after a few days or a week, but I haven't tested it yet.

To your specific point about temperature, I do think this could be useful to anyone looking for high accuracy data logging! However, in most cases, the scale can be tared before use, eliminating at least half of the error (that from drift of the zero point), and any scale used indoors will experience only very minor temperature fluctuations. A very easy way to improve the resolution of a load cell is to simply reduce the range, but in this case, I'm limited by the potential full weight of a beehive, so I don't have that option.

More generally, any circuit or measurement device will experience variation with large temperature changes, so the process of temperature compensation may be useful to someone else who's trying to measure something outside year round. Even for someone with a strained relationship with math, it's really pretty easy to take data at 3-5 temperatures with a known weight and get a compensation factor that can be added to the datalogger's firmware. I'm wary that drift in the circuit or load cell could cause the compensation factor to change, so I may test the compensation once a year or so, but as before, this is only necessary to get precise accuracy over the full range of conditions. In almost all hobbyist cases, it's probably enough to be aware of the rough magnitude of the source of error and to simply design experiments that don't require such high precision over such a wide range of conditions.

Are you sure? [yes] / [no]

Christoph wrote a month ago null point

Ken, commenting on your comment on my terminology: Now that I re-read my comment, it was not clear in the point you are addressing. Let me re-phrase it:

Setting up a separate experiment (besides you beehives) for getting compensation data for the load cells would certainly not be hard to set up. That way you can take measurements with your hives far away from home and have a second project whose purpose is to get the errors corrected. I'm well aware of long-term drift and my point was to have a closer look at that without disturbing the bees. When that is done, you can correct your already collected data from the bee hives - so no wasted measurements.

Actually I had a look at industrial load cells today and they are very expensive. Coming up with a good hacked alternative would be a cool project, I'm now looking into that.

Are you sure? [yes] / [no]

Ken Meyer wrote a month ago null point

It seems weird to me that I can't reply to your reply...

Anyway, I got 10 of these 200kg load cells from aliexpress, and while I haven't tested them beyond getting a signal out, they look very well made. I obviously have some questions about their specifications, but at $30 each, they're not too pricey!

http://www.aliexpress.com/snapshot/271417700.html

The 5-10x markup for purchasing from a reliable company is certainly worth the cost if you absolutely need to hit specifications, but it's not remotely worth the added price to me when I'm trying to build a low-cost scale for each of my hives!

Are you sure? [yes] / [no]

Christoph wrote a month ago null point

Indeed the ones you found are way cheaper than what I've found here in the industrial range, and they will probably suffice. So that would be 1 load cell with 200 kg full scale range for each apiary?

Are you sure? [yes] / [no]

Ken Meyer wrote 19 days ago null point

An apiary is a collection of hives, and honestly, I don't think one monitored hive is enough since there are so many variables that could influence nectar collection. If you meant one per hive though, yes, it'd just take one load cell per hive.

The scale frame should be designed to reject side loads (probably touching down if pushed toward any side) since these load cells can be damaged, ESPECIALLY in commercial use where glued-together, 50+lb boxes (glued with the bee's propolis, made from tree sap) are being jerked around. Frankly, a commercial design might require a higher max limit load cell to prevent damage from shocks, but I'm betting that as a careful and slow hobbyist, I can get away with a lower damage threshold to get higher resolution.

Are you sure? [yes] / [no]

Adam Fabio wrote 2 months ago null point

Hi Ken! Thanks for entering The Hackaday Prize! I really love the way you've used low cost materials where possible - like that electronic scale. Way cheaper to use one of those than an industrial load cell! Don't forget about the 2 minute video for the first round of competition. I wish you sweet success on your way to space!

Are you sure? [yes] / [no]

Ken Meyer wrote 2 months ago null point

Thanks Adam! The apitronics system is overkill for a system with minimal cost, but I badly want a full streaming system working reliably before I try to gut it and demonstrate lowest cost options for simple datalogging and simple GSM transmission.

Yesterday I talked to a guy who just wants the data saved to an SD card he can swap out each time he visits the hive. Once I get this system working, I'll make him one of those easily in time for the spring start of beekeeping season.

Are you sure? [yes] / [no]

Eric Tsai wrote 3 months ago null point

Hello fellow Twin Cities resident,
Very cool project. I like the practicality of it. I also like the Apitronics kickstarter and Louis Thiery's commitment to open source. Very good project - good in the sense of generosity.

If you ever have a need to add more sensors here and there, feel free to contact me. I might be able to help you. I'm an Arduino user, and my project is actually very similar to the Apitronics project. We're both using Arduino as field nodes communicating with a SBC, in my case I'm using a Raspberry Pi. And we have free reign over what sensors to mount on the field Arduino node. A program running on the Raspberry Pi provides the interface to show you current sensor data, as well as the capability to push data out to Xively or whatever cloud telemetrics service you might be using for data collection and charting. I don't have any bees, so I'm monitoring my garage temperature/humidity. But it's the same idea.

How far away are you from your bee hives?

Are you sure? [yes] / [no]

Ken Meyer wrote 2 months ago null point

I'm about 45 minutes away from both my apiaries, one over by Wisconsin and another to the north.

I'll have to build an OpenHAB system at my house once I get the beehives wired up and running reliably. I'll definitely spend some quality time reading through your blog for ideas!

Are you sure? [yes] / [no]

johannesgj wrote 3 months ago null point

I will try to spread the word in denmark and see if the local bee hive communities want to collab on data gathering.

Are you sure? [yes] / [no]

Ken Meyer wrote 3 months ago null point

That's awesome! I've been in touch with a commercial beekeeper in Australia who is interested in a simpler GSM version that texts the weight once a day, and which I think is very possible with basic components like Arduinos, and could work reasonably well without temperature compensation to track trends and allow a beekeeper to know when to drive out a few hours to their remote apiary to add room for honey collection.

I try to be very up-front with people that my pace of development is very slow due to my work and family responsibilities, but once I have a working system, and especially if your local beekeepers can collaborate with local electronics hobbyists, this weight tracking should be quite straightforward on a range of budgets.

Are you sure? [yes] / [no]

johannesgj wrote 3 months ago null point

This project can have an outstanding collective impact on our ecosystem. Bee death is everywhere. Thanks for keeping an eye on them :-)

Are you sure? [yes] / [no]

Ken Meyer wrote 3 months ago null point

I agree, it's an important issue, and even worse than with honeybees, there are countless native pollinators that aren't being closely tracked, but are likely just as susceptible to growing use of new pesticides!

I honestly don't think bees are going to suddenly go extinct, but almond pollination prices have tripled in the last decade, largely because it's getting harder and harder to keep hives alive over the winter.

As an engineer, I'm convinced that we simply need more data, and while I can't afford to attempt randomized experiments on dozens of hives at multiple locations, I CAN work on helping beekeepers like me to collect and analyze data from their hives!

Are you sure? [yes] / [no]