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.

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.

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.

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.

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.

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.

Christmas Board Games (Part 2)

Its taken some time but I've finally been able to try out a few more games that showed up for Christmas.

Coup

Coup is designed to be a short, simple game of bluffing and conspiracy.  Each player has two hidden characters with special abilities and using these abilities, attempts to remove the characters the other player's control. And, since nobody knows who your characters are, you can bluff and act as if you are any character at any time. Of course, if you get caught, things won't work out so well. At no point in the game will you every know which character's the other player's hold and every play is a gamble.  They call this kind of game a "social deduction" game as it is somewhat possible to infer who might be what character based on how they (and everybody else) is playing.

The games tend to go quickly and I enjoyed them, even though I lost most of the time. And you can't beat the feeling of lying through your teeth and getting away with it.  The worst part of the game is that players are eliminated one at a time; if you're the first to lose in a six-player game, you'll have a bit of sitting to do.  Not too long, though, as the games are over in about 15 minutes, usually.

Space Cadets Dice Duel

Space Cadets Dice Duel is a follow-on game to the original Space Cadets, a cooperative game.  In that game, each player has a role on the ship and to contribute to the success of the mission, he/she must complete his/her own mini-game.  Space Cadets Dice Duel is similar in that each player has their own role but rather than a mini-game each rolls a special set of dice and rather than all working on one team cooperatively, two teams play against each other.

There are lots of dice and lots of rolling.  There are no turns per-se and the only cost to an unfavorable roll is that the dice end up being rolled again. Each team ends up with multiple players rolling their dice simultaneously in an attempt to position their ship into advantageous firing positions or avoiding and preventing their opponent from doing the same.  The game is almost literally non-stop; when our pilot took a break mid-game to grab a snack, we were sitting ducks just hoping the other team wouldn't be able to get their act together.

I was attracted to this game because it seemed like it might be simple enough for many non-board-gamers to understand and exciting enough for them to enjoy.  I haven't been able to really test it in such a scenario but I will say my more strategic and nerdy board game group did enjoy it.  We picked it up quickly and the we were able to play three games in about 90 minutes.  Its more of a tactical game than strategic but we got good enough in a short amount of time that we got past the dice-rolling random-ness and were trying to execute specific movements and attacks.  I suspect it will make a repeat appearance at game night.

Dissertation Simulations

As of this morning, I have begun what I hope to be the official simulations for the work on my dissertation. I have 33 separate cases to study and this morning I queued them all up to run on my school computer over the weekend.  For exactly this reason, the machine I get to use has eight cores and 48GB of memory so it should be able to handle the workload; nevertheless I don't expect it will be done for several days.

I've been working since summer 2013 on the development of the computer code that is being run in these simulations.  I started with a model of the electrical grid in the western US and have been working on a way to add energy storage (a battery) to a specific location in the grid.  It was important for my research that the simulated behavior of the battery should wear out over time (like batteries do) so a bit of my work was getting that implemented. A week or two ago I started putting the individual pieces together and began testing the system as a whole, making sure everything was behaving as expected.

When the final development test results came back this week with the system appearing to function I was faced with a startling realization: I was ready to run the simulations with the specific conditions I wanted to study.  Though the difference between these "real" simulations and the test ones I had been doing involved only changing a few lines of code, the psychological hurdle was immense.  I'm actually doing it; I'm almost there.

These simulations will take a while to complete.  They have to figure out, for a given set of demand for electrical energy in the western US, the output level for each generator in the western US that will provide this energy for the lowest cost.  And it has to do this for every hour of the year (8760 of them).  In half the cases I'm simulating, it has to do this for five years in a row.  

I hope everything will be done when I come in on Tuesday.  When I left, all eight cores on my computer were maxed out and I expect they will stay that way for a number of days.

The completion of the simulations is a significant milestone but I still have plenty of work even after they are done. Analyze data, make graphs and tables, and write the several hundred page document that PhDs traditionally have to write. I won't be done this semester but I'll be very close.