Device Trees and You!

Linux is pretty awesome, and the fact that I have a board the size of a credit card that can run a full Linux OS is incredibly awesome.  This awesome does come with a bit of a price though.  A stock Beaglebone Black comes with a pre-built version of Angstrom Linux which allows you to boot the Black and setup some software packages like a webserver or a database.  What it doesn't do out of the box is talk to the 1-wire device, the DS18B20 temperature probe I'm using.  To do that you need to define a Device Tree Overlay.  This file, when compiled into your kernel image, will tell the hardware what GPIO pin the signal from the 1-wire device is coming in on.  Here is the .dts file I found on a very helpful site called Hipstercircuits.

 /dts-v1/;  
 /plugin/;  
 / {  
      compatible = "ti,beaglebone", "ti,beaglebone-black";  
      part-number = "BB-W1";  
      version = "00A0";  
      /* state the resources this cape uses */  
      exclusive-use =  
           /* the pin header uses */  
           "P9.22",  
           /* the hardware IP uses */  
           "gpio0_2";  
      fragment@0 {  
         target = <&am33xx_pinmux>;  
         __overlay__ {  
                          dallas_w1_pins: pinmux_dallas_w1_pins {  
                               pinctrl-single,pins = < 0x150 0x37 >;  
                          };  
         };  
      };  
      fragment@1 {  
         target = <&ocp>;  
         __overlay__ {  
               onewire@0 {  
                    compatible   = "w1-gpio";  
                    pinctrl-names  = "default";  
                    pinctrl-0    = <&dallas_w1_pins>;  
                    status     = "okay";  
                    gpios = <&gpio1 2 0>;  
               };  
      };  
      };  
 };  

This file tells the Black that I want the 1-wire input to come in on the P9 Header on pin 22, if you look at the picture in my last post of the Black you can see a green wire going into a header, that's the data line from the DS18B20 going into the 22nd pin on that Header.  There are quite a few GPIO lines on the Beaglebone Black, some of them are reserved by the system already on startup so you need to know which ones are free, I took the .dts file above straight from Hipstercircuits and assumed the person who posted it had done the necessary research to identify that pin 22 wasn't already in use.

If you keep reading the post on Hipstercircuits you'll see they compile the .dts file into a binary .dtbo file, copy it into /lib/firmware on the Black and then enable it with the following command

echo BB-W1:00A0 > /sys/devices/bone_capemgr.9/slots

NOTE: on my Beaglebone Black my /sys/devices did not have a bone_capemgr.9 but a bone_capemgr.8.  I believe that is because I don't currently have a display connected, make sure the path under /sys/devices is correct for you before issuing the command above.

Since I didn't want to have to do this everytime the board booted, and as it seems like the Kernel currently has a bug that prevents loading userland .dtbo files we need to add our device tree to the Kernel by compiling our own.  If you've never compiled a Kernel, it's gotten a lot easier.  You'll need access to a Linux box, I used a Linux Mint 14 machine with no problems and only had to install one program, lzop, to finish the compile with no errors.

To compile the kernel follow the steps on this page, wiki.replicape.com.  Once you can compile a kernel with no errors you need to add the .dts file from above and follow the steps on this Hipstercircuts post.  In my case I had named my .dts file BB-W1-00A0.dts, in device tree language BB-W1 is the name and 00A0 is the version.  So in the section for editing /arch/arm/boot/dts/am335x-bone-common.dtsi you would use BB-W1 for both board-name and part-number and 00A0 for the version.  The manufacturer bit doesn't matter, I used Dallas.  Finally you need to add your compiled .dtbo file to the package which is done by editing kernel/firmware/Makefile and adding

fw-shipped-$(CONFIG_CAPE_BEAGLEBONE) += \
    BB-W1-00A0.dtbo

to the end of the Makefile fw-shipped section.   Recompile your kernel and then follow the instructions on the Kernel compile page for copying the new kernel to the Beaglebone Black.

NOTE: your rootfs/lib/modules/3.8.13-XXXXX-XXXXXXXX will have a different number than the one listed in the compile page, just do an ls -al in rootfs/lib/modules/ and find the version you compiled, mine had two directories, one with a -dirty flag so I left that one alone.  Once you've copied and rebooted your board and hopefully succesfully reconnected do a uname -a and you should see the kernel version report the current date as the compile time, if not you may have mistyped something.  Make sure your uImage symlink in /boot is pointing to your uImage-3.8.13 file.  It should have the date you compiled it as it's datestamp.  When that's done, you should be able to access the device and read a temperature.

root@beaglebone:~# python temp.py 
Temperature is 23.562 degrees

temp.py is a really basic program that simply reads from the 1-wire device that now shows up and translates the value read into a readable temperature.

import time

w1="/sys/bus/w1/devices/28-00000449da30/w1_slave"

while True:
    raw = open(w1, "r").read()
    print "Temperature is "+str(float(raw.split("t=")[-1])/1000)+" degrees"
    time.sleep(1)

NOTE: Your device address will probably differ from the one above, just look at /sys/bus/w1/devices and if you've only got one probe attached whatever address shows up will be your probe.  1-Wire allows multiple devices to be connected to the same pin, so theoretically I could add more probes to the same GPIO and they would show up with their own specific address, accessing the temps from those probes is as simple as changing the w1 variable to point to the new address.  I don't plan on adding more then one probe to CrankBrew so this is a moot point, but for those of you planning on monitoring multiple fermentations this would work really well.

Building an Automated Fermentation Controller - Why bother?

As a home-brewer I am constantly looking to make the best beer I can, and as a tinkerer I'm always looking for ways I can make that process easier and, at least in my mind, better.  One of the really important steps in brewing is Fermentation, for those of you unfamiliar with brewing, Fermentation is the process by which the sugars in your wort are converted into alcohol by the yeast you pitched.  Yeast are really good at their job, but they can be picky about working conditions and these conditions vary by strain and style of beer you're brewing.  When you first start brewing most new brewers will attempt to find a relatively cool place to ferment their beer, hopefully one that has some constant temperature like in a cold cellar or basement, and while this type of fermentation will often result in a good beer you're rolling the dice and relying on the ambient temperature in your house to decide the fate of your finished product.
People who don't have the luxury of a cold room or a basement with stable temperatures may opt to run a swamp-cooler which involves soaking a t-shirt or rag in water and wrapping your fermenter in the wet garment and placing this whole contraption into a bucket of water and pointing a fan at it.  This drives down the temperature of your fermenting beer through evaporation, you can even throw some ice-packs into the water to keep it chilled and can often get the beer down to an acceptable fermenting temp, although you have very little control over what that temperature will settle on and you can still experience large temperature swings.  

STC-1000 Digital temperature controller

Remember those picky yeast I mentioned earlier?  If you ferment beer outside of the acceptable range of the yeast you pitched you may experience attenuation problems, meaning the yeast don't finish the job of converting the sugars in your wort to alcohol and you can end up with a much sweeter beer than you intended.  Yeast also produce a number of by-products during fermentation, some of these by-products can really change the character of the beer and make it taste nothing like you intended, sometimes in a bad way.  The easiest way to prevent these undesired flavours is to control fermentation temperature more precisely.

To that end I built a chamber out of 2" rigid foam insulation which is attached to a very small mini-fridge which acts as the cooling source.  The first iteration of this build used an STC-1000 temperature controller to switch the fridge on and off whenever the set point of the controller was exceeded by .5 degrees C, and while this enabled me to control the fermentation at a static temperature, it made it difficult to run any kind of stepped fermentation where the temperature could be raised or lowered based on a set schedule.  The other problem with the STC-1000 is that it provided no way to log temperatures, or to be able to manage and modify the fermentation temperature without going into my basement and manually plugging in a new value.
I wanted more visibility and more control into my fermentation than I had with the STC-1000 and thus the CrankBrew idea was born.  While there are a few systems out there already based on the Raspberry Pi I really wanted to do something from scratch so I could build a truly custom system.  I choose a Beaglebone Black as the primary controller, it's similar to a Raspberry Pi but has more I/O pins, a faster processor, and built in storage and you get all that for about $10 more.

Beaglebone Black with test wiring for DS18B20 temp probe

I'll be logging the temperatures from the fridge so I can plot my fermentation schedule over time.  The unit will be controllable through a web-interface I'm going to build, but I also plan on driving a little touchscreen LCD from the unit.  I will be using Crank Storyboard Suite to build the interface.  I have worked at Crank Software for about three years now, and while that makes me biased, I also believe Storyboard provides a really impressive suite of tools for building your UI on an embedded platform.  The temperature information will be logged in a database and sent to the UI using the Storyboard IO API, this info will be used to present a Current Temp readout plus a trend graph of the temperature.  I'll also integrate the ability to pick a fermentation program that will be defined using the web tools so the chamber knows what temp to hold and for how long.