I have started work on my custom fermentation controller using peltier based thermo-electric elements. If you don’t know what that is, there is a good article available on wikipedia.

The benefit I will find is that for the (hopefully) short durations that the peltier will need to run, it will be more efficient than just running a fridge through an ATC. The only moving parts will be two cheap computer fans, so it should be cheaper to maintain should something break. It also means that the unit can be built to my exact requirements, which is always a bonus.

The unit it’s self will be a double ply wooden box with a full front door for inserting/removing the fermenting vessel. The box will most likely be made from 2×4′s, plywood (probably OSB on the inside), and a load of insulation. My basic idea is to build a frame out of 2×4′s, fit the internal paneling; fill the crevice with fiberglass, rockwool or polystyrene, and then fit the outer panels. The inside will most likely be sealed with a wood sealant, and then have the joints smeared with caulk, and then coated with a plastic resin coating. This will allow for restricted movement of air (like a fridge) and for waterproofing.

Electronically, the peltier element can both heat and cool by reversing the polarity on the cables. I have purchased almost all of the electronics for this (and some nice new tools ) and I’m just waiting on delivery. In it’s most basic sense, the peltier will be in one of three states, heating, cooling, or off. This will be accomplished using a H-Bridge setup built from FET’s (think of them as switches). If you would like more information on H-Bridges you can find some good information here.

The unit will also have a 4 digit LED 7 Segment display, a few LED’s, a few buttons for configuration, a buzzer for an alarm, and will probably be powered from a hacked computer PSU.

I have some of the parts I need here, and I have begun development and testing on them. Unfortunately, I don’t have the peltiers themselves, or the heatsinks for them, or the display, I do have a temperature sensor, but it is not the correct one. As such, I have been using a serial console and some LED’s to monitor the states.

Within the software, I have it set up such that a minimum and a maximum temperature can be specified. In addition to this, an alarm temperature can also be specified, in such that if the current temperature exceeds the minimum or the maximum by this value, an alarm sounds.

I think I’m babbling a little now….

Here’s what it does so far:
The unit powers up, and retrieves the user specified minimum, maximum and differential temperatures from memory (EEPROM).
The unit then measures the current temperature, and will activate the respective heating or cooling logic based on the current temperature (or do nothing if it is within bounds).
If the temperature is above or below the min/max temperature by the differential, it will sound off 3 beeps and continue to take corrective measures.
If the differential is set to 0, it will not sound the alarm.

There is also functionality to store the users parameters persistently between sessions.

Here’s what I have to make it do:
Display the current temperature on the display (which I don’t have yet).
Provide a configuration menu for the user to input the min/max/dif temperatures.
Provide a configuration menu for the user to input the cycle time and jitter time (explained below).
Port it from the development platform (Arduino) to a bog-standard microcontroller (PIC or AVR, or MSP430).
Design & Test the H-Bridge Circuitry.
Get some circuit boards made

The cycle time is the delay the system pauses for at the end of each cycle, realistically this code could run thousands of times a second, and there is no need. So rather than do that and waste power, the circuit will sample every X number of seconds. (Currently hard set to 1 second)

The jitter time (or dampening time for you engineers!) is when the system changes state from heating to idle, idle to heating, idle to cooling, or cooling to idle. Ideally, this delay should be slightly longer than the normal cycle time to allow for some measurable change to take effect. This will also cut out on a temperature being a point of a degree off, activating another state, then deactivating the state almost straight away, and ending up being a point of a degree out again a second later. (Currently hard set to 5 seconds).

Are there any other features that you think I should implement? It will be easier to do now than when I have it all done and have to rework code to add a new feature…