Archive

I tracked down the source of my Download % complete issue. Turns out it was an “order of precedence” issue. When calculating the % complete, I divided an integer value by a bigger integer value and multiplied by 100.0 – well, since the division operator occurred first, I was always getting 0 * 100.0. As soon as I changed the code to say 100.0 * downloadedTotal / totalFileSize – everything worked just fine.

I also made a small tweak to show sensors that had a downloaded data file but were not currently represented on the device as either a connected sensor or a remote (device) data file. The user can download a data file to the phone, then delete both the config and data file on the device. Before the tweak, the local data file wouldn’t show up at all – now it is displayed as “(local only)” in the list.

When looking around online I happened upon AChartEngine, a graphing library for Android that seemed relatively simple and powerful. I started thinking about how awesome it would be to quickly plot the data from my phone rather than pushing it to the PC, bringing it up in Excel, and plotting it within that application. As it turns out, it only took about an hour of fiddling (mostly formatting) to get a result I am very pleased with. As you can see from the screenshot, it will plot however much data is in the data file, and even breaks it into sections depending on the name the sensor has assigned to it at the time. This means you can easily and visually distinguish the various batches for a given sensor.

Because of the “(local only)” tweak I made, this also means that you don’t have to be connected to the device to display a sensor’s last downloaded data file. I don’t know how often that is going to be required, but I suppose at least when I am somewhere and want to explain the application to someone I could at least show the plotting capability.

The source code for my Android application has been uploaded to my OneDrive. It’s not perfect or pretty, but it gets the job done. I suspect I will end up writing more Android apps in the future, although I will likely do so in a different IDE – I really despise Eclipse. It crashes frequently, and is extremely temperamental.

As anticipated, my main boards for the temperature monitoring circuit came in from OshPark.com last week. The same night they arrived, I soldered a board together and hooked it up to the LCD screen and other circuit bits – and nothing displayed at all. After swallowing down a brief moment of complete panic, I deduced that I must have somehow messed up the pin 3 wiring in my schematic and PCB. When I reviewed the design, my fears were confirmed. I had tied the resistor to the 5V rail instead of GND, which meant there was basically no current flowing through that PCB pin. I decided to desolder the side incorrectly going to 5V and rather deftly (not really) rigged it into the solder pool for pin 1, which is a GND.

The updated schematic and PCB on my SkyDrive folder is now corrected. I also realized I should add some silk screening for the OneWire buses so it is clear which side is the 5V/Power side and which is GND, so that update is included as well.

One everything was working as expected, I loaded the components into the aluminum project box and mounted it on the wall next to my lagering fridge. I bounded upstairs to connect up the computer and test the Windows application I wrote (shown in the previous post)… and then spent several hours fighting with the Bluetooth. Finally I got the bright idea to go down and try to connect with my phone while standing next to the device – and it worked perfectly. Additional research revealed two key points:

I had used a RN42XV modem, which is only a class 2 device and has maximum ranges of 7-10 meters when unobstructed by subflooring, joists, etc. There is a class 1 version, RN41XV, which has a much more powerful transmitter and greater distance… which is probably what I should have used.

A metal enclosure (like my fancy project box) is apparently a totally AWESOME way to completely dampen the effective range of a lower power Bluetooth transmitter

My short-term solution while waiting for the class 1 to arrive was to run the transmitter outside the project box. It’s ugly – but it works. I can connect and download data to my PC now.

On another front I also basically wrapped up my Android application development. It’s not as sophisticated as the Windows application, but it doesn’t need to be. It performs the basic functions of connecting to the device:

listing out the sensor information,

allows for the name and frequency values to be updated, and

the data files can be downloaded.

For someone who had never written an Android application before, and for whom it had been nearly 18 years since I wrote any Java code (the Comp Sci object-oriented design class senior year I took as an “elective”… and made all the CS majors wonder what the hell a Chemical Engineer was doing in there…) I think it turned out pretty well.

One aspect I don’t have working the way I want is displaying the % complete while downloading – basically the BluetoothSocket hangs the user interface thread while it is downloading and the %s never update until it is over and a “download complete” message pops up… but I’ll get there. I intend on posting that code on my SkyDrive as well when it is cleaned up enough.

The control box is similar in layout and components to the original “wired” one I assembled back in 2008. The controller component and display have changed, but I was able to re-purpose most of it to accomodate the 2.0 components. The front panel has a cut-out for the LCD screen and three buttons to the left to enable navigation through the screen items. There is a contrast adjustment knob below the screen to modify the LCD screen intensity depending on conditions (daylight vs. nighttime) and two override switches for the pump control. The override basically negates whatever the current pump state is – so if the microcontroller has them turned off, you can turn them on, and vice versa. I will try to do a video or post about the various screens and options sometime soon.

The control box internals are identical to before with the exceptions I cited earlier.

The two solid state relays turn the pumps on and off based on 5V signals from the Netduino and custom controller board. They are powered from a single plug and main on / off switch that also powers a 120V to 5V converter board. This converter board I cannibalized from the previous mainboard through a tactical mitre saw cut that kept the 120V and 5V header circuitry intact and removed all the old PICAXE circuitry. It’s not pretty, but it gets the job done. The 5V output powers a fan that blows directly on the SSRs to keep them cool as well as the Netduino.

A header allows a Sparkfun Xbee Regulated Explorer board to plug into the control board and receive the wireless transmissions from the grant and sparge arm end-devices. This Xbee is set up as the network “coordinator” and any signal is transmitted back to it. There is also a very colorful 6-wire rainbow jumper that runs from the control board up to the custom LCD backpack I posted about a couple weeks ago. The LCD backpack takes care of the output to the screen as well as recognizing when one of the buttons is pressed and sending an “interrupt” message back to the microcontroller so it can process the user input.

I still hope to replace the enclosure with something more sleek and industrial at a future date, but this will keep be brewing in the time being and allow me to resolve issues and upgrade in the meantime.

Now for the parts list, as best as I can manage. You will have to forgive me – many of these items I sourced back in 2007/2008 and I can’t remember where they came from or how much they cost – so I did my best to hunt down equivalents in today’s online environment.

Much of the build for the wireless grant was posted in the previous two posts. I will try not to repeat things that have already been covered and focus on those things that are unique to the grant. The grant is actually based on the MoreBeer hopback with the addition of another 1/2″ stainless half coupler located 180° from the lower outlet coupler. 2 Madison 8700 horizontal float switches occupy the two half couplers on the same side, spanned by a custom-fabbed 1/8″ stainless steel support for the electronics housing. These float switches have a pivot point well clear of the threaded half coupler and allow the floats to move freely, which is an important criteria when selecting / sourcing them. As I found out, the stainless switches I bought a few months back can’t be used for this reason.

The outside of the electronics housing is identical to the wireless sparge arm with an on/off switch, two LEDs, and a port to recharge the LiPo power supply, although they are located on the bottom of the enclosure to limit the potential of unwanted liquid getting inside. Internally the layout and quantity of components is identical to the wireless sparge arm with the exception of an addititional header for another switch.

From a cost perspective the wireless grant is in the same neighborhood as the wireless sparge arm. One issue to navigate is getting an extra coupler welded into the grant, a service that MoreBeer no longer offers. That said, here is a reasonable estimate:

This week’s activities included the final build of the wireless grant and wireless sparge arm for BrewzNET 2.0 – I will focus primarily on the sparge arm in this post, and the grant in a subsequent one. Make sure to click on the pictures to blow them up so you can also see the labeled components.

As has been mentioned in prior posts, the base for the sparge arm is a standard MoreBeer Ultimate Sparge Arm that I have pimped out with some custom components. There are multiple adjustment knobs that set the height of the sparge arm itself inside the mash tun, the height of the float switch, and if required the height of the electronics housing. Both the stainless steel float switch and electronics box are supported with another MoreBeer special order item that is not in their online or mail-order catalog, the SCUP405. I had to write to their customer service department and ask if they had a solution for supporting the float switch, and that is what they came up with. After I received the first one I realized how perfect it would be for also supporting the electronics and ordered a second.

The top of the electronics housing has 4 components – an on/off switch, a bright green LED indicating whether the power is on or not, a bright red LED that reflects the device’s current charging status, and a mini USB port to recharge the device in between brewing sessions. When the device is plugged into a standard USB cable and power source (wall charger, laptop PC, USB hub, or whatever) the red LED remains lit until the battery is fully charged, at which point it turns off. I did some preliminary test several weeks back and found the battery would power the electronics for more than 4 hours (more than adequate for the typical brewing session) so I did not determine what the ultimate life of the battery was… It could potentially be good for several brew sessions.

The 2″x2″x4″ plastic electronics housing does a nice job of encapsulating the circuit boards and components. I could have maybe used a slightly thinner project box, but I like having a little extra space to accomodate my sausage fingers when assembling. At the top is the SparkFun LiPo Charger board that serves as the recharging and use interface between the remaining components and the LiPo battery. A custom PCB design acts as the interface between the 3.8V supplied by the LiPo battery & charger to the Sparkfun XBee Explorer Regulated board and ties the float switch to the appropriate pins on the XBee modem.

So what did the wireless sparge arm cost, in total? I’m scared to total it up because I know my wife reads these posts too (when I don’t bore her silly enough to quit half way). Here’s the raw materials / components breakdown:

So that’s the wireless sparge arm. I’ll hopefully have some video of it in action up soon (once I get the other pieces finalized and tested). It’s certainly not the cheapest piece of brewing gear ever, but it certainly looks good and is one-of-a-kind… for now 🙂

Sometimes the proverbial “Plan B” just has to be good enough. For my wireless grant, that means settling for the old plastic float switches I was already using instead of the fancy-schmancy stainless ones I purchased several months ago. “Why?” you ask? Ah, well because the stainless ones have a design that renders them completely useless in my grant, and I didn’t know that until I had completely disassembled the old grant and tried putting them in.

The 1/2″ half-couplers that the float switches screw into are a certain depth, and the stainless steel float switches are shorter than that. When you add in the 1/8″ stainless steel electronics support bracket, it backs it out even more. This means the pivot point for the float sits back in the coupler and is recessed too far to allow the float to swing freely (or at all). This means they’d be stuck in the “closed” position, no matter what the liquid level was. Argh! The most frustating thing about that is that no matter what vessel I try to put them in, they wouldn’t work – all my 1/2″ half couplers are the same length.

Maybe I’ll use them in a hydroponics project in the future or something. I dunno.

So behold Plan B: I salvaged the plastic Madison float switches from before, replaced the old electronics housing with the bracket and new electronics enclosure, and hooked everything up. I tested it and it works with the breadboarded Netduino main circuit. I still need to make enclosure penetrations for the power and recharge LEDs, but that will be pretty quick. I also need to glue down the XBee interface board – that’ll be the final step before closing everything up.

Here’s a quick shot of the underside – Currently there is an on/off switch and the USB port for recharging the LiPo battery. I’ll probably put the power and recharging LEDs down here too.

Hopefully the mounting bracket for the sparge arm electronics will come in this week and I can get that one buttoned up too, then it’s a matter of waiting for my mainboard to come back from OSH Park. Since I ripped out the old grant electronics and basically have no way back – I am going to do some serious surgery to my current control box as well. Even though I ultimately intend on getting a new enclosure, I’m going to rip out the main board and other assorted PICAXE-specific stuff and build in the BrewzNET 2.0 electronics so I at least have something to brew with. I will post as that work progresses…

I did it. I’ve been considering it for a week or two, and I finally did it. I took the ApiFrameBuilder class out of the Grommet XBee library and fused it into the MFToolkit Xbee library. I have never been overly happy with how the original MFToolkit XBee class handled receiving data in on the serial port, and I did like the Grommet method – so I combined the best of both libraries. In short, it seems to work REALLY well. It even handles the crazy packet dump problem that was occuring before my Netduino reset every time. Yeah, the Netduino doesn’t seem to be rebooting anymore.

Cue the rays of light and the chorus of angels…

This also means that my code is no longer a direct port of EITHER of the libraries to VB, but I did leave the original header comments in the classes so full credit for those sections of code is traceable back to the original authors.

The other interesting side-effect of having a program that no longer reboots is I found additional issues with the original MFToolkit library, mainly that it doesn’t manage disposing of resources too well, so after 20 or so minutes of running, the program threw a “OutOfMemoryException” when trying to create new objects. I guess I am not surprised because there is a significant quantity of byte manipulation going on in memory using the MemoryStream object… so I ended up having to re-code 20-30 classes with Using / End Using blocks to try to force proper resource disposal. For PC-based .NET programs you probably would never see this, but on these smaller embedded platforms it appears that efficient and explicit use of Dispose() is critical. Or I need to buy a newer Netduino with more memory *GRIN*.

I still intend on trying to track down what is causing the byte dumps shown in the screenshot above, probably through the DIGI support forum, but for now I’m going to breathe a sigh of relief that my programs don’t crash and the Netduino keeps running. I opened a thread on the issue so hopefully someone will have some ideas.

I did finally get that replacement stainless float switch for the sparge arm assembly – check it out. It’s much smaller and provides significantly more vertical position adjustment options. I need to come up with a plan to keep the braided wires from becoming gross / discolored from repeated exposure to the wort (maybe I’ll just heat-shrink tubing the whole deal), but that’s a minor issue.