The UI is Alive!

I've started working on the UI for the fermentation controller and thanks to Storyboard things are coming together very quickly.  I mentioned Crank Storyboard Suite in my first post and I'm going to go into some detail on how I'm putting together the interfaceand control logic using Storyboard.  As noted in my first post I've been a Crank Software employee since July 2010 and not only is it a really awesome place to work, we produce an incredible tool for designing and deploying UI applications to embedded targets.  A Storyboard deployment consists of two things, the Runtime which is a board specific package of binaries and libraries used to render the Storyboard Project you deploy to the target and the Project, which consists of the exported gapp file and the image assets and scripts.  Storyboard supports a wide variety of CPU/OS/Graphic chipsets.  For the Beaglebone Black I'm running the Linux Codesourcery Armle FBDev runtime, this allows me to run a GUI without having the overhead of X-windows as it renders content directly to the framebuffer on the target.  If my beaglebone image supported the SGX graphics processor and I had the right OpenGLES libraries installed I could also run the OpenGLES_2.0 runtime which would unlock some nifty 3D transition and animation options.  Unfortunately for me the Linux image I'm running doesn't currently support the SGX chipset yet, so I'll be running on FBDev for now.

Storyboard uses a WYSIWYG editor to enable the user to place the controls and graphics by dragging and dropping.  Variable's can be assigned to control data and then updated using either the integrated Lua scripting or by using the greio API provided in the runtime.  The API allows a user to write a native C application that can send data to and receive data from Storyboard, I had originally planned to write a small daemon that would read the 1-wire temperature data and pull up the proper GPIO line to enable the SSR which would switch on the cooling device plugged into it.  After a bit of research I discovered that Rsisto had published a free to use GPIO library for Lua.  Since Storyboard has full support for Lua baked right in, I can simply write all my code as a Lua script, making my application that much simpler as all my code now lives in a single Storyboard project!  I was pretty excited to get started so I whipped up the fastest thing I could, I honestly spent less than 10 minutes putting together the UI you see in the video below, I plan on making it a lot nicer in the coming days, but I wanted to get the bare minimum up to test the GPIO library and to make sure the temperature reporting was also working properly.  Check out the very quick demo below;

It's a little difficult to see in the video but I have a room lamp plugged into the outlet controlled by the SSR, when the GPIO line is pulled High the SSR enables the 110v circuit to complete energizing the plug and anything attached to it.  The idea here is that when we go above a certain set-point we want the fridge that acts as my cooling source to turn on which will drive the temperature in the fermentation chamber down to our set-point and keep it there ( within a couple of tenths of a degree ) so that the wort is fermented at exactly the temperature we want.  I will also be adding a heating element which will be controlled by another SSR which will turn on a heating element of some kind so I can manage my temperature exactly.

And now the Lua code that controls the GPIO and feeds the temperature display on the GUI.

require ("gpio") -- import library
local device_path = '/sys/bus/w1/devices/28-00000449da30/w1_slave'

-- setup the device defaults
local ssr_fired = false
configureOutGPIO(60)
writeGPIO(60,0)

-- timer callback function, read temp every second and update GPIO as required.
function read_temp()
 local f = assert(io.open(device_path, 'r'))
 local t = f:read("*all")
 local temp
 local data_table  = {}
 
 
 f:close()
 for w in string.gmatch(t,"t=*=(%d+)") do
  temp = w
 end
 local report_temp_c = string.format("%.2f",temp / 1000)
 data_table["probeTemp"] = report_temp_c
 gre.set_data(data_table)
 local temp_c = temp/1000
 --print (string.format("Got temp of %s C",temp_c))
 if ( temp_c > 24 ) then
  if ( ssr_fired == false ) then
   local data_table  = {}
   print("Turning on")
   ssr_fired = true
   data_table["Layer1.Cooling_On.grd_hidden"] = 0
   gre.set_data(data_table)
   writeGPIO(60,1)
  end 
 else
  if ( ssr_fired == true) then
   local data_table  = {}
   print("Turning off")
   ssr_fired = false
   writeGPIO(60,0)
   data_table["Layer1.Cooling_On.grd_hidden"] = 1
   gre.set_data(data_table)
  end
 end
 

end

This is a first cut at the logic behind the temperature controller, but all of the magic required to turn on and off the cooling element is already here, I just need to make it a bit smarter. The first thing I'll be adding is some hysteresis so that the system doesn't cycle the mini-fridge on and off constantly as the temperature hovers around the set point. The primary reason for this is that compressors in fridges don't take very well to being cycled on and off frequently. I will be building in a 2 minute delay to prevent burning out the compressor. I also plan on displaying the temperature values in a graph that will update constantly so you can get a quick overview of the fermentation schedule and see if there were any drastic changes due to a heating/cooling system failure. As it stands I've got a nearly functional fermentation controller application and I've spent more time writing this blog entry than I have building the GUI and control logic! I'll be spending the next couple of days polishing the GUI and rounding out the control logic and adding in the graphing of temperature values. After that I'll switch over to building out the Web interface which will allow for the uploading of Fermentation profiles and for controlling and viewing the fermentation from any Internet connected device.

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.