Create a global network of sensors to detect insecticides suspected as harmful to bees.

Similar projects worth following
Bees. Kinda important for human food production, right? I thought maybe I'd create a small, 3D printable bee-replacement 'bot, but that's just a band-aid on a bigger problem. Let's find out where the chemicals are, and get that data in the hands of the public. These are wi-fi enabled detectors which tweet location and toxicity.


As an open source project makers the world over can build and operate the device and automatically participate in the global measurement of the health of our bee populations.

1. Get neonicotinoids concentration via a sensor at a bee hive entrance, from a sensor where groundwater passes, or direct hive pollen samples.

2. Tweet Concentration, Time, Location for analysis to a central @account.

3. Data is then available to all for inspection. 

4. Crazy-Goal: Audio fingerprint wingbeat sounds of each individual bee to provide local population counts and possibly measure changes to colony members wing beat patterns potentially related to poisoning. 

Questions that may be answered:

Are my bees ok?

Are there chemicals here that shouldn't be?

Is there a correlation between detection and population size and health?

Parts List:

Power: Solar/LiPo

Brains: Arduino Yun (base station) & RF Receiver

Remote sensor: Trinket / ATtiny85 & RF Transmitter

Detector: Not yet sourced (see Links for possible sensor development)

Location / Time: GPS

Construction Notes

Single Master: A single Arduino Yun connects directly to the sensors and to wifi.

Multi Master model:

Arduino Yun; WiFi to the 'tubes (ie twitter)

RF 433 MHz receiver (to receive data from remotes deployed in the field at some distance from wifi)

Remote Pinout (ATtin85, adaptable to the Trinket):

RST1     8Vcc

Why use a Trinket? For the effort, it's simpler and cheaper as it has onboard USB, as compared to using a bare Atmel '85. After all, we want to make this easy to build and program!

Sensor(s): I2C Based

Option: I2C Based FRAM for logging storage and more infrequent transmission

ENA: Power up sensors, transmitter (MOSFET controlled voltage regulator) and GPS.

TX: Serial output to transmitter (ie 433 MHz)

GPS: Serial input

Theory of Operation

Assuming deployment of multiple remotes at distances too far for wifi, remotes use inexpensive RF serial links transmit on a schedule to prevent collisions. For example remote1 would transmit only at 5 minutes after the hour, remote2 at 10 minutes after the hour, and so on. Remotes are GPS enabled, so they keep accurate time. This also means that remotes can be moved and they will report data with accurate position information without setup.

The Arduino Yun acts as a bridge, receiving the RF serial data, validating it, and then sending it via wifi to a central service (ie a centralized twitter account). This also may be used to extend the distance somewhat from the wireless base station/router.

  • A Detector?

    Noel Dodd06/17/2015 at 16:47 0 comments

    The tough part of this project is that it lacked an actual sensor - but this might be changing soon.

    Check out the June 2015 news here: and keep your fingers crossed!

    Do I think we'll get a $5 IC sensor out of this? Probably not - at least at first. But I could see something like an inexpensive I2C based device one day. The key is that it has to be inexpensive enough to get into Makers hands, and to get a LOT of them out there.

    With IoT dev boards integrating wireless and support for the Arduino IDE & Libraries it seems like this could boil down to something as simple as an Autonomo, battery, solar panel, and some wiring :)

  • Radios... Radios... Radios...

    Noel Dodd01/20/2015 at 22:35 0 comments

    The last little while I've been tinkering with the RF24 library for those inexpensive Nordic based radios. Pretty neat. The hardest part has actually been getting a Processing sketch to parse the serial stream in a stable way; ie not chopping off a 32 byte packet at random places. I think the easy answer is to just stream a bunch of data into a buffer until a no-receive window happens, then parse the buffer.



    Seems (under OSX Yosemite / Processing 2.2.1, at least) that serial data arrives in 48 byte blobs from the driver. Nice.

    I also switched to sending a start character trigger, and at 250000 bps a typical send (32 bytes/packet x 32 packets = 1024 bytes) takes at least 42ms, but occasionally up to 73ms, but 50ms seems about right.

    I also discovered that one of the odd things that was fouling up processing was a weird behavior of the control.p5 library; it was causing a long delay at the end of every loop() pass.

View all 2 project logs

Enjoy this project?



zakqwy wrote 08/01/2014 at 17:05 point
The sensor is crucial to this project; I'm fascinated to see what you discover in your research. This project is incredibly important!

  Are you sure? yes | no

Ken Meyer wrote 07/08/2014 at 08:44 point
I'd love to add this to my beehive monitoring system if you ever get a sensor that will work to sample air at the entrance to a beehive! It'd have to be sensitive enough to measure traces of insecticides in the air, but as long as it's not incredibly expensive to implement for a year (I'd pay up to around $100, it'd be more successful around $10), even a single-use disposable sensor could yield fascinating results!

Here's my project page on
And my blog:

  Are you sure? yes | no

Adam Fabio wrote 07/03/2014 at 05:23 point
Bees are incredibly important to the survival of so many crops - this is a great project Noel! Thank you for entering The Hackaday Prize! The bismuth electrode research sounds pretty darn intersting - I can't wait to see what you come up with! Try to get some photos and documents up as soon as you can, as they help with the weekly votes.

  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