µPower (beehive) SD logger

Let's observe an emerging beehive throughout the year 2018! (And create an logger from scratch for that purpose)

Similar projects worth following
We build a low power micro SD logger. Operational life > 3 years on 3 AAA or 1 18650 li-ion cell.
EEPROM-backed and precision-timestamped with a DS3231 RTC.

Latest updates:
Sensors after 5 months in a bee hive

There are many loggers out there of which I wanted to put as many features in my own design as possible. My main inspiration and an awesome source is the cave pearl project by @Edward Mallon. Thanks for putting all your findings on the internet and sparking my interest in long-term-logging!

So, what do I want to log? BEEEEEES! My father is a beekeeper and so I really wanted to log the climate in one of the beehives all year round.

Power consumption of V1.2

  • sleep mode: 0.0018mA (1.8µA)
  • logging to EEPROM: 5mA average when reading sensors and writing logs to the EEPROM
  • SD-backup mode: 50mA average when transferring logs from EEPROM to SD card.
  • Estimated battery life (single 18650 2400mA cell, logging for 500ms every 15 minutes): > 3 years


  • low power consumption by:
    1. SD card power ON/OFF via high side switch (TPS2051B)
      • V1.2: TPS27082
    2. ultra low drop/quiescent current regulator (choose one)
      • MCP1700: input voltage max 6V
      • MCP1703: input voltage max 16V
    3. low frequency (8Mhz, even works without external quartz/resonator)
  • up to two EEPROMs with max 2Mbit each
    • 512Kbit EEPROM example: stores 3220 logs of 5 floats plus timestamp
  • easy to use push-connect terminals
  • voltage sensing via resistor divider
  • dual color LED for signal purposes
  • PCB outline (85x 55mm) with mostly SMD parts
    • fits exactly in water tight RND 455-00133 case (100x100x55mm)

As I wanted to use KiCAD a little more anyway (and due to the needed features see above) I did not just buy cheap chinese knock-off board off eBay but designed my own board. I sent it to @oshpark as I didn't need 10 of those boards, plus the last boards from another chinese manufacturer (though only hot air solder leveled) were kind of hard to solder.

So here it is: my go at long-term logging the climate in one of my fathers beehives!

As usual I'd like to thank all the fine persons who write libraries and software for everyone else to use free of charge, especially:

Fixed version of my V1.2. THIS board works as expected. Footprint for the MCP1700/MCP1703 corrected.

x-zip-compressed - 2.16 MB - 06/09/2018 at 17:42



We've got a wasp hive nearby, which eat many of those dead or close to dead bees laying in front of the hives. They are quite picky and only cut out the stuff from the torso!

MPEG-4 Video - 35.26 MB - 06/03/2018 at 13:37


28.04.18 1030 to 05.05.18 1035 Interval 1 Minute.csv

First week of logs. Interval was 1 Minute, not 15 as I thought...So I now have very detailed data of 9700 data points to work with!

Comma-Separated Values - 388.57 kB - 05/05/2018 at 08:59


OSHPark ready KiCAD4.0.7 files (and Gerbers) including two annoying bugs fixed

x-zip-compressed - 1.78 MB - 05/02/2018 at 16:11



Version running on first deployed unit (28.04.2018)

x-zip-compressed - 27.36 kB - 05/02/2018 at 16:01


View all 6 files

  • The "mystery" of the temperature peaks solved

    Jan02/03/2019 at 12:25 2 comments

    So, in the last update I mentioned strange temperature peaks on some days around noon in the outer temperature chart.

    It jumped from -7°C to +9°C (green line) here:

    What made me wonder is the small peak before the main peak. I thought this can't be a environmental cause then.

    But today I managed to get to the hives on a cold but sunny day. Turns out, it's been the sun :)

    The small peak before is because the sun finds a small gap between the houses surrounding ours to shine on the outer sensor. Then, a shadow shades the sensor for a longer period and after that the sun shines on the sensor for quite a while.

    By the way: thanks to the people in the chat. They did everything to convince me it's a natural cause. I'm looking at you @Morning.Star and @anfractuosity :)

    shadow on the sensor, moving to the right
    sunshine responsible for the bigger peak

    On another note, we moved the hive to the later position in summer. Here's how the stand looks like after moving it:

    That light brown stuff is the bees waste. It's exactly where the winter cluster sits.
    position set for summer

    The new position will be in direct sunlight a bit later, so the peak (if any) will move to a later time each day.

  • Logging in a winter cluster

    Jan11/06/2018 at 18:21 0 comments

    Update 22.02.2019 - back to "spring mode"

    Bees just "dissolved" their winter cluster and went back to 5 or 6 combs to care for their brood etc. See Update from February 2nd to see the difference!

    Read more »

  • Data visualization with dygraphs

    Jan10/07/2018 at 15:07 0 comments

    Today I sat down and did my first steps in html/css. My aim was to not publish pre-rendered graphs anymore but to just append new data to a csv-file and let the browser render it for me. It even is kind of interactive!

    click to get to my github-page
    click to get to my github-page

    I set up a quick github page and got it working pretty quickly. It's just noch finished yet, but it basically does what I want.

    Updates coming!

  • Sensors after 5 months in a bee hive

    Jan10/05/2018 at 13:36 0 comments

    Update 08.10.18 - Yep, data shows sensor was glued shut

    Have a look at that:

    65% RH all day long? reason see pictures below!

    For context: Look at the pictures below. Data clearly shows what the bees did to the sensor :)

    Read more »

  • Fighting varroa mites

    Jan10/05/2018 at 12:58 0 comments

    Update 12.11.2018

    Totally forgot to show you what effect the formic acid has:

    varroa mites (dark brown shiny slightly oval looking spots)

    The dark spots are those mites, they die, fall off of the bees and down onto the marked squares. We count them and can estimate how affected the hive is/was. If you don't do this (of course a few bees die too), your hive will most likely die.

    If you can't spot them (I won't blame you!) here's two of them circled:

    Read more »

  • Saving precious EEPROM space

    Jan08/05/2018 at 10:37 4 comments

    Tl;dr: Use this trick if you need to save space and don't need more than one decimal precision. Save >60% more logs using the same EEPROM.


    Okay, using a 512Kbit EEPROM isn't exactly the reason to save space. After all it stores 3120 data entries which consist of timestamp and 4 float values. Reminder: the internal EEPROM of the Atmega328P is 1024 bytes only. Using that, the following might come in handy.

    But can we get more out of it? Yep:

    It's a small trick which works if we need only precision to one decimal e.g. 25.3°C or 67.9% RH.

    Floats use 4 bytes (but are much more precise of course), integers do need 2 bytes in EEPROM.

    Let's assume we just shift the decimal point of 25.3(°C) to the right. We get 253, which is easily stored as an integer. Same with negative values. I use the following function to store my floats as integers (and convert them back to float):

    #define floatToInt(x) (int)(x*10)
    #define intToFloat(x) (float)(x/10.0)

     Here's my data structure I use to save log entries:

    typedef struct
      uint8_t tag;
      uint8_t monat;
      uint8_t jahr;
      uint8_t stunde;
      uint8_t minuten;
      int temp1;
      int temp2;
      int temp3;
      uint16_t feucht1;
    } logEintrag;
    logEintrag LOG;

     When I get my values from the sensors I just write them to the struct like this:

    LOG.temp1 = floatToInt(25.3);

    Of course 25.3 is some variable I access directly.

    When reading back the logs to write them to the SD as a CSV string I j´convert them back on the fly:


     Works like a charm, with negative values as well. It takes a few processor cycles more but now the EEPROM holds 5041 instead of 3120 logs, which is 61,5% more!

    Want to save even more logs?

    Other things to optimize would include:

    1. saving the year-value only once and then again, when it changes
      1. savings: 1 byte
    2. same with months
    3. (...)

    This would need more code to handle that when creating the CSV entries which are saved to SD. Doing this with year and month would get you close to 6000 entries or over two months of data in EEPROM (and thus not switching on the power hungry SD in two months).

  • Switching off SD DOES work - 1.8µA in sleep mode ✔

    Jan08/02/2018 at 17:58 2 comments

    Edit - 04.08.2018

    A hint from @K.C. Lee together with my own findings helped making it work. The SD seemed to bleed voltage from either or all of the pins which were still high after turning off the VCC of the SD card. 

    Switching these all off after turning off SPI comm. worked. Quiescent power consumption is now 1.8uA.

    Read more »

  • EEPROM and SD write times

    Jan07/28/2018 at 15:10 0 comments

    My new program takes shape slowly. After all it's quite hot here with some days over 35°C, which we don't get too often in Germany...

    Anyway, I switched from putting together the CSV string directly in EEPROM to a struct which has all the values in it. This saves a lot of space. With my 512Kb 24LC512 I can save 3120 log entries with 21 bytes each. This is more than a whole month without switching on the SD card while still taking 4 readings per hour. As there's space for two EEPROMS on the PCB, I theoretically could put two M24M02 2Mbit chips which would give me >4 months of data storage. These are quite expensive though...

    The human readable strings are put together on the fly when the EEPROM is full and everything needs to be written to the SD. I tried two methods:

    1. writing each value, separator, value, separator...
    2. making a whole string from it before writing to the SD

    Method 2 is much faster, so I used that.

    Writing to the EEPROM is between 3 and 5 milliseconds per LOG, which is not of interest to me as this doesn't need much power and is done only 96x/day as part of the sensor-reading, wake-up etc routine.

    What is of interest are SD write times:

    It takes close to 18 seconds to read the (whole) EEPROMs content, convert it to CSV and save it to the SD card. I do not use optimized write routines like writing full blocks/raw data.

    I don't care about that at this point, because writing to the SD for say 20 seconds once a month is perfectly fine. The logger is off @ 75 to 85µA idle power consumption for 99.88% of the day anyway!

    Using totally conservative numbers, I should get way over one year of battery life:

    Oregon embedded battery calculator

    I have a post about using C++ structs and unions as a draft, but it's not yet ready. Stay tuned!

  • Energy consumption of V1.1

    Jan07/06/2018 at 10:10 0 comments

    Edit 07.07.18 - voltage drift of single cells in a battery pack?

    It is often mentioned using a single Li-Ion or LiPo cell is better technique, because of 2 or more AA cells one will die sooner than the others.

    I bought Ansmann industrial cells for my loggers, which had no difference in cell voltage out of the box.

    It's exactly like that after 2 months: Two cells are 1.439V, one is 1.440V. So everything's in perfect condition!

    Read more »

  • V1.2 current consumption: 73µA ✔

    Jan06/16/2018 at 16:20 0 comments

    Update 29.07.18 - current consumption without SD

    This won't surprise most of you, but the SD card makes up for like 99% of the power-down current consumption...

    Current draw is <2µA in sleep mode when no SD is present. So I'm going to add the high-side switch again and do my tests/code rewrites till I manage to turn the SD off. On/off itself is just one line of code, but re-initializing the SD after power-off isn't exactly supported by the library. Seems to work for others, so I'll give it a shot.
    Hardware-side of things is done by soldering the framed components and moving the solder bridge from # to *:

    Read more »

View all 23 project logs

Enjoy this project?


Discussions wrote 07/10/2018 at 10:06 point

Hi your monitoring system for beehive is impressive. I have just got a Nuc of Bees myself and would also like to monitor my hive. Do you have the latest version of your code for the logger V1.2 or > ?

Keep up the great work


  Are you sure? yes | no

Jan wrote 07/10/2018 at 10:46 point

Hey there! I just began optimizing the code. But it's not even close to be done yet. The new code will be optimized in many aspects. The 512kbit EEPROM will hold 3040 data entries (4 floats incl time stamp) for example...

Anyway, I can't promise you a finish date for the complete code yet. Working on it! Just write me a PM if I can help you with something

  Are you sure? yes | no

Vishnu Mohanan wrote 04/23/2018 at 19:26 point

Cool project and nice PCB.

  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