Aluminum air batteries for extended trips in electric cars

I like the idea of owning an electric car, except that we frequently make trips to see family members 100 and 350 miles away.  So I've been scratching my head about ways to let an electric car do that.  (The obvious approach is to buy a Chevy Volt or a plug-in Prius).

Today I read up on aluminum-air batteries, which have some neat properties.  They have very simple chemistry from very plentiful sources: aluminum, water and carbon.  They let the aluminum oxidize using oxygen from the atmosphere, and as the aluminum anode dissolves, you get aluminum hydroxide, which can be reprocessed into pure aluminum.

The other great thing about them is their theoretical energy density of 8 kwh / kg, far higher than we see with lithium-ion batteries.

The downside is that they're single-use -- no recharging.  But for a road trip, that may not be so bad -- instead of gassing up, you trade in the depleted battery modules for fresh ones and head back on your way.  I'm imagining a standardized battery module rack in the trunk that you only fill with modules when you're planning a long trip.

The economics kinda sorta work.  This paper claims they can get about 1.3 kwh / kg of the 8kw theoretical maximum, and that they could recycle the batteries for about $1.10 / kg.  So you'd basically be paying $1 / kwh.  The Nissan Leaf takes about 34 kwh / 100 miles, so your road trip miles would cost about $0.34 / mile.  That's 2x or 3x the price of gas for a traditional car on the highway, but you're only paying it on long trips, and it saves you from having to install a gas motor + generator in your all-electric car.

The other interesting possibility is using solar thermal plants to reprocess the spent aluminum hydroxide.  It melts at 572F, which is a downright easy temperature for a field of mirrors to produce.  The great thing about that process is that the solar thermal plant doesn't have to actually generate any electricity directly -- it's just generating heat to strip off the oxygen atoms, which turns into electricity later when it's in your car.  So the plant is much simpler than a solar thermal electric plant would be.

Here's a paper that proposed that very arrangement back in 2010.

In my studies, it was sad to see a lot of the startups from the 1990's and 2000's working on aluminum-air batteries closed down.  I only found one or two companies selling metal-air batteries at all, and those are zinc-air batteries, which have a lower theoretical energy density limit.

So maybe it's time to start looking into this technology again, especially now that electric cars are hitting the market.

Disable "browser back" and "browser forward" keys in gnome

My lenovo thinkpad has keys above the left and right arrow keys, that by default are wired to my browser's "forward" and "back" buttons.  This is a horrible idea, because it means that frequently I'll accidently hit them while entering text in a textbox, and lose all my edits when the browser leaves the page.

This fixed it for Ubuntu Lucid (running gnome):

System ... Keyboard Shortcuts ... Add ... Name: Do nothing ... Command: /bin/true ... Apply ... click in the "Shortcut" column for the newly created shortcut ... press the browser back button.

It should display as "XF86Back".  Now repeat, creating another shortcut for XF86Forward.  Problem solved!

mbw MCBLOCK test results (used to be) bogus

Update: Andras updated mbw to fix this.

I was testing a machine's memory performance, and ran across the "mbw" package in Ubuntu lucid.

$ mbw -a -n 1 1024
...
0 Method: MEMCPY Elapsed: 0.23493 MiB: 1024.00000 Copy: 4358.801 MiB/s
0 Method: DUMB Elapsed: 0.16298 MiB: 1024.00000 Copy: 6282.864 MiB/s
0 Method: MCBLOCK Elapsed: 0.08543 MiB: 1024.00000 Copy: 11986.562 MiB/s

I was curious why the MCBLOCK numbers were so much higher than the others, and this led me to the relevant piece of code:


                for(t=0; t < array_bytes; t+=block_size) {
                        c=mempcpy(b,a,block_size);    
                }
                if(t > array_bytes){
                        c=mempcpy(b,a,t-array_bytes);
                }

Which appears to be completely broken.  The mempcpy(b, a, block_size) call does exactly same thing every time.  All I can figure is that the author either was trying to demonstrate cache performance, or fumbled an attempt to do the memcpy() calls on blocks of block_size each.

Anyway, it's a good reminder of Caveat Emptor when using random benchmarks.