2010
12.10

Design and Concept

IMG_0184

Goals

Let me start by putting in to words the goal I was seeking. I wanted a way to control fermentation temperature and timing of my beer with a high level of precision and to be able to extract data along the way that might help me make better beer. Perhaps a bulleted list of requirements would be more clear:

  • Precise control over temperature
  • Programmable phases or durations of fermentation with defined temperatures and periods of time
  • Collection of temperature samples at regular intervals for graphing
  • Multiple beers at different temperatures simultaneously
  • Ample capacity
  • 100% automation

Theory

I wanted to support multiple fermentations which would occur independently at different temperatures, so immediately I knew that I would need to build something in the style of a cabinet with well insulated separation. The automation would require that I have some equipment to do my bidding, so I would need a chamber for that as well.

Fermentation Chambers

In order to maintain separate temperatures, I needed some electronics. If I didn’t mind manually adjusting the temperature at the right times, I could have gotten away with one of the many commercial temperature controllers that exist. But I wanted to automate that process, and those could have bumped the cost of the project quite a bit. So I decided to get a programmable microcontroller that could help change the temperature exactly the way I wanted it to. I quickly came across the Arduino, which looked like something I could learn to use quickly.

The fermentation process needed to be completely automated, so I needed a source of “cold” in order to remove heat from the system. The only option that really left me was a refrigerator. Some similar projects I had seen drilled a hole in a fridge (or freezer) in order to pump coolant from a chamber to a refrigerated reservoir. I decided instead to remove the cooling system from an small fridge I had been hanging on to, and incorporate that into one of the chambers mentioned previously.

Recommissioned refrigerator compressor

This would allow me to keep something cold, but I needed to keep multiple fermenting beers happy. I needed to “distribute” the cold to each in a manner that would allow me to keep very precise and steady temperatures. This problem has been solved well by others, such as Jason Smith, so I decided to borrow his knowledge and use pumps, fans, and radiators.

So here’s how the system would work. The cooling system from the old fridge keeps a large reservoir of water (mixed with a small amount of glycol to inhibit freezing.) cold. Ultimately, I decided that this reservoir should be as large as I could fit in the chamber I had to work with, which is about 13 US Gallons. For each chamber, I included a pump in the coolant attached to a tube which runs to the chamber. On the other end, inside the chamber, the tube attaches to a radiator, which is coupled with a fan. From there, a tube brings the water back to the reservoir. This allows me to pump cold water from the reservoir to the chamber and then pull the air in the chamber over the cold radiator to bring the chamber temperature down.

Radiator-fan assembly

Radiator-fan assembly

cooling_system

Click to enlarge

The electronics control when this occurs. Each chamber has thermometers that can sample the temperature of its air and also the temperature of the beer as it ferments. When the fermentation temperature becomes too high, the corresponding pump and fan turn on briefly, causing the temperature of the air to drop. This happens very frequently, and the result is that the fermentation temperature settles somewhere very close to its target. Meanwhile, another thermometer samples the temperature of the coolant in the reservoir, and the cooling system is turned on and off as necessary to keep the coolant cold enough to suit its purpose. I will elaborate on the electronic components later.

Architectural Concerns

The architecture of the chamber was fairly straightforward: I needed several chambers each large enough to handle my 10-15 gallon batches and an extra chamber to hold the coolant reservoir, the coolant system, and my electronic components. I did need to make some decisions to meet a few challenges, though.

Each chamber needed to be insulated from its neighbors adequately such that it wouldn’t influence the temperature of other chambers drastically. Initially,  I decided to use boards of insulation that could be easily cut to shape and layered between chambers. However, I double-guessed myself and decided I could use space more efficiently (my calculations involving R-values said so!), while saving time and money, by using an expanding foam product instead. As I will explain later, this was a bad decision and a waste of time and money.

I also had competing concerns with the doors. I wanted to make sure that my doors were air tight, but were also easy to open and close. As I opted to include 3 fermentation chambers and a fourth chamber for my other equipment, I had to keep things compact as best I could and did not have space for large hinges or latches, etc. I decided that the insulation on the door, since it was to be about 1.5 inches thick, would provide a fit tight enough that the doors would remain in place. This was almost adequate, but eventually I decided to use some bolts to keep the doors on very tightly, as I will explain later.

Electronics

The electronics involved in this project were not very complex, but I didn’t have very much experience here so I had to climb a learning curve before I could make informed decisions and a working product. As mentioned above, the heart of the electronics is an Arduino microcontroller. It connects primarily to two different devices: temperature probes and relays.

The temperature probes were one of the more exciting parts of the project. Cheap, small, and inexpensive, they allowed me to exceed my goals related to temperature in a manner that brings to mind the word “overkill.” The Dallas One-Wire temperature probes, which are available at virtually any electronics vendor, provide temperature readings accurate to +/- 0.5°C with extreme precision. They derive their power from the bus over which they communicate, meaning that fewer wires are necessary, and they can be chained together. The Arduino has a very useful One-Wire library available, so implementation was actually pretty trivial. The One-Wire bus is an interesting study, and if you are so inclined, I would recommend a study of it.

The relays were also very easy to utilize (a relay essentially allows you to open and close one circuit by opening and closing a second circuit). Controlling them via the Arduino is ultimately one very simple line of code at this point, so turning on and off the pumps, the fans, and the refrigeration system is trivial.

Software Architecture

With the cooling capability and the electronics to control it, I now needed to design the software that would allow me to control the temperatures in a meaningful manner. I’m pleased with the way I approached this.

Since the Arduino is written in a C-like language with a very limited binary size (something like 14k, most of which was consumed the minute I imported the One-Wire and TCP libraries), it was clear that it’s job needed to be minimal. On the other hand, I have at least one machine in the house that I always keep running with more than adequate storage capacity. By contrast, it could manage virtually anything job I threw at it.

I decided, then, to define the Arduino’s responsibilities as anything that another more powerful machine could not do:

  • Sample a temperature from a probe
  • Turn a switch on or off

I will get more in to depth in regard to the software architecture and the decisions I made later on.

Cost

I’ve been asked more than once about the cost of this project, so I’ll try to recount the ballpark numbers. Altogether, the project cost me a little over $1000 (I assume the fridge to be “free”). The majority of that was in construction materials, tubing, etc. The electronics accounted for about $400 of that. I had some considerable waste, as I will explain later, so others could easily build something like this with a smaller budget. Also, it may be perfectly acceptable to use only one pump instead of three.

In a later article, I will attempt to list the items I purchased (a “bill of materials”).

See the Fermentation Controller index page for more information on my project.

2010
01.27

One of the drives in my 3ware 9650SE card recently gave me cause for concern: it randomly began rebuilding and the raid went into degraded mode. There were no SMART errors issued, so I did some digging in the smartcl manual in order to run some self diagnostics. There’s a lot to smartctl to begin with, and the syntax for addressing a drive inside a 3ware RAID is cumbersome. So I thought I’d make note of the useful commands I came up with.

First, to address a drive in a 3ware RAID, pass “-d 3ware,X” to smartctl, where X is a drive number (starting with 0). To list all SMART output for the second drive, for example, run:

smartctl -a /dev/twa0 -d 3ware,1

The -a switch will print out everything. In order to run this on the first (in my case all) four drives, and filter on the temperature output, I run:

for drive in {0..3}
do
    smartctl -a /dev/twa0 -d 3ware,$drive | grep Temperature_Celsius
done

After the aforementioned drive issues, I issued a command to run extended self tests on all drives, like so:

for drive in {0..3}
do
    smartctl -T permissive /dev/twa0 -d 3ware,$drive -t long
done

These tests can be run while online. In order to see the results (including progress along the way):

for drive in {0..3}
do
    smartctl -T permissive -l selftest /dev/twa0 -d 3ware,$drive
done

So far no errors have turned up.

2009
09.30

I’ve been on a man-hunt lately to evict all ATI cards from my machines. ATI may make good cards — I won’t argue that — but their support for Linux is pathetic.

I replaced my old ATI Radeon x1650 with an Asus NVidia 9600 GT Silent. Asus’ Silent version of this card takes up two slots, the second being for its massive heatsink. The card uses no fans, only an enormous heatsink. Naturally, it is completely silent, but performs like a champion.

To drive my dual 24″ monitors, I set up my Xorg to use NVidia’s Twinview. I’ve read (and (disclaimer) this may be incorrect) that Twinview is a similar technology to Xinerama, with the difference being that Twinview presents a single display to Xorg encompassing both displays while Xinerama runs a separate Xorg on each display with some hacks to allow windows to be dragged back and forth, etc. (If anyone can elaborate or clarify here, please chime in.)

Anyhow, this tends to confuse some applications into thinking that there is only one display, and that it is only capable of one resolution. Whether this is full screen Youtube, mplayer, or a video game, it is quite a nuisance.

After some searching, I discovered that adding a “metamodes” option under my Screen section in xorg.conf could allow applications to think other resolutions were supported. Here is my xorg.conf:

Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0
	Option		   "OffTime" "10"
EndSection
Section "Files"
    FontPath        "unix/:7100"
    ModulePath      "/usr/local/lib/xorg/modules"
    ModulePath      "/usr/lib/xorg/modules"
    FontPath        "/usr/share/fonts/"
    FontPath        "/usr/share/fonts/misc"
    FontPath        "/usr/share/fonts/100dpi:unscaled"
EndSection
Section "Module"
    Load           "dbe"
    Load           "extmod"
    Load           "type1"
    Load           "freetype"
    Load           "glx"
	Load           "kbd"
	SubSection	"extmod"
		Option		   "omit xfree86-dga"
	EndSubSection
EndSection
Section "ServerFlags"
    Option         "Xinerama" "0"
EndSection
Section "Monitor"
    # HorizSync source: edid, VertRefresh source: edid
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "DELL 2407WFP"
    HorizSync       30.0 - 83.0
    VertRefresh     56.0 - 76.0
    Option         "DPMS"
EndSection
Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce 9600 GT"
EndSection
Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "TwinView" "1"
    Option         "metamodes" "DFP-0: nvidia-auto-select +1920+0, DFP-1: 1920x1200 +0+0; DFP-0: 1600x1200 +0+0,NULL; DFP-0: 1280x1024 +0+0,NULL; DFP-0: 1024x768 +0+0,NULL; DFP-0: 800x600 +0+0,NULL;"
    SubSection     "Display"
        Depth       24
		ViewPort 0 0
    EndSubSection
EndSection

If I remember correctly, the metamodes option was created by the nvidia-settings utility, but only contained the string, “DFP-0: nvidia-auto-select +1920+0″. I added the rest. The display specified (DFP-1) seems arbitrary, as do the coordinates. So just add something similar, replacing the resolutions as appropriate.

Hope this helps others who encounter similar issues, as I had a very difficult time finding anything useful on this matter.

Search engine optimization by SEO Design Solutions