Fermentation controller

Projects
Participants	Algoldor, Justa
Skills	electronics, Biology, Brewing, Coding, Construction, Making, Open source projects, PCB Design, UI design
Status	Planning
Niche	Electronics
Purpose	Fun

QUICK NOTE

If you are here for information about firmware/development of the PCB-version of the incubator as sold on CCC Camp2015, please:

- Find info below (to be updated/completed) - Join the mailinglist to be kept up to date about developments AND to be able to contact us in case of issues/problems/etc. - The mailinglist can be joined by:

• Sending an empty mail to incubator-subscribe@lists.foodhackingbase.org
• Reading the mail you get back, asking for confirmation of your address.

We endevour to get everyone a working and useful device!

Outline

Prototype measuring temperature

The fermentation controller has been a longstanding item on the wishlist of Fermentation-god [Frantisek Apfelbeck] of [Tastebridge]/[Noisebridge] fame. The goal is to have a simple to construct device that will manage fermenting a number of products; managing the aspects involved such as temperature control, timing, etc.

One of the specific goals is to implement one that supports heat-cycles where one keeps the fermentation-batch at different temperatures for periods of time to ensure that, in a multi-species culture, each species will have a time for optimal growth.

Other aims are to ensure easy construction , safe operation and ease-of-use.

Basic requirements

The device is primarly engaged in timing and controling temperature within a preferably insulated enclosed space containing a batch of liquid. Direct heating and/or cooling of liquid is assumed but perhaps not guaranteed.

The operation of the device should be field-adjustable. As such it requires a way of providing feed-back on the device and allowing for input of parameters or adjustments of settings.

It would be good to have a way of storing presets on the device for easy re-use, as well as preservation of operational settings during power-down.

Since the device is involved with controlling temperature , it requires both a device to measure temperature as well as a device to control it. For our current purposes, it is assumed that keeping the temperature high enough is the basic design challenge, but optional cooling-devices should be kept in mind as well.

Given that the heating of larger batches of liquids might well involve greater amounts of power than is easily feasible through low-voltage devices, the need for a safe way to drive HVAC currents might be introduced.

Since the device involves controlling temperature in 'cycles' , it is obvious it will require an accurate way to time it's operation. Since the device could concievably undergo power-cuts due to deployment on renewable and unreliable power-sources such as solar or wind-power. Having the device 'forget' how far it is into it's operation would mean an almost guaranteed failure of the fermentation-batch.

With the above in mind; the device could concretely consist of:

• A microcontroller with enough IO for driving the below peripherals as well as internal or external eeprom-memory for storing settings/presets.
• A/some temperature-measurement peripheral(s)
• A display device of some kind with accompanying set of inputs.
  • A graphical LCD or character LCD
  • A set of buttons in cursor-layout and/or rotary encoders or joystick could all serve as inputs
  • Alternatively; one could replace or augment the onboard input/output through means of using an existing and commonly available communication-device as input/settings controller and display. Think smartphone + Bluetooth/wifi
• A way to heat things; preferably liquids. Immersion-heaters come to mind. Either 12V or 110/220VAC should be considered; keeping options open for easy adjustment of existing design to fit specific needs
• An option to add a cooling device. Either through the means of air-displacement and/or evaporation, or more brute-force approaches such as peltier and/or refrigeration-units.
• An immersible, rugged and food-safe way to measure the temperature of a gas, liquid or perhaps solid attached to the fermentation-product. It should be able to survive the usual range of temperatures from -20 to +100 or so, and be accurate within the range of 5 to 50 degrees celsius.
• Unless realized through means of battery-backup and brown-out protection, the device might benefit greatly from having a small dedicated-purpose battery-assisted real-time-clock module onboard to preserve the device's sense of time.

Basic prototype

Considerations

With the above requirements in mind and the wish to have a platform that's easy for me and others to develop/prototype for, I have chosen to take the basic 'Everything is an arduino, unless specified otherwise' approach. Using that guideline, it becomes easy to have whole sections of the hardware-requirements covered with full support in the development-environment used. Arduino has a large number of well-supported peripherals available to it, despite it's further flaws. Also, the arduino environment and language is well understood by many , making it easy to find references and assistance when stuck on a particular part of things.

Given that the Arduino is basically an AVR Atmega168/328 with some power-select logic and , often, a USB->Serial convertor onboard, the choice of further peripherals must come with a number of considerations in mind:

• They preferably use 5Volts as a working voltage
• They interface through one of the available buses on the AVR; SPI, I2C or even serial.
• The perhaps come in easily acquired pre-made 'shields' available for the Arduino, if at a cost low enough to warrant not simply making one yourself.
• The AVR has the benefit of containing built-in EEPROM memory, usable for storing settings/etc.

Parts ordered

Parts for my current 'working draft prototype' have been ordered and shipped by now and should be underway. Most of them have been acquired through [DealeXtreme] An overview of the parts I intend to use:

• [Some Arduino Board ] Approx $15
• [An LCD and Keypad shield for Arduino ] $6.90 A real bargain given that it solves user interaction in one fell swoop. 16x2, 6 buttons for input in extended cursor-pad layout.
• [An Arduino prototyping shield] $2.30 Makes for easy interfacing to Arduino IO-pins and add extra onboard peripherals as well as connectors to off-board devices.
• [An DS18B20-based temperature probe] $5.90 Not cheap, but totally foolproof to work with. Great for first prototypes, can later be retooled into calibrated PT100 setup or otherwise.
• [A solid-state relay for HVAC] $6.70 These make safely interfacing with HVAC a problem that anyone can easily and safely implement; taking the pain out of having to do your own opto-isolation and creating a seperate PSU for the isolated HVAC-related switching circuit.
• [An RTC (real-time-clock) module based on the DS1302] $3.60 Battery-backuped, precise, cheap. Comes with an extra 31x8 bits of backuped RAM; perhaps saving the EEPROM-flash from getting written too often. Yet to be purchased, however.
• Various and miscellaneous bits of hardware; think plugs, sockets, powercords, wire-terminals, pinstrips, resistors, diodes, etc. Perhaps MOS-FET for driving fan or other low-voltage peripherals.

Parts received; evaluation

The order from DX.com came in and there's a number of things to note:

• The [Arduino prototyping shield] doesnt seem to be able to support stacking shields with. The pin-rows on the top are too close together to allow another shield to be stuck into this one again. Perhaps there's a simple work-around possible with an adapter-board, but it seems it's just a shame. However....
• the [LCD and Keypad shield] is well worth it's money. It seems a blatant ripoff/remake of [the DFRobot lcd/keypad shield] and seems perfect for the job. The amount of [pins it uses] is limited to 7 digital pins and 1 analog pin, of which one digital pin controls the backlight and could be freed. The shield has a number of other arduino-pins linked through on the top and makes them accessible on a pin-headers for easily adding prototype-boards 'on the sides'; fixing the problem with the proto-shield in the bullet-point above. The DFrobot page shows how to make it work with several libraries and how to read out the button-states. One button is connected to 'reset', however.. which is weird.
• the [ds18b20 temperature probes] that I ordered are perfect for the job. They are more sensitive/precise than the normal DS18S20's that are used a lot; some trickery is required to convert the higher-precision digital output to a celsius/fahrenheit value. Work is underway. Attention must also be given to the 4.7Kohm resistor that must be added between +5V and the data-line of the probe (pullup) or it will not work.

Prototype status so far

When adding the LCD-shield shield onto the arduino and soldering the temperature probe to a free digital pin on the headers, it was easy enough to load some sample code into the arduino to display the temperature from the tempsensor. Conversion of digital values to the right celsius-value was not directly clear. A little more research is required but shouldnt be hard. My next efforts will concentrate on adding two 'wings' on the edges of the LCD-shield to mount connectors for the relay(s), temp-sensor(s), etc. After that, the next part is the hard part: designing software based on specs. I think the main challenge is to design an interface-style that works well with just 2 lines of 16 characters. Bar-graphs can be made with [=========-----] characters... etc. It would be good to look at some existing LCD-based projects to see how they handle this.

Progress Feb4; 2013

While reviewing the available options with regards to menu's and LCD-panels I stumbled upon [MENWIZ] which provides a simple and procedural way to create (nested) menu-structures and allow you to navigate through them with 4/6-button interface or even override some controls with self-implemented controls (like rotary encoders, etc). This is especially handy as the chosen LCD-pad currently uses an analog input and thus requires overrides.

Another great thing is that it provides a way of driving the LCD via i2c/serial as well; it comes with an improved version of LiquidCrystal that is more efficient and has some nice addons.

And to top it all off; the library also takes the pain out of device-resets and saving parameters by providing built-in management for them with EEPROM support. Great for this device. I will start to experiment with this library soon.

Meanwhile, the difference between the DS18S20 and DS18B20 has been ironed out.

Code to differentiate between the two:

if ( !ds.search(addr)) {
      Serial.print("No more addresses.\n");
      ds.reset_search();
      return;
  }

  Serial.print("R=");
  for( i = 0; i < 8; i++) {
    Serial.print(addr[i], HEX);
    Serial.print(" ");
  }

  if ( OneWire::crc8( addr, 7) != addr[7]) {
      Serial.print("CRC is not valid!\n");
      return;
  }

  if ( addr[0] == 0x10) {
      Serial.print("Device is a DS18S20 family device.\n");
  }
  else if ( addr[0] == 0x28) {
      Serial.print("Device is a DS18B20 family device.\n");
  }
  else {
      Serial.print("Device family is not recognized: 0x");
      Serial.println(addr[0],HEX);
      return;
  }

Code to retreive data from the device (the 'sketchpad') for DS18B20 and print to serial:

LowByte = data[0];
  HighByte = data[1];
  TReading = (HighByte << 8) + LowByte;
  SignBit = TReading & 0x8000;  // test most sig bit
  if (SignBit) // negative
  {
    TReading = (TReading ^ 0xffff) + 1; // 2's comp
  }
  Tc_100 = (6 * TReading) + TReading / 4;    // multiply by (100 * 0.0625) or 6.25

  Whole = Tc_100 / 100;  // separate off the whole and fractional portions
  Fract = Tc_100 % 100;


  if (SignBit) // If its negative
  {
     Serial.print("-");
  }
  Serial.print(Whole);
  Serial.print(".");
  if (Fract < 10)
  {
     Serial.print("0");
  }
  Serial.print(Fract);

  Serial.print("\n");

Code to do the same for DS18S20 and write to LCD:

present = ds.reset();
    ds.select(addr[sensor]);    
    ds.write(0xBE);         // Read Scratchpad

    for ( i = 0; i < 9; i++) 
    {           // we need 9 bytes
      data[i] = ds.read();
    }

    LowByte = data[0];
    HighByte = data[1];
    TReading = (HighByte << 8) + LowByte;
    SignBit = TReading & 0x8000;  // test most sig bit
    if (SignBit) // negative
    {
      TReading = (TReading ^ 0xffff) + 1; // 2's comp
    }
    Tc_100 = (TReading*100/2);    

    Whole = Tc_100 / 100;  // separate off the whole and fractional portions
    Fract = Tc_100 % 100;

    sprintf(buf, "%d:%c%d.%d\337C     ",sensor,SignBit ? '-' : '+', Whole, Fract < 10 ? 0 : Fract);

    lcd.setCursor(0,sensor%LCD_HEIGHT);
    lcd.print(buf);

The trick is to integrate them both into one method and create a generic 'fetch temperature' method that'll provide the Celsius temperature of a given probe-id. The probe-id can be selected in a menu; configured (what input, what type (analog ? one-wire ?..etc) and assigned a task.. etc. This way the fetch_temp() has only to be extended with extra functionality when different types of sensors get added to the device's functionality.

Upcoming: picture of the device measuring temperature Done

Update Feb 28, 2013

I have since acquired a number of stacking-headers meant to be used for creating perfectly stackable shields for the arduino. The set was quite expensive, €5,00 to be exact, but it allowed me to solder them into one of the proto-boards that I had and then allow the LCD-shield to push into that shield in turn.

What this means is that the original idea of adding connectors , etc, on the proto-shield is back on track and I can continue on that road.

I hope to create a first test of this soon.

Update March 15, 2013 (Algoldor)

16:15 FAA: I went through the list of items necessary for the prototyping on the experimental incubator project. I am creating my own list to order which I would like to ask others to comment on and update it because I'm beginner and I have seen that Arnd have found some "not so good options already".

Importantly I'm preparing a proposal for an electronic laboratory for a project here in Jeju so the parts for the experimental incubator would be actually incorporated in it. I wonder what would be best option to share this list so it can be updated by others, maybe Google file? Will post about that within next two hours or so. The next meeting where I propose the community electronic lab build up will be held on Tuesday 19th of March, so I have around three days to make a nice list, till now I was using the list above from Arnd and the list here for a basic info.

Sincerely FAA

17:15 FAA: I have finished the basic proposal for the electronic lab parts and the experimental incubator parts and shared it as a Google spread sheet with the fallowing share link

https://docs.google.com/spreadsheet/ccc?key=0AoI1FSp-qkEWdERyYzQ1UzZ1UXBMenJxVl9Ta0NYU3c&usp=sharing

It would be great if you could go through that and check out what am I missing for both the electronic lab and the incubator project. I'm aiming for +- $600 budget for the electronic lab and +-$150 for the incubator at least for the moment. I will be presenting the proposal next week on Tuesday 19th of March.

Many thanks for tips etc.

Sincerely,

FAA

Circuit overview and discussion

Basic Overview

The basic setup currently consists of:

• A basic old-style arduino.cc Arduino like the UNO or Demilanove.. or whatever. Something with a 328 should be fine.
• A [DFRobot LCD/Keypad shield]
• One or two DS18B20 [OneWire] temperature sensors.
• A [DS1307 I2C RealTimeClock module] with Battery Backup for knowing what [time] it is/was. It also contains a 24C32 32-KBIT (4KiB) memory for storing settings/fermentation-programmes if we choose to not use the eeprom of the arduino itself.
• And a set of outputs used to drive the heater and/or peltier element via the use of a Solid State Relay

What the Arduino can do

The Arduino is a specific prototyping board based on the Atmega-8 series microprocessors. The old-style boards like the UNO expose a total of:

• 14 Digital IO -pins
  • of which D0 and D1 are used for Serial already
  • there are 6 PWM-outputs available on pin D3,D5,D6,D9,D10 and D11
  • there is an SPI-bus available on pin D10, D11, D12 and D13 (4 wire)

• 6 Analog IO pins
  • Analog inputs have a max of 1024 (10bit) resolution. typically used between 0 and 5 volt.
  • the Two-Wire-Bus (AKA: i2c) controller uses pin A4 (SDA) and A5 (clock)

What pins we need/want

With that in mind, it becomes important to look at how to connect everything that we want to connect. The DF-robot board uses:

• Analog pin A0 for reading the status of the buttons
• Digital pins D4, D5, D6, D7 to write nibbles (4bits) to the LCD-unit on D4, D5, D6, D7
• Digital D8 is 'RS' on LCD
• Ditital D9 is 'Enable' and might be made optional if 'ENABLE' can be held at a fixed level OR we can re-use D4->D7 by using 'enable' to NOT have the LCD listen to them when controlling other things
• Digital D1 is 'Backlight control' and could be strapped to GND or VCC, depending on what's desired.

The DS1302 unit is an I2C-based device and is most easily hooked up to A4 and A5

Then we need at least one output (preferably two) for the SSR's And we need one (or two) digital pins for communication to the one-wire based temperature-probes. There is no way to 'strap' them to a different address on the bus as far as I can see (a feature often seen in I2C devices), so making two buses might be the simplest.

An overview of pins used

An overview of Arduino/Atmega328 pinouts

The following table then emerges:

• D0: Serial RX
• D1: Serial TX
• D2: SSR1
• D3: SSR2
• D4: LCD D4
• D5: LCD D5
• D6: LCD D6
• D7: LCD D7
• D8: LCD RS
• D9: LCD 'Enable' (might be optional)
• D10: LCD backlight control (might be made optional)
• D11: One-wire bus 1 (first temp-probe)
• D12: One-wire bus 2 (second temp-probe)
• D13: Free (see note below about LCD and buttons)

• A0: LCD Buttons
• A1: Free
• A2: Free
• A3: Free
• A4: I2C SDA-line for DS1307
• A5: I2C SCL-line for DS1307

This leaves one digital pin free in a 'plain and simple way' of connecting two SSR's and two temperature-probes. We could free up two digital pins with the LCD, even more if we move it to an I2C-based way connecting it (saves another 2 to 3 wires, I believe), at the expense of more code/parts. As it is, it's not required for what we want to achieve with the device right now.

A note about the buttons on the LCD-panel

There is only one extra consideration concerning the LCD-shield. It has six buttons of which 5 are connected via resistors so they can be read out via A0. The sixth button is directly connected to the RESET line of the Arduino. Pressing it resets the device and makes the sketch run anew. I think it will be required to find a way how to connect the sixth button to A0 via a resistor too OR connect it to a free digital pin (D13) directly. This will also make navigating through menus (and coding the menus) easier. There are a number of libraries out there for LCD-menu's that either use 4 or 6 buttons; not 5 ;)

How to hook it up using the prototype-PCB-shield

The prototype shield is a convenient way of tapping the right signals between the Arduino and the LCD-shield and 'splicing them out' to some connector/screw-terminal for connecting the sensors/SSR's to.

• The SSR's are easy connect using a simple two-pins screw-terminal.
  • One pin connected to D2/D3 and the other pin connected to GND
• The one-wire probes can be hooked up in 'parasite' mode (2 wire) or normal mode (3 wire). It is easiest to use 3-wire mode in our case.
  • You can use a three-pin 'stereo headphone plug' or a screw-terminal with 3 screws.
  • When using a stereo-headphone , make the 'tip' be "+5", the first ring "signal" and the base "GND"
  • A 4.7KOhm resistor is required between +5V and the 'Signal' line on each of the two one-wire buses, functioning as a "pullup resistor"
• The I2C DS1307 RTC can be housed directly onboard the prototype PCB.
  • It has two communication-lines that connect to A4 (SDA) and A5 (SCL).
  • It has two power-lines connect directly to +5V and GND.
  • The RST-line can be left disconnected or strapped to GND or VCC.. not sure.
  • Interestingly, it seems that the specific unit we use also provides a spot to hook up a DS18B20 sensor. It includes the required 4.7Kohm resistor but doesnt provide any protocol-conversion or anything. The DS-pin connects to a free Digital Pin on the Arduino. See [[1]]

Schematics

Prototype layout V1

Prototype V1 schematic

The basic layout of the 'prototype' device based on arduino-shields, etc, can be found in this schematic.

The only device not shown/included is the DS1307 RTC-module as it is quite generic and best bought as a fully tested/working module even for the production version. There is no way of beating the cost of this part in a self-made layout.

A pdf version of the schematic can be found here.

PCB-v2.0 version

PCB v2.0

This version is different from the original prototype v1.0 design in a number of important ways.

Differences

• It has a full 6 button layout, back, enter and a star-shaped cursor-pad
• The keypad is made 'detachable' from the rest of the PCB, allowing connection via 3 wires (GND, VCC, A0)
• It uses i2c for controlling the LCD instead of using up a lot of digital pins; connected via 4 dupont wires (GND, VCC, SDA, SCL)
• It uses an Arduino Pro MINI (328 @ 16mhz) board which cost only 3 euro/pc
• All the pins of the arduino are broken out on extra pin-headers for driving outputs or connecting extra inputs.

The photo to the right shows the first version.

From left to right, you can see

• USB-connector for power (only)
• Two 3 pin headers for connecting 1-wire tempsensors (ds18x20's)
  • The six holes there are for mounting screw-terminals to connect the sensors instead of pin-headers)
• The ds1307RTC. It provides a realtime-clock and some eeprom storage for settings/etc.
• The arduino Pro Mini, soldered to the PCB via pinheaders.
  • The loop of dupont-wire is for connecting the i2c pins to the board. These are not in the 'standard' pinout of the arduino pro mini. Different designs have them on different positions. This solution seemed the most useful.
  • Above and below the Arduino Pro Mini are two rows of pins; 24 holes per side. These are for mounting double-row pin-headers to break out all the pins available on the Arduino Pro Mini for connecting actuators, SSR's, etc OR to extend the design with more/other sensors.
• A six-button keyboard is shown at the bottom of the board. The PCB has been carefully designed to allow cutting the PCB into two sections, seperating the key-pad from the rest of the PCB and allowing it to be connected using a dupont female-female wire (3 connections). Footprints for the required pin-headers are already present. On the photo the holes for these have not been drilled, however.

Total expected cost of all the items in THIS build is as follows:

• USB-connector: $0.20
• RTC-module : $1
• Arduino Pro Mini: $2
• Pin-headers (single): $0.20
• Three-pin screw-terminals: $0.60
• Buttons: $1
• Double pin-headers: $0.40
• Dupont-wire: $1
• LCD+ I2C module: $4
• Temperature-sensors: $6

---

$16,4

This excludes cost for PCB (self-etched) or any actuators/ssrs/peltiers/etc.

Needed work

The design uses 6 buttons instead of 5 of the original prototype. The resistor-values for proper functioning need to be devised/calculated and tested. The design , otherwise, works/acts the same way as the Prototype V1.0 design, except for the noted changes:

• LCD requires I2C version of library
• Buttons require different values to be read on the analog port.
• More IO-ports are available for driving/reading.

Programming

It uses a cheap i2c-> lcd board that has the PCF8574A on address 0x3F. Realtime-Clock (ds1307) and LCD (16x2 via pcf8574A) are driven through libraries:

• [RTCLib]
• [New Liquid Crystal]

An important note is that the Arduino Pro Mini does not have the auto-reset feature when uploading a sketch. It is required to press the reset-button just when the arduino-software is about to upload the sketch. Also, it doesnt have it's own USB-connection. It requires the use of a FTDI-cable (expensive) or any of the other low-cost alternatives (I use a CP2102HX for $1). Some Prolific 2303HX based controllers don't seem to work on windows 8(.1), also not with official Prolific drivers; then use this driver/instruction for a fix: http://ananddrs.com/2014/09/24/pl2303-prolific-usb-to-ttl-driver-for-windows-8-1/

The following sketch was used to display date/time. It also prints out RTCLib test-data on serial port:

// Date and time functions using a DS1307 RTC connected via I2C and Wire lib

#include <Wire.h>
#include "RTClib.h"
#include <LiquidCrystal_I2C.h>

RTC_DS1307 rtc;
// for PCF8574A based I2C displays
LiquidCrystal_I2C lcd(0x3F, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);
// for PCF8574T based I2C displays
// LiquidCrystal_I2C lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3 , POSITIVE);

void setup () {
  Serial.begin(115200);
  lcd.begin(16,2);               // initialize the lcd 
  lcd.backlight();
  
#ifdef AVR
  Wire.begin();
#else
  Wire1.begin(); // Shield I2C pins connect to alt I2C bus on Arduino Due
#endif
  rtc.begin();

  if (! rtc.isrunning()) {
    Serial.println("RTC is NOT running!");
    // following line sets the RTC to the date & time this sketch was compiled
    rtc.adjust(DateTime(F(__DATE__), F(__TIME__)));
    // This line sets the RTC with an explicit date & time, for example to set
    // January 21, 2014 at 3am you would call:
    // rtc.adjust(DateTime(2015, 8, 6, 0, 0, 0));
  }
}

void loop () {
    DateTime now = rtc.now();
    int a = analogRead(0);
    
    Serial.print(now.year(), DEC);
    Serial.print('/');
    Serial.print(now.month(), DEC);
    Serial.print('/');
    Serial.print(now.day(), DEC);
    Serial.print(' ');
    Serial.print(now.hour(), DEC);
    Serial.print(':');
    Serial.print(now.minute(), DEC);
    Serial.print(':');
    Serial.print(now.second(), DEC);
    Serial.println();
    
    Serial.print(" since midnight 1/1/1970 = ");
    Serial.print(now.unixtime());
    Serial.print("s = ");
    Serial.print(now.unixtime() / 86400L);
    Serial.println("d");
    
    // calculate a date which is 7 days and 30 seconds into the future
    DateTime future (now.unixtime() + 7 * 86400L + 30);
    
    Serial.print(" now + 7d + 30s: ");
    Serial.print(future.year(), DEC);
    Serial.print('/');
    Serial.print(future.month(), DEC);
    Serial.print('/');
    Serial.print(future.day(), DEC);
    Serial.print(' ');
    Serial.print(future.hour(), DEC);
    Serial.print(':');
    Serial.print(future.minute(), DEC);
    Serial.print(':');
    Serial.print(future.second(), DEC);
    Serial.println();
    
    Serial.println();
    lcd.home ();
    lcd.print(now.year(), DEC);
    lcd.print("-");
    lcd.print(now.month(), DEC);
    lcd.print("-");
    lcd.print(now.day(), DEC);
    lcd.setCursor(0,1);
    lcd.print(now.hour(), DEC);
    lcd.print(":");
    padIfNeeded(now.minute());
    lcd.print(now.minute(), DEC);
    lcd.print(":");
    padIfNeeded(now.second());
    lcd.print(now.second(),DEC );
    lcd.print(" ");
    lcd.print(a, DEC);
    delay(1000);
}

void padIfNeeded(int x) {
  char result;
  if (x < 10) 
  { 
    lcd.print("0");
  }
}

Schematics

This design was made in KiCad.

SVG versions of the schematic and the PCB are provided at the right side.

You can find a File:Experimental-incubator-v2.1.tar.gz of the combined files here.

For reference, the values for the resistors are:

• R1: 2K - 2k2
• R2: 330 - 360
• R3: 620 - 680
• R4: 1K - 1k
• R5: 3.3K - 3k3 (3k6)
• R6: 10K - 10k
• R7: 470
• R8: 470

Layout of the resistors:

        R7
        R8

      R1            R4
                          R5
      R2     R3      R6

PCB-v2.1b version

A new production run with minor improvements and professionally produced PCBs is being made for 33c3. Complete kits including all parts will be sold, or just bare PCBs for the die-hards.

Soldering and connection info

For the people that purchased this kit, we've created a new page that gives instructions on how to solder/connect/use this version. Please look at Incubator_v21b page for info.

Temperature probes

The DS18B20 temperature probes used have PVC shielding; that makes them unsuitable for long time use at temperatures of 100C or above, although the sensor works upto 125C. Some sensors are shielded with PTFE cable (more commonly known as Teflon) which is considered foodsafe to 160C, so these sensors can be used upto 125C (max sensor range). Here are some ordering options:

• [Cheapest found on DX - lead only 90cm, not 100!] eu 2.26
• [Cheap and tested sensor from DX] eu 2.53
• [Slightly nicer due to pins on leads] eu 3.37
• [Local source delivers very quickly] eu 3.25
• [Adafruit never cheap] $9.95
• [PTFE version on AliExpress] $8.50
• [PFTE version on ebay] eu 12.47
• [PTFE version on Adafruit - never cheap] $14.95
• [Local supply of PTFE version] eu 14.95