The 091001 Geordie Boy is tapped. I find it to be somewhat different from the previous versions of the recipe, but pretty good nonetheless. (It's no Por Favor though.)
It's obviously more bitter than the previous versions, as I expected with the higher alpha-acid bittering hop addition. The thing that throws it off somewhat is the higher finishing gravity. There's a sweet/thick finish on this brew that was not present in the others. How much of that is psychological, because I know the gravity finished 6 points too high, and how much of that is actual because of the residual unfermented sugars?
I predict it will take several sampling sessions to fully form the hypothesis.
Wednesday, October 28, 2009
Tuesday, October 27, 2009
Boil, Float, Keg, Dump
Where does the time go? More to the point, where does the beer go?
First Boil
Yesterday I boiled a little over 16 gallons of water in my new 80 quart pot to season it, and to get an idea of its thermodynamic performance. The first thing I noticed was that it takes a long, long time to put 16 gallons of water in a pot. It takes even longer to bring 16 gallons to a boil. I estimate that it took at least two hours in the conditions that prevailed yesterday. (It was a little cool and a little breezy.)
I did note that I got better heat performance while the pot was covered, but once the boil began I removed the cover (since I wouldn't boil wort that way). Without the covering, the burner couldn't maintain the boil - it could sustain between 205 and 210 F but it couldn't push through the latent heat required to keep boiling. I don't think that's a show stopper because I'm not planning on boiling 16 gallons under normal circumstances, and the lower thermal mass of 10 gallons should be easier to keep heated.
However, I have to find a way to get more heat into the boil faster. I just don't think this burner I have is putting out enough BTU/hr to be effective. I have a few options. I could get a more manly propane burner (like the Bayou Classic banjo burner), but I see a big spike in propane use if I get it. I could switch to an electric immersion heater like this one or mount one through the side of the pot. I could also go with a natural gas burner but there's a plumbing issue involved.
What I may do is go in combination at first, and build a heatstick to assist the propane burner, with an eye on going electric at some point. The all-electric solution seems to require a control system which sounds like fun but I have other software to deal with now and can't be bothered with that additional complexity. (Also, I'm not sure the sidewall of this new kettle is thick enough to survive having the port for the heating element drilled into it.)
RIP: 090902 Por Favor
This was good beer. I have the ingredients to make another 5 gallon batch but I think I may go over to AlaBrew and get some more grain and make another batch of this as my first 10 gallon batch.
Kegged: 091001 Geordie Boy
This is the multiple equations in multiple unknowns version of the Newcastle clone recipe from HBT's Biermuncher. The original post noted that it came up short on volume and high on gravity - in hindsight I should have topped it up with water. The FG was 1.020, which is way higher than it should have finished. I left it in the fermenter for over 3 weeks, so the yeast had plenty of time, but the attenuation wasn't there. The sample tasted OK though, I could tell there was more hop character. We'll see how it tastes when I carb it tomorrow.
DIAF: 090502 Honey-Brew List
I gave up and dumped this batch. It never mellowed to the point of drinkability. I will remake this recipe in the spring but use 1/4 the amendments I used this time. A little goes a LONG way. I just hope I can get the smell out of the keg.
First Boil
Yesterday I boiled a little over 16 gallons of water in my new 80 quart pot to season it, and to get an idea of its thermodynamic performance. The first thing I noticed was that it takes a long, long time to put 16 gallons of water in a pot. It takes even longer to bring 16 gallons to a boil. I estimate that it took at least two hours in the conditions that prevailed yesterday. (It was a little cool and a little breezy.)
I did note that I got better heat performance while the pot was covered, but once the boil began I removed the cover (since I wouldn't boil wort that way). Without the covering, the burner couldn't maintain the boil - it could sustain between 205 and 210 F but it couldn't push through the latent heat required to keep boiling. I don't think that's a show stopper because I'm not planning on boiling 16 gallons under normal circumstances, and the lower thermal mass of 10 gallons should be easier to keep heated.
However, I have to find a way to get more heat into the boil faster. I just don't think this burner I have is putting out enough BTU/hr to be effective. I have a few options. I could get a more manly propane burner (like the Bayou Classic banjo burner), but I see a big spike in propane use if I get it. I could switch to an electric immersion heater like this one or mount one through the side of the pot. I could also go with a natural gas burner but there's a plumbing issue involved.
What I may do is go in combination at first, and build a heatstick to assist the propane burner, with an eye on going electric at some point. The all-electric solution seems to require a control system which sounds like fun but I have other software to deal with now and can't be bothered with that additional complexity. (Also, I'm not sure the sidewall of this new kettle is thick enough to survive having the port for the heating element drilled into it.)
RIP: 090902 Por Favor
This was good beer. I have the ingredients to make another 5 gallon batch but I think I may go over to AlaBrew and get some more grain and make another batch of this as my first 10 gallon batch.
Kegged: 091001 Geordie Boy
This is the multiple equations in multiple unknowns version of the Newcastle clone recipe from HBT's Biermuncher. The original post noted that it came up short on volume and high on gravity - in hindsight I should have topped it up with water. The FG was 1.020, which is way higher than it should have finished. I left it in the fermenter for over 3 weeks, so the yeast had plenty of time, but the attenuation wasn't there. The sample tasted OK though, I could tell there was more hop character. We'll see how it tastes when I carb it tomorrow.
DIAF: 090502 Honey-Brew List
I gave up and dumped this batch. It never mellowed to the point of drinkability. I will remake this recipe in the spring but use 1/4 the amendments I used this time. A little goes a LONG way. I just hope I can get the smell out of the keg.
Thursday, October 22, 2009
On left-handedness
I think I may have found the source of my CO2 leaks. The tank pressure gauge on my primary regulator looks like it's malfunctioning - the pointer assembly appears to be sprung loose. I suspect that the leak is in there.
I went to Airgas to get my tank refilled (again) and took the gauge with me to see about a replacement. After some searching the guy offered me a welding gauge that has about the same pressure indication range as the original one, and off I went. There was one crucial factor I didn't consider, though: my gauge is left-hand threaded.
I got home after work and went to reassemble the regulator only to discover the thread issue. Obviously I'm going to return the new gauge, but that left my in a jam, since I still didn't have a fully functional regulator. I figured I would just plug the gauge port for the time being with a brass plug and worry about a tank pressure gauge later. (After all, the other one hasn't worked for quite some time, other than as a contributor to global warming.)
Oops. The plug would have to be left-hand threaded too. Guess what? You can't get a left hand threaded anything at Lowe's. Not only that, the gauges they have in the compressor and welder area are all right-hand threaded.
What I ended up doing is packing the gauge orifice with JB Weld to create my own plug. I put a little piece of plastic over the top to spread out the pressure from the tank (stuck in the excess JB Weld), taped it, and screwed it in. So far it appears to be OK. I'm taking the precaution of not leaving the tank valve open and cutting off the shutoff valves in the lines to minimize the leak possibility if I got it wrong. I'll return the gauge at some point.
I went to Airgas to get my tank refilled (again) and took the gauge with me to see about a replacement. After some searching the guy offered me a welding gauge that has about the same pressure indication range as the original one, and off I went. There was one crucial factor I didn't consider, though: my gauge is left-hand threaded.
I got home after work and went to reassemble the regulator only to discover the thread issue. Obviously I'm going to return the new gauge, but that left my in a jam, since I still didn't have a fully functional regulator. I figured I would just plug the gauge port for the time being with a brass plug and worry about a tank pressure gauge later. (After all, the other one hasn't worked for quite some time, other than as a contributor to global warming.)
Oops. The plug would have to be left-hand threaded too. Guess what? You can't get a left hand threaded anything at Lowe's. Not only that, the gauges they have in the compressor and welder area are all right-hand threaded.
What I ended up doing is packing the gauge orifice with JB Weld to create my own plug. I put a little piece of plastic over the top to spread out the pressure from the tank (stuck in the excess JB Weld), taped it, and screwed it in. So far it appears to be OK. I'm taking the precaution of not leaving the tank valve open and cutting off the shutoff valves in the lines to minimize the leak possibility if I got it wrong. I'll return the gauge at some point.
Monday, October 19, 2009
...and it turned out to be for naught
In another burst of "this should have been obvious in hindsight" I have discovered that you can't assign a physical serial port on a VMWare ESXi server to a serial port in a virtual machine that it's hosting. Evidently this is to cut down on the hardware dependency that would restrict VMs from having full mobility from host to host under VMotion. How that differs from the CDROM drive, which can be physically assigned to a VM, is unclear, but I understand the rationale.
Where does that leave me? I have a dependency to deal with: Proficy Workflow's OPC client can only make local calls, meaning the OPC servers it talks to have to be on the same host. I think what I will have to do is switch the serial I/O to another box and use a web interface to retrieve the data into the OPC server. It's a hack but it's a lot cheaper than going for a serial-over-IP solution since I've already got a bunch of beater hardware I can use for that purpose.
Where does that leave me? I have a dependency to deal with: Proficy Workflow's OPC client can only make local calls, meaning the OPC servers it talks to have to be on the same host. I think what I will have to do is switch the serial I/O to another box and use a web interface to retrieve the data into the OPC server. It's a hack but it's a lot cheaper than going for a serial-over-IP solution since I've already got a bunch of beater hardware I can use for that purpose.
Sunday, October 18, 2009
You down with OPC?
What a weekend. Who knew it was such an issue to work out a serial protocol in Visual Basic? (Actually, as it turned out, it wasn't as big an ordeal as I was trying to make it.)
Let's recap the status quo. I have an Arduino Duemilanove microcontroller board that I'm trying to use as a low-budget PLC. I have three Dallas Semiconductor DS18B20 digital thermometers hooked up via the One-Wire wiring topology. I also have two solid-state relays (SSRs) that I will use to switch line voltage to various devices. I need a way to read the temperatures from the thermometers and modulate the SSRs from a "traditional" manufacturing environment like, for instance, GE Intelligent Platforms' Proficy Workflow.
The best way to do that is to use the industry standard for connecting to devices, namely OPC. The trick is that my homebrew (no pun intended) microcontroller doesn't have a driver for anybody's OPC server environment, so I have to create one. To complicate matters, I have to do it using tools that I can afford.
Lots of vendors offer trial versions of their OPC server toolkits. Most of those trial versions are time limited, in that they either only work for some trial period (like 30 days) or they only work for a short interval without requiring a restart (like 2 hours). Fortunately, OpcConnect.com has a listing of lots of OPC server vendors, and I found one that had a toolkit with a tag limited demo instead of a time limited one. The software comes from Graybox (at www.gray-box.net) and I would recommend that you check them out if you're looking for a .NET based OPC server solution. (Some of you who know me are probably asking "has the Unix geek turned coat? .NET? Really?" The sad fact of the matter is that OPC is a Windows technology - the organization that controls the standard has "retronymmed" OPC to mean Open Process Connectivity or some such BS but its original name was "OLE for Process Control." So to make it work you have to use a Windows environment, more's the pity.)
Fortunately Graybox provides some sample code with their OPC server toolkit. This is important because I have not had an original thought in my life but I can copy with the best of them. I built the sample server in Visual Studio 2008 and it ran fine, so I moved on to the significant work - making the sample server talk to my controller. To quote a former colleague, "it's just a simple cereal link" - how hard can it be?
Famous last words. In the end it was simple. Getting there was complicated. I struggled for a while with a confusing phenomenon: when I hooked up a terminal emulator to the com port I could get the exact expected results, but when I tried to use Visual Basic I would only get the response about once every four commands. (This was way before I tried to use the OPC software. I was just trying to build a simple command-line based interface to prove I could do the serial I/O correctly.)
After several hours of frustration and debugging, I finally figured it out by having the Arduino echo the commands received from the serial port onto the LCD display I hooked up to it. When I did that, the problem was clear, and in hindsight obvious: Windows terminates a line with a CR-LF pair, and real operating environments only use LF. (Well, let me qualify that. VMS used a different technique for ending records.) The WriteLine() function used in Windows sends a CR-LF, but the I/O reader on the Arduino was only expecting an LF. What was happening was that after the first successful command from the Windows program, it took four iterations for the Arduino's input buffer to realign (because of the extraneous CR in each iteration). Once I realized that, I changed the Windows-side I/O to use Write() instead of WriteLine() and things started working more effectively.
The last challenge was the actual OPC server code itself. The big problem here was a basic misunderstanding on my part concerning the .NET and Windows security models. Evidently you can't do operations in a class constructor if they require privilege. Including things like opening a serial port. My OPC server kept throwing exceptions on the port open command, telling me I didn't have sufficient privilege. I thought that odd considering I was logged in as the local administrator. Something I Googled made me move the Open() command out of the constructor into a separate method, and that resolved the issue.
As of now I have an OPC client running and getting periodic updates from the Arduino. The tags are available, and I'm ready to move the code to the Proficy Workflow server so I can get on with the next phase of the project.
Maybe I should call Jumpin' Jack Flash
It looks like I may have leaked out my CO2 again. The primary regulator is only showing 10 PSI. I suspect there's an issue with the high-pressure gauge in that assembly. It never read 0 PSI even when it was disconnected, and I had to whack it to get it to register the new cylinder's pressure when I changed it last week. I think I will just stick a plug in there. I'd hate to have to buy another regulator. because...
10 gallon batches are coming
I got an 80 quart pot so I can ramp up production to 10 gallon batches. It arrived Friday, but I have yet to boil anything using it to build up its oxide levels. I don't have enough grain on hand to run a 10 gallon batch of anything except Gayle Bait. I will order up some more stuff and brew later this week. (Hopefully.)
Let's recap the status quo. I have an Arduino Duemilanove microcontroller board that I'm trying to use as a low-budget PLC. I have three Dallas Semiconductor DS18B20 digital thermometers hooked up via the One-Wire wiring topology. I also have two solid-state relays (SSRs) that I will use to switch line voltage to various devices. I need a way to read the temperatures from the thermometers and modulate the SSRs from a "traditional" manufacturing environment like, for instance, GE Intelligent Platforms' Proficy Workflow.
The best way to do that is to use the industry standard for connecting to devices, namely OPC. The trick is that my homebrew (no pun intended) microcontroller doesn't have a driver for anybody's OPC server environment, so I have to create one. To complicate matters, I have to do it using tools that I can afford.
Lots of vendors offer trial versions of their OPC server toolkits. Most of those trial versions are time limited, in that they either only work for some trial period (like 30 days) or they only work for a short interval without requiring a restart (like 2 hours). Fortunately, OpcConnect.com has a listing of lots of OPC server vendors, and I found one that had a toolkit with a tag limited demo instead of a time limited one. The software comes from Graybox (at www.gray-box.net) and I would recommend that you check them out if you're looking for a .NET based OPC server solution. (Some of you who know me are probably asking "has the Unix geek turned coat? .NET? Really?" The sad fact of the matter is that OPC is a Windows technology - the organization that controls the standard has "retronymmed" OPC to mean Open Process Connectivity or some such BS but its original name was "OLE for Process Control." So to make it work you have to use a Windows environment, more's the pity.)
Fortunately Graybox provides some sample code with their OPC server toolkit. This is important because I have not had an original thought in my life but I can copy with the best of them. I built the sample server in Visual Studio 2008 and it ran fine, so I moved on to the significant work - making the sample server talk to my controller. To quote a former colleague, "it's just a simple cereal link" - how hard can it be?
Famous last words. In the end it was simple. Getting there was complicated. I struggled for a while with a confusing phenomenon: when I hooked up a terminal emulator to the com port I could get the exact expected results, but when I tried to use Visual Basic I would only get the response about once every four commands. (This was way before I tried to use the OPC software. I was just trying to build a simple command-line based interface to prove I could do the serial I/O correctly.)
After several hours of frustration and debugging, I finally figured it out by having the Arduino echo the commands received from the serial port onto the LCD display I hooked up to it. When I did that, the problem was clear, and in hindsight obvious: Windows terminates a line with a CR-LF pair, and real operating environments only use LF. (Well, let me qualify that. VMS used a different technique for ending records.) The WriteLine() function used in Windows sends a CR-LF, but the I/O reader on the Arduino was only expecting an LF. What was happening was that after the first successful command from the Windows program, it took four iterations for the Arduino's input buffer to realign (because of the extraneous CR in each iteration). Once I realized that, I changed the Windows-side I/O to use Write() instead of WriteLine() and things started working more effectively.
The last challenge was the actual OPC server code itself. The big problem here was a basic misunderstanding on my part concerning the .NET and Windows security models. Evidently you can't do operations in a class constructor if they require privilege. Including things like opening a serial port. My OPC server kept throwing exceptions on the port open command, telling me I didn't have sufficient privilege. I thought that odd considering I was logged in as the local administrator. Something I Googled made me move the Open() command out of the constructor into a separate method, and that resolved the issue.
As of now I have an OPC client running and getting periodic updates from the Arduino. The tags are available, and I'm ready to move the code to the Proficy Workflow server so I can get on with the next phase of the project.
Maybe I should call Jumpin' Jack Flash
It looks like I may have leaked out my CO2 again. The primary regulator is only showing 10 PSI. I suspect there's an issue with the high-pressure gauge in that assembly. It never read 0 PSI even when it was disconnected, and I had to whack it to get it to register the new cylinder's pressure when I changed it last week. I think I will just stick a plug in there. I'd hate to have to buy another regulator. because...
10 gallon batches are coming
I got an 80 quart pot so I can ramp up production to 10 gallon batches. It arrived Friday, but I have yet to boil anything using it to build up its oxide levels. I don't have enough grain on hand to run a 10 gallon batch of anything except Gayle Bait. I will order up some more stuff and brew later this week. (Hopefully.)
Wednesday, October 14, 2009
Resistance is futile
I have more cable fragments and loose parts lying around here now than a Borg knows what to do with, but with a little help I have overcome the issues with the extension cable for my DS18B20-based temperature probes.
Since I could demonstrate that the extension cable was wired right, the issue was down to the added length of the cable changing the electrical characteristics of the circuit enough to screw it up. Having not done any actual, useful circuit work in over 25 years I didn't have an immediate concept of what the change could be or how to fix it, but I figured it was resistance based and related to the small gauge of the signal wires in the extension cable. I tried an experiment in which, instead of 50' of headphone cord, I used 50' of 12 gauge Romex wire (which, as a side note, is pretty difficult to solder to, because it acts as its own heat sink). That did nothing except add more debris to the workspace.
As it turned out I was on the right track but for the wrong reason. Once again, "Triple Mutt" Chuck provided the crucial concept that led to the answer. The added cable length does change the signal characteristics, but the solution isn't to change the wire gauge, it is to lower the pull-up resistor value so that more current is available to the parasite device. Through experimentation I was able to get a 50' extension working using 1.2K of pull-up (4 x 4.7K in parallel on the breadboard, it was easier that way and has that special Fork and Hay quality look).
The circuit now looks like this (obviously simplified):
I ran a preliminary test last night that showed in boiling water the probe read 211.3 F, so I think we are in pretty good shape to move forward now.
Since I could demonstrate that the extension cable was wired right, the issue was down to the added length of the cable changing the electrical characteristics of the circuit enough to screw it up. Having not done any actual, useful circuit work in over 25 years I didn't have an immediate concept of what the change could be or how to fix it, but I figured it was resistance based and related to the small gauge of the signal wires in the extension cable. I tried an experiment in which, instead of 50' of headphone cord, I used 50' of 12 gauge Romex wire (which, as a side note, is pretty difficult to solder to, because it acts as its own heat sink). That did nothing except add more debris to the workspace.
As it turned out I was on the right track but for the wrong reason. Once again, "Triple Mutt" Chuck provided the crucial concept that led to the answer. The added cable length does change the signal characteristics, but the solution isn't to change the wire gauge, it is to lower the pull-up resistor value so that more current is available to the parasite device. Through experimentation I was able to get a 50' extension working using 1.2K of pull-up (4 x 4.7K in parallel on the breadboard, it was easier that way and has that special Fork and Hay quality look).
The circuit now looks like this (obviously simplified):
I ran a preliminary test last night that showed in boiling water the probe read 211.3 F, so I think we are in pretty good shape to move forward now.
Sunday, October 11, 2009
The controller rises again, in a disappointing way
Remember that Arduino-based controller I was working on back in the summer? Neither do I. Actually, that is not completely true; I remember it all too well, and remember that I'm stymied trying to figure out what to do next.
I think I have settled on moving most of the control decisions out of the Arduino and into Proficy Workflow. (This is clearly not one of the first or second level use cases for Proficy Workflow, but I think it will be fun and educational.) In order to really leverage the power of Workflow, I need at least one of the temperature probes to have enough cord length so I can use it to monitor the boil kettle temperature during a brew session. I alluded to this in an earlier post but it has been a while.
In that earlier post I recounted how my friend, colleague and unindicted co-conspirator Chuck of Triple Mutt Brewery fame wired the Dallas Semiconductor DS18B20 digital thermometers we're using for temperature probes. Dallas Semiconductor created a topology and communication protocol called OneWire which has two operating modes. One is actively powered with a +5VDC source and requires three conductors to be connected. The other one only requires two conductors and has no external supply voltage requirement. This is referred to as "parasite mode," in which the DS18B20 chips actually steal potential from the signal line and store it in an onboard capacitor for use as needed. Chuck and I decided that parasite mode was good enough for our application, and that's how he wired up all the probes, using a 3.5mm (1/8") mono phone plug to terminate them, with the tip connected to the signal lead for the DS18B20 and the shield connected to the other two leads.
What does that have to do with anything? Well, as I started to get back to the hardware basics this week, it occurred to me that I needed an extension cable for the temperature probe I want to use during boils. Luckily I was able to find some 50' 3.5mm stereo extensions at Amazon for a ridiculous price (like, $2.99 each) and I have Amazon Prime so they shipped free.
You may start to detect the beginning of a problem. If Chuck wired the probes with a mono plug shouldn't you use a mono extension? In theory, yes, but in practice the wiring convention is for the "ring" or middle connection of a TRS plug (tip-ring-sleeve, the stereo version of the plug I'm using) to be shorted to the sleeve when a mono plug is connected. It makes sense from a visual perspective: the ring is carved from the real estate that the mono sleeve occupies. So in theory (he says again) a stereo extension should extend mono without alteration.
Well, theory be damned in this case. I plugged it in and nothing worked. I got no temperature reading at all from the probe when it was connected via the extension. After spending most of the afternoon Saturday trying to troubleshoot the connections (in and around watching football and drinking Por Favor), I finally determined that inside the extension cable, the connectors are crossed. The conductor that is attached to the tip at the jack end is on the ring at the plug end. This is not any kind of standard, it's a manufacturing "feature" that is probably an artifact of the low cost of the finished assembly.
No big deal. I cut the cable and respliced the conductors the right way. However, I still didn't get a reading when the probe was plugged into the extension. I ohmed that cable out 20 times and still couldn't figure out what was going wrong.
I thought the issue might have something to do with the length of the cable. The literature I was able to find seems to indicate that a parasite OneWire bus should be able to support an aggregate "weight" of 300M. The "weight" is a representation of the load and is a function of both distance of cabling and the number and types of devices and splices in the bus. With only one device I thought it was reasonable to have my topology with a cable run of 15M or so.
Maybe the problem is the software. After updating my program to the new version of the DallasTemperature library (which is causing me to refactor it, maybe I'll discuss that later) I could reliably read from the probe cable but not when it was connected via the 50' extension.
Back to the length. I created a 3M extension from some hook-up wire and it worked fine, so I decided to cut the 50' cable approximately in half. Yea verily, this worked. I can have a cable of 25' or so as an extension, provided it's wired correctly, but the 50' length is not going to work in this configuration. I'm guessing, but I bet if we had wired them as active busses and not parasites, the length wouldn't have been an issue. Oh well, it's too late to fix that now since the DS18B20's are potted into the stainless probe ends with JB Weld.
I think I have settled on moving most of the control decisions out of the Arduino and into Proficy Workflow. (This is clearly not one of the first or second level use cases for Proficy Workflow, but I think it will be fun and educational.) In order to really leverage the power of Workflow, I need at least one of the temperature probes to have enough cord length so I can use it to monitor the boil kettle temperature during a brew session. I alluded to this in an earlier post but it has been a while.
In that earlier post I recounted how my friend, colleague and unindicted co-conspirator Chuck of Triple Mutt Brewery fame wired the Dallas Semiconductor DS18B20 digital thermometers we're using for temperature probes. Dallas Semiconductor created a topology and communication protocol called OneWire which has two operating modes. One is actively powered with a +5VDC source and requires three conductors to be connected. The other one only requires two conductors and has no external supply voltage requirement. This is referred to as "parasite mode," in which the DS18B20 chips actually steal potential from the signal line and store it in an onboard capacitor for use as needed. Chuck and I decided that parasite mode was good enough for our application, and that's how he wired up all the probes, using a 3.5mm (1/8") mono phone plug to terminate them, with the tip connected to the signal lead for the DS18B20 and the shield connected to the other two leads.
What does that have to do with anything? Well, as I started to get back to the hardware basics this week, it occurred to me that I needed an extension cable for the temperature probe I want to use during boils. Luckily I was able to find some 50' 3.5mm stereo extensions at Amazon for a ridiculous price (like, $2.99 each) and I have Amazon Prime so they shipped free.
You may start to detect the beginning of a problem. If Chuck wired the probes with a mono plug shouldn't you use a mono extension? In theory, yes, but in practice the wiring convention is for the "ring" or middle connection of a TRS plug (tip-ring-sleeve, the stereo version of the plug I'm using) to be shorted to the sleeve when a mono plug is connected. It makes sense from a visual perspective: the ring is carved from the real estate that the mono sleeve occupies. So in theory (he says again) a stereo extension should extend mono without alteration.
Well, theory be damned in this case. I plugged it in and nothing worked. I got no temperature reading at all from the probe when it was connected via the extension. After spending most of the afternoon Saturday trying to troubleshoot the connections (in and around watching football and drinking Por Favor), I finally determined that inside the extension cable, the connectors are crossed. The conductor that is attached to the tip at the jack end is on the ring at the plug end. This is not any kind of standard, it's a manufacturing "feature" that is probably an artifact of the low cost of the finished assembly.
No big deal. I cut the cable and respliced the conductors the right way. However, I still didn't get a reading when the probe was plugged into the extension. I ohmed that cable out 20 times and still couldn't figure out what was going wrong.
I thought the issue might have something to do with the length of the cable. The literature I was able to find seems to indicate that a parasite OneWire bus should be able to support an aggregate "weight" of 300M. The "weight" is a representation of the load and is a function of both distance of cabling and the number and types of devices and splices in the bus. With only one device I thought it was reasonable to have my topology with a cable run of 15M or so.
Maybe the problem is the software. After updating my program to the new version of the DallasTemperature library (which is causing me to refactor it, maybe I'll discuss that later) I could reliably read from the probe cable but not when it was connected via the 50' extension.
Back to the length. I created a 3M extension from some hook-up wire and it worked fine, so I decided to cut the 50' cable approximately in half. Yea verily, this worked. I can have a cable of 25' or so as an extension, provided it's wired correctly, but the 50' length is not going to work in this configuration. I'm guessing, but I bet if we had wired them as active busses and not parasites, the length wouldn't have been an issue. Oh well, it's too late to fix that now since the DS18B20's are potted into the stainless probe ends with JB Weld.
Friday, October 9, 2009
Una momenta, "por favor" - esta es la cerveza más fina
Wow, this Vienna Lager type ale is seriously good. I am really sorry that you, my gentle readers, are not here to appreciate it. (Or not, because that means there's more for me.)
Serving: 090902 Por Favor
It didn't come out as dark as a Negra Modelo. It's more akin to a Dos Equis in its coloration. But whatever the color, me gusta esta cerveza. This is a recipe I think I will be keeping continuously on tap.
That sort of brings me to another question. If I have to have Por Favor on tap, along with Geordie Boy and Gayle Bait, I don't have room for anything else. What to do, what to do?
Serving: 090902 Por Favor
It didn't come out as dark as a Negra Modelo. It's more akin to a Dos Equis in its coloration. But whatever the color, me gusta esta cerveza. This is a recipe I think I will be keeping continuously on tap.
That sort of brings me to another question. If I have to have Por Favor on tap, along with Geordie Boy and Gayle Bait, I don't have room for anything else. What to do, what to do?
Sunday, October 4, 2009
New tun, new water, new yeast, new hops, new volume = new beer?
There's a commonly-held belief that you should only change one thing at a time while troubleshooting a problem. My philosophy is more like "let's change things and see how it breaks differently." Saturday's brewing session exemplified that quite well.
Brewed: 091001 Geordie-Boy Ale
Can I even call this Geordie-Boy with all these changes? On the ingredient side, I used all the right grains, but the grind on the 4 ounces of chocolate malt was a little fine - I have it uncrushed, and I used my coffee mill. (Actually, "a little fine" is an understatement - a lot of it was powder. Wonder what that will break?)
I was going to try for the original recipe's hop schedule as well. The IBUs on the finished beer have been a little light because I didn't scale the East Kent Goldings I was using for bittering to take into account the difference in alpha acid percentage between EKG and Target, which is what the recipe actually calls for. I set out to use Target for the bittering, but Alabrew didn't have any so I got Galena instead. It has the same alpha acid percentage (11%) as Target. I used East Kent Goldings as usual for the flavor and aroma addition.
I used different yeast too. Since I don't have any Wyeast 1099 (Whitbread Ale) which is what I had been using, I switched to White Labs WLP005 British Ale yeast. It's the first time I have actually used a White Labs vial. I have two Irish Ale vials that are now expired, from my plan to brew a Guinness recipe that never made it into the pipeline because I didn't invest in the nitrogen system to serve it. The yeast was easy to use (they don't call it "pitchable" for nothing). We'll see how the fermentation goes.
Process changes abounded as well, and some of them were not intentional at all.
I planned from the start to use my newly-constructed larger mash tun, and it worked out fine. I was a little concerned because the grain bed wasn't very deep, being spread over a much larger surface area, but gravity-wise it worked out. As I suspected, I was able to control the heat loss during the mash just by insulating the lid. I used bed pillows, laying them on top of the tun, and I had no measurable temperature loss over the hour of mashing. This tun was large enough to take my entire volume of sparge water at once, and my screen manifold worked just fine. The best part was the convenient rolling of the tun to the back yard to dump the spent grains.
About that water: I constructed a filtering system to provide filtered tap water for brewing instead of using it straight from the Pelham Waterworks. I got a Omni U25 whole-house filter at Walmart. It is intended to be plumbed directly into the 3/4" supply line in your home. The filter housing itself is 3/4" NPT threaded, so I got a female garden hose to 3/4 NPT male adapter for the inlet side, and an threaded hose bibb for the output side, and voila! instant on-demand filtered water in a volume and delivery format I can actually use. I hooked it up to the hose system I was using, drew the mash and sparge water volumes, and disconnected it to store for the next brewing session.
Of course, filtering the water's not much use when you boil it away. Somehow during the boil session I let the boil-off rate get out of control and I ended up with a post-boil volume of 4.6 gallons. I'm not really sure how that happened, to be honest. I actually started with more wort than the batch sheet called for and had to boil some down to the right amount before starting the "timed" 90 minute boil. I flamed out right at 90 minutes and ended up a half gallon short. Guess it's time to recalibrate the boil rate. Maybe it's seasonal - it is a bit cooler now than it has been.
The original gravity for this batch came in at 1.048, which I computed as equivalent to 1.044 in 5 gallons using this great discussion on gravity in wort. The particular calculation I used to determine this is labeled as Equation 7 in that article: SG2(points) = v1/v2 * SG1(points). So in my case it was SG2(points) = 4.6/5 * 0.048 = 0.044 (you only use the fractional part of the gravity in the calculation, see the article for an explanation). That means I had 65% efficiency in the new rig, which is about what I expected.
Kegged: 090902 Por Favor
The Vienna lager-as-ale is in the keg now. It finished at 1.010, for an ABV of 5.74%. The sample tasted pretty good. I put it in the keg under 10 psi and will leave it there to carbonate the "set and forget" way. It should be ready next weekend.
Brewed: 091001 Geordie-Boy Ale
Can I even call this Geordie-Boy with all these changes? On the ingredient side, I used all the right grains, but the grind on the 4 ounces of chocolate malt was a little fine - I have it uncrushed, and I used my coffee mill. (Actually, "a little fine" is an understatement - a lot of it was powder. Wonder what that will break?)
I was going to try for the original recipe's hop schedule as well. The IBUs on the finished beer have been a little light because I didn't scale the East Kent Goldings I was using for bittering to take into account the difference in alpha acid percentage between EKG and Target, which is what the recipe actually calls for. I set out to use Target for the bittering, but Alabrew didn't have any so I got Galena instead. It has the same alpha acid percentage (11%) as Target. I used East Kent Goldings as usual for the flavor and aroma addition.
I used different yeast too. Since I don't have any Wyeast 1099 (Whitbread Ale) which is what I had been using, I switched to White Labs WLP005 British Ale yeast. It's the first time I have actually used a White Labs vial. I have two Irish Ale vials that are now expired, from my plan to brew a Guinness recipe that never made it into the pipeline because I didn't invest in the nitrogen system to serve it. The yeast was easy to use (they don't call it "pitchable" for nothing). We'll see how the fermentation goes.
Process changes abounded as well, and some of them were not intentional at all.
I planned from the start to use my newly-constructed larger mash tun, and it worked out fine. I was a little concerned because the grain bed wasn't very deep, being spread over a much larger surface area, but gravity-wise it worked out. As I suspected, I was able to control the heat loss during the mash just by insulating the lid. I used bed pillows, laying them on top of the tun, and I had no measurable temperature loss over the hour of mashing. This tun was large enough to take my entire volume of sparge water at once, and my screen manifold worked just fine. The best part was the convenient rolling of the tun to the back yard to dump the spent grains.
About that water: I constructed a filtering system to provide filtered tap water for brewing instead of using it straight from the Pelham Waterworks. I got a Omni U25 whole-house filter at Walmart. It is intended to be plumbed directly into the 3/4" supply line in your home. The filter housing itself is 3/4" NPT threaded, so I got a female garden hose to 3/4 NPT male adapter for the inlet side, and an threaded hose bibb for the output side, and voila! instant on-demand filtered water in a volume and delivery format I can actually use. I hooked it up to the hose system I was using, drew the mash and sparge water volumes, and disconnected it to store for the next brewing session.
Of course, filtering the water's not much use when you boil it away. Somehow during the boil session I let the boil-off rate get out of control and I ended up with a post-boil volume of 4.6 gallons. I'm not really sure how that happened, to be honest. I actually started with more wort than the batch sheet called for and had to boil some down to the right amount before starting the "timed" 90 minute boil. I flamed out right at 90 minutes and ended up a half gallon short. Guess it's time to recalibrate the boil rate. Maybe it's seasonal - it is a bit cooler now than it has been.
The original gravity for this batch came in at 1.048, which I computed as equivalent to 1.044 in 5 gallons using this great discussion on gravity in wort. The particular calculation I used to determine this is labeled as Equation 7 in that article: SG2(points) = v1/v2 * SG1(points). So in my case it was SG2(points) = 4.6/5 * 0.048 = 0.044 (you only use the fractional part of the gravity in the calculation, see the article for an explanation). That means I had 65% efficiency in the new rig, which is about what I expected.
Kegged: 090902 Por Favor
The Vienna lager-as-ale is in the keg now. It finished at 1.010, for an ABV of 5.74%. The sample tasted pretty good. I put it in the keg under 10 psi and will leave it there to carbonate the "set and forget" way. It should be ready next weekend.
Saturday, October 3, 2009
Yeast among evils?
I'm getting ready to brew today with my new mash tun, but the washed yeast I had been planning to use in my batch just isn't any good anymore. It can't possibly be because I left it sitting out in unconditioned space, can it? (Doh!) Fortunately AlaBrew is available to pick me up. I sent Tommy over there to harvest some yeast for me. They didn't have the normal Wyeast strain I have been using in the Geordie family so I'm going to try White Labs WLP005 British Ale for the next iteration. Hopefully I will get to it today.
Interestingly, Tommy was subject to some (good natured) questioning about why he was there to pick up yeast. ("Are you SURE this is for your dad?" kind of stuff.) I thought it was funny because I can't imagine that too many teenagers trying for a quick path to rotgut show up with a list specifying four specific yeast strains by name - and get a response when they text back to "Dad" because the Danstar Nottingham was recalled and he needs to take something else instead. Is it really an issue for an adult who is not of drinking age to buy yeast? I wouldn't have thought so, since there's quite a few tedious steps between having yeast and having beer, but I guess in a state where it's still technically illegal to homebrew, as a supplier you can't afford to take too many chances.
Kegged and carbed: 090901 Gayle Bait
I forgot to mention that I got this into the keg. It's very mild, except for one thing. To me at times it seems to have sort of a yeasty aroma that's reminiscent of the smell of the carboy after I racked it to secondary. The Brewmistress doesn't seem to notice it though, so maybe it's just my imagination, or maybe it's just green and needs to season a little more. Either way, once you get past the aroma (if you're me) it tastes good if a little bland, which is exactly what I was shooting for.
Interestingly, Tommy was subject to some (good natured) questioning about why he was there to pick up yeast. ("Are you SURE this is for your dad?" kind of stuff.) I thought it was funny because I can't imagine that too many teenagers trying for a quick path to rotgut show up with a list specifying four specific yeast strains by name - and get a response when they text back to "Dad" because the Danstar Nottingham was recalled and he needs to take something else instead. Is it really an issue for an adult who is not of drinking age to buy yeast? I wouldn't have thought so, since there's quite a few tedious steps between having yeast and having beer, but I guess in a state where it's still technically illegal to homebrew, as a supplier you can't afford to take too many chances.
Kegged and carbed: 090901 Gayle Bait
I forgot to mention that I got this into the keg. It's very mild, except for one thing. To me at times it seems to have sort of a yeasty aroma that's reminiscent of the smell of the carboy after I racked it to secondary. The Brewmistress doesn't seem to notice it though, so maybe it's just my imagination, or maybe it's just green and needs to season a little more. Either way, once you get past the aroma (if you're me) it tastes good if a little bland, which is exactly what I was shooting for.
Subscribe to:
Posts (Atom)