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
The fermentation controller has been a longstanding item on the wishlist of Fermentation-god Frantisek Apfelbeck of 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.
Current status
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
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 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.
- [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.