Project Logs

Collapse

• The "mystery" of the temperature peaks solved

  Jan • 02/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 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.
  
  

• Logging in a winter cluster

  Jan • 11/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

  Jan • 10/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!
  

  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

  Jan • 10/05/2018 at 13:36 • 0 comments

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

  Read more »

• Fighting varroa mites

  Jan • 10/05/2018 at 12:58 • 0 comments

  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:
  

  
  
  

  Read more »

• Saving precious EEPROM space

  Jan • 08/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.
  

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

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

  Jan • 08/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

  Jan • 07/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:

  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

  Jan • 07/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 ✔

  Jan • 06/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