Sous Vader

If you happen to keep up with what's trendy in cooking, you might be aware of sous vide. This style of cooking involves vacuum sealing your food and then cooking it in a precisely controlled water bath, typically for long periods at low temperatures. Despite the name ('under vacuum'), the vacuum sealing is seldom the key aspect of sous vide dishes. Instead, it is the superb temperature control which yields such interesting results - you can essentially select which chemical reactions occur in the food, and you can do it in an extremely reproducible fashion. This is exciting for two reasons: you can get some truly excellent cooking results, but you can also do it very repeatably and with minimal effort. If you're skeptical (and you should be, I'm just some dude on the internet you've never met), Google will give you a long list of food bloggers gushing about some awesome dish they've made with a sous vide machine.

Naturally, commercial equipment exists for sous vide cooking. Possibly the most famous of these is the Sous Vide Supreme, but this product line starts at $600 AUD. Unless you're very serious about cooking or have plenty of disposable income, you probably won't get to play with one of these. Cheaper options are available and expanding as the popularity of the technique grows, such as the $360 Nomiku or the $160 SousVideMagic. The latter is a a sous vide controller, meaning you connect your own rice cooker to it rather than it being a stand-alone unit. In this article I'm going to discuss my efforts in designing my own sous vide controller, for the delightful price of $100 AUD (more like $60 if you already have an AC adapter and enclosure). Let us remember that I'm just some clown doing this in my spare time because writing a PhD thesis can get dull - it's possible that the professionals have thought of things I haven't. But as we'll see, it's quite possible to make a perfectly functional sous vide cooker at a fraction of the price.

I'll take you through the build details, because the fact that you've arrived at this website suggests you're into that sort of thing. Hopefully there is enough information here for you to modify and design one of your own. I don't have a stack of these in a backroom or anything, but if you're interested in building one (or just getting some kit-style parts for one), email me before Disney sends me a stern letter about star-wars copyright infringement.


As mentioned, the approach we'll take is to operate a rice cooker (or crockpot, or water distiller etc.) as a temperature controlled water bath, under the assumption that one of these appliances is already kicking around in your kitchen (rice cookers are pretty cheap anyway). We'll do this by creating a special mains AC socket, one which will control the amount of power going into the cooker in order to maintain a desired bath temperature. A quite nice aspect of this approach is that once you're done, you can just unplug the relatively small control box and you have your rice cooker back. (It's important however that the rice cooker is simple - units with digital readouts or other such fanciness probably won't work.)

The first part of this problem is getting control of mains AC electricity. In the simplest case, this means simply being able to switch it on and off in a controlled way. You may be familiar with techniques for switching DC electricity with a transistor, but these won't work for switching mains. If you're distrustful of semiconductor physics and you don't mind the cacophony, a simple solution could be a mechanical relay - the switching frequencies we'll end up using here are quite slow, so this is workable if inelegant. If your tastes run more to the solid-state, the conventional, cheaper solution is to use a triac. I won't go into the details here - in Figure 1 I've shown the configuration of a triac and accompanying driver circuit, and for the rest of this discussion I'll simply abstract this block as an logic-level controlled on/off switch for the AC. The triac I used (Q4025L6) is rated to 25A at 400V, which is more than enough for this purpose - the rice cooker I'm using has a nominal power rating of 350W, which corresponds to about 1.5A at 240V. For discussion about sizing the two resistors in the triac circuit, see my calculations here..

Figure 1. Schematic for the parts of the project which deal with mains electricity.

The rest of Figure 1 shows the fused mains input on the left (240V/50Hz, with an earth pin - this is Australia) and a control socket on the right which we'll plug the rice cooker into. At the top of the figure there is a DC plugpack, also fused. This produces a nice low voltage DC supply line for the rest of the electronics, and most importantly it allows me to avoid rolling my own AC/DC adapter ... that's a project for another day.

I haven't built any zero-crossing detection into this, so the control electronics have no idea about the phase of the mains AC. I didn't think it was necessary, but if you like you could easily add it in with a couple of resistors and an extra pin on the microcontroller. There are several nice application notes from Atmel and Microchip discussing how to do this.

Let's now move on the digital side of the board, shown in Figure 2:

Figure 2. Schematics for the digital parts of the project

An ATMega328 microcontroller is doing all the thinking in this project. Cheaper controllers would certainly work, but I'm using that 32kB pile of memory to facilitate a text-based menu system. This is also the processor used in the Arduino, so you should have minimal trouble adapting the project if that's the way you lean. The temperature sensor is the venerable DS18B20 in a waterproof housing. This sensor is rated to 125°C, which is plenty for sous-vide cooking - I seldom go higher than 65°C. A 4 line, 20 character LCD allows the display of status information, and with the help of 3 tactile buttons also permits a menu system for setting parameters. A bluetooth module (JY-MCU board from ebay) provides a cheap form of wireless serial output, which as we shall see shortly can be quite useful. Lastly there's a speaker in there. A sous-vide cooker doesn't really need a speaker, but I happen to be of the opinion that few things are not bolstered by the ability to play a bleepy version of The Imperial March.

Excluding the AC adapter, all of that comes to about $50 (sourcing from a combination of ebay, Sparkfun, Futurlec and the local Jaycar Electronics). Add another $5 for a small aquarium pump to circulate water in the bath - this quite important for obtaining a perfectly stable temperature. These are cheap on ebay, but they don't tend last long if you're cooking above about 65°C. The assembled electronics, housed in a nice, solid, expensive ($30) enclosure is shown in Figure 3. The final total cost comes to around $100 AUD, which includes a $20 AC adapter. You can get those much cheaper on ebay, but I've had bad experiences with cheap wall adapters. I won't put my PCB files (Eagle) up here - I'm constantly changing them to streamline assembly and fix silly mistakes. They're available on email request, but I encourage you to lay out your own. (A bill of materials is also available if you want advice on where to source anything, but this regularly changes too)

Figure 3. An assembled DIY sous-vide control unit

Lastly, we should do something about the fact that it's ugly by putting a nice faceplate on there. I made something up in Inkscape, printed and laminated it then stuck it on with double sided tape. This gives labels for the buttons, a super cool logo and a nice LCD window (cut out a rectangle before laminating). Importantly, it also hides any scruffiness you might have introduced when dremeling the cutouts in the case.

Figure 4. Faceplate applied for the finishing touch.

And with that, the Sous Vader is created. Physically, at least - without a program on that microcontroller it's not very useful. What shall we have it do, and how?

Firmware, and a frank discussion about PI loops

For the truly keen, the complete firmware for the ATMega328 is available here (start with sousvide.c). I'm always receptive to comments or questions if you have any. For the marginally less keen, I'll provide a brief overview of what the program does and why. There's a lot of fluff to handle things like the menu system, the speaker and serial output, but the essence of the project lies with being able to set a variable output power through the triac, and moreover to set it in a way that maintains a desired temperature.

The variable output power comes from a very simple form of pulse width modulation. One of the internal timers in the mega328 counts through 100 'ticks' over the space of about 2.6 seconds. The variable `Mains_OutputPower' is used to set how many of these ticks the triac should be held on for. A value of 100 means the triac is on the entire time, and the load sees a normal mains socket. A value of 40 would means that the triac is on for 40 ticks then off for the remaining 60, then on for another 40, then off for 60 ... Averaged over several tens of seconds, this is no different to providing a steady 40% of full power. Note that because the load is a plain old resistive heating element and because it has a lot of thermal mass, it's quite forgiving of both having such a slow duty cycle and of cutting the power in and out with no regard for the phase.

The more interesting part of this equation is how to establish a feedback loop, so that the output is automatically adjusted to maintain a temperature. Feedback and control systems constitute an entire academic field, and by way of a disclaimer it's not one that I'm formally versed in. In the end I've gone with a classic proportional-integral loop, which is of course 2/3 of a PID loop.

Let's hastily review PI loops, or at least a PI loop in the way I've implemented it. The idea is to regularly measure the difference between the parameter you're trying to control and the desired value of that parameter, with this difference called the error:

Error = Setpoint - TemperatureReading

Each iteration you multiply this error by some fixed number (ProportionalTerm, abbreviated P), and if this were purely a proportional loop you would then walk away exuberantly because you'd be done:

OutputPower = ProportionalTerm * Error
Assuming your ProportionalTerm has the correct sign (i.e. pushes the system towards setpoint rather than away), the error will grow smaller - it might overshoot and bounce around a little, but eventually you'll land on a value of OutputPower that keeps things right where you want them. Ideally.

Actually what you tend to find is that you'll come quite close to your setpoint without sitting exactly on top of it. This is because when you're perfectly on setpoint, the error term is zero and so your output power is also zero. But with no output power, the temperature will droop ... the only stable configuration is one with a little bit of error in order to 'drive' the proportional loop.

For this reason, you can consider upping your game and including an integral term (making it a PI loop). The idea here is to keep some memory of how bad the error has been lately. So now we do one more thing in each iteration:

IntegratedError = IntegratedError + Error

If the error does not settle on zero, this IntegratedError term is going to grow larger and larger with each iteration (in fact the only way to reduce it is to have a negative error, i.e. to overshoot). We capitalize on this behaviour by putting it into our OutputPower calculation with a multiplying IntegralTerm (abbreviated I):

OutputPower = (ProportionalTerm * Error) + (IntegralTerm * IntegratedError)

Now we have the proportional part of the loop doing most of the work, with the integral part getting rid of the droop and making the zero-error state stable. I stopped here - you could also add a derivative term to help prevent overshooting if you like, but in this particular application it's not really necessary. All that's left is picking good values for these P and I terms, which brings us into a whole new section entitled:


Picking good values for the P and I terms is called tuning, and the aim is to pick values that take you quickly to the setpoint without too much overshooting and oscillation. The classic (though not the only) technique for tuning a PID loop is known as the Ziegler-Nichols method. It begins by operating the system under purely proportional control, slowly increasing the P value until the output begins to oscillate without decaying. Bear with me, there's an example coming. Call this the critical P value, PC, and measure the time period of the oscillation, TC. In the case of a PI controller, you then set P=PC/2.2 and I=1.2*PC/TC.

Upon hearing this, you may as I did grow suspicious about where these magic numbers have come from. The original 1941 paper is free online, and if you read it you'll learn that there's nothing particularly fundamental about Ziegler-Nichols tuning. It's educated trial and error, so by all means use it as your starting point but don't assume that it's some analytically derived optimum.

Before we move on to looking at the tuning experiments, I have to point out this spectacular line from the Zeigler-Nichols paper:

"...no attempt will be made ... to make acknowledgement of material from published literature"
And sure enough, there are no references anywhere the paper. This might only be entertaining to the scientists reading this, for most of whom such a statement would be outlandishly bold.

Back on task. Carrying out this tuning procedure requires you to record the temperature as a function of time, and at this point the bluetooth transmitter included in the Sous Vader proves itself invaluable. A typical temperature curve with no integral feedback term looks like the one in Figure 5. The rice cooker takes about half an hour to bring the water up to temperature, overshoots and then settles close to the programmed setpoint. How long this takes very much depends on the starting temperature - filling the bath from the hot tap can easily save half an hour.

Figure 5. A typical temperature-time plot for the Sous Vader under purely proportional feedback control.

The first part of the tuning process is to find the value of P at which the temperature first starts to oscillate. To do this I set up some firmware to loop through different values of the P constant, then just left it going for a day or two. The results are shown in Figure 6, and I've highlighted in green the trace at P=1200, which is where I think the steady oscillations first start. The frequency of these oscillations is very close to 9 per hour, a period of 400 seconds.

Figure 6. Sweeping through different P values in a purely proportional loop

According to Zeigler-Nichols, the optimum P value is therefore 1200/2.2 = 545, and the optimum value of the I term is in the vicinity of (1.2*1200)/400 = 3.6 [Postscript May 2013: Pretty sure I misunderstood something here - the calculation should use the period in samples, not seconds. If you think about it, the same integral value would give very different behaviour for a loop running at 1Hz vs 100Hz. Calculating the integral term using the period in samples addresses this. This means my discussion here is off by a factor of 3, but I seem to have got away with it. Always question what you read on the internet...]. Armed with that information, I started another series of measurements, this time fixing the P value at 600 and sweeping through values of the I term:

Figure 7. Fine tuning of the P-I loop parameters. Grey bands represent our target accuracy of 0.1°C.

This plot is quite nice, because you can clearly see the role of the integral term. With only a proportional term (black trace), the control loop does a respectable job but is drooping outside the desired 0.1°C accuracy band. Adding a small integral term immediately fixes this, but too much and the loop becomes unstable. In this particular case it looks like I=2 is about right. I imagine that if you changed the appliance used for the bath (e.g. swapped in a crockpot or a different rice cooker) these terms would need adjusting. Probably there is enough computational power in the microcontroller to set up some kind of auto-tune function, but that's a job for another day.

And with that we've got a tuned sous vide cooker, all ready to go!


I don't have any epic food photos to tantalize you with - I'm usually too preoccupied with immediately eating the results to faff around taking photos - but I can assure you that the Sou Vader works very well. For the last few months it's been given an absolute hammering in the kitchen, cooking things like eggs, steaks, pulled pork and creme brulee custards. Some with results you couldn't achieve any other way, some with results which you could achieve conventionally, but only if you were very good in the kitchen. Most recently it produced a super Australian chili with kangaroo mince and wattleseed, cooked straight in the rice cooker (no water bath) for 20 hours at 57°C.

I don't own a vacuum sealer, but as I mentioned earlier this is not really a deal breaker. When food needs to be bagged you can get by just fine using ziplock bags, dipped in a sink full of water to squeeze all the air out.

That's all for now. Go forth, build something fun, and eat the fruits of your labour!


Figure 8. The importance of a having a tolerant partner

comments powered by Disqus