Recently, I've been alternating between working on the Rascal and various renewable energy engineering projects with Matt Dorson at Mystic River Engineering. In April, the first batch of Rascal beta units arrived from an assembler in China; I've sold 4 of them to various adventurous friends of mine for hardware testing. In the immediate future (May, June), I'm working on a project at MIT with Matt, but on the side, I'm selling more Rascals and gathering results from hardware testing. Depending on the results of the tests, I'll either commit to a larger batch of 100 Rascals, or run another small batch with improved hardware. If you're interested in the Rascal, you should follow the Rascal on Twitter here, or add your email address to the announcement list on the main page of the Rascal website. There's also a quick video interview of me explaining how the Rascal works. It was shot by Chris Connors at the 2011 mini-Maker Faire in Cambridge, MA, USA.

For the past few months, I have been working solo on a device that I intend to be open hardware. In my circumstances as not just a "small business," but the smallest possible business, the crucial question is whether opening my hardware designs to the world will result in someone taking a design and replicating it more cheaply than I can, thereby stealing all my customers. Against that fear, I have the hope that opening my designs will result in people improving them in ways that I can't predict.

This issue came up repeatedly at the summit. Many of the speakers were actually building and selling open hardware. Very few came from VC-funded companies (Bug Labs is the notable exception). Most of them were engineers who had bootstrapped their way from a few small designs they made themselves. They are evidence that my fears are unfounded, particularly in my current state of obscurity.

The explanations varied. Limor Fried of Adafruit said something like, "People say they will copy you, but it's hard to actually do. . . . Being obscure is worse than being ubiquitous." (A video of her talk is now available.)

In a later talk, Chris Anderson, who runs DIY Drones, mentioned the power of the community. They design small, autonomous aircraft and release all the plans on the internet. Their customers buy the electronics from DIY Drones and then tweak them. Anderson isn't worried about closed competitors: "We think the customers will go with the community." He also pointed out that the community of drone zealots was innovating faster than most private companies; even if you were to copy the hardware today, you'd be obsolete in short order.

After one of the panels, I talked to Nathan Seidle of Sparkfun for a few minutes. Sparkfun is the internet version of what Radio Shack was in the 70's, when they sold lots of electronic components. They have over 80 employees and around $10M in annual revenue. I asked Nathan why Sparkfun, if run by an evil version of him, wouldn't just collect open hardware designs and start replicating them. His answer was that breaking the trust of the community like that would devastate his sales.

Later in the day, I talked with Chris Gammell of the Amp Hour for a few minutes. He said that he was worried about what was going to happen when larger distributors enter the open hardware market. This is an interesting point viewed in the light of Nathan Seidle's and Chris Anderson's comments about the trust of the community. When the open hardware community is a small subgroup of a 10-100 thousand people forming a somewhat cohesive culture, losing the support of the community might be catastrophic. But if the electronic hobbyist world grows so that most of Sparkfun's customers don't even know that the hardware they're buying is open, it might be worth it for a giant like Digikey to risk alienating the hardcore open hardware folks. The situation might be like the libertarian anti-Obamacare editorial published by the CEO of Whole Foods in the Wall Street Journal last year-- hardcore liberals started boycotting Whole Foods, but the majority of their customers didn't care, because have you tried their almond cookies?

For me, as a new entrant to the market, I have no worries about a large corporation stealing my ideas-- risking the $100,000 it would take to beat me on volume on the hope that this solitary engineer has come up with a winning product would be colossal folly. I do think that the Rascal will be a great product, but it's definitely not there yet, and it will take a community of users to get it there.

Footnote: mbed.org

One other interesting note-- during lunch, I met Simon Ford and Dan Ros of mbed.org, a small group within ARM that is making development tools for ARM processors. The Mbed is not fully open hardware, though they do distribute schematics of the system. Simon said it was because he wanted to be sure they were built right.

The Mbed is an interesting board. It actually has two microcontrollers on it. The main processor, on top, is an LPC1768 running at 96 MHz. There is a second processor running at 12 MHz on the underside of the board that acts as the programmer for the first processor. You compile your code on their website and then transmit your programs to this supervisory processor via USB. It puts the code on the second processor via JTAG. The advantage of this is that the main processor behaves exactly as it will in a final design. You can design a device using the mbed, and when you're done, you can buy the same LPC1768 processor and replicate what you've got, minus the second processor, which is no longer necessary. It's an elegant architecture.

Having switched from Wordpress to Jekyll (a blog compiler, if you will), I needed a way to quickly browse a directory of images on a webserver and copy links to the images for insertion into blog posts. The PHP script below, if saved as index.php into a directory of images you want to browse, will create a page showing 200-pixel wide versions of all the images in rows of 5. You can tweak the image size and row length by changing the 200 and 5 in the script.

It's not kind on bandwidth, as it makes you download all your images, but it's simple. Save the code below as index.php with your images, and then browse to that file in your image directory (something like http://yoursite.com/img/index.php). Assuming your webserver has the PHP engine running, you'll see rows of images. You can then grab links by right-clicking and paste them wherever you like.

The code

<!DOCTYPE html>
<html>
    <head>
        <title>Images</title>
    </head>
    <body>
        <?php
        echo "<table>\n";
        echo "\t\t<tr>\n";
        $i = 0;
        if ($handle = opendir(".")) {
            while (false !== ($file = readdir($handle))) {
                if (strstr($file, "png")||
                    strstr($file, "jpg")||
                    strstr($file, "bmp")||
                    strstr($file, "gif")) {
                    echo "\t\t\t<td><a href='".$file.
"'><img src='".$file."' width='200px' /></a></td>\n";
                    $i++;
                    if ($i%5 == 0) {
                        echo "\t\t</tr>\n\t\t<tr>\n";
                    }
                }
            }
            closedir($handle);
        }
        echo "\t\t</tr>\n";
        echo "\t</table>\n";
        ?>
    </body>
</html>

What we really need are massive, cheap, efficient batteries. The idea in the Sadoway lab is to make something like an aluminum refinery, but instead of just sinking huge amounts of electricity to extract aluminum, you set up a reversible reaction so you could get the electricity back later.

Go take a look at this awesome, enormous picture of one of these furnaces in an aluminum refinery so you know what I'm talking about. Look at the size of the guy in the picture, and then look at how many furnace chambers there are in the row. That's an industrial scale operation.

To make aluminum, you dig bauxite out of the ground and use heat and sodium hydroxide to extract the part that's aluminum. What you get out, unfortunately, is oxidized aluminum, known as alumina. This is because aluminum, in its elemental form, reacts with oxygen, and when it sits in the earth for eternity, there's plenty of air seeping around, so all of the aluminum bonds with oxygen.

Fortunately, we have electrochemistry on our side. The large smelting furnaces in the picture you looked at a moment ago are long steel troughs that are lined with carbon and filled with aluminum oxide. These form the two electrodes in a chemical reaction. When electricity is run through the carbon into the aluminum oxide, the oxygen releases from the aluminum and bonds to the carbon, creating carbon dioxide, which is then vented to the atmosphere to help keep the planet warm. During the reaction, the aluminum oxide in the center heats up and liquefies, while the outer crust remains solid, sort of like the liquid-filled gum of the 70's, Chewels. (You may also recall Freshen-up, "the gum that goes squirt.")

To turn this process into a battery, we need an electrode that doesn't turn into a gas, and we'd like both electrodes to be cheap and lightweight, relative to the amount of energy they can store. Sadoway's lab started with one magnesium electrode and one antimony electrode, with a salt electrolyte in between. (They have since moved on to better combinations that I'm not at liberty to describe.) If you heat the core of the battery up to 700 C, everything becomes liquid, and the resistance drops substantially. Most remarkably, the three materials separate by density — electrode, electrolyte, electrode — all in a stack.

What's so great about a liquid metal battery? They have several advantages, notably extremely low internal resistance and huge current capability. Aluminum refineries run at currents above 100,000 amps. For comparison, most household circuitbreakers blow at 15 amps. The low resistance of liquid metals means that the battery is likely to charge and discharge very efficiently.

At first, the fact that the battery needs to run at high temperature seems like a major disadvantage — if you have to dump a lot of energy into heating, that makes the battery less efficient. This is true, but what's not obvious is what happens to a furnace's thermal behavior as it grows in size. In general, hot objects cool off in proportion to their surface area, which grows proportional to the square of the size of an object, roughly speaking. The capacity of a battery, however, grows with its volume, which is proportional to the cube of its size. This means that as the battery becomes huge, the amount of heat loss per unit of capacity decreases, i.e. the volume overwhelms the surface area. It's this same property that allowed icehouses in pre-industrial times to store ice well into the summer. There's some hope that at the right scale, with the right insulation, the small inefficiency in charging and discharging the battery will suffice to keep the core in the molten state.

So that's what I'm working on recently. (I'm still working on a Linux board on the side, but it's kind of on the back burner for the next month or so.)

We're about to see a shift in embedded systems development. Around 2008 or 2009, embedded microprocessors like the one in your cellphone, reached a threshold where they can perform as decent webservers without special tuning. Even with a slow database query or some inefficient templates, they've got the speed to handle real web serving. This means that suddenly the most efficient development pattern for embedded systems is not the proprietary hardware and software tools that have dominated the industry for the last 30 years, but the open source web development tools that have arisen in the last decade.

The transition will be painfully slow, and of course there are some niches where specialized hardware and real-time control will preclude the use of generic web tools-- motion control springs to mind. But I think that the combination of cheap hardware and modern web frameworks will crush the industrial controller market, like digital cameras did to film cameras.

First, some background on tiny computers

There are millions of tiny computers used for monitoring and control systems around the world. Let's break them into two categories: small (microcontrollers like the Arduino or a PIC development board, which runs $10-500) and large (embedded controllers like National Instruments hardware, which cost $500-5000).

To use the small ones, you write code from scratch, perhaps with some pre-written libraries to talk to certain peripherals and a bootloader to run your code on power-up. The vast majority cannot be connected to the internet without substantial effort, and when connected to the internet, they aren't powerful enough to work like most servers on the internet. For example, a webserver built on a small microcontroller would be overwhelmed by the background noise on the internet, i.e. traffic from bots and viruses. This kind of system is perfect if you want to log temperature in your basement, or turn on a light whenever the garage door is open. They're no good for running an inventory management system in a warehouse with 20 workers.

Below: an Arduino

The large ones come with an operating system, like Windows CE, Linux, or VxWorks. Most of the devices are reworked versions of hardware from the pre-internet days that have had Ethernet ports added to them. They can handle real internet traffic, but they usually use proprietary software to do it. They're shaped like a long, skinny shoebox.

Below: a larger controller

The change is that something equivalent to the iPhone, which uses a 600 MHz ARM processor, can store years of data and serve it up to anyone with a web browser in seconds with hardware cost of a few hundred dollars. Industrial controllers lose on cost of both hardware and programming time, and performance. The hardware has to be expensive to support the R&D costs, which are borne entirely by each manufacturer. There's just no way that even a large industrial control company, which might have a dozen dedicated programmers at best, can compete with the thousands of developers working on open source web software worldwide.

How web software development has changed

In the 90's, software development for the internet meant either writing server software or designing static web pages. Starting around 2000 (give or take a few years), websites started incorporating dynamic data, which was stored in databases. Around 2005, a new kind of web software gained popularity-- the web framework-- with the release of Ruby on Rails.

With old-style web development, a web programmer would write code that inserted data into a database, more code that updated the database with new data, and more code that retrieved and sorted the data for presentation in a web page. With a web framework, the programmer writes out a template for how the data should be presented on a webpage, and the framework figures out what to request from the database. Web frameworks can't scale to the level of a big website like Amazon, but for low traffic systems, they work fine and reduce the programming time needed dramatically.

Most of the time, what people want to do with microcontrollers is log some data from sensors and maybe trigger some actuators in response. After they log the data, people want to analyze the data, make graphs with it, and then do it again, maybe with a different sensor. This matches well with the typical database-backed website. The only substantial additions are code to interact with hardware-- read sensors and trigger actuators. I think this is the least developed part of the systems I expect we'll see in the next few years.

Proof of concept

It's definitely possible that I'm just some blowhard on the internet. I mean, I'm at least some blowhard on the internet, but I might still be right in predicting this change. To that end, I've done some testing to see whether I'm going in the right direction.

Using an off-the-shelf microcontroller kit that cost $339 plus shipping, I installed a Python web framework called Django and wrote code to make it act like a thermostat to replace the one in our house. It took about 2.5 weekends to write the code, which is much faster than I could write a similar application for something like an Arduino with an Ethernet carrier board, and this was my first try. I had played around with Django a few times previously, but this was my largest effort by far.

Below: the proof of concept

The hardware interface is just a cron job that runs once per minute. It queries a temperature sensor on the PCB using a short C program called by a Python script, which also logs the data to a SQLite database. Retrieval of a webpage that queries the database for the last 300 datapoints (5 hours worth) and generates a chart of the data using Javascript takes around 1.5 seconds. That's with a processor running at 250 MHz (relatively slow) and the database stored on an SD card. Most of the time is spent converting Python datetimes to Javascript timestamps.

I could have written a similar application even faster using a GUI tool like LabView, but that requires specialized hardware that cost 3-10 times more-- either a dedicated PC with a USB device for sensors, or a industrial controller with a sensor module. With Django, I got an administrative interface, allowing different users and groups different levels of access, for free. If I want a central repository of users with LabView, I'm looking at another $800 for the "Datalogging and Supervisory Control Module." If I want to talk to a SQL database, I'll need the "Database Connectivity Toolkit" for another $1000. This is on top of the $1500 I would have paid for LabView already, plus the hardware.

Embedded control systems running web services are still an immature technology at best, but I think they'll grow up quickly in the next few years.

Why are you writing this?

I've been thinking about this change for a year or two now. I'm working on developing something like the Arduino, but a little heavier duty, so it can run a web framework, but with the hardware drivers pre-integrated. Send me an email at brandon at pingswept.org or post a comment if you want to know when it exists for real.

Of the A8 and A9, the A8 is the cheaper, slower one, running in the 500 MHz to 1 GHz range; the A9 can have multiple cores and run up to 2 GHz. To me, the A8 crosses the threshold where we can build embedded systems that connect to the internet, have decent performance without requiring tuning to make applications run fast, and have a price in the $100-200 range. There are certainly many processors that can handle internet traffic in that price zone, like every decent consumer-grade Ethernet switch built in the last 10 years, but those are machines optimized for niche tasks. What's new is that we're finally getting enough clearance above the minimum requirements that cheap, general-purpose systems can function on the internet.

So if you want to make an embedded device that uses a Cortex A8, what chips can you buy? ARM is an unusual company in that they don't produce chips themselves; they license their designs to manufacturers in return for royalties on each chip sold. Right now, ARM lists 7 public licensees of the A8 design; in addition to those listed, Alchip and Ziilabs are claiming to have licensed the design. Several of the licensees, such as Ziilabs and Broadcom, are targeting niche multimedia applications and will likely only sell to large manufacturers of stuff like DVD players and video cameras. Of the remaining companies, two have released general-purpose A8 processors: Texas Instruments and Freescale.

Freescale has released the i.MX5x series, with two subfamilies: i.MX50 and i.MX51. They cost $30-40 in low quantities but the sole distributor listed (Avnet) reports a lead time of 26 weeks for all parts.

TI has two series of A8 processors: OMAP3 and the not-quite-released-yet Sitara AM35xx series. The OMAP3 series has been around since 2008, and there are several embedded Linux boards (Gumstix Overo, Beagleboard based around the OMAP35xx series, though none have a Ethernet port in their stock configuration. The first Sitara, probably the AM3517, will likely be the cheapest of the lot, but assuming we want to limit ourselves to chips that we can actually order, that leaves us with four choices (before we consider packaging): OMAP3503, OMAP3515, OMAP3525, and OMAP3530.

The two higher-end OMAP35xx chips, the OMAP3525 and OMAP3530, include a TMS320 DSP onboard, which is not worth the cost in a general purpose tool. This leaves us with the OMAP3503 or OMAP3515. The major difference between the two is the PowerVR SGX graphics accelerator in the OMAP3515, which, like the DSP, isn't worth the cost. Until the AM3517 or AM3505 hit the distributors, I think the OMAP3503 is the winner. We'd have to choose between the three different packages the chip comes in, but Digikey only has the CBB package (a 515-pin ball-grid array, distinguished from the CBC package by the pin spacing of 0.40 mm rather than 0.50 mm).

In the words of Captain Stillman, "Load and fire the weapon, soldier!"

Solution: Colin's blower door

A friend of mine from Stanford, Colin Fay, runs a company with his dad, David Fay, called Energy Metrics. Last weekend, Colin and his nearly homonymic associate Cullen were kind enough to bring Colin's blower door over to our house to run a test to see how drafty our house is.

The basic idea of a blower door is this: you fill your front door with a curtain and a massive fan that forces air out of the house. While it's doing that, a small sensor measures the air pressure difference between the inside and outside of the house. There are a few different tests you can run, but the standard test that the fan controller runs is to automatically adjust the fan speed until the pressure inside is 50 Pa lower than outside. For comparison: 50 Pa is roughly equivalent to the pressure from a windspeed of 20 mph, but blowing at your house uniformly from all directions. Atmospheric pressure is around 100,000 Pa.

When the fan reaches a steady state, air is whistling in through all the gaps around your windows, doors and foundation, and you can tell where the problems are. For us, the largest draft was coming under the basement door. The next worst were the gaps between the sashes in our larger, older double-hung windows. In real life, I suspect that the gap under the basement door is not so bad-- the thermal gradient keeps the colder, denser air sunk down in the basement. I didn't realize it at the time, but most of the draft was probably coming down through our vestigial chimney.

Colin's blower door, a Retrotec 2000 with a DM-2 Mark II controller, pulled air through our house at 3900-4000 ft³ per minute to generate a pressure difference of 50 Pa. Our house has a volume of around 18000 ft³, so with the fan blowing, we were replacing all the air in our house every 4.5 minutes, or 13.3 times per hour.

Assembling the blower door frame

The blower door from the inside

Once you know how drafty your house is with a fan pulling the heavens through it, you need to scale that to match the typical conditions for your house. As a rough rule of thumb: just divide by 20. With the fan, we had 13.3 air changes per hour, so that's about 0.7 air changes per hour without the fan.

But if you want to ascend to the peak of Mount Energygeek, and you're willing to do it unashamedly, you can use the empirical corrections of Max Sherman of the Energy Performance of Buildings Group at Lawrence Berkeley National Lab, who completed his thesis on modeling building air infiltration in 1980, when oil rolled down like waters and righteousness like acid rain. You look up correction factors for climate (~18 for Boston), building height (0.7 for our house), wind shielding (1) and leakiness (1), multiply them together, and you've got a better correction factor than the rough guess of 20. For our house, we end up with 13.3/(18 x 0.7 x 1 x 1) = 1.06 air changes per hour.

With that knowledge, you can calculate the power required to offset the drafts cooling or heating your house. Our house, nominally a 1900 ft² Victorian, has an internal volume of 18000 ft³, or 510 m³, so when it's 0 C outside, we're heating about 1.06 x 510 m³ of air per hour by around 20 C. The heat capacity of air is around 1200 J/m³C. That means we need to pour in 1200 J/m³C x 540 m³ x 20 C every 3600 seconds. By my calculation, that's about 3.6 kW.

The conductive heat loss model I developed for our house a few months ago when we were installing the boiler predicts that the conductive heat loss at the same temperature will be around 18 kW, so we lose about 1/6th of our heat from air infiltration.

Colin suggested we could reduce our draftiness by around 2x before we'd have to worry about the effects of too little fresh air (farts, basically). He suggested picking up a tube of transparent silicone caulk in the fall to fill the gap between the window sashes, as that's where our worst leaks are. In the spring, when it's time to open the windows again, the silicone peels off.

After seeing fellow energy geek Holly's sexy basement windows last weekend, I think I might look into replacing those as well.

The vise from my brother arrived first, so I mounted it up first. My dad brought the other vise over a few days later; with the arrival of some bolts from McMaster-Carr, I now have enough clamping force for three men.

Thanks, family!

Counterbores to keep the bolt heads below the table surface

One vise mounted

Enough vises to conquer Afghanistan

The bench with both vises (and a pile of pallets turned into firewood)

I learned some interesting stuff. The gables of our attic appear to be completely uninsulated. There is one stud bay missing insulation next to our front stairs. I hadn't noticed it, but once I knew to check, I could feel the temperature change with my hand.

Our windows are generally our most poorly insulating surface, but in the picture below, you can see the panels in the front door are a close second. (The large box of fire is a radiator.)

I was thinking I should insulate the garage roof, but the thermal camera revealed that the door was leaking more heat.

I had noticed that our cats preferred lounging in certains parts of our kitchen floor, but I hadn't noticed the large cold stripe down the middle.

Here, you can see that there are two rooms we aren't heating-- their windows are blue.

There aren't many activities in our modern society where it makes economic sense for me to engage in the kind of physical labor that will keep me healthy, but there are a few. From what I can tell, they tend to cluster at the margins of fossil fuel consumption. I'll explain what I mean by that shortly.

The first good example I've come up with involves the woodstove we had installed recently. (Barry John Chimney did a great job, by the way.) We can buy a cord of wood for around $250, but I can collect pallets from around Somerville pretty easily as well. We get some pallets at work, but I can also pick up pallets around Davis Square; I guess they're a waste stream diffuse and intermittent enough that the only collectors are amateurs such as myself.

Before I can burn the pallets, I have to cut them up. I'm not strong enough to break them into 13" lengths without the help of steel, at least stone, tools. Cutting them up with only a handsaw is possible, but grueling. A better combination for casualties of the modern workplace like me is to use a circular saw with the blade set to cut just shy of the full depth of the cross planks. If you cut all the way through, the planks sag and bind the blade. Once the planks are 95% cut, you can stomp on them, and then cut up the remaining stringers wih a handsaw. Between the two types of sawing, the stomping, and the lugging of pallets, it's a fair bit of work.

The pattern I've noticed is that I can substitute labor for fossil fuels at margins of our consumption. Heating our house entirely with wood would take a lot of effort; I've spent enough time with a splitting maul (10 hours, maybe) to know that I don't want to do it all winter. But, dragging home some pallets and cutting them up piecemeal in the basement is pretty satisfying.

One of the other large fossil fuel sinks in our lives is commuting. When I worked out in Lexington, I commuted 22 miles a day on a bike, rain or shine, all winter long. But, as we've moved and I've changed jobs, I switched to biking 16 miles per day, then 5 miles on foot. (Last year, we moved just a few blocks from my office, so I had to take up running, but you won't hear me complaining about that.)

I've been casting about for a name for these activities, and Hard Times Athletics is the best I can do.

(If you called it Fake Athletics for the Hard Times, or FAHT, you could say, "Have you been FAHTing in the basement again? It smells terrible down there." In Boston, that's funny.)

Below are some snapshots of my Hard Times gymnasium. Further suggestions of new Hard Times Athletics events are welcome in the comments.

The input

The tools of transformation

The output