Home > Brew gear, BrewzNET 2.0, Tech geeks > Progress and frustrating bugs

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…


wpid-2014-01-21_17-43-23_753.jpg 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.

wpid-2014-01-21_17-48-37_683.jpg 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
Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: