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!"

It has been a long time since I've done a wort stability test. One of my aims this year is to make better beer, and I've had some trouble with spoilage bacteria lately that has seemed to get worse over time. We opened a 6 month old bottle of Dortmunder the other night, and while it was drinkable, it showed symptoms of the problem even then. I wish now I'd been more attentive.

I realised when setting up the brewing rig last Saturday that the $@^@&@ polysulfone quick disconnect bulkhead fitting on the kettle outlet was quite dirty. I gave it as good a clean as I could, and did a solid clean in place with PBW at 70 deg C.

At 2 days into the wort stability test, there was the slightest bit of froth on the top of the wort and it didn't smell as fresh as when we collected it. Three days in confirmed the signature spoilage we've been experiencing. Time to improve our methods ...

The good news is the fermenting beer seems good. It has a little more to ferment out, but the flavour profile is the classic clove hefewiessen which we love. It has been fermented at a steady 17C in the cellar which has been pleasing considering the outside heat. We made sure the starter was healthy, although I'm still not happy with the speed of reaching pitching temperatures.

I had a critical look at the components between the kettle out line through to the fermenter. There are a few things that I'm concerned about. Firstly, the polysulfone bulkhead connector on the kettle is out of the clean in place loop. While the sanitising solution is dropped through it into the fermenters, the lack of cleaning process is an issue. Other things to be concerned about are that there are some taps that remain in place during the last phase that could be eliminated. They are there for convenience, but convenience is no good if they harbour spoilage bacteria.

The final thing that might be an issue - although I'm not sure - is that I have no way of fully drying the chiller and plumbing from kettle to fermenter at the end of the day. I have used a hand pump to pump air through the system, but maybe it needs something a little more. It is hard to tell because I can't see inside all these bits.

Anyway I've devised a simpler flow path from kettle to fermenter and a way of involving all parts in the clean, flush, sanitise, chill, clean, flush, dry process. It does mean that some manual patching is necessary, and I'll need to buy some better fittings. In particular doing away with the polysulfone fitting will be satisfying. I've had nothing but trouble with them even though they seemed like a good idea.

The kettle (an old 50 litre stainless steel urn) had an outlet in the middle bottom that I blocked up a long time ago. The current outlet is in the wall of the urn via a polysulfone bulkhead with stopper. With some re-plumbing, the original drain point can be used again. This means the polysulfone connector can then be used as an overflow for cleaning.

To clean these parts in place, I intend to put a PBW solution in the hot liquor tun. This then gets pumped via a camlock disconnect (yet to be installed) into the fermenter line which is patched in for the cleaning cycle. Hot PBW gets pumped up through both chillers and a three-piece ball valve into the bottom kettle outlet. When the kettle reaches a sufficient level, a line from the existing polysulfone connector will drain excess cleaning solution back into the hot liquor tun. This way the cleaner can cycle in a closed loop.

The same process can be used to circulate flushing water or sanitising solution. This way it involves all critical post-boil parts in the cleaning and sanitising process, hopefully realising the aim to make better beer this year.

The summer has arrived late this year, but we've been having a run of hot days of 100 or more degrees F. When I was a kid at school we still use Farenheit in Australia, and 100 was the mark when we could go home from school.

Anyway, with the heat comes all sorts of challenges in a home brewery, and one of them is getting wort from boiling down to pitchable yeast temperatures. The brewing rig before our current one had a large copper counter-flow chiller. This worked well but took up a lot of space. It was capable of getting wort down to within 1-2 degrees of the cooling water. For the sake of a compact design, we bought a plate chiller to use in the current brew rig. I miss the old unit though, because it was so much more effective. The plate chiller does ok for its size, but it is only capable of getting wort down to within about 10 degrees of the cooling water. At this time of year that makes a significant difference.

Because we like making lagers, it is still an issue for us, even in the depths of winter. A chat with the brewer in a local brewpub revealed an interesting idea that I'm inclined to implement in the home brewery, now that the ice bank is up and running.

What they do at Two Brothers is a two-stage cool of the wort. They have two plate chillers, the first one is run from the domestic water supply, the second from their glycol plant. I did some guestimates today and it makes sense. If the tap water is 20C, the best you can hope for with an efficient cooler is wort that exceeds most ale pitching temps. They make lagers as well, so a second run through with glycol will probably give them any temperature they desire from 0 degrees upwards. Even the coldest of lager pitches is only likely to be about 8 degrees C.

When I bought my ice bank, there were some specs that suggested how much cooling capacity was available before all the ice had melted. They are designed to be a peak demand unit, and can supply 66 litres of cooling for beer stored at 16C; 40 litres of cooling for beer stored at 24C; 29 litres of cooling for beer stored at 32C.

By these figures, I worked out that if I can do a cooling stage from the domestic water stage that will drop wort to 28C (which is feasible even at this time of year), then I can flash chill in stage two using the cooling water from the ice bank, and end up with 42 litres of wort at 10 C, ideal for lager pitching. As I don't intend to make lagers during the peak of summer, there should be more leeway than this.

So I had a look at the old counter-flow chiller. Apart from it being a ridiculously expensive lump of copper, it seemed a shame to see it lying about in the parts bin. On the new rig, space is not the issue it once was, so I figure that this will be ideal for stage one cooling, with the existing plate chiller for stage two.

I now have a bit of work ahead of me to sort this all out, but is seems like a good solution to something that has nagged me for a long time.

With decent software to model and re-model layouts, I'm finding the process of designing boards much less of a chore and more fun than ever.

Being able to nut out a control panel design and then re-work it into a versatile set of strip boards has inspired me to do similar things for the tuns.

A few posts back I had drawn a model of the mash tun under CorelDraw and soon realised that I needed a 3D model. After spending some time to learn SketchUp, the modelling has come a long way.

I wanted to model the mash tun for a couple of reasons. One is to make a dough-in mixing paddle which did not interfere with sensor probes or the liquor return manifold. The other is to make sure all the sensors and housings fit together.

The mash tun boards are essentially remote sensor connections back to the main picaxe controller. I wanted to get this bit right so unplugging tuns for cleaning and maintenance would be simple, and the sensors would be rugged and waterproof.

Through modelling under SketchUp, I was able to determine which dimensions and parts were critical on the sensor board. The other pleasing thing is that a simple design is easy to build on and improve. I had never intended to have the pressure sensors plug directly into the board, but rather connect via a fly cable. Using SketchUp, it was easy to move the sensor around and then figure out how the board layout might be improved for the two to go together.

The other aspect of this I've enjoyed is being able to have both schematic and board 'interact' until the design has been optimised. Some parts are not critical on the schematic, but the way they are drawn can affect a board significantly. Being able to draw a schematic, rough layout a board, look at the board critically, refine the schematic and so on has made this task fun and creative.

We are brewing a Dortmund lager today but the dremel drill press should arrive today or tomorrow. We will then have all we need then to make some boards next weekend. The only reason I can wait that long is I enjoy making beer as well.

I'm glad I haven't done the usual thing and rushed into building HERMAN circuits. While it is very tempting to replace the old control panel with some nice, neat and well built switches and LEDs, I've just looked again with critical eyes and come up with what seems a much better solution - and one that is useful for others too.

The control panel design currently has 20 switches. The first 16 have definite control functions, but the last 4 are for future expansion. I've been trying to think of expansion without needing to design for every possibility, so was thinking about how a ladder array of buttons might easily be extended.

The other thing on my mind was that although the circuit would work and the front cover would make the panel look pretty, the board design itself was quite messy because it was complex.

So applying the simplicity cycle to the project with these things in mind, I've come up with the following circuit.

Rather than a complete control panel, it is a strip of three buttons and LEDs (that in my case are built into the buttons) that can be easily expanded upon. Each strip has the buttons, LEDs plus a header and a footer . The first button in any array is connected to the header via the link LK1. This connects the array to Vcc or in our case 5V. The buttons in between will produce an output somewhere between 5 and 0 volts, so the last button in the array needs to be connected to ground. This is done by closing LK2.

Although there are three buttons on a strip, the strip does not need all of them populated on a board. If a project demanded a two button decoder, omitting a button means it will never be closed. The picaxe code would still need to account for three steps in the divider chain.

Where more than three buttons are needed, extra strips can be added to build up the array. If, for example, 9 buttons were required, the first strip would have LK1 closed, and then a cable from J2 to J1 on the middle strip. The middle strip would have J2 connected to J1 of the last strip. The last strip would have LK2 closed to complete the ladder array.

Over the weekend I hope to use DipTrace to route out a board design but it ought to be much simpler than the previous version.

Now that we are getting close to building the control circuit for HERMAN 6, it is time to make some final design decisions. I find this phase really difficult, as I want to keep all my options open, and yet the more complex something becomes, the more it slows progress.

I intended to install float switches in the tuns with electric elements to prevent heating while the elements were not covered. It should have been incorporated into the first model, but I have been reluctant to cut a hole in a perfectly good stainless steel vessel just in case ...

Anyway, it is now time to do it.

I wanted to use the float switches to not only control power switching, but also light a panel indicator to show what the float was doing. Inputs are now at a premium on my picaxe, and while it is possible to do, it is really unnecessary.

I then began to think through how the physical wiring of float switches, solid state relay (SSR) switches, and power wiring might come together. The sketch below shows a complicated way of doing things.

The reason it is complex is because all the SSRs are currently sitting in one box underneath the control panel. This seems like a good idea until the float switches are introduced.

So I began to think about mounting SSRs directly onto tuns. The drive to the SSR from the control panel would simply loop through the float without the complex wiring of the drawing above. The wiring shown below shows a much simpler configuration. The only downside I can see is that the 240V sockets to the tuns would be permanently live. Currently they go through the SSR box and are only live during the brew. I think this is something I can live with considering the machine has residual current protection built in.

I spent the morning today working on the new control panel - the panel buttons and indicators. The control panel artwork has been tweaked a little so there is an update in the HERMAN6/Design section under files.

I spent most of the time working out how the buttons would function before finalising the schematic. As an example, the timer has three buttons - one that will increment minutes, one to decrement minutes, and the other to start and stop the timer. Thinking a little more about it, a timer reset would be useful. I have a little kitchen timer that resets when you hold its two adjusting buttons down together. This won't work in my case, because all the buttons are decoded on a single picaxe ADC input. This means that the button highest on the resistive ladder will be the only one 'seen' by the picaxe.

This isn't a problem though, because it is simple to indicate a long button press (ie. the button is held down rather than pushed). So a button hold will reset the timer.

This process is needed for all the buttons, and working it out before a component is laid down will save a lot of heartache later. The heat chamber control buttons are now mash temperature control buttons, with the 'on' button activating the recirculation control loop.

I've thought about having the option of adding the heat chamber back into the system as a heating boost controller. The simplicity cycle suggests I cut the idea, so I'm not adding any extra buttons just in case. I figure that if I do things like that later, I can add the buttons then.

While all the control panel buttons have LEDs in them, not all of them need to be controlled. To simplify things, I'm only going to wire up the ones that I want to light up .... despite the undeniable urge to over-complicate things .... simplicity now!!!

LED indicators on control panel

So the control panel schematic comes in two sheets - one for the buttons, and one for the LED indicators. The indicator sheet shows 16 LEDs which will ultimately be driven by an output extender board on the extension bus. I'll finalise that circuit some other time, but I have done testing with code and a VSM schematic, so I'm confident it will work ok.

The two schematic sheets are posted as bitmaps under the files section of the blog site. If anyone is interested in the actual VSM files, just let me know.

So next step is working on the netlist export on VSM so that I can use DipTrace to build a PCB.

With the mod from a RIMS to HERMS, the brewing machine needs some fine tuning of its control system.

RIMS controls are much more critical than HERMS. PID is pretty much essential for RIMS but not for HERMS. So I've decided to keep it simple and drop the PID coding, and replace it with a couple of IF-THEN statements.

These statements are to apply only if a target temperature has been set on the mash tun. This means that the system will be recirculating mash liquor in order to regulate mash temperatures.

So, using pseudo code:

'Regulate mash temperature by cycling pump on/off

IF MASH_TEMPERATURE >= MASH_TARGET THEN
     PUMP=OFF
ELSE
     PUMP=ON
END

'Ensure HLT can supply sufficient heating for mash

IF HLT_TARGET < MASH_TARGET + SYSTEM_LOSS THEN
     HLT_TARGET = MASH_TARGET + SYSTEM_LOSS
END

The main mechanism for regulating mash temperatures is turning the pump on or off. Obviously, when the pump is not recirculating liquor, no extra heat is added to the mash. When the pump is on, the liquor passes through the heating coil in the HLT and adds extra heat to the mash liquor.

I must admit I am not sure why many recirculating sculptures have more complex heating bypass systems in them. It seems way to complex, even for me, to have an extra solenoid or two to switch between heating and bypass path when just cycling a pump will do the same job. I've also seen systems where an attempt is made to control the speed of the pump to control the speed of liquor flow. Again, what could be more simple than turning a pump off when the mash is at temperature, and on again if it drops below?

The nice thing about a HERMS system, is that once you figure out the system loss you can pretty much set the HLT temperature and let the machine to the rest. This machine will do that, but by using the pump on/off cycling system above, it gives the option to shorten the time between temperature steps in the mash. This is explained in the example after the schematic.

The secondary mechanism for regulating mash temperatures is through setting a target on the hot liquor tun. The system loss component is the difference between the HLT temperature and the liquor flowing into the mash tun through the heat exchange coil. In my system this is around 3 degrees C. The coding of the second IF-THEN statement ensures that there will be enough heat supplied by the HLT whenever a mash target has been set. This can be manually adjusted up by the user but not down. (In actual practice, this just affects the target, the user can still deactivate the HLT if needed.)

As an example, suppose the mash is sitting at 67 C for a saccharification rest and we want to step up to 75C to perform a mash out. If the HLT was the primary means of regulating mash temperatures, we would need to wait until the end of the 67C step before setting a target on the HLT of 78C. Doing this is ok except that the thermal lag in the system means it will take a long time for the mash to reach its target.

Suppose now that 15 minutes before the end of the 67C step the HLT target is adjusted to 86C. As the HLT rises in temperature, the mash is prevented from over-heating by the pump turning off. Suppose that by the end of the 67C step the HLT has reached its target of 86C. At this point the mash target changes to 75C and the pump turns on because the mash temperature is now less than its target.

As the pump continues to recirculate liquor, a significant amount of heat is drawn out of the HLT and its temperature drops rapidly. As this happens, the mash liquor temperature is increasing more quickly than if the HLT was slowly heating up to 78C. If the system is balanced, as the mash approaches its target of 75C, the HLT will be close to its target of 78C. Should this happen, the pump will constantly recirculate liquor in the system without the need to cycle off.

That's enough for theory. We intend to brew on the weekend so will test it out in practice.

The HERMAN 6 control system will have a picaxe 28X1 processor as its heart. I did a lot of experimenting with this chip last year when it was released and I'm really impressed with its feature set and ease of programming.

What I intend to do is create a simple mother-board based on the 28X1 with many ways to extend functions with plug-ins. In part I've been inspired by the Make controller and Bug Labs, with an honourable mention for the Arduino. The Make controller is a mother-board with a heap of connectors for the outside world; the Bug Labs project is a collection of modules that you can plug together in any configuration depending on what you want your 'Bug' to do.

Below is a near finished schematic for the HERMAN 6 motherboard. I need to check through connectors and add a few components like capacitors on the voltage supply, and LED indication of power.

Essentially is it mostly connectors. I've chosen to use common dual inline connectors that clip onto ribbon cable without the need to solder (insulation displacement - IDC) for the ease of construction. It may seem strange to connect the pins of each side to one another (8-9, 7-10 etc.) but this is for ease of board layout. I don't need 16 connections on an IDC 16, and it also means that power supply capacity is increased should it need be (ie. for driving a motor).

The mother-board will be located underneath the control panel on HERMAN. The connection to the mash tun (hot liquor tun etc.) is via ribbon cable off these IDC connectors. Where feasible, these remote connections carry extended serial bus lines. The extended serial bus is there to allow simple expansion of inputs and outputs. In the future, if I decide to build a LED 7 segment display, I can plug it into the serial bus at the Mash Tun (or other location) and use it to show the Mash Tun temperature. The same bus can carry extra temperature probes or control a hop dropper or switch on the hot and cold liquor solenoids.

This all means that the parts for HERMAN don't need to be all built at the same time. The basic machine requires these bits:

• mother board (design nearly completed)
• Mash Tun board (simple design, nearly completed)
• Hot Liquor Tun, Heat Chamber, Kettle, Fermenter boards as per Mash Tun board (likely all the same design - if possible at least)
• control panel (buttons design complete, some work needed on the LED driver for the buttons)
• solid state relay board (complete and in use on current HERMAN machine)

As far as control code goes, the work done so far on HERMLET and the existing control code for HERMAN 5.5 should mean a simple transition to the new mother board.

I've been working through the DipTrace tutorial to get the hang of the program. Ultimately I want to be able to draw a schematic in picaxeVSM and export that into the DipTrace PCB program. For now, I'm learning how to use the DipTrace schematic so I've redrawn a small section of the Sea of keys encoder circuit.

But first I needed to create the component outline of the pushbutton switches with inbuilt LEDs.

Its not exactly great art, but the screenshot above shows the schematic representation of the switch and LED on the left, with air wires connecting it to the component outline on the right. This means I can draw a schematic of the encoder with my custom switch component, and then export to the PCB program without any trouble.

I knocked together a quick schematic of the Sea of Keys encoder with three switches and a connector.

This was then sent to the PCB part of DipTrace and after a bit of component rearranging, it looked like this with the air wires.

I then set a few parameters set on the autorouter. Because I am making boards at home and I want it to be as simple as possible, I chose 1 layer and allowed jumper wires. Then after about 30 seconds, the board was transformed into this:

I find this simply amazing, but I have not been working professionally with electronics for about 15 years now. Once the component outline and schematic were sorted, it took about 15 minutes to draw the schematic and produce the PCB outline above. What an incredible difference compared to my old program! It would have taken me hours to manually route a board like the one above using ExpressPCB. I still can't believe that DipTrace is free for up to 250 pin circuits. The autorouter alone makes it worth paying money for.

cheers, Arnie

If you have been following this blog you will have no doubt realised that I am very much a fan of the picaxe range of microprocessors. Amongst things that are appealing are low cost, easy to program and the power of them.

Picaxe chips have been finding their way into many projects here including power controllers, temperature controllers and brewing sculptures.

One of the reasons the HERMLET project slowed down dramatically late last year was one of complexity. Once both program code and circuitry get to a certain level of complexity, it is difficult to proceed to design in a reliable fashion.

The free software that comes from Revolution Education to program the picaxe chips has in its latest version had a software simulator built in. This means that code can be stepped through a line at a time by means of debugging - an essential tool.

The latest offering is a commercial package called PicaxeVSM and this offers schematic drawing features with full analog and digital modelling of circuits - integrated with picaxe and code debugger. This means that you can literally step through lines of code and watch virtual LEDs come on when an output turns high (depending on code and circuit). If that isn't good enough on its own, I2C, SPI, RS232 and USB debuggers help you keep track of these many communications features that a picaxe is capable of. And then you can connect two picaxes together (such as I have with the current HERMAN machine) and watch them interact on a PC screen before you build the circuit. And you can even connect to a real PC or picaxe from your virtual circuit!

I am totally sold on what this software can do, and I'm finding it hard to slow down and learn about it properly before I leap into more design and improvements on HERMAN and HERMLET. It has already proven itself to be invaluable - a couple of days ago I was modelling on screen the control panel that HERMAN uses (the array of resistors and push buttons that get decoded as and ADC value) and I accidentally left off a ground connection. In my mind I knew it should work - but when the voltage and ADC values showed me there was a problem, I discovered my mistake. In the past it has been too easy to overlook simple errors only to find them once a board had been built.

For just over $AU 100, this seems to be the bargain of the year.

A few years back when I began to make printed circuit boards for the HERMAN project, an internet search revealed that ExpressPCB had software available for free, which is a good price for any hobbyist.

The string attached to this free offering is that the format of files is their own specific one, and that the software is geared towards internet ordering of boards from them. OK, not a bad thing in itself, and it was the software I began to work with and know how to use quite well.

Since then I have been made aware of other offerings that I probably would have chosen over ExpressPCB, had I known of them at the time.

EAGLE is probably the best known as it has a free offering (full program but limited size board) and is a bit quirky to get up and running. I have just begun to appreciate the power of EAGLE thanks to some terrific tutorials on the instructables website.

The other one that seems to deserve attention is the open source program KiCad. It seems to have a lot in common with EAGLE, and even though it is a free offering, the summer edition of Elektor suggests it is not lightweight in what it can do.

Although I'm most familiar with ExpressPCB, I can't say I'm really happy with it. It is very basic, and it gets the job done, but it doesn't do much to harness the power of the PC. I can't say I'm all that impressed with either EAGLE or KiCad either, but for different reasons. Both these offerings are incredibly powerful and versatile - but they are damn hard to work out how to use.

Having been a bit disillusioned about computer aided software for schematics and PCBs, I happened by chance upon DipTrace. After some serious analysis, I think I have finally found the program I've been looking for.

DipTrace is easy to use. It has a very capable autorouter. It is not too difficult to find components when you need them. It is easy to change the outline of any component for the PCB. It comes with a very capable 250 pin free version. There are not-for-profit entry points, home packages all the way up to professional offerings.

The reason I came upon DipTrace is because I am now a happy owner of PicaxeVSM software.

PicaxeVSM is a spice based virtual modelling program which models the range of picaxe micros and can do analog electronics as well. Schematics seem even easier to draw on PicaxeVSM than DipTrace. Where DipTrace comes into play is for making PCBs.

So after a long break of thinking about other things, I'm set for another round of playing with things electronics and beer.

Every time I start up our dishwasher I am inspired by the simplicity of its control. I can select between a few cycle types such as normal or pots, and if I want I can add an economy feature which helps to save water.

It is this kind of simplicity that I am drawn to in designing a brewing machine control interface. Brewing machines are more complex, or at least if I am going to the trouble of making beer with grains, then I want to have greater control over temperatures and times than I would ever need in a dishwasher.

Designing a control interface that is both versatile and simple is a challenge, but I am happy with progress. For control, essentially the machine will have UP/DOWN, PREV/NEXT options and a start button. All information will be displayed on an LCD with 2 rows of 16 characters.

I made a template to help with designing screens. Above is an example of how I intend to deal with mash steps. The drawing shows a 3-step mash where both temperature and time settings can be adjusted simply. I found it a bit painful to do, but I made myself stick to temperature adjustments of 1 degree increments, and time in single minute increments. This will be more than enough accuracy for a machine like this, and 0.1 degree C resolution is really only "eye-candy".

With a screen like the one above, user-control is simple. The first number is displayed as >63<. The >< indicators show the user that this is the active variable. If I want to adjust this temperature setting, say to 67 degrees C, all I need to do is press the UP button four times. If I want to adjust the time duration associated with this temperature, I would press the NEXT button until the '30' below the original '63' is the active variable.

One of the features intended is that variable changes will be saved to memory. This means that if a brewer has a favourite step-mashing regime, this will become the default setting.

If the settings require no adjustment, the user can simply press the START button to select the next screen. This means that despite the complexities of a brewing machine, the machine can start brewing with only three START button presses (toggling through mash settings, boil settings and volume settings).

One of the design features of the machine is that settings screens like the one pictured above are easily accessible no matter where in the brew cycle the machine is. If, for example, the machine is mashing per the settings on the screen above, an information screen will be displayed showing actual system temperature, volume and system time (a count-down timer). A single button press will immediately return the user to the relevant settings screen, where parameters can be adjusted on the fly. After a short time of inactivity, the information screen will be displayed again.

At present, coding is complete to this stage. The next stages of coding will involve actual control of pump, heating element and taking the machine through a full brew cycle. Although that sounds complex, I think the coding is probably 2/3 complete.

In a recent blog I mentioned my excitement at discovering Dan Ward's book called The Simplicity Cycle. Having devoured the concepts and been inspired, I've been doing some work to apply good design to the HERMLET project.

I spent some time this morning working on a menuing system for the machine, and this continues to be a work in progress. There are several ways where simplicity has already made for a better product.

While musing over lunch, another piece of the simplicity jigsaw fell into place. The original HERMLET idea called for the mash tun to be inserted in the boiler and operate in a manner similar to a double-boiler. After mashing, this meant the mash tun needed to be lifted above the kettle and the liquor given time to drain from the grains.

To automate this process is more complex than I had wanted. The use of an electric hoist, and a way to simply disconnect plumbing during the raising process had bothered me since the original idea was conceived.

While thinking about the various capacities of the tun and kettle and fermentable wort, I considered that if the mash tun was raised a little out of the kettle, the system would be capable of holding more liquor during mashing, particularly because the pump would keep topping up the mash tun before all the liquor could be drained out of it.

BINGO! Why not put the mash tun above the kettle - not partly inserted, but fully above?

The grains in the mash tun ought to slow down any liquor that might want to overfill the kettle. The pump can be throttled back so that the mash tun does not overfill (although an overfill would simply have liquor returning to the kettle anyway - it just would not be very elegant!).

A sensor or two in the mash tun could show when the pump ought to be turned on or off, and for this extra complexity, there is the bonus simplicity where the mash tun will not need to be raised or lowered.

... it might make it a bit hard to claim this as a one vessel brewing machine now though. ;-)

• discrete level sensors (a single switch per level being detected)
• hall effect with floating magnet (discrete sensors at different levels as per above)
• capactitive probe (using the difference between air and wort to change capacitance)
• ultrasonic sensor (bouncing a signal off the surface of wort and measuring level by time difference)
• pressure sensor (changes in pressure caused by changes in wort level)

Discrete v. continuous sensing methods:

The first two methods above are discrete methods - that is they require a sensor for each level being detected. This means that if there is a senor at 5 litres and another at 10 litres, the machine will not be able to tell if the level is 6 litres compared to 9 litres. To improve sensitivity, more sensors need to be added.

The last three methods are continuous methods and typically provide level sensitivity of 100 ml. In the case of ultrasonic and pressure sensing, these tend to be expensive to implement. For a machine to have sensing on 3 or 4 vessels, costs can be prohibitive.

The capacitive probe sensor is perhaps one of the cheapest methods but requires the most R&D.

The discrete level sensing method is perhaps the simplest to implement but apart from the disadvantage of lack of sensitivity as outlined above, it also requires substantial mechanical work to install sensing points.

Wicked Stone has used a pressure sensor in his machine: http://www.employees.org/~joestone/Sbs/Html/boil.htm

Methods employed so far in HERMAN:

We have researched extensively infrared detection with a reflective float. This proved to be unreliable due to reflections and other environmental factors.

The discrete level sensor system has been reliably implemented, and is possible to use with many sensors into a single analog input. It is best suited to simple applications such as mash tun full, heat chamber full or kettle and hot liquor tun have adequate level to turn heaters on.

An ultrasonic level sensor was mounted above the kettle and proven in principle to work well. This method was not pursued due to expense and because it was prone to environmental interference.

Capacitive Level Sensing:

This has been extensively researched and been shelved at different times for various reasons. The original impetus for this idea came from C.D. Pritchard who found a capactive transducer circuit in an issue of Ciruit Cellar Ink. http://home.chattanooga.net/~cdp/level/level.htm

To the best of my knowledge, C.D. never actually implemented the idea in his machine. In my own reseach I've taken the idea and tried a few different approaches, including a circuit I designed in 2001 that used an LM 2917 frequency to voltage converter on the output of the 555 timer.

This circuit had limited success due to difficulties in matching dimensions of a capacitive probe with other circuit components to give a reasonable voltage output range. It is also complicated by virtue of the dielectric 'constant' of water changing substantially with temperature. A sensor of this type needs to be adjusted for both dielectric change with temperature and liquid expansion changes with temperature.

C.D. Pritchard's original circuit had a varying frequency output with changes in level. This was a problem for me back in 2001 because I did not have the picaxe cheap at my disposal. It seems worth pursuing this method at this point knowing that the picaxe can count pulses in a versatile manner; they can read temperatures simply; and they can do basic mathematics also. It ought to be feasible to use a picaxe chip to build an automatic temperature compensated capacitive level sensor.

Dielectric changes with temperature:

At 0 deg C, the dielectric of water is 88 (air is a constant at 1). At 66 deg C, water has a dielectric of 67. At 100 C, it changes to 55.3.

I've devised a formula that models this reasonably to be:

D = -0.327 x T + 88

where D is the dielectric, and T is the temperature in degrees C.

Probe construction:

C.D. Pritchard lined his probe with aluminium foil to minimise stray capacitance. If a probe is made coaxially then this is not necessary as the outer plate which is earthed acts as a shield for the inner conductor.

As a final note, the inner conductor needs to be insulated from the water/wort or electrically the capacitor will become short circuited.

Steppers were already being done by everybody else, so I decided to see if I could get shaft encoded gear motors to work. They're potentially a lot cheaper than steppers and are energetically a lot more efficient. You get much more bang for your buck.

Because you're not using so much power the controller boards are easier and cheaper to build, though the coding is considerably more complicated.