Keggerator

We used to have an old bar as our dining table. It kind of came about by chance. It wasn't designed for that and was a bit of pain to use - not much overhang meant you couldn't get your knees under. But we liked the height.

When thinking about a replacement, I thought of making the underside more functional too.

Why not put a chest freezer under there to hold our beer? An upgrade from the 2-keg system we had would also be welcome. Chest freezers are great for the job - they are well insulated and when you open the lid, you don't let all the cold air out.

So in early 2011 I got a new chest freezer, built a collar, a bigger 4'x4' birch hardwood table top and installed our taps.

I built up a temperature controller to maintain the beer temperature (turn off before freezing).




All good. Only problem was it quickly accumulates junk, so often it isn't opened easily. Which makes checking beer levels harder.

There is nothing worse than running out of beer.

So I started scheming on ways to detect the beer level in the kegs.

The method I decided on was to weigh each keg.

I had seen a hack online where a guy had modified his bathroom scales to log his weight each time he got on. I think the hack involved wiring the display output to a micro controller.

I got a $15 set of bathroom scales thinking I could do the same. But the scales I had only turned on when you got on, and first needed to calibrate itself with no weight on it. Not so good for continuously weighing the kegs.

So I started to poke around the load cells it used. It had one in each corner. They seemed to be 3-wire units setup as a 2 wheatstone bridges. But they also seemed pretty insensitive. I could only get a single load cell to give a 0.5 mV change with the weight of a full keg when driven at 10V.

I originally hoped that I could use one load cell from each corner of the bathroom scales for each keg. But that signal was just too small. The gain needed would make the amplifiers unstable and susceptible to noise.

I ended up using 2 load cells for each keg, in a wheatstone bridge (so about 1mV signal at full deflection) and some INA129 instrumentation amplifiers setup with a gain of about 2000.




The circuit consists of + and - 5V regulators supplying the load cells and amps. Each amp has a low pass filter and diodes to clip the signal to 0-3.3V to keep the micro controller happy.




The display is a pretty simple bar graph and estimation of the amount of beer left.



Finally a demo of it in action:

STM32 LCD touch screen demo

[Update: Torrent available for downloading the Virtualbox image ]

You see many hobby projects use the good old 16x2 LCD.

Pretty easy to use. But limiting. No graphics. Limited text. Hard to have a very complicated UI. You need some other device for input - push buttons usually. Unintuitive.

In a word: ugly.

Most consumer devices these days include a graphical LCD and touch screen interface. People understand how to use them. People expect them.

So I started to get away from 16x2 LCDs in my projects.

Fortunately 320x240 LCDs with touch screen and micro controller can be had cheaply on ebay. So I have been using them for my projects.

I have a some friends who have started using these boards or expressed interest in using them. Now they are ARM based and can be tougher to bring up that an Arduino. So I have decided to make a downloadable VirtualBox image that has the toolchain and environment setup, with a demo project, that includes a simple menu system. This should help people get started with these boards.

Which boards?

ebay auctions expire all the time, so it's hard to link to specific boards. Instead take a look at a search:

http://www.ebay.com/sch/i.html?_nkw=STM32+tft+lcd

Look for the ones that are clearly 2 boards - the LCD board on top. CPU is usually a STM32F103.

The first sort of board has a 2.4" LCD:

The second has a 3.2" LCD:

Both LCDs are the same resolution, but I prefer the 3.2", it's substantially bigger (and so buttons will be bigger for fingers to hit).


However the board with the smaller LCDs have other goodies, like 16MB flash, speaker and RS232.


You can take a look at the schematics for each:

• STM32 board with 2.4" LCD 
• STM32 board with 3.2" LCD 

Either way, LCD + touch screen + STM32 CPU for less than some Arduinos cost.


STM32 CPUs are significantly more powerful than the trusty old Atmels (Arduinos).
 Your code may have a main task to accomplish, and then the LCD+touch UI to look after. Programming to bare metal, this can be tricky to pull off. Why not use a multi-tasking OS to help?

FreeRTOS to the rescue. Go read the 5 or so pages here for a good overview of how it works:

http://www.freertos.org/implementation/a00002.html


So then how to get started?

I have put together a VirtualBox image you can download that contains:

• Ubuntu desktop
• ARM toolchain (gcc + newlib)
• Eclipse C++ IDE
• stm32loader.py - for loading code into the board
• openocd - for loading code and debugging
• Example FreeRTOS project with all source code, include LCD+touch drivers and a simple menuing system to get you started quickly

 Demo

Getting started

Download the virtual box image: https://www.dropbox.com/s/rkpiq3wa1jfnof9/ubuntu_stm32.7z

https://thepiratebay.se/torrent/7803003

(~800MB download, ~3GB disk space uncompressed)

Login/password: ubuntu/reverse

Install virtualbox if you don't already have it: https://www.virtualbox.org/

You will need 7-zip to uncompress the image: http://www.7-zip.org/

Create a new virtual machine in the Virtual box manager. Give it a gig or ram or so. Select "Use existing hard disk", and choose the ubuntu image. Boot it up.

Building and running the demo

Demo menu code walk through

Loading code

The ARM Cortex M3 chips have a built in bootloader that allows you to load code over the serial interface.

http://www.micromouseonline.com/2009/05/08/stm32-arm-cortex-bootloader/

You need to boot the device with the boot0 pin grounded. Most dev boards have a switch or jumper.

This can become pretty tedious so it's worthwhile to get a JTAG programmer - you can then load your code faster, without touching the board. You can also run openocd and gdb to help debug your code.

I use and recommend a bus blaster:

http://dangerousprototypes.com/docs/Bus_Blaster



OpenOCD config files are included in the JTAG directory in the Virtalbox Image.

You will also probably need a 20 pin JTAG cable.

printf debugging

gdb & JTAG debugging

Boot, FreeRTOS and the LCD - how it comes together

Pump testing and new solenoid

Mash recirculation pump

Upgrade plans

There are some problems with the fresh water delivery part of the brewbot.

a) The quick disconnect I was using for connecting the brewing vessel to the water supply ended up containing some steel which had began to rust.

b) The clear PVC hose I was using was not up to mains water pressure and eventually burst.

c) The water delivery rate was too high and I was using a small tap on the Y-piece in the laundry to control the flow rate. This was difficult to tweak.

So the solution is to move to a braided dishwasher hose, new 1/4" all brass solenoid and standard corny keg quick disconnects. I'm hoping the smaller 1/4" solenoid and corny fittings will reduce the flow rate sufficiently.

While not a huge problem, we were also seeing a fair bit of trub in our final wort.

My mates over at http://www.aussiehomebrewer.com are all about the Speidels Braumeister. Interestingly this is what inspired BIAB back in 2006.

This system is a single vessel system that recirculates the wort for the duration of the mash. The grain bed catches a lot of protein and particulate leaving very clear wort.

I'm interested in experimenting with this technique in a different configuration for the brewbot.

Instead of having an impeller based pump sit under the vessel, I'm thinking of having a peristaltic pump mounted above the vessel with hoses attached to the lid that lower with it.

The peristaltic pump should be able to self prime and hopefully deal with any fine grain particles.

The new mash process would be:

a) lower the grist bag into the strike water
b) stir the mash for the first 5-10 minutes
c) run the peristaltic pump for the remainder of the mash
d) raise the grist bag

The mash would be a RIMs effectively.

Unfortunately most cheaply available peristaltic pumps offer pretty low flow rates. The ones that offer higher rates are both expensive and bulky.

So I'm going to have a go at building a ghetto version with the silicon hose I have, some small ball bearing and another windscreen wiper motor. I'd kill for a lathe, or even a drill press at the moment, but hopefully I get something going to prove the concept.

Results, prizes and return

A lot has happened since the last post.

The brewbot was packeted up and sent off to California for judging. For that I had to build a box to hold it.

The results came back and the Brewbot picked up 3rd place:

http://www.renesasrulz.com/community/rx-contest

Dave Jones did a video on how some of the judging went:

http://www.eevblog.com/2011/06/05/eevblog-174-renesas-rx-design-contest-winners/

All of my prizes have arrived and the brewbot is back home too.

A big thanks to Renesas, Micron and Total Phase.

TTL Bluetooth Transceiver with Linux

I recently got one of these cheap chinese TTL to Bluetooth transceivers.

http://gb.suntekstore.com/wireless-bluetooth-transceiver-module-rs232-||-ttl.html

I got mine off ebay delivered for under US$7. The seller unfortunately didn't have a pinout diagram or any real info about the module (or maybe couldn't understand enough English to work out what I was asking).

I figured that all of them on the market are probably the same design so it shouldn't be a big deal.

Luckily I was right. The best resource I found was this:

http://www.egochina.net.cn/e-shop/ebay/datasheet/Bluetooth_Module_L6.rar

A number of diagrams, manuals and pieces of software in that archive.

The only problem is they are all windows specific.

The Ubuntu Bluetooth applet let me see and pair with the device, but no clue on how to use it.

Time to learn a little more about the Linux bluetooth stack.

hcitool scan
Scanning ...
 00:19:5D:24:B7:63 OBDII

Ok so we can see it from the command line and see it's address, it's the only thing found.

Most of the other diag tools didn't return any useful info.

Eventually I found the following to work.

sudo rfcomm bind /dev/rfcomm0 00:19:5D:24:B7:63

picocom -b 38400 /dev/rfcomm0

At that point I could talk to my MCU over bluetooth!