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

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