I’ve been making alcoholic beverages at home since I have been of legal age to consume them. I started out making mead, then switched to beer when I moved to a house across the street from a beer-brewing friend.
I won’t go into much detail about brewing, but I should mention that temperature control is pretty important. I was taking a couple of classes with a friend, and we needed to come up with class projects. We decided to combine the projects and build a temperature controller for homebrewing.
We liked this because it combined control design (which was the topic of one class) and microcontrollers (which was the topic of the other), effectively allowing us to do half the work we were expected to do.
Inside the box are a few things:
- Arduino Duemilanove, a neat little microcontroller project board ordered from Sparkfun. This guy sports an ATMega328 AVR microcontroller.
- LCD Display with the ubiquitous HD44780 LCD controller, also from Sparkfun
- Blue and yellow “arcade” buttons, also also from Sparkfun, to decrease or increase the temperature set point. Blue decreases and yellow increases. They were out of red buttons.
- Switches and LEDs, also also also from Sparkfun
- Omron G3NA225B-DCS-24 solid state relay. This guy is switched with 5-24VDC and can switch 24-240VAC loads up to 4A (or 25A if you heatsink it). I picked this from Grainger after I found out they had a warehouse in Denver. You can just walk in and get stuff!
- A gutted 12VDC regulated wall-wart power supply. I think we got this from Sparkfun too. This let us have one power plug for the whole assembly.
- A regular two-plug wall outlet. The same thing that you plug your lamps and toasters and vacuums into, if you’re in the US and have more than one toaster and vacuum.
All this was stuffed into a black plastic project box from RadioShack. There were a couple of important things outside the box that plugged into the box, too.
- A 1500W 120V heating element, from an electric kettle untimely ripped.
- An Omega 700-series linear thermistor.
All this stuff was wired together according to this simple schematic, presented in glorious almost-illegibly-low quality
The general idea is this: The Arduino monitors the temperature of the brew, and flips a heating element on or off to keep the temperature in the appropriate range. This is normally pretty straightforward, since you can just program it to flip the heater on if the temperature is too low or flip it off if the temperature is too high. This is how a thermostat typically works.
But, since we were trying to control the temperature of the wort (which is the stuff that you get when you brew beer but before you ferment it), and we can’t heat the wort directly (because it would burn), we had to pump the wort through coils of tube in a tank of water that was itself heated by the heating element. Here’s an illustration:
Because of this, a simple thermostat won’t work: it would sense that the wort is too cold and flip on the heating element. Then, because the wort isn’t in direct contact with the heating element, it will heat up much slower than the water, so by the time the thermostat senses that the wort is hot enough, the water tank will be way too hot, and the wort will keep getting hotter even though the heating element is turned off.
Which is bad.
So, instead of a simple thermostat, we designed a
PHASE-LEAD-COMPENSATED PULSE-WIDTH MODULATOR
Which is a fancy thermostat. Instead of flipping the heater on and off as needed, it flips it on, leaves it on for a few seconds, then flips it off again. Then, ten seconds after it first flipped it on, it does it again. The ten-second wait between on-flippings is called the Pulse-Width Modulation (PWM) Period, and the few second that the heater is on is called the Duty Cycle (or Pulse-Width). So, if the controller leaves the heater flipped on for two out of every ten seconds, it’s as 20% duty cycle. If it’s on for seven-and-a-half seconds out of every ten seconds, it’s a 75% duty cycle.
You get it, but here’s an image anyway.
The controller monitors the temperature and, based on the current temperature trend (whether it’s increasing or decreasing) and the past temperatures, controls the duty cycle (“Heater On” time in the image), and thereby governs the temperature.
The trick to this is to determine exactly how the temperature readings should affect the duty cycle to make the system work best. This is where the phase-lead-compensation comes in. Basically, phase-lead compensation is one of many ways of converting an error (which, in this case, is the difference between the measured temperature and the desired temperature) into a control signal (which, in this case, is a duty cycle). If you’ve heard of a PID (Proportional-Integral-Derivative) controller, those do the same thing in a different way.
Anyway, the idea is that you characterize a system mathematically (which we did by taking temperature data while we brewed beer). Then you do more math to determine the parameters of a control algorithm to make the system perform in a certain way. Eventually, we came up with this:
uk = 63.68ek – 61.272ek-1 + 0.5167uk-1
Which means that
(new duty cycle) = 63.68*(current error) – 61.272*(previous error) + 0.5167*(previous duty cycle)
We set the new duty cycle according to this equation every ten seconds. So, as long as we know the current temperature error, the temperature error from ten seconds earlier, and the duty cycle from ten seconds earlier, we can figure out what the new duty cycle needs to be to maintain temperature.
There is one other minor detail, which is that the system is nonlinear. This is because we can have a maximum duty cycle of 100%, and a minimum of zero. We don’t have any way of heating the system with more than 1500W or any way of pulling heat out of the system faster than the environment can do it. This sort of complicates things, but we didn’t worry too much about it.
These graphs show simulated duty cycle and temperature changes when we try to bump the temperature from 154°F to 175°F.
These are generated by Simulink, where formatting output graphs is widely considered to be black magic dabbled in only by dark wizards.
If you check out the duty cycle graph on the left, you’ll see that as soon as we set the desired temperature to 175°F, the duty cycle jumps to 100%. Then, after about 1700 seconds, it drops to zero, then slowly climbs to a steady-state of around 75%.
And the temperature responds with a nice, smooth upward swing. Just look at those curves. Gorgeous.
The next step was to write software to implement all this on the hardware. We used an infinite loop to continuously monitor the temperature and adjust the duty cycle as needed (according to the above algorithm), with a couple of interrupts tied to the arcade buttons. Here’s a flowchart.
And that’s about it!