LowBrau morphs into a Raspberry Pi brewbot

October 7, 2013

It’s been 4 months since I last wrote about my automated brewing project.  LowBrau was meant to be a low cost single-vessel automated step mash and boiling system.  But, although the controller box was mostly complete, I ran into problems when I fried my Arduino.  That and the hellishly cramped nature of my project box (which was designed to sit neatly under the boiling vessel) really put the brakes on mentally for me – I just wasn’t super motivated to push forward.

Although I may have been silent on this one, I have been working on the next iteration of the project for the last couple of months.  It was always my intention to not simply clone the commercially available systems, but to better them where I see a feature that is clunky or limited.  As a result this hiatus seemed like the perfect opportunity to rethink the core technologies of the project.

The biggest change is that I have now decided to ditch the Arduino and base the control box off a Raspberry Pi.  At $35 this little embedded linux computer is vastly more powerful than an Arduino, yet it really isn’t much more expensive than a name-brand Arduino.  It will allow profoundly enhanced functionality.

I also bought a far bigger project box.  Rather than living under the boiling vessel this one will be fully detachable, with all inputs and outputs connected via sockets.  It can happily live on the bench next to the brewbot.  I divided it into two physical sections with an off-cut of PVC square-section drainpipe to separate the high and low voltage components.

I’ll write a bit of commentary about each main component pictured in the photo below…

PiNT control box

As I wanted the control box fully detachable the AC power comes in and the pump and element connect via IEC sockets.  I went with snap in mountings rather than ones that require bolts/rivets, so all that was needed was an accurately sized rectangular hole to push them through.

The element and pump are switched by solid state relays.  Mine are Fotek 25DA.  I neither recommend or warn you off them – other than to say that they cost less than $4 each including postage and one of them came dead-on-arrival.  They’re mounted onto the heatsink used in the previous edition of the controller box.

Lastly in the high voltage area there’s the 5V 2A power supply module.  Everything else in the box gets powered off this 5V supply.  The RPi requires 1A, so there’s an additional 1A overhead for all the rest of the bits.

Down the left hand side is the Raspberry Pi (RPi).  The 26 pin general purpose input/output (GPIO) connector is connected to my breakout board via some grey ribbon cable.  I have thrown a very cheap $4 USB wifi (rtl8188cus chipset) on the RPi which will allow the advanced interface opportunities.

The temperature probe attaches via a 4 pin socket on the right.  The probe uses the DS18B20 chipset which is read natively by the RPi using the 1-Wire connector on the GPIO.  In linux the output of this probe appears as a text file for easy reading.  Couldn’t be simpler.

Along with wifi control, I also want to keep the option to control everything through the control box as usual.  I have selected a 20×4 LCD ($5), which provides more screen space than the Braumeister’s 16×2.  This in turn will allow me to implement a more sensible user interface that doesn’t require so many nested menus and laborious button pressing.  The LCD is a standard HD44780 chipset, however I do not connect it straight to the GPIO.  I have soldered to the back an i2c conversion board ($3) which further shrinks the number of IO lines to 2.  It also conveniently takes care of all the contrast potentiometer wiring.  Between this board and the RPi is a level shifter board ($2).  This is necessary because the RPi GPIO all works off 3.3V levels, not the 5V standard.  This board is bi-directional so it pumps 3.3V signals to 5V in one direction and 5V back down to 3.3 in the other.

On a related note, all the other outputs (SSR signals and LED indicators) are passed through a Darlington array (60c).  The 3.3V supply internal to the RPi only has a total capacity of 50mA – so even 3 LEDs would take it beyond its capacity!

The buttons are set with both pull-up resistors and current limiting resistors.  The pull-ups (10k) are required to stop the inputs from floating.  The current limiting resistors (1k) are often left out by people, but they’re a pretty good idea to do it correctly.  If your GPIO is always set up correctly as inputs then you’d never need them, but in the case that they get set erroneously as outputs they prevent them from creating a short circuit between the RPi output and ground.  I have also installed 100nF ceramic capacitors across the terminals of the buttons to hardware debounce them.  A quick circuit diagram is below.

PullUp-SwitchProtected-DebouncedAnd finally, there’s a speaker and amplifier.  One of the annoyances I find with the Braumeister is the incessant beeping that seems to accompany almost every step of the process.  Yet despite this it can also be surprisingly unapparent when everything has stopped waiting for you to press a button.  I have decided to solve these problems by replacing the buzzer in favour of voice prompts driven off the RPi audio output.  While a flashing status LED will give clear indication that a user input is needed.  The amp is a 5V D-class 3W audio amplifier ($3), which is commonly used in USB speakers and for that reason conveniently runs off my 5V supply and is plenty loud enough.


RaspBMC: Ebay USB IR remote

December 8, 2012

raspi_remote

One of the beauties of RaspBMC is the variety of control methods available to the user.  My first box is connected to an HDMI-capable television and uses CEC to pass control codes from the TV to the Raspi, which is all very neat and convenient.  I also use Yatse XBMC remote on my Android phone because there are lots of benefits to being able to browse titles, select and queue content to watch (it can also be a little more responsive than the TV remote).  I also like the feature where you can browse on your phone and send youtube content to the TV, etc.

But the second box is connected via composite video and so gaining control codes from the remote is not an option.  Until very recently this unit did not have network connectivity either, so control via a phone app wasn’t possible either.  Indeed even though it now does have wifi, phone control as the sole option isn’t exactly the golden solution.  Sure, browsing the library via the phone is much nicer than the blocky, hard to read, low resolution of the TV but for every day tasks like pausing, volume control, etc having to unlock your phone is not super convenient.

So I thought that I’d have a go ordering a really cheap, generic USB IR remote off ebay ($4 delivered) and simply see what happens.  Again this is one of those areas where I have not read any forums posts about whether or not this works but it’s not a high-stakes gamble.

And the answer is that yes it does work.  You’ll need to reboot to get it to recognise, it won’t just hot-plug the same way that connecting a mouse to your PC would.  Many of the common keys are already functional straight away (eg play, pause, arrows, page up/down) and the mouse feature also works.  There are plenty of buttons however that are not assigned, but that should be fairly trivial to work out using a similar approach to detecting CEC commands via SSH and then creating an appropriate entry in /home/pi/.xbmc/userdata/keymaps/remote.xml.


RaspBMC: USB Wifi with RTL8188CUS

December 7, 2012

raspbmc_wifi

I recently built up my second RaspBMC box and due to its location this one really has a need for wireless network connectivity.  Taking a quick look on ebay this is actually a very cheap thing to achieve – indeed, a tiny USB wifi adapter at $4 (including postage) is cheaper than buying a network cable.

The one draw-back is that I have read many forums posts about people having issues with certain chipsets not being supported by RaspBMC out of the box.  In particular was Realtek’s RTL8188CUS, which seems to be by far the most popular (if not completely ubiquitous) chip in these cheap usb wifi sticks.  Most of the posts seemed to me to be a number of months old and in that time the RaspBMC project has come a long a lot in terms of updates.  So, although I have not read anything to say that this problem has gone away, I thought I would commit the measly funds required to buy one regardless and see what would happen.

And so the point of this post… I have tried it with RC4 and the RTL8188CUS chipset works totally fine without the need to install any additional drivers.  The Network Manager add-on was required, however, to get everything configured and connected.  And it’s worth noting that if initial wired network connectivity is a problem there are some pre-built images available which come with this add-on already installed.

Hopefully this post will let others know that it appears that bog-standard ebay adapters are now fine after all and the search for less widely available chipsets is no longer required.


RaspBMC: Samsung remote key codes

November 14, 2012

In a previous post I detailed the difficulty that I have been experiencing mapping the non-standard key codes implemented by Samsung for my television remote.  In that post I showed how SSH can be used to inspect log files to see what actions are taking place in response to key presses.  While this can be very useful it is not always possible to discover all the key names in order to map them.  So the purpose of this post is to keep a running list of the keys on my remote, whether they are mappable and what their key code is (if I can discover it).  As I find new codes I’ll update the list.

First of all here’s a picture of my remote for reference.  I would seem that plenty of Samsung TV remotes for different models keep the same physical layout but just screen print different labels on the buttons.  If your remote differs from mine only in a minor way it may be worth matching your physical button up with mine and giving the respective code a go.  Certainly on my remote the key codes do not necessarily match the physical label on the button.

So working from left to right, top to bottom I will present each button in the following format: <physical label>,<behaviour>,<key code>…

POWER    tv only  --
TV/DTV   tv only  --
ON/OFF   tv only  --
1        passed   one
2        passed   two
3        passed   three
4        passed   four
5        passed   five
6        passed   six
7        passed   seven 
8        passed   eight
9        passed   nine
-/--     passed   title
0        passed   zero
PRE-CH   ??       ??
+(ch)    passed   pageplus
MUTE     tv only  --
^(vol)   tv only  --
-(ch)    passed   pageminus
SOURCE   tv only  --
v(vol)   tv only  --
GUIDE    passed   guide
MENU     tv only  --
W.LINK   tv only  --
TOOLS    tv only  --
^        passed   up
RETURN   passed   ??
<        passed   left
ENTER    passed   select
>        passed   right
INFO     tv only  --
v        passed   down
EXIT     passed   back
RED      passed   red
GREEN    passed   green
YELLOW   passed   yellow
BLUE     passed   blue
TTX/MIX  tv only  --
P.SIZE   tv only  --
DMA      tv only  --
E.MODE   tv only  --
CHLIST   passed   livetv
SUBT     tv only  --
<<(rew)  passed   reverse
PAUSE    passed   pause
>>(ffwd) passed   forward
REC      ??       ??
PLAY     passed   play
STOP     passed   stop

RaspBMC dual card risk mitigation strategy

October 8, 2012

Recently the RC5 update came out for RaspBMC.  Unfortunately for me (and others) this update completely boned what was a perfectly functioning RC4.   It all started during the update process when my system got stuck in an endless loop of RaspBMC logo, XBMC time-out screen and install progress bar.  Even after a fresh install (ie loosing all my library database, custom keymaps, etc) it’s still horribly flakey – a scan to sync files with tvdb, etc causes the system to hang, the network drops out and the GUI freezes and gets covered in terminal text with clockwork regularity.

It must be said that this project is well and truly up the hobbyist end of the open-source community spectrum and quality control is not exactly robust.  It is after all basically one guy’s hobby putting it together (and what a great guy for doing it!).  But this doesn’t reduce the frustration when you go to use your media centre only to find it’s auto-updated itself into a flaming heap.  Yes, that’s right: auto-updates are turned on by default.

I can’t help but think that the responsible course of action would be for them to distribute the system with auto-update turned off by default and for the RaspBMC website to list prominently on the necessary hardware page a recommendation to run two SD cards – a primary and a test card.  Having just visited the local supermarket this is exactly the operating model that I plan to adopt.  This way the current system can be duplicated onto the test card, the update applied to it, it can be run in for a day or two and then if it all works okay it can be kept.  Should it all grind to an awkward halt then it’s super easy to simply swap the cards back like nothing ever happened.

I fully acknowledge that this project is still very much in the embryonic development stage, but users should be encouraged to treat it as such – and that involves treating updates with a high degree of skepticism until shaken down, to maintain a robust backup strategy and not to rely on the irreversible inbuilt auto-updaters.  Yet this isn’t the how it comes across in their documentation – if anything the opposite: the auto-updater has its praises sung and the files needed to install previous versions are not officially provided (I got my image file from a bloke on the forums!).

By officially encouraging the use of two cards (which let’s face it costs loose change) all the potential bad-blood from a premature code release is completely negated.  For me, if I manage to get one other user onto the dual-card system without having to find out the hard way then this post has been worth it.


RaspBMC: mapping Samsung remote

September 22, 2012

One of the great features of RaspBMC is the ability to control it using your existing TV remote when connected via HDMI.  It accomplishes this task by making use of CEC to pass control codes from the TV to the Raspberry Pi.

While most of the important buttons on my Samsung TV pass happily through to XMBC (such as navigation arrows, play, pause, stop, etc) one of the controls which is sorely missing is the ability to access the context menu.  Which means that every time I need to alter a setting I need to plug in a usb keyboard.  I would also like to be able to adjust the XBMC volume using the remote.

Thankfully XMBC is designed in such a way that you can set up your own custom keymaps to alter the behaviour of the existing remote buttons or add new ones.

The first step is to work out which of the buttons on your remote actually get passed through to the Raspi.  Not all buttons on a remote are CEC enabled, which seems to be at the whim of the TV manufacturer as is the name that each button appears as.  My volume buttons are not enabled so I want to remap Channel Up/Down to perform this function when video is playing.

If we connect to Raspi via SSH (using a terminal program such as putty) then we examine the status updates recorded in xbmc.log in response to each key press…

tail -F /home/pi/.xbmc/temp/xbmc.log

This then shows the name of each button (in this case I pressed the ‘green’ button).  The response was to bring up the Videos screen.

22:00:43 T:1182790720   DEBUG: CecLogMessage – key pressed: F3 (green) (73)
22:00:43 T:1182790720   DEBUG: PushCecKeypress – received key fc duration 0
22:00:43 T:1102835712   DEBUG: OnKey: 252 (fc) pressed, action is XBMC.ActivateWindow(MyVideos)

(You may find that key presses are not being logged.  If this is the case then you need to create /home/pi/.xbmc/userdata/advancedsettings.xml and add the lines <advancedsettings> <loglevel>1</loglevel> </advancedsettings>)

Then the final step is to make an entry in /home/pi/.xbmc/userdata/keymaps/remote.xml to bind the key to a new action (such as XBMC.ActivateWindow(VideoLibrary,MovieTitles).  The list of actions can be found the XBMC wiki (ButtonTranslator.cpp).

However things get more complicated with my Samsung remote because many of the buttons do not come up with their actual name…

12:10:10 T:1183839296   DEBUG: CecLogMessage – key pressed: channel up (30)
12:10:10 T:1183839296   DEBUG: PushCecKeypress – received key d2 duration 0
12:10:10 T:1075412992   DEBUG: OnKey: leftshift (d2) pressed, action is PageUp

Above is what happens when I press the Channel Up button.  From the above log you would expect this to respond to something like a <channel up> or <d2> tag.  But it doesn’t.  The tag you want is inexplicably <pageplus>.  The way I found this out was that this button already had a behaviour associated with it in /opt/xbmc-bcm/xbmc-bin/share/xmbc/system/keymaps/remote.xml, so I could trace it back.  However there are buttons on the remote that do pass CEC codes through but aren’t already defined with a behaviour and it seems at this point in time I have no way of finding out what their tag should be!

This is a real pain, because of all the buttons that pass through CEC only half of mine I can work out the correct tag for.  Grr!

So anyway my volume fix ends up looking something like this…

<keymap>
  <global>
  </global>
  <FullScreenVideo>
    <remote>
      <pageplus>volumeup</pageplus>
      <pageminus>volumedown</pageminus>
    </remote>
  </FullScreenVideo>
</keymap>

UPDATE: work-in-progress listing of codes


Raspi starts its life as media centre

September 10, 2012

I now have the Raspberry Pi hooked up with my TV.  It’s really something great.

HDMI has now given a new way to control the Raspi – it passes CEC control codes from the TV remote so no extra remotes are required, and the keyboard can disappear.  HDMI-CEC fires up automatically with no configuring required, however my Samsung TV only passes the basic TV remote keys to the Raspi and I will need to edit an xml file if I want to assign a key to access the context-menu.  No biggie.

I learned very early on that if I want my media files to happily slot into the libraries that I would need to rename a lot of my content so that it scrapes properly.  Originally the scrapers were mis-identifying most of my films and shows, but if you sacrifice your own free thought to the XMBC naming conventions then everything very quickly resolves itself.  Of course one could always choose not to use the scrapers and just browse through file structures, but you’d miss all the bling of cover art, plot information, genre categorisation, etc.  And if you do name things correctly then you can also get XBMC to treat multi-part/split files as single gapless files – which is excellent for films whose encoding harks back to the CD-era.

I set up the local (Australian) TV catch-up services without any great issue (apart from SBS On-Demand creatively being called SBS2 in the addons).  I was rather hoping to be able to access overseas catch-up and streaming services but most of this content is blocked for foreign IP addresses.  Having fiddled around with proxies, which most addons support, I’ve given up on this for the time being.  It’s way too hard to find a combination that actually works.  Which is a pity because I’d love to ditch the moron Australian F1 commentators and get the unadulterated feed from the UK.  Apparently this is possible using TOR set to GB outlets, but again I think this is a bit of a stretch for me at the moment.  I’ll just stick with missing all the action while a baldness remedy advertisement is being shown for the billionth time…

The performance of RaspBMC is excellent.  I know some people who are used to running XBMC on a full-sized multicore tower find it lacking, but this thing beats the pants off my $300 DVD player.  And unlike the HTPC it’s fanless, silent and you can hear your programs.  I find the Android remote useful for queuing content, but the TV control via HDMI-CEC is perfectly responsive enough that all my usual controlling happens through that.

I originally had the box powered off the TV’s usb port and it was quite happy to do so.  It meant that the Raspi would turn on and off with the TV.  But I have had a change of heart on this because it basically means that I’m crash-stopping it many times a day, and this really can’t be a good thing.  So now it’s being powered off a spare usb plugpack and lives on all day.  Of course if you had a TV that was configurable to allow permanent usb supply even when off (which many sets do) then you could save yourself some cable mess.

This really is an excellent project for anyone to get involved with.  I found the software setup and install very easy.  The RaspBMC guys provide a Windows-based helper program which allows you to download and burn system images to your SD card, and really everything else on the Raspi just gets detected and configured automatically.  You don’t need to be a boffin to set up a <$40 media centre (and cheat your way into some healthy nerd-cred).