I've had mixed results recently working on HERMAN. Last week I began the process of re-plumbing the solenoid valves to tweak machine performance. This included having two water in valves (one dedicated to the mash tun and one dedicated to the HLT) after I found that reverse pressure would open them. The other change was brought about by installing the immersion chiller with agitator in the kettle. This meant I no longer needed to circulate kettle wort through a chiller until it reached pitching temperature. A side effect of this was that there was only one wort path out of the kettle (into the fermenter) compared to two previously.

I had to pull apart the valve that was part of the old kettle wort chilling loop and discovered a good deal of hop debris in it. I think it was a good move to eliminate this path. Now the chilled and settled kettle wort simply gets dropped via gravity into a fermenter. The valve and fermenter fill path will be sanitised at the start of brewing with Starsan or equivalent.

Through various plumbing changes I had a significant amount of trapped liquor. Revising the solenoid arrangement gave me the opportunity to add a low point valve (manually operated ball valve) for drainage. The changes also meant that the solenoids needed re-wiring.

All that seemed to progress quite well until it was time to connect everything up and test. The manual switches did not engage the relays and after about 15 seconds puzzling I noticed that a ribbon cable connecting the BrewTroller controls to the relay card was melting! I have no idea yet what was happening but this is one of the drawbacks of creating a complex vero-strip interface. I noticed one cable was not plugged in, but not sure why that would make a difference. At least the BrewTroller seems to be fully functional so that is a blessing. I'm eager to get a version 3 board with 16 outputs (assuming that will be the final arrangement) so that I can settle on some final interface designs and etch decent relay boards.

So at the moment I have a pretty looking set of solenoids that are not working.

Beyond that there were numerous small tweaks. This included improved plumbing between solenoids and tuns and changing the depth of the kettle temperature probe so that it is higher in the tun than the heating element. The idea is that when hot wort from the mash hits the probe, the BrewTroller can automatically apply kettle heating because the element will be covered. The BrewTroller control box was finally mounted properly with suitable placement of cables and space for the laptop to sit if so desired. I think pretty much every time I brew I will have the laptop running with BTremote just for the convenience of it.

I've managed to stockpile enough beer to last me through a longer phase of BT improvements so I'm in no hurry but rather wanting to apply good solutions rather than temporary ones. Assuming the relay interface board is actually ok, I think I will brew in two or three weeks. I'm aiming for a nice tasty American Pale Ale.

Beyond physical construction work, work has continued on the BTremote program. There have been a lot of tweaks communicating between BT and the PC and I'm nearly ready to release an update where recipes can be done reliably on the PC and downloaded to the BT. This means no more painful tweaking of the rotary encoder to add recipe names and set parameters. It is a great input option for a stand-alone device, but so much easier if you don't need to use the encoder for detailed input like setting up a recipe. My APA recipe was uploaded from the PC to the BrewTroller without even a tweak of the encoder, so a big step forward there.

It always seems like there are way too many projects to work on in the home brewery.

I'd love to have built that counter-pressure bottle filler and I have the parts to do it but ...

And I still haven't finished my LPG tank conversion into a stainless fermenter, nor have I sorted out the conical shell I have for another fermenter...

And I've now done enough on the bar to allow myself to be distracted by other things ...

There are many loose ends on the BrewTroller sculpture that need sorting out. The solenoid valves need a bit of work so that I can effectively fill both mash tun and hot liquor tun and also provide a system drain point for storage, so liquor does not stay in pipes and stale.

I continue to have problems with the BrewTroller dropping out with back emf spikes from the solenoid switching. I'd really like to sort this out so that I can concentrate on brewing rather than getting back to a restore point on the BT. There are at least two things to do here - put some filter capacitors on the rotary encoder switch, and put in some filtering on the one-wire bus.

Then the pressure sensors need some attention. I suspect I am getting some pressure leaking but I also need to add some filter capacitors to the sensor. I'd then like to do some solid testing of temperatures and levels so that we can improve the level readings for the BT community.

But right now I'm not even doing work on the sculpture but rather I'm engrossed in coding for BTremote. Now that the program can load data from a ProMash file, it is close to getting recipe data uploaded to the BT without the need to use the rotary encoder for data entry. Being able to do this will be satisfying personally but will also probably please a lot of other BT users. And then after that it will be adding support for BeerSmith, and then enabling more robust control of the BT via BTremote and eventually the web.

The source code and latest build versions of BTremote are available at Google code and the wiki and forum at brewtroller.com are also a great source of information.

So many things and so little time ...

I've not had much time of late to work on brewing things but the last week I've begun to develop phase II of the bar and cellar.

Phase I was an insulated box with my three tap flooded font mounted on it. It was primarily a fermenting chamber although during the summer it was needed to house the serving kegs. The cooling unit was external as was the gas bottle. The gas manifold for serving kegs was mounted inside the chamber which was less than ideal. Also the condensation from the flooded font meant the inside was always quite damp.

The fermenting chamber maintains temperatures well. In effect it is a fancy 'son of fermentation' chiller. There is no need to change out ice bottles as the cooling comes from the ice bank. I pump ice water through a PC cooling radiator which then blows cold air into the chamber.

I've been wanting to have two parts to this arrangement for a while. The opportunity to make a bar and have the existing chamber solely for fermenting and conditioning came when Leah's brew sculpture was given back to me. A while ago she decided she couldn't brew on her own, so after some negotiating I ended up with a solid base for a new bar.

One of the main condensation problems with the old arrangement came from the flooded font. With the new bar the font is directly above the ice bank which means the condensation ends back into the ice water reservoir. I've now got this part on the bar running well. The next issue I needed to resolve was getting the cellar temperature right for serving English Ales through my beer engine. I didn't want to use the fermentation chamber for this because I would again have issues about gas lines and manifold access. Additionally, last summer I needed to keep the kegs in a temperature controlled environment when the summer was at its hottest. The mercury hit 48C here in January! The new bar allows enough room for serving kegs and gas bottle and creating a mini cool room around the kegs. This means I can run it like an English pub cellar and also keep the beer engine cool at the same time.

The beer engine is designed to sit on the serving side of a bar and so it needed a bit of dressing up to look nice. It took a bit of cutting and adjusting but I now have the engine mounted in a box like structure that I'm happy with. A lift up flap on the bar top gives access to the gas manifold, keg tops and gas bottle. Front doors will allow access to the ice bank on one side and kegs and gas bottle on the other.

Beyond that I will have some shelving to hold beer glasses and trophies. The glass storage might have to stay on the fermentation chamber.

It has been a nice break from building the BrewTroller machine but soon I will get back into that project. It will be nice to test the bar and fermenation chamber during the coming summer. It is already warming up here in Melbourne so lager season is nearly over.

I brewed a lager today that is a cross between a Helles and a Czech pils. It's a recipe that was inspired a long time ago by a lunar eclipse so I've given it the name Eclipse. The recipe tweak this time around is to use Summer Saaz hops which are a new breed coming out of my home state of Tasmania. They don't have the spiciness of Saaz and have a touch of the grapefruit flavours, but other than that they are similar to Saaz according to the description.

I haven't had any time to do improvements on the machine except that I'm running build #263 on the BrewTroller and Matt has coded in some of my asked for features. This time around the HLT temp is based on the Mash target plus a differential. Also the kettle power can be controlled on the fly now to get that perfect rolling boil.

Probably the most significant thing is that I had a moment of insight while looking at a graph of my last brewday. I've had troubles with mash temperatures oscillating nearly a full degree C. I've not been happy with that and the average temperature has been nearly half a degree low. While it is not devastating to brewing, it had puzzled me.

What I realised is that my dough-in mixer wets the grain well but it leaves hotter liquor at the top of the tun compared to lower down where the bulk of the grain is. With HERMAN 6, if I hit target the pump would simply turn off and it meant that this layering of temperatures stayed that way without me realising it. Now that HERMAN 7 has a heat bypass switch I have been recirculating for the entire mash and wondering why I was missing my target by a couple of degrees on the low side.

It also explains why I've needed to 'fudge' my strike liquor calculations. I've aimed a couple of degrees lower than the ProMash calculator for years, and to do that with the BrewTroller I've used a ridiculously high grain temperature.

So it turns out that my temperature probe sits at a high point in terms of mash liquor temperature. It also explains why my beers have tended to be on the dry side (which hasn't been an issue because that's my personal preference).

So with this as a theory, I've trusted the calculators today and what do you know ... the mash settled spot on the target of 66 degrees C. Getting this bit right and having the HLT track the mash target has meant that I've not only hit target, but the mash has stayed on target for the whole hour. I don't think it has ever been as finely tuned as today where my variation around target was +- 0.1 degree C. (Ignore the dodgy time scale - I've got some recoding to do there).

The wort chilling seemed to take a long time but it was okay because I'm not in a hurry while making beer. I chilled the kettle wort to 20C with ground water and then dropped to 8C via the ice bank water and pump. That all worked okay.

There are still lots of rough edges that need attention, but this was a very successful brew day. I've now got plenty of beer in the cellar which means that in the near future I can make those improvements I've been dreaming of.

I've been listening to Brew Strong lately and again Jamil and friends have helped improve my brewing. In particular I listened to their yeast starter program and have just pitched the healthiest yeast starter for a lager ever.

The starter was for a Dortmunder lager which was batch #3 on the new HERMAN 7 powered by BrewTroller.

I've blogged about a number of things on the BT site about this brew, but some observations for my own reference:

• To chill to lager pitching temps, I need to use ground water initially and then do the last stage (maybe below 30C) with ice water.
• What I actually did to chill was use the plate chiller with ground water and pumping ice water through it to pre-chill the ground water. It chilled everything a lot quicker than normal, but most of my ice water was depleted too soon. I had to wait a while for the ice bank to restore to get to lager temps and had to pump ice water directly through the immersion chiller to do it.
• Use a hop sack in the boil kettle to minimise hop debris and therefore trub dumping into the fermenters.
• Improve the filter at the kettle pickup to fermenter.
• Wire in the fermenter fill solenoid and remove the kettle pickup solenoid.
• Put a meter on the mash level sensor to figure out what is going on between mash fill and mash empty and record notes.
• Get some air bleed valves so that the March pump primes reliably.
• add a low point drain on the system so it will clear all trapped water.
• Use the retrieved solenoid from kettle pickup to be the mash liquor in solenoid.

All up I was happy with how the brew day went. There is still a lot of debugging to do on the BrewTroller and hardware but it is a joy to use HERMAN 7 and is by far the best HERMAN yet.

Last time I outlined a number of changes that would improve the working of HERMAN 7. Changing the valve configuration and building an immersion chiller coupled with a busy work week meant that it was a push to be ready for brew day.

Despite this it was a pretty successful day, and definitely some huge steps forward. I forgot a spring while re-assembling one of the valves so I couldn't use the 'liquor in' line at all. It was inconvenient (especially after the work that went into it) but the workaround was simple enough. I'm glad that the system is modular and the camlock fittings work a treat.

The immersion chiller worked really well. It is nice to have proper control over the chilling process after battling for so long with an inadequately sized plate chiller. The immersion chiller takes away sanitisation anxiety, especially compared to the plate chiller. It also means that cleanup is much simpler because I don't need to rinse/PBW/hot water flush the chiller like I needed to before. The immersion chiller is aided by a whirlpool paddle on a motor that agitates the wort and whirlpools it.

The plate chiller has been re-plumbed as a pre-chiller. I didn't use it today but it is a simple matter to pump ice water through it to lower the ground water temperature. It seems to be a much better use of that piece of gear - no sanitation questions and still helping the chilling process.

I realised while brewing that I no longer had a need to recirculate liquor from the kettle drain via the chiller and back into the kettle. As the kettle is higher than my fermenters, I can gravity feed from the kettle once the wort is chilled. This eliminates the pump from the system and makes it far easier to sanitise. As an added bonus, it means one less solenoid valve is needed. This is handy because I needed an extra for the 'water in' modifications.

I don't yet like the way the BT is coded for running an electric kettle. I will speak to Matt about this on the BT forum but may end up doing some custom code to suit my system.

I still had one switching event that upset the controller during this brew. Last time I had at least half a dozen induced resets so again a significant improvement. The difference was having all three tuns run with shielded cable compared to only the HLT for the first brew.

Overall the brew went much better than last time. I started it later, had more time to do other things while brewing and had a lot of fun brewing with the BT. Next week it will be time to make another lager, and there are not too many things that need to be modified. The spring is already back in the solenoid and the only urgent thing is to hook up the ice water pump which is easy.

When I first joined the BrewTroller group the philosophy was 'let's build a stand-alone controller without the need for a computer attached'. It is a great philosophy, but it doesn't logically follow that you should never connect a computer to a stand-alone machine. Once the BT guys captured the vision for a PC app to enhance the BT, the coding for BTremote gathered momentum.

An early release of the program is available on Google code. Currently it shows information on a display panel that is more versatile than using the BT LCD. Information can also be streamed live to a web page for viewing on wap enabled phones and other mobile devices. I use my PDA to keep an eye on what the machine is doing while I am away from it. Soon the code will include graphing of data.

The development path will take us to remote control via ftp which is an exciting prospect. This may not be a great idea currently because the BT still has some fine-tuning before it will work automatically.

While these ideas bubble away in the background I've been thinking about a schematic layout view of the machine. A visual always provides better information than numbers in my opinion. Anyway I'd initially thought the simplest way to implement a schematic was to have different static images for each configuration for the machine in question. The BTremote app would then switch in whichever image is relevant.

One of the BT strengths is that it is very versatile, catering to vastly different machine layouts. For this reason each user is likely to need different images for each of their valve configurations. Asking people to draw these images with a wide array of 'paint' programs and incentive or ability seems problematic. Add to this that a number of switching configurations can be active at once and it becomes a nightmare to administer.

So I got to chatting with my friend Garrett who has done substantial work on his layout designer. As the BT crew renewed my enthusiasm for coding, my interest in Garrett's code has sparked his enthusiasm. There is still a long way to go, but I'm really excited about the potential of his work to enhance BTremote. You can see below a screen shot of my layout looking a lot prettier thanks to Garrett's rendering compared to my earlier schematic images.

So the open source brewing community seems to be humming along with lots of exciting developments in rapid time. As big Kev here in Australia used to say, "I'm excited!".

The solenoid valves from China are fabulous and show great potential for automated brewing. The problem is that they have a direction of flow arrow on them. Without really understanding why this might be, I had configured my valves to fill the hot liquor tun and mash tun with mains water against this directional arrow. The design choice was made because it saved me a valve.

After some testing it was quickly apparent that there were troubles with this approach. Without knowing why, whenever I turned on the solenoid that supplies mains water into the machine, the kettle solenoid, mash tun solenoid and hot liquor tun solenoid would all leak water in against the arrow flow.

At first I though I'd been supplied valves that were normally open rather than normally closed, as powering the valves slowed down the reverse flow (but didn't fully stop it).

I was determined to get to the bottom of this problem so I pulled a valve apart. It was a simple issue. The pressure against the arrow was providing the same mechanical action on the valve that the solenoid does - that is it opens the valve. If the valve was the oriented the other way around, the solenoid would have to work against the water pressure to open the valve. These things are designed to work against a significant back pressure, not a significant forward pressure.

It seemed a possible 'fix' would be to stiffen the spring that holds the diaphragm in position. I figured there must be some latitude here because the tuns won't hold a lot of pressure compared to the mains water. If that is so, the solenoid should have some spare power to act against a stiffer spring.

The simplest way to stiffen the spring was to lengthen its action. A nylon thread (4mm) fitted neatly. With the valve still apart, it was tested with power to see if the solenoid could pull against the stiffer spring.

So far so good.

So the next test was to reassemble the valve and try some back pressure against it. And even with a low pressure trickle on the outlet side of the valve the diaphragm still opened. The same test was done with stiffer springs until the solenoid would barely open under power and it still would not hold against the back pressure. These valves are simply not designed to be used this way.

In order to fix the water fill path, we will need an extra solenoid and need to move the path to the other side of the mash tun and hot liquor tun drain valves. A picture is better than a description here:

Above is the old fill path via the solenoid (circle) at right. The pressure against the three arrows at left create the problem. The proposed fix is below:

The single 'water in' solenoid is replaced with discreet solenoids for both mash tun and hot liquor tun, and now there is no back pressure from mains water against the existing solenoid valves.

I have an extra valve (and a spare) on order but it looks like they are 6-8 weeks away. In the meantime I intend to move the existing fill solenoid into the new HLT fill path and test the fix.

After a month or so of frantic building, the time came to run HERMAN through a brew session. There is an issue with the way I currently have the solenoids configured for filling the machine with water, so I did the fill the night before brewing. The level sensors are not yet giving reliable information so levels were eyeballed.

The process of pre-heat, dough-in and saccharification rest went like a dream. There was no trouble at all with valves getting clogged with grain matter. Also configuration changes are made so easy using solenoids and a controller. I am impressed with the BrewTroller and its versatility. More development is needed to truly automate a brew session, but there is a solid platform there already.

Filling the kettle with liquor went smoothly just like everything before it. It was great to see the copper liquid of a future English Bitter filling up the tun. And all was going so well during the heating of kettle to boil that I left the shed to do some other things.

And the next thing I knew the entire house lost power. OK, some troubleshooting. The residual current device (GFIC) on HERMAN had tripped and main house wiring RCD had also tripped. Normally the HERMAN one will trip early so the whole house doesn't trip. Also the breaker on the kettle line was tripped.

After another bit of testing it was apparent that the heater wiring underneath the kettle was at fault. Unfortunately this was sitting under 45kg of hot wort. The kettle was drained to the HLT and upon closer inspection I found that mechanical stress on a connector had caused it to fail - and a bolt nearby had caused the ground fault. This is what these breakers are designed to protect against, so nothing lost except the hour getting back up to boil.

The boil itself was pretty straightforward except that the BrewTroller wasn't able to figure out the wort was boiling. I've requested a temperature calibration feature to be added because my probe was reading 98.5C for boil. This meant I needed to time hop additions manually, but considering I haven't automated additions yet this didn't make any difference.

With the new build, I'd decided to chill liquor to pitching temperatures with a variation of Jamil's technique of recirculating kettle liquor while chilling via an immersion chiller. He uses return liquor to form a whirlpool. My differences are that I have a plate chiller and actually have a paddle built into the kettle to perform the whirlpool.

And here I came unstuck. The whirlpool was not effective because the liquor was drawn to the edge of the kettle and eliminated any effect of whirlpooling. The greater issue was that hop debris nicely caked over my pancake filter and prevented flow in the loop with the wort sitting at about 27 C. At first I thought the plate chiller was clogged but I could not drain the kettle into the fermenter. I had to back fill the kettle under water pressure prior to filling the fermenter. This was not ideal but I will make changes for next time.

So all up it was wonderful to brew with the new rig. It is so full of promise that I can't wait to brew again next. There are some major issues to sort out though.

• emf that causes the BrewTroller to lose the temperature probes
• filling via solenoid valves
• revisit (again) the chilling process

The last one seems most important so I will begin with that.

A few months ago I uttered something about actually finishing a brew rig before I updated to the next model. OK, so I could not help myself once the BrewTroller arrived. I never did finish working on HERMAN 6. I didn't finish coding for it. I never did design and etch a motherboard for it. And I never did get to a final plumbing layout.

But I did learn a lot along the way.

And all that experimenting has given birth to a new machine, and this time one that is radically better than all previous incarnations.

For a start, I'm not trying to do everything myself this time round. The BrewTroller is a good example of what I mean. Matt and Jeremiah have put a lot of work into a sanguino based brewing controller that is open source. The base model is full of features I'd barely even dreamed of, and I still get to code my own bits into it if I want to.

Also, having a like-minded brewing community means that ideas and resources are shared more easily. I have taken the plunge and bought cheap solenoid valves from China that so far look to be the goods.

And having solenoid valves available means extra features are easy to implement. I've added a mash idle configuration to the plumbing layout as an example of this. Until now when the mash reached temperature (or went too high), all HERMAN 6 could do was stop recirculating. Now the mash idle valve means that the heat exchanger can be bypassed, meaning that mash liquor is always recirculated, and that overshoots will drop to normal more quickly.

I didn't mean to kill HERMAN 6

Once I got the BrewTroller I did some experimenting to get to know its capabilities. Then to test it I needed to add pressure sensors, which I did. Then it made sense to wire the temperature sensors into the BrewTroller. And then I needed to test outputs so I built a relay board. And then I thought that it was time to buy zero-crossing solid state relays to power the hot liquor tun and kettle. And by then ... HERMAN 7 was so close to being a reality that it made no sense to hold onto nostalgia or legacy bits and pieces.

And behold ...

Before long the solenoids went in. And then it was a simple matter to wire in the relay board. And then the solid state relay board simply plugged in. And by then ...

... there was no more HERMAN 6 at all.

A quality upgrade

I've had the luxury this time round to do things right. This has meant buying quality components rather than cobble together bits and pieces that kind of work. I haven't gone to the degree of building everything in stainless steel (that remains beyond my skill level), but all the fittings are quality fittings, including stainless camlock fittings throughout the rig.

So close ...

There is still a small amount of wiring to do. I am short a few plumbing bits that I will need to get via mail order. I am short a few switches and LEDs to do a complete dry run. But by the weekend I will be ready for a wet run, and then the weekend after I expect HERMAN 7 will be making beer.

Over the last month or two I've radically changed my approach to the brewing machine and its development. I ripped up most of the solid pipe and have been hacking different configurations with hose and miscellaneous bits so that I can test changes and fine-tune before I really commit myself.

Chilling issues

One example of testing in place is the process of cooling the wort from the boil kettle. I've had a plate chiller for a couple of years but I've not been happy with its performance. Even as we approach mid-winter the best I can hope for with a single pass and normal mains water as coolant is for 30 C wort into the fermenter.

The brew day before last I tried pumping ice water from the ice bank through the chiller as wort made a single pass into the fermenter. Balancing both flow rates the best I could manage was 25C wort. About 2/3rds through I had to abandon the test because all the ice had melted from the bank. Back to mains water as coolant and then a further problem. The ice bank was needed to cool my cellar box, and with 42 litres of wort at 25C it no longer had the capacity to cool that down to lager temps.

Time for another test. While brewing on Monday I did the Jamil trick of pumping wort around the kettle (in my case via the external plate chiller) until the wort dropped to 30 C. I then substituted the mains water for water from my ice bank. It was lovely to watch the wort slowly but surely drop to 8 C and be able to pitch instantly onto my yeast slurry.

One issue with this is that the chilling process took forever. I was able to minimise water use though, so there are some trade-offs. What I intend to do next is an idea that came from a local micro. There they use a two stage chilling process. Part A via one chiller is done using domestic cold water; part B via a second chiller is done using glycol (or the ice bank in my case). So the inefficient plate chiller will do for part B, but now I need to buy an efficient plate chiller.

Changing the wort flow path

Because I haven't done this kind of chilling before, I had not really considered the chilling path (the loop out of and back into the kettle). In my current system it goes through the heat exchange coil which I'm not happy about. While I've done some serious PBW cleaning of that coil I'm not convinced it is really sanitary. I will re-plumb the system again to eliminate this as an issue.

Better filtering

Also I need to do a better job at keeping hop debris out of the plate chiller. Some improved filtering on the kettle out and the addition of a proper whirlpool paddle should improve things greatly.

Automated brewing

All these tweaks and changes are heading me towards some serious re-building towards an automated machine. I've been slowly working on the electronics based around the BrewTroller. I've also been busy doing coding for the BT guys to allow remote monitoring and eventually remote control of a BT.

Last week I took the plunge and ordered some valve solenoids from China so things are moving here. I've also had critical eyes on the current setup, particularly with fittings that I'm not happy with and taking the trouble to source the right adaptors that I might need. When HERMAN was first built I did not have suppliers of nice shiny bits at my finger tips, so now is the time to really do this job properly. I'm about to put in a serious order with Beerbelly.

And to top off my spending spree I ordered a couple of zero-crossing solid state relays from Oatley.

Even though it has been ages since my last blog entry I've been busy building and inventing. One of the things that has taken my attention is putting together a BrewTroller control panel.

There is more information at the BT forum here.

I've been spending a lot of time upgrading the code in my remote PC application for the brewing machine. When I first dreamed of HERMAN, I began coding in Visual Basic 3 and had all the 'intelligence' on the PC side of the machine. This was necessary because the first interface was an analog slave to whatever the PC did.

In those early days I had no idea what the ultimate aim for the machine would be and as ideas developed the code had bits and pieces added on until it became difficult to manage.

Then I began coding in VB6 and created a more powerful application with its own scripting language but eventually got to the point where it was difficult to manage. My problem with coding is that I get too many ideas and code just enough until things get done. Usually it means the code is not very elegant with lots of workarounds that ultimately come back and bite me.

With the VB6 program came a new and more powerful interface. Using a picaxe based interface meant for greater options and reliability, but some legacy code meant that most decision-making stayed at the PC end.

The latest version has seen coding in VB.net 2008 and a simpler remote application with as much decision-making as possible in the picaxe chip. This means that for the first time the brewing machine runs on its own without a PC. In fact it has run so well like this that I haven't done any coding at the PC end of things for a long time. It also means that the Windows 'blue screen of death' is no longer a tragedy.

Because the picaxe basically takes care of things, I've had both time and patience to try and code things properly as opposed to whatever workaround will work. I have found it quite painful to learn how to code in vb.net, but I'm getting there slowly.

It was the BrewTroller project that has given me renewed interest in the PC end of things. Because there is interest from others in being able to remotely monitor or control the BrewTroller machine, I've been motivated to tidy up some code.

It is not yet perfect, but the PC application now allows loading of a saved brew session log for replaying. It is quite interesting to see the data like this. The real benefit of this code is that I can test FTP communications when I'm away from the brew rig. The image below shows a picture of how a brewing network might go together. In theory it will be possible for phones and other mobile devices to not only monitor a brewing machine but to control it.

The FTP part of the code is now working in a rough manner. At the moment there is about a 10 second lag time between the main PC uploading data via FTP and a remote PC displaying that data. Soon the machines will be taking over the world

The image above shows the PC on the left sending data to an FTP site, with the laptop on the right downloading the same information about 10 seconds later.

Further to the above, I'm only a few components and a small amount of testing away from getting a solid state ball valve controller to work reliably. Automated brewing is getting closer.

The other testing I'm keen on pursuing is working out the best way to chill the kettle wort to pitching temperatures. I have a number of ideas but need tangible data before implementing a final solution in the brew house.

Other than that, I can report that the gluten-free brewing attempt was a complete disaster, and that the first lager for the season is fermenting away in the temperature controlled cellar at a very nice even 10 degrees C. The summer-time construction of the 'Bavarian cave' has been well worth it.

With renewed inspiration thanks to the BrewTroller guys, I've had a go at another prototype of a ball valve controller.

I've had a long history of dabbling with this idea. Through it I've learned a lot about mechatronics which has been both challenging and fun.

Previous attempts at automating the opening and closing of a standard 1/2" ball valve for a brewing machine have included using a servo motor with string to drive the valve lever; using a servo with gears to increase torque; using a geared motor with feedback pot to effectively build a larger servo.

None of the previous attempts were robust enough to put into the brewing machine. Problems included insufficient torque (especially as the valve gets hot), complex mechanical arrangements, expensive and labour intensive.

Quite some time ago I bought some cheap window winder motors (from car power windows) from a surplus electronics supplier. These things definitely have the grunt to open and close a ball valve no matter how hot it is. The problem with them is that they complicate the power drive arrangement (high current) and that there was still the issue of feedback - that is how to determine what position the valve was in.

I put the project on the  backburner and have been happy to manually open and close ball valves on HERMAN. The BrewTroller project re-opens the issue of how valves will be controlled.

Thanks go to Zizzle for working out a neat and simple feedback mechanism. He is using similar motors to drive his valves, and figured that motor stall current could be detected by an analog input and 'seen' as a valve endpoint.

So ... back to designing an automated ball valve ...

The first thing to do was confirm the motor had sufficient torque to drive the valve. A simple coupling was made between motor and valve arm via some square section aluminium and polymorph plastic to 'weld' things in place. A simple test jig was built from scrap timber and the motor was wired up to a 12V battery via a three position switch (open-off-close).

Success! The motor certainly has a lot of grunt. Here are some figures:

• stalled current 4.25 A
• operate current 1.6 A
• transition time around 500mS

To make the valve capable of being opened and closed by a controller, I decided a picaxe 08M would be ideal for handling control logic. The 08M is a small, cheap and easy to program pic based processor. To handle the switching I found a couple of 12V 5A DPDT relays. I had a ULN2003 in the parts bin, so this handled the interface between picaxe and relays.

The interface looks for an earth to open the valve. This can be either the control line (ie. from a BrewTroller) or with the switch under manual control. A high on the line will close the valve.

The picaxe remembers which state it is in, and if a changed state has been requested the motor drives the appropriate direction for 500mS. At this stage I'm not sensing a motor stall to switch the unit off, but this is simple to do.

And here it is in action ...

And the code:

#picaxe 08m



'     ************************************ 
'     *                                  *
'     *   Ball valve actuator   V 0.01   *
'     *   for automated brewing system   *
'     *           10-May-2009            *
'     *                                  *
'     *        by Arnie W                *
'     *                                  *
'     ************************************


' - uses window winder motor coupled to ball valve
' - and 08M picaxe
'
' high on control input will put valve in closed position
' low on control input will open valve
'
' - motor is only actuated when a change of state is needed
' - control input may be via external microcontroller or 
' - local 'manual' switch

' Define inputs
' =============

symbol iStall=4    'adc input - feedback from motor
symbol iControl=pin3    'high = close; low=open (via microcontroller or local 'manual' switch
        'NOTE: this version does not utilise feedback to 'deactuate' the valve


' Define outputs
' ==============

symbol oActuate=1    'motor on/off control - low=off; high=on
symbol oMode=2    'motor direction control - high=open; low=close


' Define constants
' ================

symbol DURATION=50    'time that actuator is energised (x10 milliseconds)
symbol OPENED=0
symbol CLOSED=1
symbol CLOSING=2
symbol OPENING=3

symbol OPEN=0
symbol CLOSE=1


' Define variables
' ================

symbol bState=b0    'state of ball valve - 0=opened; 1=closed; 2=closing; 3=opening
symbol bCurrDur=b1    'index used during transition


' Initialise
' ==========

' put valve into known state
' - the valve is treated as being open and will apply a close command

' update state and actuate
bState=CLOSING
gosub subActuate


' Main program loop

main:

    'check for change of state
    
    if bState=CLOSED then
        if iControl=OPEN then
            bState=OPENING
            gosub subActuate
        endif    
    else
        if iControl=CLOSE then
            bState=CLOSING
            gosub subActuate
        endif
    endif
    
    pause 10
    
    goto main
    

' Actuate sub

subActuate:
    
    if bState=CLOSING then
        low oMode    'set to close
    else
        high oMode    'set to open
    endif
    
    pause 20        'ensure mode is switched prior to actuating
    
    high oActuate    'actuate motor
    
    ' timing loop
    for b1 = 1 to DURATION
        pause 10    'time in milliseconds
    next
    
    ' transition complete
    low oMode
    low oActuate
    
    ' update state
    if bState=CLOSING then
        'valve is now closed
        bState=CLOSED
    elseif bState=OPENING then
        'valve is now open
        bState=OPENED
    endif
    
    return

When the current HERMAN machine was being built, I was confident enough with my plumbing layout to create a final system, hard plumbed in copper. It took a lot of time and effort to create the beautiful sculpture.

But things change. Although 200+ all grain brews count for a lot, sometimes changed circumstances can radically alter the preferred layout. A couple in particular come to mind. While this machine was originally designed to automate the process of filling hot liquor tun and mash tuns with water, for various reasons that will have to wait for the next generation machine. Another change has come about through changed cleaning and sanitation practices.

For a long time I've been resisting the idea that Jamil Zainichef espouses about recirculating kettle wort to both chill quickly and whirlpool the kettle. He uses an immersion chiller, but the principle still applies to our plate chiller. A continuous flow loop is via the kettle outlet, to a pump and then back into the kettle. Our loop just adds an external chiller.

I've not been keen on this idea because years ago this method gave rise to off batches. I hadn't realised that grain was caught in the pump impeller, and that grain went off. Anything post boil needs to be biologically clean and sanitised.

Recently PBW and star-san have become available in Australia. I have been really impressed with both products, and particularly PBW. My stained kettle is now sparkling through using it. I am confident enough to try a loop through the pump, although I will take the head apart first, just to make sure.

Anyway, the layout below is the third version of the current machine. As time goes by it is getting simplified. There is now no direct connection between water in and the rest of the plumbing, although it can be patched in if needed. The 'cold liquor out' line is a flexible hose that can be used anywhere in the system, even to spray down if needed.

I've also had a three way valve for ages, and it was crying to be used at the top of the tree as shown on the diagram. Liquor is only ever directed either into the mash tun or the kettle, never both at once.

We are brewing tomorrow, so I must go and check that pump head.

I am always thinking of ways to do things better and one of the unfortunate side effects is I often don't finish a project. The current HERMAN machine is doing quite well but has lots of loose ends. It has now been quite a while since version 6 was conceived and I have quite different ideas now compared to the early planning days.

Early in the year I blogged on some rough plans I had for this year. This included ideas about a 'clean in place' brewing machine. The HERMLET project is now officially dead and buried as Leah has come to the conclusion that she cannot manage a brew day on her own. We will keep brewing together on whatever machine I have so she can still join in the fun.

I find simplicity quite challenging (I always want to add extra features) so I'm not rushing into HERMAN.next. I finally have the luxury of a fully working machine that I won't need to dismantle to build a new one. The LPG vessels and a spare March pump will form the basis for the new machine.

The machine is likely to be more compact than the current unit and simpler in its plumbing layout. Although not shown, it will be on castors. The three vessels are to be constructed from cut-down stainless steel liquid petroleum gas tanks. The top left tank is the mash tun, below it is a combination hot liquor tun and fermenter, and top right is the kettle with generous head space to prevent boil overs.

Each vessel will be tippable so that grains, trub and hop debris can be removed in place.

I have not yet finalised the plumbing route, but this one is likely to include a pump loop from the output of the kettle via the chiller and back into the kettle to counter current difficulties dropping wort down to ferment temperatures.

The spark that inspired this latest round of ideas towards HERMAN.next is the brewtroller open source control system. It is actually pretty much what I had always dreamed HERMAN might become. I mostly lack the time and concentration to achieve what these guys have done. If I were to put a spec sheet together for a brewing control system, I would scarcely have changed anything these guys have already gotten together.

So with my 44th birthday just a month away, I've already put in a request for a brewtroller with the lot !

This is not to put an end to my picaxe adventure or to curtail a future with arduino either. It is simply a recognition of quality work and the reality that it would take me 10 years to get something like that together. It frees me up to sort out that control system for the bar that I've been thinking of, for remotely monitoring fermenter temperatures, for ...

My challenge will be to stick with HERMAN 6 control. It is working quite well at the moment, but all the picaxe wiring is on experimenter board under the control panel. I must make the control board so I can say, "at least I finished one version of HERMAN!"

Wow, it has been ages since the last posting about things brewing here. Apart from Easter being a very busy time for me, most of the energy in this household has been spent looking at houses. We don't own the house we are living in, so we have been doing lots of research with the ultimate aim of finding a suitable place to call home. If all goes well it will be a great place to grow hops, and if we get acreage then we might even be able to grow some grains ...

To the project at hand: I've not turned celiac, but have a friend who has recently discovered she has this unfortunate condition. After lamenting the inability to drink beer, I couldn't help but want to provide some relief. So tomorrow we will brew our first gluten-free beer. It will be very simple to start with - simply using malted sorghum with no adjuncts, in a style approaching a hefeweissen.

The HERMAN brewing machine is ready to make beer with the replacement laptop, but Revolution Education have just released their X2 series of chips which could make a significant difference to operational speed and capacity of the machine. I'm yet to think through the possibilities, but I like to push the envelope of what is possible.

We are also in dire need to replenish beer stocks. With the house distraction a couple of parties, and a keg of Belgian wheat scoffed in an hour at a recent farewell party, stocks are seriously low. It may not be the best time to brew the gluten-free recipe, but I'm already quite late on this promise. The good thing is that Autumn has well and truly arrived which makes for much easier fermentation control. It is a good thing I have lots of fermenting vessels.

The laptop to IDE hard drive adaptor arrived today and to my relief the old laptop drive fired up without trouble. I now have a backup on my backup and the HERMAN project is good to resume again after only a minor hitch!

Next on the software side of things:

• implement checksums to make comms between picaxe and pc more robust
• check why the picaxe clock is about 25% slow
• wait for RevEd to release their TCP/IP virtual serial port and figure out ways to implement such a groovy idea into the HERMAN project

And on the hardware side of things:

• finish the work on the stainless steel fermenter from an old converted LPG tank

With the laptop dying unceremoniously, I've responded quickly and am now the owner of a refurbished X40 thinkpad. It is so small and light .... It makes the old machine look like a brick. At a mere 1.22 kg (43 ounces), I love it.

If I was superstitious, I would have checked the calendar today because it seems like it should be Friday 13th. It has been quite a day of bad luck - at least when it comes to technology I normally take for granted.

The day began well. We had planned to brew a Belgian Wit, one of our favourite styles and one that has been elusive to get right.

The first news of the day was that the automatic startup system actually worked. HERMAN is designed to run on its own with a picaxe 28x1 microcontroller. I have coded a companion VB program that adds some extra functions such as graphing data and for the first time today, performing an automatic startup at 5am.

I awoke to the brew machine just about ready to go - success, the VB code had done its bit, and remote automation had taken a step forward. The odd thing was that the laptop had frozen. Thinking it was a Windows crash, the brew day continued...

At this point I was glad the picaxe code had been substantially upgraded since we last brewed. The LCD now shows good information which means no more running blind. The new kettle power code also eliminated surging during the boil. At last the system was working as planned - free running without a laptop. For the previous 5 incarnations of HERMAN I'd been a victim of the dreaded blue windows screen of death.

When I had some spare time, I looked a more closely at the laptop. I began to get that sinking feeling that it will never boot up again. Nothing I tried would get the machine to fire up. As it dawned on me that I've been lousy doing backups, I did some quick ebay work for an adaptor to check the laptop drive my main machine.

Why didn't I do backups? My work computer gets a backup weekly. My recreational laptop on the other hand ...

In the last few weeks I've done a lot of coding in both VB and picaxe. The most recent backup of the picaxe code was uploaded to SkyDrive on 5th February. I think I can remember most of what I've done since then - but it is damn annoying. The last backup on the VB program was late September last year! Ouch!

If these things weren't bad enough, there was more to rub salt into the wounds. As the brewday progressed, we realised that all the recipe details were on the laptop - I'd not done a printout! The most recent recipes on my main machine were 2003. OK, so I could remember how I put the recipe together for the wit and recreated it on the main PC. It then crashed in a really odd way and wiped clean the promash recipe I'd just created for the second time. I didn't have the heart to try a third time.

OK, so the good points. Both picaxe and HERMAN were fabulous. And we have had all sorts of trouble brewing wits in the past but this one went without a hitch.

Now ... I am just hoping I can retrieve some data from my once trusty laptop. This week I will be planning a serious backup regime.

I've been inspired to get my teeth into picaxe coding again and so it was time to further develop the HERMAN code. One thing that I wanted to clean up was the duty cycle timing for the kettle power - the cycle time was way too long. I had the interrupt timer operating at 1 second for clock purposes, so to speed up the kettle duty cycle the interrupt now happens more frequently to update kettle duty each minor tick. A major tick still occurs every second, triggering all other timed functions, including one-wire timing.

Once that was sorted, it was time to tackle PC to picaxe communications via the serial port. I've had picaxe to PC working for ages, but when I first tested the other direction I was perplexed at the lack of response from the picaxe. While working on the duty cycle function, I found a logic error that prevented the receive code from ever working. 

OK, so now the motivation to step forwards again. Things were not straight-forward, however. The first symptom was that data was received but the picaxe never recognised the header, so always timed out. It turned out that incoming data was mostly corrupted, through timing problems. This was eventually sorted using the calibfreq command. The manual says this command should be used with caution. Of course I forgot to read that bit ... and ended up with a picaxe I could not program for quite a while. A hard reset on the power side eventually fixed it!

In hindsight it seems blindingly obvious that I could have implemented the calibfreq for the received comms code only. I now have this working reliably.

With a header now recognised and information getting through, I ran into more problems. Most of the information sent came through ok, but it always seemed the last byte was corrupt. I still have no idea why, but I ended up shortening the data packet and sending a dummy end and now it all works.

There is more work to do to make things more robust. I intend to implement both send and receive checksums, but for now I'm happy to finally have remote control capacity for the machine.