In a follow-up to my previous journal entry titled "Multiple Stages," I'd like to add the following link:

Finn EV Tech

I mentioned the fact that you'd be best served by batteries AND supercapacitors. Well, these guys are producing something they call the "powerpak," which is a lithium battery with an integrated supercap. The result is something which is part main store and L1 power cache. It can dump high power until the supercap is drained, then dump a more normal amount of power from the battery. The result: high energy density AND high power density. A few of these, and I could probably make a freeway-capable electric motorcycle.

Oh, and let's not forget these guys. Want a hub-motor for your vehicle, so you can do away with the transmission, differential and drive shaft? No problem; the largest one the make, at the moment, is about 14 kW (about 19 hp), but if you put one in each wheel, you've got nearly 80 hp STRAIGHT TO THE WHEELS! That should sufficient to make some little two-door putt-putt get up and hustle. And, since you eliminate a large part of the complexity (and friction), you improve the miles-per-kilowatt-hour, which mean 20 kWh of batteries will take you even further.

Getting VERY close to being able to make my own, practical, BEV.

As I've mentioned before, I've been looking for some kind of Electric Vehicle (EV) to cut the cost of commuting to/from work. Building in a little extra range to get around traffic jams, I figure I need about 90 miles/150 km of range on a single charge. So far, though, there aren't any vehicles available which will do the job. There have been, but they were leased, not sold, and most of them have been withdrawn and destroyed by their manufacturers.

One of the reasons why there aren't more EV's out there is the fact that batteries tend to be low in capacity and very heavy. That's changing, though. More and more companies are coming out with Lithium-Ion-powered prototypes and concept cars, which have range and performance similar to existing Internal Combustion Engine (ICE)-powered vehicles. Consequently, we're getting closer to the day when I can drive to/from work on electric, instead of gasoline.

I'm really looking forward to that day.

I ran across an interesting website this last week: EVUK. In this site, the author complains (frequently) about the fact that all these wonderful electric cars are available in the US, but not in the UK (where they are frequently paying more than USD 6/gallon for gasoline; and I thought the prices around here were bad!). Sorry to burst your bubble, guys, but most of these vehicles aren't actually available over here. Some are prototypes, some are vaporware (announced, but not actually in production), some are just plain speculation, some have been cancelled. Their website does have some interesting links, though. For example, they turned me on to a battery company I hadn't heard of: Thunder Sky, in China. They are supplying high-capacity lithium-based batteries, for very good prices. I'm estimating their energy density at 267 Wh/kg; the best I'd seen, previously, was < 200 for lithium-ion batteries, and those were the small ones you find in aftermarket laptop batteries. These guys are building large, high-capacity batteries, not the small wimpy stuff.

How much capacity is that, really? Let's play with a theoretical situation. I need 90 miles per charge. If my car gets 5 miles / kWh (that's do-able, for something compact), that's 18 kWh. With their batteries, that's only 68 kg/ 148 pounds of batteries. Thats about as much weight as about 23 gallons of gasoline. Yes, you're reading that right: 90 miles in an EV, and the battery pack weighs about as much as two tanks of gas.

At that rate, it shouldn't be hard to make something with a higher range. Indeed, they have. Take a look here. They list motorcycles/scooters, cars and even BUSSES which are running pure electric. These vehicles have been built, but only as showcases for their technology. I believe they are actually building the busses, though, as part of an agreement with the bus manufacturers.

Want more specs? Take a look here. Metric Mind is now supplying their batteries, along with everything else you need to do an electric conversion. Some of those cars not only have enough range to get me to/from work, they also have enough range to drive to my mother-in-law's place. While I'm not that keen on visiting my in-laws, that's a trip we take fairly often. My dad lives a little closer than that, so any vehicle that can take us to see my wife's family can also take us to see mine. That's useful for more than just going to/from work; that eliminates most of the need for a gasoline vehicle, altogether.

This changes things. Soon, I hope.

I just want to add a couple more items on the subject of input.

How does your web browser know what URL you just typed in? You're manipulating hardware, but other software is taking those raw manipulations and converting it to something your web browser understands. Modern handheld systems do the same thing, but they usually read your marks on a section of the screen and convert them to ASCII codes which are fed to whatever application you're using. Consequently, if your application can take triggers on various objects (in addition to text), and can take raw text input, you can use a keyboard for the text input, or you can have a handwriting recognition program outputting ASCII codes. Most of the problems with handwriting recognition comes when we have to enter odd, non-text inputs (like control keys, arrows, extensive amounts of punctuation or ALT-something). If those become triggered events, and we can trigger them through other means, we eliminate most of the need for the odd text inputs. We can keep them, for people who do have a keyboard, but the odd inputs become yet-another trigger for the events.

Additionally, if we have a handwriting recognition application which outputs raw text, and a text editor application which takes raw text as an input, we could have some kind of middleware, which looks at what's being entered and attempts to guess what we're writing; it could provide additional triggerable events which would cause multiple ASCII codes to be sent. I have such an application on my Palm; it's called TextPlus. I enter a letter or two, and it gives me a menu of word and phrase "guesses." If one of them is what I'm writing, I tap the word or phrase, and it is entered as if I had quickly written the whole thing. Since it adapts to what I write, it quickly becomes useful, and allows me to enter text very rapidly, even with an otherwise inefficient handwriting recognition system. It takes any kind of text input (so I can use Graffiti OR the onscreen keyboard to drive it) and provides text output, which can be used by any application which uses text input. If we can do this with text, what can we do with other forms of input? How hard would it be to implement a voice-based system which, while not quite up to taking dictation, can trigger many of the various events, as a result of voice commands? Such systems, with limited vocabularies, are much easier to implement, and could be handled by most handheld machines. Some handheld games have been set up with tilt sensors, so that physically tilting the unit causes things to happen. How hard would it be to have something like that scroll through menus, or work the scrollbars in a frame? Also, some handhelds have a "jog wheel" on the side; what if you could set that to trigger up/down/select events in a menu? Additionally, most handheld machines have additional buttons, which can be "mapped" to various purposes. Again, the basic physical inputs (microphone/tilt sensor/jog wheel/button) would drive a program, which would generate known events. Consequently, an application wouldn't have to be specially written for these input types. As long as the triggers are taken in through a standard means, and the input programs can trigger events through those means, any input program can map any kind of physical input to any kind of triggered event.

With these basic types of inputs, and the ability to convert input from one type to outputs of another type, what kind of input systems could we easily adapt to in the future? I mean, the concept of pipes, with programs taking input streams, producing output streams, and feeding that output to the input of another program, is nothing new. Unix systems have been leveraging that paradigm for decades, and to good effect. Consequently, we wouldn't need to rewrite applications, unless someone came up with a fundamentally different type of input. Considering the fact that touchscreens (originally driven by light pens), mice and keyboards have all been around since the 1960's (or earlier), and they are the main forms of interacting with applications today, it's safe to say that's not something which happens often. Consequently, this type of system, if properly implemented, could still be useful (and even powerful) four decades from now. Using intermediate object code would allow it to migrate and scale to new CPU architectures, so it wouldn't be outdated with the next CPU family to hit the market, which happens all too often with existing systems. And, since the stylesheets can be updated, the physical appearance could be kept fresh, without needing to actually replace the underlying application.

In my last entry, I laid out how I envision a User Interface being described by XML tags, much like the way we use HTML, today. I also dealt, to some degree, with stylesheets, and how they would provide a way to use the same application on different systems, even if they have very different types of displays. This time, I'd like to touch a bit more on how the code related to the applications would actually execute.

So we've got a GUI which runs cross-platform, on Mac, Windows, Linux and Palm. These systems can have very different CPU's. So, how to you "write once, run everywhere?" Normally, that's a catchphrase used by the Java programming language. Additinally, one of the basic tenets of Microsoft's .NET platform is that you write the software, then (maybe) compile it to some platform-independent format for redistribution. In both cases, you have to have software on your platform which will "understand" the Common Language Runtime or Java Virtual Machine object code and execute it. This tends to be rather slow. A better example would be Slim Binaries, so named because they tend to be very compact, and they are typically compiled to native object code, at load time. They are typically very modular, as well. That way, if your handheld is limited in RAM, it can compile the parts which it really needs (say, the display routines, the input routines, and the find and replace) and leave the parts it doesn't need at the moment (the spell checker, the rendering engine for multiple typefaces in multiple sizes). In the cases of .NET and Java, advanced systems are coming into play which will actually convert some of this intermediate-level object code to your system's native object code, improving performance. I see such systems being the wave of the future. Java's goal of "write once, run anywhere" hasn't truly been realized; usually, Java applications written for a Unix environment don't work so well on a Windows environment, and vice versa. Also, while you CAN run Java applications on a Palm (or other handheld platforms), the presentation is still sufficiently meshed with the logic that it doesn't usually work very well. Combining such a system with this universal UI would solve that problem.

This is all fine and good, but most people still don't see any reason to want to run the same apps on their desktop and handheld machines. Allow me to point out a couple more points of this system. First off, there is no rule which says that the UI elements and all of the events have to be running on the same machine; they would use a message-passing paradigm, which works rather nicely through networked connections. And, if you have events triggering other events, you have the potential to distribute the work among multiple machines. Let's say you are, in your spare time, trying to write the Great American Novel. You've got your preferred editor, and the data, loaded on your handheld. You are sitting at work, on your lunch break, and inspiration hits. You've got a full-blown desktop machine with a high-resolution screen, keyboard and mouse sitting in front of you, but your application and your data are sitting on a machine which fits in your pocket. Instead of pulling out the handheld machine and ignoring the big system, you connect the two together. Then, you pull up the GUI part of the application, along with some of the events which directly drive it, on your big machine. The data and the events which actually manipulate the data stay on the handheld. With a different stylesheet on the big machine, you can use the same application to write or edit part of your novel, without the constraints of the small screen and more limited data input methodology.

Alternately, let's say you've got a complex presentation you're putting together, with something akin to Microsoft PowerPoint. You have two displays on your machine (thanks, boss). Powerpoint generally requires you to edit in one mode, then switch to the other to see how it would look. If you can modify the stylesheet, so that the edit window is visible on one screen while the preview is visible on the other, you can better leverage the dual-headed machine, without needing to buy a new application.

Last, but not least, let's say you've got a department full of people who moderately load their machines most of the time (checking e-mail, word processing, etc.), but occasionally need some real computing horsepower (juggling a large spreadsheet once or twice a month). With traditional applications, you can either give them moderately powerful machine and let them sit there and wait once in a while (when the spreadsheet maxes out their CPU for a couple minutes at a time), or you can spend more money and buy them all more powerful machines (the machines will be lightly loaded most of the time, but making a significant contribution to productivity when it comes time to mess with the spreadsheet). With this type of distributed application, you could give the department moderately powerful machines, but install one or two powerhouses on the network, then set the spreadsheet's stylesheet to offload some of the heavier work to those networked powerhouses. Alternately, people in the department could make heavier use of smaller, tablet-type systems (with appropriate stylesheets) and move to other machines with full keyboards, mice and high-res screens when they really need it.

I'm rather fond of that last scenario. It means that you can take what you're doing and go collaborate with someone else, without them having to come to your desk to see what you're talking about. To me, this is the way things work on Star Trek; everyone runs around with one or more of the thin, hand-held PADD objects, but they all network together to share central computing resources. The specialized displays on the bridge and in main engineering provide more screen real-estate and faster connectivity, but many of the tasks could, if necessary, be performed from a humble PADD. Consequently, the ability to change the layout to handle different sized displays and different types of input systems is a necessity.

Pop quiz: what do the MacOS X, Windows XP, Linux with X-Win and Palm OS all have in common? They are all graphical user interfaces. They use the familiar system of windows, icons, text input and graphical pointers to navigate and interact with programs. Beyond that, they are very different beasts.

Yeah, I know that MacOS X has BSD running on the back-end, which is quite a bit like Linux. But, the Graphical User Interface software running on top of those systems tends to be very different. And, while libraries have been developed which will allow someone to write apps which port easily between Mac, Windows and Linux, they are still running into difficulties getting the Palm to run the same software. Quite simply, the Palm has a much smaller, lower-resolution display, and usually doesn't have a direct, text input. It typically requires tapping an on-screen keyboard or using some kind of handwriting recognition. Also, considering the much slower CPU and much smaller RAM typically found on handheld machines, getting large, bloated apps to fit into smaller, handheld machines is a challenge in and of itself. Fortunately, no one seems to have much interest in writing an application and having it run on all four of the above mentioned platforms.

Why not?

Well, most developers would tell you that handhelds are intended to serve different functions from desktop machines. And yet, they expect laptop system to function as reduced-size desktop machines. They aren't usually sure what to make of tablet systems; they have much the same resources as laptops (in terms of CPU speed, RAM and storage), but they use a pen-oriented interface like the handhelds. Maybe that's one of the reasons full-size tablet systems haven't taken off; they're too big and bulky to be used like handhelds, but too different from desktop machines.

What I propose is a system which would allow you to design the user interface once, and let it run on ANY of the above platforms. I'm envisoning some kind of XML desciption language; it would be a bit like HTML, which seems to scale reasonably well to all of the above platforms (you can web browsers for any of them), but puts a layer of abstraction between the physical input devices and the UI input types.

If you look at the constructions available in HTML, you have:

• frames/tables (useful for laying out and grouping other elements)
• text input boxes of various sizes
• one-of-many selectors (<select> and radio button tools)
• zero-or-more-of-many selectors (<select> with multiple or checkbox groups
• boolean selectors (checkboxes)
• buttons of various types and functions
• images/icons

You also have the ability for various activites to be triggered if someone enters, exits, selects, modifies or clicks various other items. Additionally, we have stylesheets; a web page designer can provide a stylesheet which indicates more precisely how a page should look, but a user has the option of providing another stylesheet which overrides it (most users don't realize this fact; I'm writing this on a page which uses small, Chancery typefaces for most of the text, because I told my browser to always use my font type/size specifications; most other users see Times Roman or Helvetica fonts and 10-16 point sizes, because that's what the web page designer specified). Anyway, the fact remains that HTML provides many of the types of UI items we need, so we'll start from there.

First off, we need a container which can hold other objects. Let's call that a frame (similar to an HTML frame or table). We need some kind of two-dimensional grid structure, which selecting two different items can indicate another item; that would be a table. We need text input areas, boolean selectors, one-of-many and many-of-many selectors (text inputs, checkboxes, radio buttons/select items and checkbox groups/select multiple items, respectively). Each of these controls needs some kind of label. And, we need events, which can be triggered by various things, and can trigger other things. From here, we have the basics in place for a complete User Interface.

Some of you may have noticed that I haven't included images or multimedia in the list. Those fall, for the most part, under the category of stylesheet objects; I'll get to that in a moment.

Now, let's say you put together a text editor application. Since we haven't built graphics into the description language, you would specify some kind of label. Then, with your stylesheet, you could say something to the effect of "if we have a bitmapped graphic display, put this image up in lieu of the label." If the person isn't using a bitmapped graphic display (say they're working from a text screen), you could provide a text-based label, instead. In this fashion, we've already covered graphical and text-based displays. This also means that, if the user doesn't particularly like the image which is provided, they can provide their own stylesheet for the application, providing their own text or graphical labels. Also, while the specification does provide a way to group elements together (within a frame), it doesn't specifically provide a way to say "put this item above this one, and this other one to the right." Again, that would be a stylesheet function. However, if the application is running on something with a smaller screen, the user's stylesheet could provide alternative layout methods. Finally, with traditional windowing applications, the designer typically puts a menu bar at the top, with nested selections which can trigger various activites. This would, again, be a stylesheet item; if someone has a lower-resolution screen, they could have the menu disappear, or they could design their own toolbar, with icons or text labels which could trigger various activities. Alternately, they could provide keyboard-based triggers for the various events they would normally access through the menu. Naturally, an application designer would want to provide a default stylesheet to be used with their application, but there would be NOTHING stopping someone from developing their own stylesheet for that application, then passing it around to others.

Basically, we're separating the logic from the presentation. The application designer deals primarily with the logic, with the presentation being extremely customizable. We're talking far more than a themeable desktop; we're talking about the user being able to completely redo the layout of the elements in an application, to better suit them. The good news to all this is that it is considerably more flexible.

Next entry, I'll address how we'll get the compiled code to run on multiple platforms.

I've been reading extensively on the subject of Fuel-Cell Vehicles (FCV's) and Battery Electric Vehicles (BEV's). I'm coming across an idea which I'm surprised no one else has stumbled onto.

In your traditional BEV, you want to accelerate (which means you need a very high power output), but batteries have a very low specific power (kW/lb). Additionally, when you kick in the regenerative braking, the motor is providing a very high power INPUT; the batteries don't particularly like that, either. To be fair, you can draw/feed power at a high rate, but the batteries tend to heat up. If the batteries are producing heat, they're using electrical energy (which you want to get out as electrical current) to do it. This is throwing away energy, robbing you of a significant share of your potential range. Consequently, your traditional BEV's tend to be kinda gutless, and leaning on the accelerator hurts your range. It also means that regenerative braking isn't as efficient as you might think.

Back when CPU's started to seriously outstrip RAM performance (I'm talking 33 MHz 386), the solution was to put a cache between the two. The cache was a small chunk of very-high-speed RAM which could keep up with the CPU. The idea was that a very small part of the actual data in the machine was used most of the time; if that very small part could be held in a small chunk of very-high-speed RAM, you'd get most of the benefits of RAM which could keep up with the CPU, without having to cough up too much money. Aside: the reality is that Static RAM could keep up with the CPU, but it is an order of magnitude more expensive than slower, Dynamic RAM. Consequently, you want a small chunk of the fast, expensive stuff, and a large chunk of cheaper, slower stuff. Anyhow, the cache needed special interface hardware and software, but it provided significant bang for the buck. While modern systems have Level 1, Level 2 and, in some cases Level 3 caches, we still use the system because it still provides significant bang for the buck.

I realize this jumps around a bit, but I'm coming to the point. To draw a parallel from the computer analogy, what we have is an electric motor (CPU) which has a very high input/output (fast data transfer), and very low-power batteries (Dynamic RAM). We need the electrical equivalent of a cache. We need a small chunk of some kind of energy storage, which can handle very high power in and out. This way, we can get the performance and braking we want, and the batteries can work the way they work best (low-power, steady output).

Such things do exist; they're called supercapacitors. They haven't been commercially available for very long (new technology), and there are relatively few companies which can supply them (two, I believe). However, like the cache on a computer, we don't need a great deal of them. Honda uses them for it's Fuel Cell Vehicle; the fuel-cell runs at a pretty steady output, while the supercaps buffer out the surges. Most reviews of its performance say it hustles nicely.

To push the analogy further, we might need multiple levels of "power cache" to make truly practical BEV's. We need short-term (L1) cache which can push the vehicle from a standing start to highway speeds AND climb the entrance ramp on the interstate. That's something which would be purged in, say, 15 seconds. Then, we need something (L2) which can provide a steady push for about five minutes (climbing a long hill). Then, we need the main power store (the main batteries). So far, supercaps look like the L1, and some of the NiCD batteries out there (which, depending on construction, can handle about 10-12C charge/discharge rates) look like good choices for L2.

A quick note on charge/discharge rates for those who don't already know. If you charge/discharge a battery so it goes from dead to full in 1 hour (or fully-charged to dead), that's a 1C rate. If you fill/kill in 30 minutes, that would be a 2C rate. Five minutes would be a 12C rate (60 / 5 minutes = 12C). Completely charging or discharging in 15 seconds would be a 240C rate. Traditional lead-acid batteries are reasonably happy with a 1C rate, but they're happier still still with a 0.1C (ten hours for charge or discharge) rate. Anything faster than 1C, however, tends to cause them to overheat.

I'm looking for BEV makers to catch onto this "multistage" approach. At the moment, most EV owners claim they're getting about 80% of the electrical energy they put in, back out. Put this into place, so the batteries don't have to deal with spikes in output when someone wants to get off the light or climb the hill, or input spikes when they hit the brakes, and the batteries can operate more efficiently. Oh, and they won't have any excuse to be gutless.

I've played more than one computer game where your vehicle has a certain top speed, but it also has a "boost" gauge, which indicates a limited timeframe when you increase your power output. Normally, you have to hit certain items to increase this; in some games, it just accumulates as time goes by. I anticipate a BEV with a "fuel gauge," indicating how much energy remains in the batteries, and a "boost gauge," indicating how much is available in the supercaps/L1 cache. It wouldn't take long for drivers to learn to read this, and use it effectively.

I've been looking long and hard at how hard/expensive it would be to make/buy an electric vehicle. I'm currently commuting about 85 miles / day to work (round-trip). Considering that my pickup ('98 Dodge Dakota) gets, at best, 20 mpg, I'm looking at NLT 4.25 gallons of gasoline to go work. That's each day. Considering the $1.70/gallon price tag, we're talking roughly $8/day for gasoline. Considering an average 23 work days/month, we talking over $170/month just for gasoline. That works out to over $2,000/year.

Ouch!

Electricity in our area is about 7.5 cents/kWh. It's due to go up in a month or two; the new price will probably be more like 8.5 cents/kWh. Even at the higher rate, if I can get 5 miles/kWh, that's about 1.7 cents/mile. That's about $33 / month, or about $400/year. We could much more easily part with that amount. Consequently, I need something which can:

• run year-round (scratch motorcyles; winters get downright NASTY in the midwest)
• keep up with traffic on the Interstate (70 mph speed limit; 75-80 mph would be a reasonable top speed; effectively eliminates any kind of Neighborhood Electric Vehicle)
• have at least a 90 mile range (in case I have to divert around a traffic jam; also eliminates NEV's)
• recharge fully in a reasonable timeframe (overnight is fine with me)

There WAS vehicle which met these criteria: the GM EV-1 (aka Impact). Unfortunately, I can't get one of those because:

• GM never sold them, only leased them
• when their leases were up, GM refused to extend them, even though the current lessees were VERY happy with them; many drivers offered to buy them outright, but GM wouldn't sell
• nearly all of them have now been scrapped; supposedly, they're going to keep a couple to put in museums

The linked page provides some interesting information on the car, as does a Google search. The car didn't have a transmission. The 3-phase AC induction motors they used (two of them) directly drove the front wheels (no tranny, and no differential). This reduced weight and mechanical complexity. Getting the motors to turn backwards (reverse) was accomplished by feeding a different signal to the motors (if it had used DC motors, they'd just switch the polarity of the power connections on the motors to make them turn backwards; AC Induction motors are very different beasts, though). Also, they didn't need gears because the motors turned solid torque from static (non-moving) all the way to 7000 RPM. While the linked page specifies .26 kWh/mile (approx 4 miles/kWh), other pages have claimed real-world performance of .16 kWh/mile (6 miles/kWh). Consequently, in a direct-drive design (like this one), with a pair of AC Induction motors, 5 miles/kWh isn't unreasonable.

The problems with most "Do-It-Yourself" electric conversions include:

• DC motors are used, rather than AC induction motors. DC motors are heavier and less efficient, but they are simpler to install and operate. AC Induction motors are more expensive because they require a more expensive controller, which converts DC from the batteries to the complex, multi-phase, variable frequency signal needed by the motors.
• the motor is typically connected to the transmission, which typically includes a significant amount of friction. The motors aren't cheap, so, rather than buying two engines and connecting them straight to the wheels, keep the tranny and buy only one motor. Many owners of converted EV's state that they really only need one or two gears, but they still have all of them, with their inherent friction. While a more efficient method might be to remove the tranny and tie straight to the differential, most conversions are front-wheel-drive vehicles, and such vehicles typically have the differential built into the tranny.
• Electrical systems for these cars are usually single-purpose. By this, I mean that the car has a system which takes power from the batteries and feeds it to the motors. While most are capable of regenerative braking, the system isn't really designed for this, so it is less efficient. Additionally, a charging circuit is typically something which sits the garage (an external box) and gets connected directly to the batteries at night. Consequently, the vehicles are limited in where they can charge.
• Lead-acid batteries are typically used. These are cheap, but only store about 25 Wh/kg. This means 88 pounds of batteries for 1 kWh of electricity. If you need 20 kWh, that's 1760 pounds of batteries. As you may imagine, adding that much weight to a vehicle makes a dent in the efficiency.
• between the weight and the relatively low power output, such cars tend to be gutless wonders

If there is some good news, it is:

• companies like Metric Mind are starting to appear, which carry AC Induction motors and controllers. These are more efficient than the older DC hardware.
• newer batteries are becoming available, such as Nickel-Zinc batteries. At 60 Wh/kg, that's about 35 pounds of batteries for 1kWh, or 700 pounds for 20 kWh. If you really want to sink some money, you can buy Lithium-Ion batteries, like these guys. They put about 50 kWh of storage in a vehicle, giving it a 250+ mile range. Additionally, they have the DC-AC conversion hardware (for powering the car) AND the AC-DC conversion hardware (for changing the batteries) built-in, with many components doing double-duty. These guys are definitely on the right track. Since one of their founders was an engineer on GM's EV-1, I guess that's no surprise.

The fact remains, however, that there still isn't an answer in sight. Not, at least, for me. There are no commercially available vehicles with the performance and range I need. I was hoping that I might be able to find an electric motorcycle, which would reduce my commute cost at least PART of the time. No dice. Google searches on "electric motorcycle" refer you to a few pages about people who've done their own conversions, or a limited number of professionally engineered experiments which aren't commercially available.

One other item of good news is found in this article. It mentions a college professor at UC-Davis who has been developing hybrid vehicles, and is currently working on something he calls a "heavy" hybrid. Basically, it's a combo between an electric vehicle and a hybrid. By this, I mean that you can plug it in, charge it up, run about 60 miles on electricity, but still kick on an ICE with generator for those occasions when you're going to be going beyond the battery range. It's also referred to, in other articles, as a "plug-in hybrid" or a "grid-connected hybrid." In my eyes, it's one of the most intriguing technologies I've seen in years. According to the article, more than 80% of commuters drive less than 60 miles at a time. Consequently, with one of his vehicles, you could plug in, charge overnight, and commute to work and back on electricity (no gasoline involved). And yet, if you want to do a major road trip, you don't have to worry about finding charging stations for your vehicle. Just "fill 'er up," and get on with it (with better MPG than most vehicles on the road). Additionally, if the power fails at your house, your vehicle could function as an emergency generator for your household.

Hey, Detroit. Can we get some of these? Please?

There is considerable talk these days about the coming "hydrogen economy." A considerable share of the discussion is about the "chicken and egg" problem associated with it: how do you get people to purchase hydrogen-powered vehicles when there is little or no refueling infrastructure, and how do you motivate companies to develop the infrastructure when there are few, if any, vehicles which can use it? I'd like to address this by looking at some other "chicken and egg" problems in the technology sector, and how they were overcome.

First off: how do you get users who are quite comfortable using MS-DOS-based applications to switch to a new OS, or at least a new user interface? In short, how do you get people to switch to Windows? The initial answer was to build a version of Windows which ran on top of MS-DOS. This way, if Windows was unreliable, or at least unfamiliar, the users could still return to a DOS environment. Additionally, make sure that DOS applications could run within Windows. Once people started using the Windows user interface, and started to enjoy the benefits of it (graphics and peripheral drivers being provided by Windows, instead of each app needing to provide its own drivers), they eventually upgraded from DOS-based apps to Windows-based apps. A few revisions later, make Windows the primary environment, instead of a "bolt-on" for DOS (Windows 95). Finally, after people have had time to switch, kill off most of the DOS compatibility (Windows NT/2000). At this date, there are very few DOS apps still in active development, and most newer versions of Windows can't run them at all. In the intervening years, however, you could use both until you were comfortable with the new environment.

Another example: the MacIntosh. The original machines were based on the Motorola 68000 and its progeny. Later on, however, it was decided to abandon that architecture and move to the PowerPC architecture. Since the two were NOT instruction set compatible, this was a major shift. The solution was to write the BIOS of the newer machines to emulate the older instruction set. Consequently, the older software would run on the newer machines, albeit less efficiently. As time progressed, the OS became a mix of 68k instructions and PowerPC instructions, while a "pure 68k" version was still available. Eventually, though, the OS and the applications became "pure PowerPC." The latest versions of the MacOS will NOT run on original hardware (I believe 8.x was the last version which provided any backward compatibility to the 68k architecture; any Mac gurus out there feel free to correct me). In the interim, however, you could still run current software on your older hardware, and your older applications would still run on the newer hardware.

The lesson to be learned is this: to avoid being completely shut down by the "chicken and the egg," you need to provide a period of backward compatibility. For the hydrogen economy, you need a timeframe where vehicles can use both gasoline AND hydrogen. Most proponents of hydrogen are advocating the use of fuel cells instead of Internal Combustion Engines (ICE's). The logic is that fuel cells are more efficient, therefore we should do away with internal combustion. I tend to agree with them, but not just yet. Most fuel cells still cost about $10 / watt of output. Consequently, if you need a steady output of 24 horsepower (enough to maintain highway speeds for a small or mid-sized, aerodynamically designed vehicle), that's about 18 kilowatts. That's about $180,000, just for the fuel cell. With a price tag like that, these vehicles WILL NOT be a sales success anytime in the near future. The fact remains, however, that ICE's WILL run on hydrogen gas. They are less efficient, certainly, but they will work, with some modification. This much was proven in the early 1970's (during the "energy crisis"). Consequently, the period of backward compatibility for hydrogen has, potentially, already begun. Unfortunately, few people are clued in.

We can wait another decade or two for the major automotive manufacturers to get off their collective duff, spend a fortune in R&D, and develop an affordable fuel cell. Or, we can spend about a couple thousand dollars to convert an existing vehicle to a "bi-fuel" configuration. This typically involves adding gaseous storage for the hydrogen, finding some way to add it to the intake air (a carbeurator of some kind; it's hard to "inject" a gas), and dealing with the backfiring which typically accompanies hydrogen use (hydrogen is much more volatile than gasoline; Roger Billings found that injecting water into the intake stream fixed the problem, and improved the engine's efficiency by about 20%). From that point on, you might have to hit a switch to convert from one fuel to the other, or a more automated system could simply use hydrogen when it is available, then "phase in" the gasoline as the hydrogen supply ran out. If modern, heavily computerized automobiles could be upgraded with this capability, the transition could be completely transparent to the driver.

Yes, internal combustion engines are less efficient than fuel cells. However, if the automobile is a hybrid of some kind, that improves the efficiency of the vehicle. The Honda Insight is routinely quoted at 65 mpg in efficiency. A kilogram of hydrogen has about the same amount of energy as a gallon of gasoline, so it is reasonable to assume that a hydrogen-converted Honda Insight would get about 65 miles / kilo. Most fuel cell vehicles get 50 miles per kilo (or less), and cost at least 10x as much (I believe $250,000 is quoted as the "production cost" of the Honda FCX). And yet, most pundits claim that running ICE's on hydrogen are a "non-starter," because the fuel cell is so much more efficient. These pundits are full of it. I mean, even a Toyota Prius (54 mpg) would get more than 50 miles / kilo, and the conversion would still be much cheaper than the fuel cell vehicles which Honda and Toyota are currently leasing to various organizations (usually government organizations; if you can influence the policymakers, they might allocate more funds to study the idea).

The market is ripe for one or more companies to develop hydrogen conversion kits for existing ICE-based automobiles. Such conversions exist for natural gas, but I know of none (yet) for hydrogen. The converted vehicles could use hydrogen when it is available, use gasoline when it is isn't, and still be maintained by the existing infrastructure. Some individuals aren't waiting for that to happen, and are doing their own conversions. These are often kludges, based more on trial and error than sound engineering. I'm not sure that I'd want to buy such a vehicle, and I'd be very surprised if insurance companies are willing to cover them.

If this idea flies, it becomes a matter of hydrogen production and hydrogen storage. The demand for hydrogen fueling facilities will rise, effectively solving the problem. Later on, when the fuel cell technology matures, we may be able to add fuel cell "Auxiliary Power Units" to existing vehicles, to provide electrical power for accessories (and for hybrid drive systems), improving the overall efficiency of existing designs. Then, maybe two decades from now, the infrastructure would be in place, motivated by existing hydrogen use, for pure fuel cell vehicles to be practical.