Brewing Beer with a Sous Vide Cooker

In beer brewing, the techniques that you use to extract the sugar that the yeast turns into alcohol are very important.  Sugar is pulled from malted grain by soaking it in hot water, which is called mashing.  The temperature of the water, and the length of time the grain is soaked makes a very big difference in the amount of sugar extracted.  The amount of sugar received is determined by measuring the density of the resulting water using a device called a hydrometer.  The ratio of extracted sugar compared with the theoretical maximum amount of sugar is called efficiency and is usually somewhere around 75%.

In addition to getting the sugar out of the grain, soaking the grain can have other effects by breaking down various proteins which can effect the flavor, the amount of head, and other factors in the resulting beer.  In order to get some of these secondary effects brewers can do multi-rest mashes where they soak the grains at different temperatures for different amount of time.  If you want more homebrewing theory, check out Palmer's excellent book.

All of this is difficult to do in the real world when all you are armed with is a stove with a knob that, when turned, will eventually change the temperature of the 5 or more gallons of water and grain.  Basically, it turns into doing a kind of human-powered PID controller, which is no fun at all.

Being an engineer, I thought that this definitely falls under the category of a task that a computer could do better than a human.  I started doing some planning in my head about what would be required for some kind of computing device to control my stove (or other heating element) so that I could set an exact temperature and let the computer worry about keeping the beer at the temperature.  It turns out that it's not hard since this kind of temperature control is used in industry all the time for many purposes besides mashing beer.

The auto mash temp control project was sitting solidly on the back burner in my brain when I saw that Sous Vide cookers were getting cheaper.  I will spare you the details, but Sous Vide cooking is a method of cooking by putting food in a water bath that is kept at an exact temperature by a temperature controller.

If you replace the water with wort (unfermented beer) then this sounds exactly like what I wanted to control mash temperature.  Sous Vide cookers operate in the same temperature range as typical mash temperatures, are generally made from food-safe materials, and are made to attach to the sides of standard cooking pots. All of these qualities make them ideal for use with a mash.

So I bought an Anova Sous Vide cooker and made a batch of beer, and the results were excellent.  I made this Irish Dry Stout recipe, with a mash temperature of 152 degrees F for 90 minutes, and a 170 deg mash out for 10 minutes.  In the end I got 75% efficiency, and I pretty much sat back and relaxed during the mash step instead of a typical batch where I have to watch the temperature like a hawk the whole time.

Footage of the mash and details and tips for using the Anova cooker with a mash are in the the video above, but the big takeaways are:

1. The Anova cooker seems to work quite well for mashing, and I will definitely use it again.
2. Only use the cooker for fine-tuning the mash temperature.  For brute force heating use your stove burner.  This is to avoid caramelizing any sugars to the Anova's heating cool which would make the Anova hard to clean and may effect the flavor of the beer.
3. Use a grain bag.  This keeps the grain from plugging up the innards of the Anova.  Be careful about where you aim the output of the Anova's circulator such that the grain bad doesn't get pulled into the Anova's intakes.
4. Carefully calculate batch size.  The liquid level must fall within the Min and Max lines on the Anova and this can be tricky to hit correctly when using a large brew pot, so do your math ahead of time to get it right.

Disclaimer: I don't know if Anova recommends using their Sous Vide cooker in this way, so I can't be responsible for any damage to the Anova cooker, problems with the resulting beer, or any other issues or problems you might encounter.

Quiz Show Buzzers

Recently I got a commission to create a set of quiz show buzzers.  There was nothing on the market that really fit what my client was looking for so they had me build something for them.  I found this instructable which was similar to, but not exactly, what the client wanted so I used that project as inspiration.

I made a video above which shows some of the steps during development as well as the finished device.

The basic requirements were:

• A control unit for the person running the game to see the order that players pressed their buttons.
• Four remote units that connect to the control box.  The remote unit should light up such that both the player and audience can see which player rang in first.
• A sound should play when the first player rings in.  The preference would be for the sound to be something like the Family Feud ring in sound.
• As a bonus it would be nice to have the cables between the remote boxes and the control unit be something that is easily replaceable in case longer cable lengths are needed in the future.

Software and Electronics
I started with an Arduino because, for simple devices like this, it is the quickest way for me to get started.  More specifically, I used a RBBB from Modern Device, since it is a cheap way to embed an Arduino in a project.

For the LEDs, I started with some old LEDs that I had lying around, but quickly found that they weren't bright enough to use with the ping pong ball diffusers I used for this project.  I ended up buying some new higher efficiency LEDs.  I tweaked the current limiting resistors for each different color of LED to maximize their drive current (and therefore brightness).  See the video for a demonstration of the LEDs.

I hadn't ever really done much with sound on the Arduino before so this was new territory.  I found that I could embed a WAV file (after re-encoding it as an array of data in the Arduino sketch), and then play it back using the PCM library.  I also found the ring-in sound from Family Feud on this website, which was really handy.

I struggled a bit getting the sound hardware working.  It's pretty easy to connect a speaker directly to an output pin from the Arduino, but that wasn't loud enough in my case where I wanted an entire room to hear it.  So I needed an amplifier of some kind, and I tried a number of different ones, but none seemed to work very well.  Eventually I found this site with the simplest amplifier of all, just a transistor and resistor.  This worked fantastically well, and required almost no work or expense to get it going!  You can see my circuit in the schematic.

I whipped up some more code to time the inputs to detect which player rang in first using the pin change interrupts on the Arduino.  This was easy using the handy PinChangeInt library.

Last of all for the software, I needed to create several different blink patterns on the LEDs.  Again an existing Arduino library came to my rescue in the form of the TimedAction library that allows you to setup psuedo-thread functions to run arbitrary code on a configurable time period.

Hardware
The prototype was now complete but I had to assemble the final version.  I decided to use headphone jacks to connect the remote boxes and the control unit together.  In this way I could carry the signals I needed over an inexpensive patch cable and make the all of the boxes easily detachable for storage.

As mentioned before, I used ping pong balls as inexpensive light diffusers attached through holes in the button boxes and held in place with hot glue.  The large buttons were attached through a hole in the top of each button box.  The speaker in the control box was attached with hot glue with a piece of screen placed in front of the speaker before gluing.

Assembly was much more time consuming than I thought.  Many hours of cutting, drilling, and soldering later, I had the final product which you can see in the video above.  My projects always seem to take way more time in the less interesting mechanical parts than in the super-fun electronics and software parts...

I got everything done in time and my client has been happily playing rounds of Jeopardy and trivia games for months now.

And now you get the benefit of all that work in the form of source code and schematics:

main project

source code

schematic (sorry, it's hand drawn)

bill of materials

Talking to an Arduino on Android with USB OTG

As part of the Thinkery robot project, we planned on creating an interface for the robots via a 7 inch Android tablet.  The tablet was supposed to display things like sensor readings and play videos and music when the robots went into dance mode.  In the end we didn't have time to finish this Android app, but I did some work in figuring out how the Android tablet and Arduino would communicate with each other.

Interfacing between an Arduino and Android devices is nothing new, the Amarino framework does it, and the MIT app inventor makes it really easy.  The downside of this and many of the existing examples is that they require the Arduino to have a bluetooth interface.  Using bluetooth for the interface is great if you need the connection between the Arduino and Android device to be wireless, but there are downsides to this approach.  First, the cost increases on the Arduino side; a bluetooth interface can cost as much as the Arduino itself.  Second, the Arduino must have its own power source, since there is no easy way for it to leech off the Android device's power supply if there is no wired connection to it.

I should mention here, for the sake of completeness, that there is another alternative besides using bluetooth: various IOIO boards.  These board connect through USB to an Android device and provide IO capabilities similar to an Arduino.  IMHO, these board still have some downsides: 1) they are still more costly than a standard Arduino board, and 2) they still require an external power source (they can't get their power from the Android device's USB port).

Since the robots were going to contain both a an on-board Arduino and Android tablet it made more sense to have a direct (wired) connection between the two.  I knew from my experiences with Linux (Android runs on top of Linux), that it is certainly possible for a portable device to act as a USB host using USB OTG.  So after a bit of searching I figured out that most recent Android devices do support USB OTG and have the correct drivers included to interface to USB serial devices (the Arduino enumerates as a USB serial device).

The next problem was how to physically connect the Arduino to the Android device.  Most Android devices have a female microUSB connector and the Arduino has a female USB-B connector.  To connect between them I got a USB OTG adapter from Monoprice.  An interesting side note is that the USB OTG adapter works equally well to connect a keyboard or flash drive to an Android device.

After even more searching, I found a very useful Android library that makes it easy to interface to USB serial devices.  While trying to build the example app I found that it was actually a little easier to use this fork of the original library project.

To test with my Android tablet (a Nexus 7), I programmed my Arduino with a simple sketch that sets the baud rate to 115200 and prints an integer string to the serial port every second, then I compiled and installed the example app from the USB serial library project and connected the Arduino to the Nexus.  It detected the new USB connection immediately and launched the Android app, and I could see my integers happily printing!

I then modified the example app to include a button which, when pressed, sends data to the Arduino.  On the Arduino side, the received data turns an LED on and off.  I uploaded my final code to this github repo.

In the end, we didn't have time to flesh out the Android interface for the Thinkery Robot Army, but it is certainly a useful tool for a future project.