Lately, I've come to the conclusion that I'd like a wristwatch with a slide rule bezel. I've spent plenty of time playing with slide rules so I'm pretty proficient with their use. Having one on my wrist would be nice.

I've spent time, at various department stores and jewelry stores, explaining to sales clerks what they're good for. Travelling in a foreign land? With a foreign currency? Set the slide rule to the currency exchange value and quickly convert prices between currencies. Simply find the "local" price on one scale and see the other price on the other scale. Are they using metric? And you'd like quantities, distances, etc. in imperial units? Or vice versa? Set the slide rule for the appropriate conversion factor and you're good. If you know what you're doing, you can even do more complicated conversions, like Chilean Pesos / liter to US Dollars / gallon. Or Norwegian Kroner / kilogram to US Dollars / pound. I have done these, and many more, at various points in my life.

There are a few problems with most slide-rule-bezel watches:

• Most of them put 60 at the 12 o'clock position. That's useful for doing time calculations. I don't anticipate doing that very often. I'd like the 10 at the 12 o'clock position. That way, I can use the minutes on the watch face to calculate logarithms (anyone who's used the L scale on a slide rule, in conjunction with the D scale, knows how to do this). And I don't want any other values cluttering up the space between the minutes and the inner scale. For me, at least, that just gets in the way. I've managed to find one Casio watch where the inner scale moves, so I can line that scale up with 10 = 12 o'clock. For most watches, the outer scale moves and the inner scale is fixed, with 60 = 12 o'clock.
• With all too many of them, the numbers on the scales are just too small for my aging eyes. I'm looking at you Casio and Seiko.
• The slide rule bezel is more of a marketing gimmick, so they don't put much effort into being accurate. As an example, line up the 10 in the inner scale with the 10 on the outer scale. Do the numbers line up, all the way around the dial? For some of the lower-priced watches, the answer is "no, they do not." Now, line up the 10 on the inner scale with the 30 on the outer scale. Do the multiples line up? On all too many, the answer is, again, "no, they do not." Which means any calculations you attempt will be inaccurate.

Here's my wishlist, in order of decreasing priority:

1. Accuracy. Must pass both of the aforementioned tests. Otherwise, it's just "marketing" (translation: lying, bait-and-switch, etc.).
2. Numbers on the scales are large enough and high-enough contrast that I can see them without needing a magnifying glass.
3. Either the inner scale has 10 = 12 o'clock OR the inner scale moves so I can set it that way. If you absolutely must put time-conversion numbers on one of the scales, put it on the outer one, preferably outside of the slide rule scale. I want the slide rule scales as close together as possible to limit errors caused by parallax.
4. No excessive ornamentation getting in the way of the minutes tic marks. I want to be able to see them very clearly so I can calculate logarithms.
5. A complication (secondary, inner dial) showing time in an alternate time zone (UTC), preferably on a 24-hour scale.
6. Solar powered, so I never need to change the battery.
7. Ability to read the time in the dark

Anyone know of a watch which fits the bill? Citizen makes some which fit most of these, but not #3. Casio makes one which fits #3, but fails on #2 (possibly #1 as well).

Coding by voice

Do you really need to use a keyboard to do programming?

If you're using a smartphone or a tablet, which has an accelerometer, you could tilt the device to navigate around in your program.

Many years ago, some researchers at IBM came up with a design for an on-screen keyboard. They analyzed the QWERTY keyboard, the FITALY keyboard and a couple others, determining how fast someone could type on them. QWERTY scored lower than any other, around 30 wpm. Their keyboard scored > 40 wpm.

Details can be found here

They get into a long analysis of Fitts Law, which explains how long it will take to move from one character to another. It's logarithmically related the ratio of how far it is from one key to another to how big the destination key is. Based on this, they come up with a hexagonal pattern to make their keyboard more "dense" and arrange the characters such that the most commonly used transitions (digraphs/trigraphs) are as close together as possible.

They're assuming every key on their keyboard will have a unique symbol on it. That might work for something like a tablet, but it stinks on a modern smartphone. I can't use a traditional keyboard on mine. My fingers are too fat. I find myself getting a pretty good input speed with a compact- or T9-formatted keyboard. Larger buttons are easier to hit/more forgiving; more forgiving = faster, assuming that the text prediction software is any good.

Let's take another look at Fitts Law, again. The shorter the distance from one key to another, the faster you get there. No surprise, there. But it's inversely proportional to the size of the key. Bigger keys mean faster response.

What happens if you put two characters/symbols on each key? Can you just take their keyboard and squash 2 adjacent symbols onto the same key and depend on text prediction to make up the difference?

Their original design for the keyboard was nearly circular. After all, the shape with the shortest distances from random-point-a to random-point-b is going to be a circle. Joining multiple symbols into a single key is going to be problematic. Maybe joining 3 at a time would get the job done.

They also designed it with a single "space" button in the middle. This is because, within most text corpi, the space is the single-most-used symbol in the bunch. After all, it's used as the separator between each word, and some of those words (such as "I" and "a") are single letters. I'm thinking that rates either an oversized "space" area (as with the oversized space bar on hardware keyboards and the oversized "space" on most on-screen keyboards) or multiple "space" areas (as with the OPTI and FITALY keyboards).

I think it's time to re-do the analysis done in that paper, with an eye toward putting 2-3 symbols on each key. If you have a cluster of letters which are on the low-end of the frequency distribution, it might make sense to put them on the same key. Letters on the high-end of the frequency distribution might rate their own key. The whole idea is to get the number of keys down, so the individual sizes can be larger.

My biggest worry is that you'd end up with multiple of the vowels on a single key and the text prediction software would have a very difficult time figuring out which word you're attempting to input. I have no idea how to design the layout to make the text prediction more efficient. I know that it tends to be more efficient with a compact keyboard than with a T9 keyboard, because compact has fewer symbols / key.

Anybody have any ideas how to approach this?

A while back, I was looking at a forum where someone asked if you'd use a tablet to do computer programming. Most of the responses were centered around "typing is slow/awkward on a tablet."

I agree. Typing is awkward. But, who says programming has to equal lots of typing? Yes, it does, currently. But does it have to?

I took a compilers course a few years ago. One of the things which I learned in that course was that a compiler does multiple steps, largely in series, where each one feeds into the next, with the object code being the final result.

The first step: going through the code, recognizing various kinds of constants, keywords and potential identifiers (variable names, class names, function/method names). Once it has a sequence of these, the next thing is to create something known as an Abstract Syntax Tree. For example:

a = b + c * d

Would be turned into a tree of nodes, containing operations, variable or constants. At the top, is an equals sign (assignment). "a" is on the left and "+" is on the right. The "+" also has nodes extending below it, "b" on the left and "*" on the right. The "*" also has nodes extending below it, "c" on the left and "d" on the right.

The next thing which usually happens is to "decorate" the tree. If "a" is a double and "b", "c" and "d" are all integers, we need to mark the "*" and the "+" as integer math, but we need to do some kind of implicit casting before the assignment. Usually, you "decorate" the various variables according to what type they are, then deal with the operations, then figure out where one type needs to be cast to another.

An interpreter or a compiler will start at the lowest point on the tree and work its way up. So, the aformentioned code becomes integer:c * integer:d, with the result being added to integer:b, with the result being cast to a double the assigned to double:a.

Most programs have more than one expression. Quite frequently, if you calculate "a" in one expression, then use "a" in the next expression, you could rewrite the two expressions as one. Shorter expressions, though, tend to be easier for a human to read, which is why only sadists and functional programmers (like me) tend to bother with creating really long expressions.

It doesn't really matter what source language you're starting with; whether you're using Java, C++, RPG, Cobol, Perl, PHP, Ruby or Javascript, the starting point is ALWAYS to turn it into a tree.

So, if the code you're writing is going to be turned into a tree, why can't you just create a tree? Such things tend to be awkward when you're using an interface dependent on a mouse and a keyboard, but they're much more natural in a touch-screen environment (tablet).

Something else I learned from that compilers course. Do you know what you get if you create a serialized version of the Abstract Syntax Tree, using prefix notation (such as "+ a b") instead of infix notation (such as "a + b") and put each simple expression inside a set of parentheses?

Lisp.

Indeed, the reason Lisp has such power over certain groups of programmers is that you're almost explicitly creating an Abstract Syntax Tree, in text. And it provides the means, not only for the programmer to create an AST, but also to programmatically create and manipulate ASTs. In other words, you can write code whch writes/modifies code. And you aren't doing anything as clumsy as putting together a string and running

eval(stringVariableContainingProgramCode);

You're starting one or two levels down the chain from there, with the initial parsing steps already done.

As such, the first step toward creating a touch-screen code development environment would be to create something which lets you drag various Lisp commands from a palette of commands, drop them onto the tree, and then execute the whole thing. From there, the next question becomes: do you want output in Lisp, or can we run some kind of code generator on this tree to create output in some other, more commonly used language?

Note: anything which can be done from XML or XSL can be done from Lisp. If we can drag-and-drop components into a Lisp program, we can also drag-and-drop components into XML and any of its derived forms (such as HTML, XHTML, HTML5, etc.).

So, would you use a tablet for writing code?

Another idea.

I was watching "Waterworld" the other night. I'm rather enamored with the Mariner's trimaran (boat). I like the vertical axis wind turbine (VAWT) on the mast. But, just how would you do that?

Here's my thought.

You make something like a cross between a Darrieus turbine and a Gorlov Helical Turbine. In short, one of those twisted, multi-blade, egg-beater-looking turbines. Mount it with the central axis on the mast.

O.k. That leaves you with no way to put sails up. The blades will sweep into the area occupied by the main sail and any jib you may have.

Unless, of course, you build the blades of flexible material. Make the upper hub able to lower down the mast, bowing the blades outward into the wind, or rise up the mast, pulling the blades in flat, against the mast. This would give you a way to completely stow the blades, for those times when you want to use sails. It would also give you a way take the turbine out of the wind in gusty conditions, when the sudden gusts could overstress the mast or capsize the boat.

O.k. So, why would you WANT one of these on your boat? Well, if the bottom hub has a generator in it, it would provide a significant amount electricity when your sails are stowed and you are sitting at anchor/in port, etc. That would be a considerable amount MORE electricity than you'd get with a traditional wind turbine, mounted elsewhere on the hull.

I can imagine a boat with a couple "auxiliary/maneouvering screws" powered by electricity, with some batteries. Charge up the batteries while you're sitting at anchor, and use stored electricity to move in/out of port.

Depending on the efficiency of the whole system, and the swept area of the turbine, you might even be able to run the turbine and have it feed power to the screws for regular propulsion, if you are going to be changing course frequently and don't want to fight with the sails.

I'd be interested in hearing the thoughts of others, on this idea.

I had an idea, this last week.

We went on vacation, recently. While in Seattle, WA and Vancouver, BC, we saw plenty of electric busses. They have long poles on the back which hold up electric contacts, which connect with overhead catenaries (conductive, electrical wires) to provide current. Plenty of people complain about what an eyesore those cables are. Additionally, since the busses can only go where the wires go, the routes are kinda limited. It's a bit like a cross between electrically-driven light rail and traditional bus service. The electric busses can only go where the catenaries go, but they don't have the added expense of building rails.

So, what if you could make a bus which only occasionally needed connectivity to recharge?

The bus drives around on normal city streets. Occasionally, it pulls into a bus stop and, while passengers are loading and unloading, it puts a contact up or down, connects with electrical power and rapidly recharges. I could see two ways to do this:

1. the bus has a pantograph on the roof, which extends up to an overhead catenary, which is only found at select bus stops
2. the bus puts a "foot" down onto the ground, which sits on top of a inductive charging device (like the "paddles" used on the EV-1, only much larger); this transfers a significant amount of current, even when wet, without the possibility of electrocution, so it can be built into the road

There would be a limited number of charging points, so there would still be some limitations on routes, but not nearly as much as a bus which needed a constant electrical supply. Minimal eyesores, as well. The latter could be built into the road, keeping the overheard area completely clear.

Various companies are working with ways to make high-charge-rate (and high-discharge-rate) batteries, and there are always supercapacitors, but I'm thinking of running a pump to build up hydraulic pressure, then run the bus as a hydraulic hybrid. If you could get enough hydraulic capacity to cover 5 miles of level ground, you could hit quite a few stops without needing much more infrastructure than a traditional, diesel-powered bus. And yet, you wouldn't have the pollution of the diesel-powered bus. Instead of waiting on new technologies which are still under development or under limited production (the aforementioned batteries and supercaps), hydraulic hybrid systems tend to use off-the-shelf parts.

This idea could be extended further to light-rail systems. Since steel wheels on steel rails have less rolling resistance than rubber tires on pavement, a given amount of hydraulic storage would go further in a light-rail system. Also, since the vehicles tend to be larger, they would (presumably) have more room for hydraulic storage.

For either bus or light-rail, the pantograph would seem to be the better idea. If you want either vehicle to be able to recharge without stopping, you could put in a short distance of electric catenary (say 1/4 mile) and the vehicle could contact it while in motion. You don't have to be stopped to use that system, unlike the inductive charger.

Imagine a hydraulic hybrid bus, without an actual engine on board. It would have an electrically-powered pump, but the electricity would come from outside sources.

I'd like to see that happen.

Most of the hybrid vehicles in the world (and all of them for commercial sale, at this point) are electric hybrids. By that, I mean that propulsion comes from electricity and something else (typically an internal combustion engine). There, are, however, other hybrid technologies out there, some of which are starting to get more attention.

Some years ago, Ford was playing with an "air hybrid." The idea was that they had a large air tank somewhere in the car, and the engine had electrically actuated valves which could take in air from the intake or from the air tank, and output exhaust to the exhaust manifold or to the air tank. Basically, if you wanted to slow down, turn off the fuel and ignition and use the engine as a big, two-stroke air pump (air comes in thorugh the intake and is compressed into the air tank). When you are ready to pull off the light or climb a hill, use the engine as a two-stroke air motor (pressurized air from the air tank is fed to the intake on the engine, pushing the cylinders down, then simply ejected through the exhaust manifold; no fuel or ignition). Yet, when you run out of air pressure or you want to cruise, use the normal four-stroke system with the normal intake, exhaust, fuel and ignition. In this fashion, they were able to leverage a large number of existing components; the only real addition was the extra connectivity with the air tank and the electrically actuated valves which let you un in the engine in a two-stroke air pump or air motor mode, or four-stroke conventional mode.

I've read about it, but I'm having a hard time finding any current links on the subject. If you find any, feel free to bring them to my attention.

This recently got some more attention, when a Korean company suggested a car with batteries and an electric motor providing the main cruise power, and compressed air providing a hybrid mode for starting/stopping. Batteries don't handle large surges in input or output very well, so let the compressed air system handle that, and let the batteries do what they do best (slow, steady power).

Another type of hybrid technology is a hydraulic hybrid. This one requires adding some components to the drivetrain (a hydraulic pump/motor), some storage (called accumulators), and a variety of valves, lines and a controller.

What's an accumulator? Think of a long hollow cylinder with a piston in it. One end has hydraulic fittings and lines on it, and the other end has some kind of compressed gas fitting on it (nitrogen gas is popular). If you have no hydraulic pressure one one side, and about 1,000 psi gas pressure on the other side, that will push the piston all the way down by the hydraulic fittings. That's considered "pre-charged." Now, put some hydraulic fluid, under pressure, through their fittings. This will push the piston away from the hydraulic side, compressing the gas to even higher levels. The aircraft I've worked with usually had about a 1,500 psi pre-charge, and the hydraulic system usually ran about 3,000 psi. With full pressure on the system, that would push the piston about 1/2 way down toward the gas fitting, compressing the gas to the same 3,000 psi as the hydraulics. If you then closed the hydraulic valve, you could store energy in this fashion for days at a time. We used them extensively in the F-16. Consequently, it's relatively lightweight (you don't want to put a lot of heavy stuff in an aircraft), it's reliable (I never replaced a single one in four years as a jet mechanic, nor am I aware of anyone else who had to), and it can store a significant amount of energy (ever tried turning over a jet turbine? The F-16 uses stored hydraulic pressure to start a small jet engine, which then starts the main engine).

As with electric hybrids, there are both series and parallel varieties. The parallel variety is sometimes known as a "hydraulic launch assist." The basic idea is that, when you are braking, the valves are set so that hydraulic fluid is being pumped into the accumulators. This provides mechanical resistance, which slows you down, and stores the energy. When you're ready to get off the light or climb a hill, pressure from the accumulators can turn the hydraulic pump (which is now functioning as a hydraulic motor) and provide power for this. Normally, the systems envisoned cut out at around 30 miles/hour, but that's enough to damp out most stop-and-go traffic.

The series variety has a motor turning a hydraulic pump, some accumulators, and a hydraulic pump/motor turning the drive shaft. Such a vehicle typically doesn't need a transmission, which is a nice feature. I've found less coverage on this type of system.

Early in my Air Force days, I was talking to a friend about making a vehicle with four-wheel independent power, and no drive shafts or axle shafts. Put a hydraulic motor in each wheel hub and tie a hydraulic pump to the engine. I wasn't too worried (at that point) about regen braking, and I didn't understand accumulators well enough to think about adding regen braking to the system. My friend (Carl) liked the idea; he had a late '60's Mustang he was putting together, and it sounded like a cool idea. I talked to some more experienced mechanics, though, and they said that, while the idea was reasonably sound, the fly in the ointment would be the hydrodynamics. Getting the pressure to each of the wheels wouldn't be too difficult (hydrostatics), but I'd need a certain number of gallons-per-minute to maintain power at highway speeds, and that would be difficult. I'd need some really fat, heavy-duty tubing to carry it, very careful attention to bends in those lines (sharp bends tend to cause severe resistance to fluid flow), etc., all of which would be heavy and would generate a lot of heat (more gpm = more heat), which would seriously impact the performance and efficiency. They knew more about the subject than I did, and the obstacles sounded pretty overwhelming, so I dropped the idea (it took some SERIOUS explanation before Carl finally gave up on the idea, as well). If engineers are actually working on highway-capable hydraulic series hybrids, someone must have found ways around these issues.

In the meantime, I've seen and heard about a few other hydraulic-driven vehicles. Something they were fond of showing us in the Air Force was a film titled The Business of Paradigms. At one point, the narrator asked us what we would think of a small vehicle which got over 100 mpg. Most people can't even picture that. Then, we got to see the vehicle. It was a three-wheeler (a trike) which had a small motorcycle engine, turning a hydraulic pump, which fed to some hydraulic accumulators and a hydraulic motor which turned the rear wheels. The motor always ran at its most efficient setting, and the throttle would control fluid flow to the wheels. It also offered regen braking. While it only carried one person, and it couldn't do interstate speeds, it did exactly what the narrator described. I would characterize it as a hydraulic series hybrid.

Ever seen a skid-steer loader? They're better known as "Bobcats," even though Bobcat is only one of the companies which now manufactures them. The engine turns a hydraulic pump, the wheels are turned by hydraulic motors, and the pedals and levers simply control valves feeding fluid flow to the wheel motors and the forklift/loader mechanism. I wouldn't want to try driving one on the highway, though.

Also, while I was in the Air Force, I was acquainted with a machine known as a "jammer." Like a Bobcat, it had a small engine, which turned a hydraulic pump, which could operate a hydraulic lift or turn the wheels. Jammers were usually operated by "load toads," who used them to lift bombs (anywhere from 500 to 2000 pounds each) up and attach them to the bomb racks on the planes. Once again, a hydraulic series hybrid. I don't know if they had accumulators in them, though; I distinctly remember hearing the pitch of the engine change as they lifted objects or accelerated forward or in reverse.

I'm starting to wonder about the possibilities of some of these other technologies. Some of the newer hydraulic systems can handle over 5,000 psi, which makes them very power-dense. Also, pneumatic (air) systems are getting up to the 5,000 psi range, in no small part because people are looking for systems which can store significant amounts of hydrogen gas or natural gas (5,000 psi puts more energy in a cubic foot than 3,000 psi). The air-electric hybrid, in particular, is starting to sound VERY interesting. Too bad I never learned to read Korean (I spent a year in South Korea, but never learned the language).

I had a complete mindstorm the other night: a combination voltaic cell and multi-layer supercapacitor, integrated into one, physical unit.

Didn't get that? Some background is probably in order.

I'm thinking about lead-acid batteries. These are usually made of lead electrodes, sitting in some kind of acid-based electrolyte. If you want a starting battery (which needs to dump a great deal of current for a short period of time), you usually use electrodes which have a sponge texture (sponges have tremendous surface area, packed into a small volume). The problem is that, if you discharge most of the current, the lead starts to dissolve into the acid solution. When you recharge the battery, the lead tends to precipitate out of the solution, bonding to the lead electrodes, and fill in the pores in the spongey electrodes. This reduces the surface area, which reduces the amount of current the battery can release. Consequently, a few deep cycles will basically kill a starting battery. Letting them sit, discharged, for a while, will further dissolve the electrodes, sometimes beyond the point which charging can recover them. The result is lead from the electrodes bonding chemically with the sulfur in the sulfuric acid electrolyte, making a lead sufate "mud" which sits in the bottom of the battery. There is no known way to recover a "sulfided battery;" replace it, or drain the electrolyte (and the "mud") and put new electrolyte in it.

Electric Vehicles are usually made with deep-cycle batteries. These batteries still use lead electrodes and acid-based electrolyte, but they use flat plates. If you deep discharge them, the leads starts to dissolve into the electrolyte, but recharging them just puts layers of lead back on the flat plates. This doesn't reduce the surface area (how do you reduce the surface area of a flat plate?) so the batteries keep their capacity for much longer (about 500 cycles to 80% depth of discharge is typical). The newest versions of these batteries don't have the plates sitting in liquid; the electrolyte is either gelled or absorbed into some kind of fiberglass mat (Advanced Glass Mat or AGM batteries). Since their flat-plate electrodes have a lower surface area than the sponge electrodes in starting batteries, they can't provide as much current.

The latest trend is called a spiral cell. Use a long, thin sheet of lead, cover it with a thin glass mat (with the electrolyte absorbed into it), then another lead sheet (the other electrode; always two, there are, a positive and a negative), then a thin layer of some kind of insulator. Then, roll the whole thing up like a jelly roll. The result is something with a very large surface area (able to dump high current), but still able to handle multiple deep-discharge cycles.

Spiral cells are fairly new; I don't of any EV's (yet) which use them.

Batteries still aren't able to comfortably handle very high discharge rates, though. For dumping significant power for, say getting off a stop light or climbing a hill, or for absorbing lots of power from regenerative braking, you need supercapacitors (sometimes known as a supercaps).

I mention supercaps in other journal entries; suffice it to say they don't store as much energy as batteries, but they can very quickly dump what they do store. Consequently, you couldn't do an entire EV with just supercaps, but a few of them added to the system would allow the vehicle to accelerate quickly (high power) for a few seconds, then settle into a more moderate cruising speed. If you think about it, that's what most passenger vehicles need to do. Unfortunately, I don't know of any controllers which can handle both batteries and supercaps. Consequently, building an EV which uses them is still way out in the experimental range.

Supercapacitors are usually made by taking a thin, aluminum plate, covering it with some kind of very porous solid electrolyte (activated carbon is popular), another thin plate (like a battery, a capacitor needs two electrodes), then covering it with some kind of insulator and rolling the whole thing up like a jelly roll.

One good jelly roll deserves another, don't you think?

So here's the idea. Lay down the first electrode, electrolyte and second electrode for a supercap (we'll call this the "layer one supercap"), then some kind of resistive material (not a full insulator; an insulator has extremely high resistance, effectively preventing any energy transfer through it; we WANT energy transfer through this layer, just not too quickly), then lay down all three layers for a second supercapacitor (call it the "layer two supercap"), then another resistance layer, then the three layers for the battery, THEN we lay down an insulator. Now, roll up this entire mess into one cell.

Tie the layer-one supercap to the terminals on the battery.

If you put energy into layer one, it will build up the voltage in that layer. When the layer one voltage goes higher than the voltage in layer two, energy will move through the resistance layer until they equalize. The same is true for layer two and the battery layer.

If the whole thing is charged up, then left sitting, you'll end up with the battery layer being charged, and both of the supercap layers being charged to the same voltage. When you draw current from the cell, layer one will discharge first. As its voltage drops, layer two will feed energy to layer one (but not too quickly). As layer two's voltage drops (slower than layer one), the battery layer will feed layer two (even slower), which will feed layer one. The result is a three-stage punch: very high power for a few seconds, fading into high power for a few seconds more, fading into moderate power from then on. The supercap layers will discharge first, then the battery.

If you feed energy back in from regenerative braking, layer one will charge first. When its voltage goes above layer two, energy will flow from layer one into layer two (not too quickly, though). When layer two's voltage goes above the battery layer, energy will flow from layer two to the battery (again, not too quickly). Consequently, the supercap layers will charge first, the battery last.

Either way, the two layers of supercap will buffer all the major surges in and out, so the battery gets relatively low current flow in either direction.

The resulting battery would have less total capacity than a regular battery of the same weight (supercaps pack less storage per pound than batteries, and this battery is part supercap), but it would be able to handle larger power surges (in either direction) better than a starting battery and be able to handle at least as many deep discharges as a deep-cycle battery. And, since the battery handles all of this internally, you wouldn't need a fancy, new controller and separate supercaps.

You would, however, need direct taps into the layer two supercap and battery layers, if only so you could accurately gauge the state of charge in each layer. I mean, a traditional EV uses a voltmeter as a kind of "fuel gauge," because batteries tend to lose voltage (slowly) as they discharge. Such a meter, tied to the main terminals (and therefore, the layer one supercap), would be swinging around all over the place. A voltmeter tied directly to the battery layer (low current; we want just enough flow to determine how much is there, so we're talking a tiny fraction of an amp) would provide a fairly accurate "fuel gauge" reading, while a volt tied to all the supercaps would provide a kind of "boost gauge," indicating how long you can hold the pedal down before the car turns into a gutless wonder.

An improvement on this idea would be to put a Zener diode between the layer two supercap and the battery. A diode generally allows electric current to flow in only one direction. More accurately, it provides very low resistance to current flow in one direction (called the "forward bias"), but very high resistance to current flow in the other direction (called the "reverse bias"). A Zener diode is slightly different; it provides very low resistance on the forward bias, and high resistance on the reverse bias (like a regular diode), until the voltage goes above a certain level. Then, it allows reverse bias current flow with very low resistance. If you put a Zener diode between the layer two supercap and the battery layer, and set it so that it wouldn't allow current back into the battery layer until, say, the supercap layer went above 2.35 volts, about the ONLY time the battery layer would get current inbound would be when we eat a SERIOUS amount of inbound current from the regen braking (riding the brakes down the side of a mountain, for example), or when we actually want to charge the battery (most battery chargers put a lead-acid battery at about 14.25 volts for charging; since there are six cells in a 12-volt battery, 2.35 volts x 6 = 14.1 volts, so the 14.25 from a charger would get past the diode and charge the battery layer). The rest of the time, the supercaps would eat ALL of the inbound current. This would be a good thing, since you don't typically want to partially discharge, then partially charge, then partially discharge batteries.

In the absence of such batteries, though, you could probably build a "power module" from an existing battery, some supercaps and resistors or Zener diodes, then tie that into the system in place of the battery. That would probably be a good starting point.

And yes, this idea could be applied to other battery technologies, so long as the battery involves a spiral wrap of some kind. The Zener diode would be extremely helpful if you wanted to a combo supercap/NiCad battery, since NiCad batteries are well known for having a "memory effect," meaning that partial charging and discharging will prevent the battery from fully charging.

Well, gasoline has broken $2/gallon around here, and I'm still no closer to owning an EV.

I've almost given up on converting an existing vehicle to electric. Existing vehicles are heavy (typically upwards of 3,000 pounds), which will require a pretty powerful motor ($$$), more batteries ($$$), more supercaps ($$$), etc. What's needed is something smaller, lighter, which gets by on significantly less power.

I've been looking at stuff by R.Q. Riley, specifically the TriMuter. If they can do interstate speeds in this thing with a 16 hp Briggs and Stratton, it probably won't take much electrical power to get this thing up and moving. It's smaller, lighter, etc., which reduces the required power, required batteries, etc. It would cost about $3k to build one, which is the rough part. I mean, I can get a pretty decent used car for the 3 grand.

On the battery front, Lithium Ion prices continue to fall in price. I figure I can build a 20 kWh pack (good for a 100-mile range) for about $7K. That's down from $20K about a year ago, which is a big improvement. If I'm willing to go with lead-acid batteries, Exide has recently started building spiral-wound Valve-Regulated Lead-Acid (VRLA) Absorbed Glass Mat (AGM) batteries. One particular model, the 31XCD, has specs WAY above any other lead-acid battery I've ever seen. At 12 volts and 115 Ah, that's 1.38 kWh for one battery. At only 54 pounds, that's over 56 Wh/kg. Note: most of their batteries in this class are in the 30-35 Wh/kg range. 25-35 Wh/kg is normal for lead-acid batteries. If the specs on this thing are accurate, a 20 kWh battery pack would weight only 972 pounds (that's 18 batteries, which will give nearly 20 kWh at 80% Depth of Discharge). Most EV's have over 1,500 pounds of batteries (if they use lead-acid), so this is a major jump. I'm HOPING the specs are accurate, but they almost seem too good to believe. Since they're asking about $150 per battery, that would be <$3K for the battery pack.

That would put the whole idea a lot closer to "possible," even if it isn't too probable.

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.