Thursday, January 21, 2016

Controlling flow through a wort chiller, part 1

Now it's time to start putting together my last two experiments in order to control how quickly the wort flows through the chiller.  This will hopefully allow me to control how quickly and efficiently the wort is chilled.


I've added a stainless steel racking cane as an input tube to the condenser tube.  The condenser tube is now better supported with a ring clamp that allows me to keep tube properly supported at an adjustable angle. The tube that leads into the glass jug is just the right diameter to fit snugly in the output of the condenser tube.

As part of this I also want to try and slow down the flow of water through the condenser tube.  I took a simple approach of using a pinch clamp to see how much that restricts the flow.  I then pulled 16 ounces of water and timed how long it took on a stop watch.

table of data
clamp gap(cm) transfer time(s)
open 0:38
0.5 0:38
0.4 0:38
0.35 0:41

Based on the numbers I collected, it seems that the pinch clamp is effectively binary, all off or all on.

Since the pinch clamp didn't work very well, I'm going to try inlining a smaller tube to see if that restricts the flow better.

Tuesday, January 05, 2016

First experiments with a glass wort chiller

The reason I was messing around with vacuum pumps in my last post is so I can pull wort through a new type of chiller.  Now that I've got the pump part somewhat figured out, I did some work on the chiller part.

Unfermented beer (wort) needs to be boiled and then rapidly chilled, since there are some chemicals that form in hot wort that can produce off flavors in the final beer.  Ideally you want to take the wort from 220F to 80F in around 15-30 minutes.  There are various methods and devices that are typically used to do this. 

One method that I have not seen used before is using a graham condenser tube.  This is usually used in chemistry labs to condense vapor into a liquid.  It's basically a spiral glass tube with a larger straight glass tube on the outside.  Cold water is pumped through the outer glass jacket around the inner spiral glass tube to cool it down.  the vapor is passed through the inner spiral tube and it hopefully coalesces into a liquid before coming out the far end of the tube.

The only difference between chilling wort and the usual use-cases for the graham condenser is that liquid, not vapor, would be the input to the inner tube of the condenser.  Besides that the goals are the same: lowering the temperature of the input liquid/vapor.  I bought this graham condenser to try.

Let's talk about some of the temperatures involved.  As I mentioned above the input liquid to the condenser will be close to boiling, about 220F.  The coolant water temp in the outer jacket of the condenser will be ice water probably around 35-40F.  That's a delta of 185F between the coolant and the input wort.  If you subjected a normal piece of glass from your kitchen to this kind of thermal shock it would probably shatter, but in this case the condenser is made of borosilicate glass.  Borosilicate glass is special in that it is made to handle high thermal shocks like this; according to some numbers I looked up online it should be able to handle 320-330F of thermal shock so our 185F of thermal shock is probably OK.  There's even a bit of wiggle room so if I decided to try something like adding salt to the coolant water to lower the temperature down to about 0F, we're still in pretty good shape.

Experimental Setup
I had a cheap submersible fountain pump pushing water through condenser tube, from output to input (opposite direction to the way the hot water will go).  The coolant reservoir is about 1 gallon of normal tap water.  During the tests I had to tip the condenser tube at about 45 deg angle to get the input water to flow through the tube via gravity.  I had several thermometers measuring the temperature of the coolant water reservoir, the temp of the input water, and the output water.  I heated the input water using a tea kettle on my stove.

Trial 1
Coolant water was at 62F and input water was 126F for a delta of 64F.  After passing through the condenser I got an output of 87F.  The temperature delta from the input to output is about 40F.  The coolant water was 64F after processing the hot water, so only a 2 degree increase in the coolant.

Trial 2
Coolant water was at 64F and input water was 143F for a delta of 80F.  After passing through the condenser I got an output of 93F.  The temperature delta from the input to output is about 50F.  The coolant water was 68F after processing the hot water.

Trial 3
This time I put ice in the coolant reservoir.  Coolant water was at 43F and input water was 150F for a delta of 107F.  After passing through the condenser I got an output of 91F.  The temperature delta from the input to output is about 60F.  The coolant water was 48F after processing the hot water.

Next Steps
Dropping 60 degrees in less than a foot with a pretty quick trip through the tube seems like a really good result!  At this point the condenser is showing enough promise to keep going with the experiment.  Next I'd like to tie in the vacuum pump to make it more like the final project I have in mind, and give an easier way to pull hot water through the condenser tube.  As part of that I may need to put some pressure feedback in the vacuum pump line in order to tightly control how quickly the hot water flows through the tube.  So I've got lots of connecting differing diameters of tubing in my future...



Tuesday, December 22, 2015

A non-contact liquid pump

I came up with a way to transfer liquid from one place to another without having the liquid pass through the pump.  My main goal was to come up with something I can use for homebrewing to transfer unfermented beer (wort).  I need something food safe, and the easiest and cheapest way to do that is if the pump has no contact with the wort.

The experiment used a sealed glass jug with a two hole stopper with a tube attached to each hole.  One tube went to a glass of water, and the other was attached to an inexpensive vacuum pump.  The concept behind it is similar to sucking water through a straw.  The vacuum pump lowers the pressure inside the glass jug, which pulls the liquid into the jug.  Another way to look at it is the atmospheric pressure pushes the liquid into the glass jug.

The experiment was a huge success!  The pump transfers water quickly and I even had to stop the pump midway through since it had built up enough of a vacuum.  It's important to note that there is definitely a lag between stopping the pump and when the liquid stops transferring (see the video below).

I measured a few things during the experiment.  Even though the pump I used was rated for 12V, I only used a 5V power supply because I was afraid of pulling the liquid too quickly.  5 volts worked just fine, and I think I'm going to stick with that.  I was able to test that the pump could pull water up to 20 inches; it probably could have done more but that was the most I could test with my rig.  I measured around 200-550 mA of current usage, and it definitely went up as the vacuum in the jug increased.




The two hole stopper is a little ugly, but it works pretty well.

Boring the holes in the stopper was definitely the most difficult part.

Jury-rigged power supply for the pump

Tuesday, November 24, 2015

Re-writing the example code from Chaos and Fractals


I stumbled on an interesting book on fractal algorithms: Chaos and Fractals: New Frontiers of Science.  What made me take notice was that each chapter ended with a short, approachable example program that demonstrates a concept.  The programs also generate some neat-looking fractal diagrams, and IMHO it's always fun to play around with algorithms that generate pictures.

Another interesting point was that, in the first edition of the book, each example program was written in the BASIC programming language. The choice of BASIC doesn't seem so odd with a little historical context.  The book was published in 1992, and around that time there weren't very many good cross-platform programming languages, especially when you consider cross-platform drawing libraries.  But, at the time, BASIC fit the bill.  It could run on DOS-based PCs and Apple IIs, which, at the time, probably covered a pretty good swath of the audience for the book.  Most BASIC dialects also included the LINE and PSET functions which were all the example programs needed to draw the output of all sorts of fractal algorithms.  In hindsight, BASIC seems like a decent choice.  In the second edition of the book, I believe the authors switched to something else like Java applets; I was working from a first edition copy from my local library so I don't know much about the second edition.

I decided it would be a fun exercise to port these example programs to javascript, since that seems to be the new cross platform language of choice in this decade.  I tried to reproduce them as faithfully as possible without any attempt at further optimization, and I tried to use as few non-BASIC language constructs as possible.  I say few as possible, since many BASIC language constructs don't have direct analogous constructs in javascript, for instance GOTOs and labels.  So I present to you below, my implementation of these examples.

I ran into a few caveats during the porting process that are worth mentioning:

  • To view my javascript source, just choose View Page Source and you should be able to look around and find the example code.
  • Most of these algorithms are recursive and I had to get a little imaginative when converting GOTOs and GOSUBs to proper function calls.
  • For displaying the graphical output of each program, I used the HTML canvas object.
  • I tried to leave the BASIC code as comments amongst the javascript code so in case you're following along with the book you'll have some guide posts in the code.
  • The example code uses several different invocations of the LINE and PSET functions, and I had to track down some BASIC language documentation to figure out what the invocations should do.  As a result, it seems that the BASIC dialect used is closest to GW-BASIC and QuickBASIC.
  • The output from the programs for chapters 12 and 13 did not look like the diagrams in the book and I spent quite a bit of time debugging them looking for my error.  In the end I downloaded the DOSBox emulator and a copy of QuickBASIC and ran the programs there.  In both cases, the BASIC code ran but outputted exactly the same result that I got from my javascript version.  So I can only conclude that there is an error either in the code or the diagram printed in the book.
  • Some of the programs take a while to run (especially chapter 12 and 14), and this can lead modern browsers to display errors that the browser tab has hung or otherwise failed.  In the chapter 12 code I tried to mitigate this somewhat by adding chunking code to sleep between chunks of loop iterations.  It's less noticeable in chapter 14, but if you run into issues you can often get around it by just reloading the page and trying again.


Chapter 1: Graphical Iteration
Chapter 2: Sierpinski Gasket
Chapter 3: The Koch Curve
Chapter 4: The Cantor Set
Chapter 5: Iterating the MRCM
Chapter 6: Chaos Game for the Fern
Chapter 7: L-systems
Chapter 8: Cellular Automata
Chapter 9: Random Midpoint Displacement
Chapter 10: Times Series and Error Development
Chapter 11: Final State Diagram
Chapter 12: Rossler Attractor
Chapter 13: Julia Sets
Chapter 14: Mandelbrot Sets

Monday, December 22, 2014

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.

Monday, December 15, 2014

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:
schematic (sorry, it's hand drawn)

Monday, December 08, 2014

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.