Forgot your password? Please contact us!
Both diagrams contain data from Summer (June/July), the main harvest season of the honey bee. First, a short description of the diagrams above:
In both charts the weight of the hive is plotted (vertical axis) and they both contain the data of two weeks (horizontal axis). The chart of the first hive (FKG) reveals a steady decrease of about half a kilogram in two weeks. During the same time interval, the weight of the second hive (GSC) rises by five kilograms. Interestingly, the weight always decreases during nighttime and the morning hours, while at the end of the day, the peak weight is higher than the day before.
A short explanation of these charts: Looking only at the GSC hive, the nightly weight decrease shows that the bees also need nourishment during this time. Therefore, they use some of the collected honey and the weight of the hive decreases. In the morning, many of the bees leave the hive for collecting nectar. This results in a steep decrease in weight and even allows an estimate of the number of field bees.
But this doesn’t explain the decrease in weight of the FKG hive. In fact, the data results from an intense infestation of the colony with varroa mites. This has two severe consequences for the colony. Firstly: The total number of bees decreases, since varroa mites mostly affect the brood and infested bees prefer to die outside of the hive to prevent passing the mites on to other bees. Secondly, the varroa mite severely damages the wings of the bees, resulting in a lower number of field bees. Thus, only very few nectar is acquired.
Therefore, the continuous decrease in weight of the FKG hive strongly suggests an infestation with varroa mites.
These charts are highly interesting from a scientific point of view and they show as well the advantage of having comparable E-Hives.
Our data poses a lot of interesting scientific questions. We invite you to work with the data of the eHives to discuss questions like the ones above. If you have any questions regarding this, just contact us.
To present our project to the wider public, multiple members of BeeBIT e.V. attended the Renewable Energy Day on 30.04.2016 in Würzburg. At this science fair, multiple projects on nature, technology, and sustainability were presented. The BeeBIT booth attracted visitors with a honey tasting, a model of the eHive, multiple posters, a short feature film about the project, selected school papers by senior graders and, thanks to support by the Environmental Agency of Würzburg, a memory game for children on bees.
Despite the difficulty of presenting the project and its possibilities in education and research to the visitors, we had a lot of fascinating tanks. A special "Thank You" to the senior graders from FKG and DHG high schools that contributed to the booth, and to the Environmental Agency.
At the beginning of 2016 our self-developed circuit board was kindly manufactured by Schneider Electric free of charge. The board mainly is used to provide 6 different voltage levels which are necessary for properly operating the sensors. Furthermore, it converts analog signals into digital ones. This must be done quite precisely because small differences result in huge aberrations. Regarding the scales for example, a voltage drift of 0.000002V is equivalent to a 10g difference in weight. Furthermore, several sensors for system surveillance are included, such as charging voltage, two current sensors and the barometer. 13 of the 24 produced circuit boards are in use now. 8 of the remaining ones are anticipated to be sold in the coming month and years.
Basically, BeeBIT establishes a network of several clients, one per bee box, which collect sensor data and send it to a central server. The central server stores the data in a database which is connected to the internet to enable a wide range of applications.
As for the clients, we use an Arduino Due to collect the data. In the aftermath, we partially regret our decision to have chosen such a device; on the one hand, it simplifies access to some obvious Features, but sometimes Blocks or at least hinders the use of some more complex and subtle functions of the microprocessor. For example, as we wanted to query the temperature sensor of the microcontroller, we had to access the specific component directly, because the Arduino abstraction did not implement such a feature. And of course, our implementation is not compatible with Arduino’s one. So, for small projects, the Arduino might have been the perfect choice, but in our case, it made things harder.
In the recent time, we have implemented some revolutionary Features on the Arduino you might also be interested in (I’ll describe them here in a hopefully high level form. If you are interested in a more technical explanation, you can contact us directly.
Well, this is one of the more obvious ones. It is easy to implement a library, right? But we developed our own way of encryption: Each, server and the clients, got their own keys and they basically generate temporary keys to communicate with each other. We can easily authenticate and authorize our clients at the server, and the encryption has shown to only lead to small performance issues about every 30 minutes when client and server exchange new keys to communicate with each other.
As you might know, the Arduino GSM library does only work for AVR-based chips which the Arduino Due is not. So we had to develop an own version of it (it only Features internet, no SMS or call functionality is planned to be implemented, as we don’t really need it; we wanted to develop a library from scratch, because the Arduino GSM library felt a bit too bulky, we thought), we are currently tweaking it a bit.
This was maybe the biggest challenge in developing the software: How to update the software of the Arduino without plugging it to a computer, so we can automatically distribute updates? Well, we did it! We just write the data from some position in our flash storage to the position where the program is executed, and we do this all from RAM. Then we just reset the microcontroller. It sounds really easy when described in such a high level way, but there is hardly any resources on this topic (specifically when you try to update an Arduino…) except from the datasheet and some additional notes by the manufacturer.
The best part about it: The update is independent from the type of internet connection (GSM or Ethernet) and is also encrypted to secure the network even further. The code used for the update might also work on other Atmel-ARM-SoCs, at least on those that include the RSTC and EFC controllers.
But we not only made some progress with client software (by the way, we are currently recording data experimentally, using the GSM library and the encryption and successfully sent some updates). We also tweaked the server software and the database and added a live diagram which is still in an early stage of development. With it, you will are able to display the data in a way which not only computer scientists can understand. It is developed as a responsive website, so it is fully functional on most devices, from smartphone to desktop. You can view up to eight different sensors at once and scroll through all our test data. As mentioned previously, we already translated it into six languages, more to follow. Pretty cool, isn’t it? You will even be able to see when new data comes in approximately every ten minutes! By the way, you can find it here: Diagram. Have fun! If you have any suggestions for improvements or found a bug, please contact us.
After we revised the circuit diagram and the layout of the PCB, two prototypes were produced in September. The boards were ordered by an external company and manually assembled by us with nearly 90 parts and over 400 soldering joints. The SMD parts were reflow soldered. First, the solder paste was dabbed on the pads of the board and then it was populated. After all, the whole PCB with the components sticking on it was heated till the solder paste melted. The through-hole components were soldered with a soldering iron, what needs to be done in this way later as well, because in the regular soldering process, the wave soldering, too much solder would be deposited at the pins, which must fit into the Arduino. The SMD parts will be assembled later by a pick-and-place machine.
One of the two prototypes is in use at the Umweltstation Würzburg right now.