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 hackaday.io chat. They did everything to convince me it's a natural cause. I'm looking at you @Morning.Star and @anfractuosity :)

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

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

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!

---------- more ----------

Update 21.02.2019 - Bees are having brood again!

The data was in before we looked into the hive and it made one thing clear: The queen started laying eggs again. The pink curve is all straight again with an average of about 34°C, which is the optimum for the brood.

The green peaks are sunlight on the outside sensor. The last few days were like early spring, so the bees went out, cleaning the hive and collecting water and pollen!

They started caring about the other "alleys" too, which can be seen by the rising temperatures of the orange and yellow charts.

Data at www.inhivedatalogging.com now with an rolling average (bottom left corner). The number means: show the average over xx timesteps (which are 5 minutes here). So a "30" averages/smoothens the data by averaging over 30x5 minutes...

Update 02.02.2019 - Position of the winter cluster.

The pic shows where the bees are in the hive right now. Position hasn't changes much from the beginning, they're still cuddling in the back right corner of the box (standing in front of the box).

Measured data backs the position and it's good to see them alive and buzzing!

---------- more ----------

Update 25.01.2019

Collecting the data from the winter cluster is really fascinating! You can scroll and zoom through the data here! There are interesting things going on (see below for sensor position to grasp, what's going on where in the hive).

First thing to mention is the spikes in the outside temperature, marked CYAN: Those boggled my mind a lot as they always appear around noon. Around 11:30 in November, around 12:30 in January.

Those are caused by the sun, hitting the hive around that time. The case lid is clear, the stuff inside mostly black. That's where the spike comes from.

Second, around Dec. 2, marked YELLOW: The hive temperature stopped being a constant 32 to 33°C and started to fluctuate a lot.

Third thing and this really blows me away, though it's known for decades now. The spikes in Comb1/2, marked RED, are what I wanted to see first person with my bees: The bees try to keep their cluster around 20 to 24°C most of the time, but on a regular basis, they start moving their muscles, heating up and reaching a pretty comfortable 30°C very quickly. Temperature goes down as quickly as it reached the maximum though.

Other interesting facts: They don't heat the rest of the hive. T3/T4 are close to the outside temperature, though the chart is a bit dampened and doesn't reach the minimum outside temperatures.

-7°C was the coldest night so far and they're still pretty vital, YAY!

Update 01.12.2018

Just a quick picture to show you that you can easily see where the bees are in a hive, without opening the box or reading sensor data:

Where there's stuff on the white board there are bees above in the combs :)

The bees already went to one corner/side inside the hive. They do this when weather gets colder to keep each other and a bit of food warm. This is called the winter cluster. Temperatures are quite warm for November, but the full cluster will soon assemble when outside temperature drops much more.

The picture shows where I put my sensors for winter logging plus a quick key in the lower left corner.

I hope to record the typical behavior of the bees in winter, which is a periodical active heating of the cluster with a following phase of doing not much at all while letting the temperature drop again.

When they used all their food on the rightmost combs, they will move their cluster more to the left. They gradually warm their honey to be able to get it out of their cells and consume it. I think the data will clearly show this next year.

Logging interval is every 5 minutes, logging started November, 6th, 2018 at 17:05.

Sensors: T1 to T3 DS18B20, T4 Si7051, H1 Si7051.

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!

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!

Update 08.10.18 - Yep, data shows sensor was glued shut

Have a look at that:

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

Today I needed to remove the sensors from the bee hive because we treat the bees with formic acid (see log before) for a week now. I guess at least the Si7021 would corrode and die from this.

This is how the breakout board looked today. It was really tightly glued to the wooden frames by the bees. As mentioned earlier they tend to close every hole and fixate everything dangling around by applying wax and or propolis (also called bee glue).

The white rectangle is the PTFE filter-sticker which keeps water out of the sensor. I need to ask myself how reliable the last months of data are because they added a thin layer of wax over the filter sheet too...

This is the backside of the sensor:

UnI removed everything, it's really sticky stuff:

Unfortunately, I ripped the protection cover off too but managed to stick it back on.
BTW: this is how the sensor looked 5 months ago :)

Update 12.11.2018

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

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:

It's this time of the year again. To not have lots of dead bee colonies next year, the beekeepers have to help the bees fighting the mighty varroa mite.

We do this by vaporizing formic acid in each hive. Most of the bees survive this (a few very young and very old ones can't handle the vapors and die), the food they have left gets slightly contaminated but isn't used for honey production anyway.

We add a tray with some kind of blotting paper, which wicks the formic acid and evaporates it over the next week.

The mites die and the bees brush them off of each other. To count the mites we add a so called diaper or nappy/napkin under the hive:

The mites (and other stuff) falls onto this sheet so we can estimate by counting the dead mites how much the hive is affected by them.

We'll know more in about one week from now.

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.

Intro

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:

intToFloat(readLOG.temp1)

 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).

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.

Situation is as follows:

Putting the board into powerDown mode without the SD inserted does exactly that: Power down. Current consumption 1.6µA.

When using the SD, doing a few test writes, closing the file etc. and turning it off by pulling low the EN pin of the TPS27082 sleep current consumption is always 75µA.

When I pull the SD out it drops to the 1.6µA mentioned above. Following pic is the integrated high-side switch I control the SD power with:

And the uSD socket:
Now the strange thing is: I measure 0V at VCC_SD sockets pin when the card is not inserted (exactly what should happen), but 2.8 something Volt when I insert it. So, the SD seems to "feed back" voltage into the output of the TPS27082. Where does it get the voltage from?
I tried pulling up/low all respective lines to no avail. Minimum current consumption I get is always 75µA when the SD is in its slot. The moment I take it out it drops to 1.6µA.

Tried different brands and cards. Checked all the circuits and soldering numerous times.
I measured the following voltages in powerDown mode

The last thing the SPI port does are the 8 cycles of the CLK pin:
So, I guess the table tells me I need to pull MOSI and CS low before turniing the SD VCC off, right? I think I tried that already, but I'll try again and report back.

In the meanwhile: Do you have any other ideas?!

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:

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

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!

After two months of the logger being "in the wild" I can estimate how much the circuit drains from the batteries.

It's been a steady 0.1V/month for two months now. At the moment the 3xAA batteries dial in at 4.33V (didn't measure each single value). The logger stops operating at 3.6V.

So if everything stays the same, I should get another 6 to 7 months of logging. Of course some other factors come into play here:

• battery voltage is higher in hot weather conditions
• ability to deliver higher currents (SD open/-writes...) goes down with lowering battery voltage

But I expect only about 4 to 5 more months before I change the batteries for fall/winter logging because the above reasons.

I'll get another V1.2 logger out by then, so I can compare them after the winter period.

Stay tuned!