Andrew Que Sites list Photos
Projects Contact
Main

July 29, 2014

Battery Selection Begins

   Started working on a spreadsheet to take the daylight data, and combine it with a solar panel and battery.  The idea is to plot the charge of the battery/batteries in relation to the daylight.  When the sun is out the bright the batteries will be taking charge.  When the sun is low the solar panel might be generating just enough power to supply the computer.  In the evening the batteries are discharging.  I wanted to see how various solar panels and battery capacities would work.  Moreover, I wanted to see how much discharge could be expected from a typical day, and a cloudy day.  With two cloudy days in the records I have pretty good data to work with.  Using the assumption that I could expect 75% of the energy put into a battery to come back out, and the Pi's load of 3.5 watts, I found that a 30 W solar panel with a 15 Ah 12 volt battery would not normally drop below 70% charge on sunny days, and could deal with the two cloudy days by dropping down to 20%.  However, I have been eying a more powerful SBC which has a 10 watt draw.  Here I found that a 30 Ah battery with a 100 watt panel would stay above 60% most days, but barely survive the two cloudy days dropping below 10%.
   What isn't factored in is the maximum charging current of the batteries.  A 30 watt panel would produce a 2.5 amp charge current at 12 volts, which is probably ok for most batteries.  However, a 100 watt panel could produce an 8.3 amp charge and this might be getting close to the limit for some batteries.  I haven't even looked at charge controllers yet.
 
   Added some more fetches to Operation Lux for calculating power usage.  First, the power generation is now given in both watt hours and amp hours (a typical rating for batteries).  The power draw can also be entered and a time period given, and the surplus energy will be calculated.  This allow one to see if a given solar panel will produce enough power to run a device of a given wattage.  The default of 3.5 watts is given for a 24 hour period, which represents a Raspberry Pi running for a day.  This setup does not factor in losses from cables and batteries, but will give a basic estimate of solar panel requirements.
   Did a 24 mile bike ride today to visit the town of Waunakee.  Encountered a strong headwind during the entire northward portion of the ride.  After stopping for lunch went west and ended up back by Epic System's Galactic Wind.  From the valley I stopped in at the side of the road I could clearly hear the low "woosh" of the turbine as the blades went by.  I also heard a higher pitch whine and the sound of metal on metal from time to time.  After observing the turbine for a bit I believe this sound to be the yaw motor used to turn the nacelle into the wind.  On my return trip I again went through the town of Ashton and used trails by Quisling Park, Middleton Firefighters Memorial Park, and the Pheasant Branch Trail to get home.  About two blocks from home it started to sprinkle and after I was home it began to rain.  So I was just in time.
   Sometime after 4:30 pm, ππ shutdown.  I reset it around 7:15 pm but it was out again 9:00 pm and wouldn't come back.  After I retrieved the device from the roof I found the 5 VDC power supply was dead.  These supplies are basically cellphone chargers so I replaced it with an other one I had laying around.  It looks like the power supply got wet and rusted the lead off a resister.  There is also some corrosion on one of the electrolytic capacitors.  The new supply I put in a separate plastic container and hopefully that should keep it dry.
   Today was a very sunny day after two rather cloudy days.  Yesterday brought in 1,731 Wh/m2·day and the day before that 1,038 Wh/m2·day.  Both would require a solar panel rated about 25 times more than the wattage desired.  A typical sunny day (this month at least) generates at least 3,000 Wh/m2·day which means a solar panel rated about 10 times the desired wattage should be sufficient.  The best days can be over 4,000 Wh/m2·day.  I might have to consider a battery bank that sustain the server for several days for cloudy times and letting that capacity charge back up on the bright days.  Even the cloudy day two days ago wasn't as dark as I expect it could get on a fully overcast day, and I would like to know that number.  More data!
   Pictured is the sunset was observed during our 13 mile bike ride today.  The town of Ashton makes a pretty good north-west pivot point.  This trip only took an hour and 18 minutes which included several stops for pictures and 4 hill climbs.
   Did a 15 mile bike ride today into downtown Madison where I spent about an hour doing some long exposure photography.  On several of these I ran some High Dynamic Range (HDR) filtering and came out with a few shots I was pleased with.  The ride itself was the first night ride I've done in awhile.  Having not ridden downtown from this direction before I had a little trouble figuring out where the bike path was going.  A couple of times had a turn back because it was clear I was no longer following the path.  I am not sure doing this ride during the day would have helped.  I also gave my head light a good workout.  It ran for nearly 2 hours without issue.  There are four color settings for power level: green, blue, yellow and red.  This is the first time I have seen yellow, but no change to light output occurred.

July 25, 2014

Applied Geometry

So while working on the galvanometer project I ran into a tricky math question. I wanted to scale the needle length and degrees of sweep based on the dimensions of the image. Here are some examples:


In both examples, the needle in the galvanometer is a different length; longer in the top and shorter on the bottom. The sweep is also different, less on the top, and greater on the bottom. The divisions are the same for both. This was the kind of auto-scaling I wanted to achieve. But the math was being tricky. I spent a day playing with the math from an algorithms standpoint, but didn't get anywhere. So I decided to play with it geometrically.  I needed an arc to pass through 3 points: the bottom left corner, the top center, and the bottom right corner. Since I was using a perfect circle, as long as I passed through one of the bottom points to the top center I could be assured the arc would do the same on the other side.

Initially I approached this as an equation with two known (one bottom corner, and the top center), and two unknowns (radius and angle). I failed to find any system of equations that did what I needed.

In the past I have used a geometric approach to solve these kind of problems, looking for way I could draw a solution rather than calculate it. So I played around for awhile in Sketchup before I discovered the following.

In the above drawing I have half the galvanometer (width is really ½ width). Point A is the top center, and B is the bottom right. What is known is the width and height, and the unknowns are the needle length (line AC), and angle c (∠ACD). I found that by drawing a line from A to B, dividing this line in half (point D) and making a line perpendicular to AB at point D, this would intersect line AC at exactly the correct location. That is if line AC were rotated at point C, point A would end up perfectly touching point B and making the desired arc. So the length of line AC is the needle length. The sweep angle can also be derived from this drawing. Angle c is half of what it would need to be to rotate AC to touch point B. And since this drawing is half the total sweep, angle c is ¼ the total sweep for the galvanometer.

This did not take long to implement, and had the desired results. One added benefit was the fact the math worked just fine for ratios that had more than 180 degrees of sweep. However, there are a couple of scenarios now possible with the galvanometer I needed to address. If the sweep is greater than π radians (180 degrees), the needle's start is no longer off the screen. Here is an example:

I no longer have a galvanometer, but a more general analogue gauge. So I added a correction to make the needle center when it was not off the screen. The last issue was when the ratio was such that the needle length was greater than half with image width. This caused some of the chart to be drawn off screen. When this happened, I simply limited the needle length to half the width. The results are exactly what I desired.

The library needs some cleanup and I need see if anymore functionality is required. Afterward I plan to add this to my open source libraries.

July 23, 2014

Power Calculation Script

   Now that Operation Lux has a decent amount of data I want to stop using spreadsheets to do energy calculations.  At the bottom of the page I added some Javascript that will allow energy production to be calculated for a given solar panel.  A list of solar panels of various sizes allows the characteristics to be filled in automatically.  Then the amount of light over a given period can be entered, and the amount of energy produced is returned.
   I did a 17 mile bike ride today to visit the town of Cross Plains.  There is a long 250 foot climb to the top of a hill on the way out, followed by a fairly rapid drop at the top of the hill.  Pictured is a few from a park in Cross Plains I stopped for a break before the return trip.
   Today's bike ride destination was the small wind farm just north-west of Middleton.  It is called Epic System's Galactic Wind and consists of 6 turbines generating up to 9.9 MW.  They are fairly visible and being a fan of wind power I thought this might be a good destination for a bike trip.  The winds on this trip were fairly high, and the way to the turbines I had a good tailwind.  They turned out to be much further away than I had initially though, and getting to them required a little zip-zaging on back roads. I couldn't pre-plan the trip because the turbines don't yet appear on the satellite image maps, but they are visible from at least 10 miles away so I didn't figure I would have a problem.  This was the first time I actually heard a wind turbine from a distance.  In the past the only time I could hear a turbine was when I was under it.  From my observation point about 300 yards from one of the turbines I could discern a low swoosh as the blades rotated parallel to the tower.  It was quite subtle and reminded me of a muffled ocean wave. 
   The wind speed for the afternoon (as logged by the Dane County Airport) were between 13 and 18 MPH which according to the Vestas V-82 (the turbines that make the wind farm) datasheet means each turbine was generating between 200 to 1200 kw of electricity.  On my 2 hour and 18 minute ride, I estimate each turbine generated about 3.9 kWh of power—enough electricity to run our house for 3 months.  Such number dwarf my little solar project.  But then it costs about $2 million to put up a turbine like those at this wind farm.
   My trip finished up at 19 and 2/3 miles.  The day was already getting warm and I had consumed close to 2 liters of water (most of which I think went into soaking my clothing with sweat).  However, I think it a good trip.

Today I tried an experiment using shared memory. I wanted to add a galvanometer chart to the Operation Lux section that would show the current level of sunlight. The lux logging software has this information, but how to transfer it from the C software to PHP script was the question. I had a number of options. I've done this in the past using an Internet socket. For those projects I had a lot more information to convey. Here, I just had a few bytes of data (the current lux measurement) so I decided to try shared memory because I hadn't worked with that before.

On POSIX style systems shared-memory is pretty easy to work with. In C you can establish a shared-memory file and get a pointer to this memory. That makes Inter-Process Communication (IPC) easy. PHP doesn't have pointers like C, but it does suppose POSIX style shared-memory. Instead the shared-memory is treated like a file. This still works fine because I am only transferring a few bytes. In very short order I had data transferring between the logging software and the PHP script.

Now that I had instant access to the luminosity data I wanted to display it in some meaningful way. I decided to add a galvanometer chart. The needle of the meter would indicate how much light the sensor was receiving, and update regularly. Back in 2008 I wrote an article about how to create a galvanometer. I pulled this code out and decided to turn it into a generalized class. Turned out so well I might continue the cleanup work and turn it into an other open source project.

My bike can fly

My bike can fly

   The last couple of days I have been putting my bike to work and doing some exploration of my Middleton surroundings.  Since our good friend Pluvius got us a smart phone I have been growing rather fond of it.  I often use the GPS to keep an eye on upcoming traffic as I drive as the Madison area can get bad at times.  Some years ago I had considered getting a GPS for my bike trips and never did.  I knew my phone should be able to do this now, and I have been testing it out.  On my frist trip the application I was using didn't update my position all that often and didn't produce a great map of my trip.  After adjusting the update rate I did an other ride and it produced a much better path.
   Pictured is how my bike is stored in the garage.  Xiphos and I thought about how to fly the bikes when not in use shortly after we moved in.  Over the winter most of the bikes could easily be hung upside down from a few nails in the garage door support structure.  However, my bike, with all of it's bags and such, weights too much for this.  Xiphos had been experimenting with pulleys and had a nice block and tackle with 4 sheaves on each end.  We hung this from one of the rafters and it made easy work of flying my heavy bicycle up and out of the way.