Unholy Alliance

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.

Progress and frustrating bugs

It’s been a couple weeks since my last update. I’ve been picking away at the to-do list as time and life allows. Some things have progressed quickly, while others have gone very slowly. I am also amazed at how rough integrating multiple functioning components together can become, particularly when threading processes is involved. So here’s where things are for now…

All of the float switches finally arrived. When I ordered the stainless steel horizontal float switches from Amazon I failed to recognize that they would be coming in from Asia, so they took a good 3 weeks to travel, clear customs, and arrive on my doorstep – but that said, they seem to work well and they should work out nicely. The photo to the left shows the two grant switches and the one sparge arm switch hooked up to a breadboard circuit with a couple Xbees configured to transmit their switch state (open / closed) when the value changes. I’ve got them powered independently from the Netduino circuit and can turn them on/off individually by the SPST switches that control their power from the rails. The travel distance before registering an off/off change is different from the polymer float switches I’m currently using in the brew system, so when I retrofit my gear to use the new setup I’m going to have to take some new measurements for the grant volume so it properly calculates the collected amounts and remaining sparge time.

I also created a debug screen that allows me to see what the float switch states are, the sparge and grant pump statuses, and make sure they are aligned with the expected functionality of the program. I’ve manually tested and debugged the program to a point where it calculates the sparge rate (quart/min) and pump rate (gal/min) based off the time it takes for the liquid in the grant to rise and fall as well as the volume transferred to the kettle and the time remaining to hit the target volume. Part of this process was building in some error-checking to handle switch noise and unrealistic calculation values, and I believe the system calculations are pretty stable.

Some additional items I’ve worked on:

• All the electrical components are on one big breadboard. I gave up my multiple breadboards and shields because they were becoming unruly.
• I implemented a PingModem routine that checks for activity from the sparge arm and grant XBee modems every 10 seconds, and that handle a modem that goes “silent” for some reason (dead battery, bad networking, etc).
• Interaction with the screen is handled by the three momentary interrupt buttons – an “up”, a “down”, and a “select”. These drive the line selected and the functions happening on the LCD display. At this point, my testing is done through these buttons that simulate the end grant control box.
• I tried to implement a count-down timer to facilitate brewing, but found my I2C updates to the LCD were too slow to deal with reliably displaying the information (and ended up garbling the screen pretty badly), so I ripped all that code back out.

Unfortunately I’ve run into a big issue that I haven’t managed to resolve. The system seems to work fine for 5-20 minutes, but usually within that time something goes sideways and the Netduino reboots. This means the collected volume, the switch states, and any other information for the session is basically lost. I don’t know exactly why it is happening, and it seems to occur randomly so it is wicked difficult to track down. Some of my ideas for root causes include:

• Threading issues between multiple classes in the program – perhaps one thread trying to access a property at the same time another thread is?
• Some weird I2C collisions between the MCP23008 in my LCD backpack and the MCP23017 I use for capturing the button presses.
• Power problems – maybe the LCD and other components are pulling too much power from the Netduino? This seems unlikely since I have powered the circuit with the breadboard power supply instead of the USB and had the same issue.
• Netduino 1 firmware issues – Seems unlikely, but I could get a Netduino 2 and see if it has the same problems.
• Bad garbage collection / memory consumption – maybe my program is coded poorly and ends up using up all the available flash memory, causing the device to reboot?

I have no idea. I am continuing to try to work through the list above and eliminate causes as I can, and I even have a thread on the Netduino community forum to try to get outside opinions – but so far it has multiple views and no replies. This bug could be the nail in the coffin for BrewzNET 2.0, but I’m determined to figure out what is going on… it just might take some time.

As far as additional development goes, I still have the following to work on:

• Integrate a logic chip to handle a manual pump on/off switch with both the grant and sparge pump signals from the Netduino as an override
• Determine if a Darlington driver chip is required to turn the SSRs for the pumps on and off
• Figure out what kind of end-device enclosures I want for the grant and sparge arm electronics
• Figure out how I am going to mount the sparge arm switch to the sparge arm
• Identify and order additional components required for the control box