Thursday, April 17, 2014

Dissertation Simulations Continue

A month ago, I projected that I would be done with all the computer number crunching in just a matter of a few days.  I was very, very wrong.  My few day estimate turned into three weeks.

A week ago, I discovered a mistake in my program.  In looking through the results I noticed a particular value, which I knew was always a sum of a bunch of fractions, was always coming out as a whole number. I investigated and found the obvious error I had made.  It had take me a lot of time writing the code that would generate those very significant fractional values and I was accidentally throwing it all away, choosing to round them all up to one and add that up instead.  These fractions are an important part of the simulation and drive a lot of the results; incorrect values here mean my overall results were invalid.

My bad results were saved (because hard drive space is cheap) and the simulations were restarted. Oh, and another sixteen cases were added, bringing the total up to forty-eight.  After letting my main computer at school work at it for a week or so, I surmised it was going to take a long, long time to get through all the simulations. We had just recently cleaned the lab and taking an unused machine, I spent a day getting it set up and put it to work. It is not near as powerful as my main computer but every little bit helps.

Monday afternoon, as I was watching results slowly trickle in, I began racking my brain for where I could get more computing power.  There was another souped-up computer there in the lab just like mine that probably wasn't getting used much but it was assigned to another student.  Maybe she'd let me get on and run my simulations in the background?  There were plenty of other older computers around but, besides not having the desk space and network connections, they looked much less capable than the one I commandeered. Where could I get the number-crunching machines I needed?

My home computer.  It is new, relatively high-powered, and I had most of the software already installed. It took me a few hours to get it up and running and right before bed the other night, I set it to work.

In the morning I looked at the results and there is no two ways about it: this machine is a monster. I've compiled results from all the runs that have completed so far and I'll let the graphs do the talking:

Each bar is one case that was simulated.

There are two significant differences between my school computer and home computer: my home computer has processors running at almost twice the speed and it also has a solid-state hard drive.  My simulations write out to disk a lot, constantly logging results and reading back in logged values to make calculations.  I wrote the simulations this way so that I could stop and start them at will, giving them the ability to always pick-up right where they left off. (The more fundamental motivation was due to Matlab, the simulation environment I'm using, silently crashing on my school computer.  I have no idea why it does this and wish it would stop.  Having the crash recovery has been essential in getting simulations done and it has given me a lot of flexibility in scheduling the simulations.)

A solid-state drive is MUCH faster for disk writing and reading, giving my home computer a big advantage.  My school computer only has a conventional spinning-disk hard drive and, to make matters worse, it runs eight of the simulations in parallel, each constantly trying to access the disk.  I've done testing during development that showed the per-simulation time increases as the number of simulations being run in parallel increase.  Its still faster overall to run as many as I can in parallel but they definitely get in each other's way.  My computer at home is only running four simulations in parallel but I bet the solid-state drive presents virtually no roadblock to any of them.

The graphs above aren't a purely apples-to-apple comparison but it is clear for even moderately disk-heavy tasks like my simulations, the solid-state drive goes a long way.  Even though my home computer got in on the action a week late, I'm betting it will end up completing half of the simulations itself.  Why didn't I think of this last month?

Saturday, March 22, 2014

Bicycle Lights

One of the things that drew me to Breezer bikes, the brand I currently ride, is the integrated lighting system.  A generator driven by the rear wheel and pre-mounted and -wired lights for the front and the back meant I never had to worry about running out of battery power.

After riding for several years, though, and dealing with being hit by a car (during the day) while on my motorcycle, I have come to the conclusion that brighter is better.  These integrated lights are nice but if I'm serious about riding my bike at night, I need to do more so that I can ride safely.

For a while I had a helmet-mounted light powered by a battery on the frame but wiring was a pain to deal with at times. I had to run the cord down my back and plug it into a I had installed jack beneath the seat.  It worked pretty well and it was nice to have a light the followed the direction I turned my head.  The light fixture I had made for the helmet and wiring were not durable enough, though, and it became clear a better solution was needed.

While I was convalescing I came up with an improved solution, ordered the parts, and yesterday I finally put all the pieces together.

Two LED "headlights" up front, one always pointed the same direction as the wheel and the other the direction of the frame (straight-ahead).  

These rear lights are some LEDs that I have had for over a decade and I think I've finally found the perfect home for them. They started as some night-time dim light for my bedroom in Boise and were previously used at my nerd desk before I upgraded the lights there.  These lights are clusters of red and green LEDs and for rear lights I'm not powering the green ones.  The canisters for the lights were just a little bit too large to fit into the milk-crate grill and had to be filed down.

This is the main junction box for the system.  The red/green/white wires are coming up from the rear lights and enter the box through a hole in the bottom.  The switch powers both front and rear lights.

Just below the junction box is the battery for the system, strapped on the bike rack and the milk crate.  It is well beyond the needs of lights in terms of capacity but it means I won't need to charge it very often.  Speaking of charging, the yellow terminal sticking out the bottom of the junction box is used to do just that; there is a matching terminal on the other side.

UPDATE:  Here's a view of the lights at night.  Note that the headlight is illuminating the area directly in front of the bike as well as to the left, where the front wheel is pointed.

Thursday, March 20, 2014

Even Better Fix for the Temperature Shifts

As I discovered previously, the load of the relay coil was causing Vcc (which is used as the analog reference voltage by default) to droop when the coil was being driven to provide power to the heating pad.  This caused a shift in the measured temperature whenever the coil opened or closed. The problem was significant when the Arduino Uno was powered by USB and less but still noticeable when powered through the DC jack.

There's an even better fix, though, and it hinges on the fact that the temperature sensor I'm using, the TMP36, has the same output over a wide voltage range (2.7V to 5.5V).  By default, the Uno uses the 5.0V regulated voltage as the ADC reference voltage (AREF).  It is possible, though to wire an external voltage to the AREF pin and use that voltage as the ADC reference.  As it so happens, the Uno has a second regulated voltage on-board: a 3.3V supply.  I verified that whether the relay is open or closed, the supply provides 3.3V.  

It was a simple matter to make the hardware change and wire the 3.3V pin to the AREF pin. I also added a capacitor across AREF and ground to help stabilize the voltage, something I should have done before.  I left the temperature sensor on 5V; it puts out the same voltage whether powered by 3.3V, 4.93V, or 5.03V. The software changes were also straight-forward: tell the Uno to use the externally provided voltage on the AREF pin as the ADC reference and change one line of code used in converting the ADC value, having it use 3.3V instead of 5.0V in the calculation.

The proof is in the pudding, as they say:

No big shift when the green trace hits the temperature control limits. Looks like the problem is solved.

Tuesday, March 18, 2014

Root Beer Temperature Controller Under Load

I finally have done some testing using bottles actually filled with...

... water.  Didn't even cap them.

Note the time scale on the bottom: hours.  With all the "thermal mass" of the water, it takes a lot more energy to cause a temperature shift in the chamber.  With air the temperature would swing out of control band in minutes; with water it takes hours and really doesn't ever venture outside the target range.  You can still see the temperature shift when the relay turns off, the temperature moving up a few tenths of a degree.

(Incidentally, from a conversation I had with a guy who used to design appliances, this is why burners on ranges don't have temperature settings on their control knobs, just generic levels (like "1" to "10" or "Low" to "High").  Without knowing the type of pan being used (aluminum, cast iron, stainless steel...) and what is being cooked (grilled cheese, bit pot of water for boiling pasta, steak...) it is virtually impossible to design a control system that will keep the item being cooked at the required temperature without taking forever to reach that temperature or wildly over overshooting the temperature (that is, burn the food).)

I think we're ready to give this a shot.  I'll check my supplies but I hope to have a batch of root beer going by the weekend.  Expect pictures, though they will probably not be very exciting.

Friday, March 14, 2014

Temperature Shifts

Where we last left off, I had been able to use a relay-actuated electric heater and a temperature sensor to act as a simple thermostat to regulate the temperature for use when allowing root beer to ferment. Yesterday I upgraded the system to use a transistor to control the relay rather than driving it directly from one of the Arduino Uno microcontroller pins.  It looks like this may have solved some problems with losing serial communication to the Arduino IDE (at least the problem hasn't shown up again) but the trouble-shooting process revealed another: a temperature shift whenever the relay opens or closes.

I actually observed this problem the first day I was doing testing on the system:

If you look at the "Heating Pad on High" plot (the green one) you see that as soon as the chamber temperature hits the lower limit (and the relay closes to turn the heating pad on), the temperature shifts down almost a full degree.  Oddly this behavior doesn't show up for the "Heating Pad on Low" curve which is at least a little bit odd. 

My immediate guess, which turned out to be correct, is a sagging Vcc.  With all voltage supplies, as the amount of current being drawn increases, the voltage at the output will decrease.  Supplies that have very little voltage drop are considered "well-regulated"and there are various metrics that can be used to quantify this degree of regulation.

So I pulled out my multi-meter and measured the 5V supply:

Relay closed: Vcc = 4.93V
Relay open: Vcc = 5.03V

That 0.1V shift messes with the on-board analog-to-digital converter (and the math I do in software to convert the measured value to temperature).  The converter and math think they are working on a 5V scale but some of the time its actually a 4.9V scale.  Not a huge difference except that my temperature sensor measures from -40'C to 125'C and the temperature differences I'm trying to measure are less than 1'C.  In this application, very small changes in supply voltages can cause trouble with the temperature measurement.

Since I discovered the problem, I have though of three different solutions in succession:
  1. Op-Amp Range Adjustment - Use a rail-to-rail op-amp (like the MCP6002 which I have used before and have on-hand) to magnify the output of the temperature sensor so that at say, 100'F the sensor/op-amp combination effectively put out 5V.  This would effectively increase the resolution of the sensor around the temperatures I care about at the cost of not being able to read temperatures over the whole sensor range.  Any temperature above 100'F would all produce the same 5V value.
  2. Constant Load - If the changes in load are causing the voltage supply to drift, why not do something to keep the load constant?  Using a PNP transistor and a fixed load (something like this), I could provide a constant load on the voltage supply whether the relay was engaged or not. When the relay was open, a dummy load would be switched in through the PNP transistor (using the same control signal for the relay coil) and when the relay closed, the dummy load would get switched out and the relay coil would load down the power supply.
  3. Change the power supply - It took me a while to figure out why, in the above graph, the "Heating Pad on High" showed this problem but "Heating Pad on Low" didn't.  The amount of power the heating pad draws does not affect Vcc on the Arduino; it is on a completely separate circuit. I eventually realized I had effectively changed the power supply to the Arduino between these two experiments.  When the heating pad was on low, I had been supplying power through the DC power jack and when I had changed the heating pad setting, I had unplugged this power supply for some reason.  Without the external power, the Arduino was being powered by the USB bus it was attached to and it doesn't surprise me that the voltage regulation was not near as good.
Obviously, solution 3 is the easiest to implement, though it didn't come to me until the next day.  I had already planned to power the Arduino from an external supply when the system was actually in use as it would be operating stand-alone, apart from a computer.  With the external supply in place I get the following Vcc measurements:

Relay closed: Vcc = 4.99V
Relay open: Vcc = 5.00V

This is probably within the range of error for my meter and should be good enough for my purpose. Here's what the thermostat performance looks like under USB power compared to external DC power:

The shift under USB power is very obvious and it is clear that there is also a slight problem still when being powered by the DC jack (the little squiggle at the lower control limit).  By the way, this data is when the heating pad is on high; way over-shooting the target temperature range.  But more about that next time.

Thursday, March 13, 2014

Transistor Controlled Relay

Today I was having some problems with the temperature controller not sending information out to the serial port for viewing on the serial monitor in the Arduino IDE.  I don't know if I solved the problem but in the midst of trouble-shooting I decided to upgrade the system to using a transistor to control the switching of the relay.

Previously I was using a single digital IO pin to drive the relay coil directly.  By using a high enough series resistance I was able to get the coil current down to 36mA and despite the fact that the datasheet would not guarantee my relay would work under such a situation, it did. (The Arduino site says I should have been safe at 36mA, just below the 40mA absolute rating. Still, not a good place to be.)  The serial communication problems seemed to go away when I didn't plug the relay in and draw so much current so it seemed like a good idea to bite the bullet and use a transistor to drive the relay coil.  This would reduce the load on the digital IO pin and allow me to drive the relay coil with enough current to operate within the datasheet specifications.  Two birds, one stone.

The circuit I used is simple (and readily available):

And here's what it looks like all built up:

The blue connector on the bottom right is switched in and out by the relay directly above it.  In the picture it is wired into an outlet that the heating pad is plugged into. The header in the center bottom provides 5V and ground to the temperature sensor as well as running the output from that sensor back into an Arduino analog input. In the top center is the transistor used to drive the relay coil.  I used a header here as a socket so I could easily replace the transistor. This is was a good idea as the first transistor I tried was dead.

(I didn't bother trying to connect to that off-pitch header.  They seriously need to fix that.)

Building this "shield" seems to have helped with the serial communication bug but now I've got another problem.  Every time the relay closes or opens the temperature sensor output shifts.  I think I know what's going on here and I have an interesting solution.  Stay tuned for more details.

Monday, March 10, 2014

Root Beer Temperature Controller

As I was continuing to clean my nerd desk this weekend and get the basement cleaned up after months of neglect, I ended up sinking a few hours into a side project. It was all started by the downsizing of my root beer bottle collection.  I have two or three times as many bottles as I typically used and I was in the process of throwing them out to make shelf space for some of my wife's stuff. Seeing all the dust on the bottles made me realize it had been a while since I had made root beer which further reminded me that my root-beer process was highly variable and what those in the business call "out of control".

The big uncontrollable factor is the temperature at which the bottles sit while the yeast eats up the sugar to provide the carbonation.  After making root beer for several years I have some idea how long this process should take but the margin of error is still very wide.  I usually end up opening test bottles to see the carbonation is progressing and it often takes two or three before I consider the bottles ready for refrigeration.

I remember my mother saying when they made root beer they used an electric heating pad to provide a more consistent temperature and as I was cleaning out these bottles, that sounded like a great idea to me.  In fact, I could go one step further and use one of my Arduino Unos and build a thermostat to control the temperature in the "fermentation chamber" (probably just a plastic cooler).  I already had all the hardware I would need to make this work and most of the code already written as well.

The idea is simple.  Put a temperature sensor in the fermentation chamber where the heating pad and root beer bottles are.  When the temperature drops below a certain temperature, switch on the heating pad and when it gets too hot, switch it off; basic thermostat.  I already had a few extra temperature sensors from my home temperature measurement project and the code to take a bunch of measurements with the on-board ADC, average them, and convert them to a Fahrenheit value.  Stripping down that code to work with one sensor instead of six was not difficult.

The hardest part was figuring out how to switch the heating pad.  These pads plug into the wall outlets which run at a much higher voltage.  I wouldn't be able to directly switch that voltage on Uno but I could probably control a relay that was capable of providing that switching.  I scrounged through my relays and found one (and only one) that was designed with a 5VDC coil (the voltage the Uno uses) and could switch the 120VAC that comes out of the wall.  The the Uno doesn't provide enough current to switch coil at 5V, by putting in a series resistance I was able to get the current under control and the relay still switching properly.

Rummaging through the garage I found an old outlet and outlet box I could use to mount the hardware.  Though the circuit is simple, making sure that everything is done correctly and safely took a little work. I didn't have the heating pad yet so I used an incandescent light bulb (there still good for something) as my heat source when I tested the system.

After only a few hours, I got it working!  The light bulb heats up the sensor to 82 'F and then the Uno shuts off the light via the relay.  When the sensor cools back down to 80 'F it turns the light back on.  I made a little movie showing an animated graph of the measured temperature with an inset clip of the lamp being turned on and off as dictated by the controller.  The synchronization between the animation and live-action recording is not perfect but you'll get the idea.

There is always room for improvement.  My bare-bones control algorithm does not guarantee that the temperature will stay between 80 'F and 82 'F as the temperature in the chamber may continue to rise even after the heating pad is turned off as it is cooling down. It would be nice to log the temperature so I could see how it actually ends up behaving.  I could try using some radios I purchased for the home power measurement system that is under development and tying it into the temperature measurement system; I doubt that will happen any time soon.  I also have some external flash memory I could write to and then read back after the batch was processed.  One of those data-logging shields would be nice right about now.

None of these limitations is going to keep me from using this immediately. Once the heating pad arrives from Amazon, I'll be ready to brew up a batch and see how well this works. I'll keep you posted on how it turns out.