John Graham-Cumming

I had emailed Tim Robinson who's been working on Meccano versions of the Analytical Engine and Difference Engine. He graciously replied: My website is quite out of date and I have done a bit more since I last updated it. I have a new and much better version of the control mechanism (operation cards & barrel) which is much more reliable than the one described on the website, though still probably not good enough for a real engine. It also incorporates a critical feature which was missing from the first version (the ability to branch at the last moment on a result generated in the current cycle.). I have a working demonstration of an anticipating carriage on 12 digit numbers. My current project is a store, but I have a long way to go. The sheer quantity of stuff needed to build this is one big problem, together with the tedium of making huge numbers of identical assemblies. I'm sure you have realized that the biggest single problem in proposing to actually build an

Some time ago I complained about pie charts without giving a real alternative. But the alternative is actually quite clear: it's not pie, it's sausage. Just like in iTunes: The length of each slice of sausage is proportional to the percentage. Since this is linear it's much clearer and easier to understand than a segment of a pie. And naturally, at Causata we use the same style in our own application.

I managed to get hold of Doron Swade who led the build of Difference Engine No. 2 . He graciously replied to my random email about the Analytical Engine . I won't reproduce the entire reply because it's long, and because the most important thing is something that he didn't say. He didn't say I was nuts! In fact, he too has been thinking about the best approach to building an Analytical Engine. The conclusion that he had come to (as had I), is that the best way to approach building the Analytical Engine would be to begin with a physical simulation using a 3D graphics program with a physics engine so that the motion could be studied. My opinion is that this simulation would be a vehicle for raising the money to build the real device. But even building the simulation is very complex because Babbage's plans for the Analytical Engine are incomplete and there are multiple versions. Getting to the simulation would itself be a research project to decide what would

I've created a domain specially for my investigations of the possibility of building an Analytical Engine to (close to) Babbage's plans. It's called Plan 28 . It references the fact that Babbage's most detailed plans of the Analytical Engine are in the form of two plans numbered 28 and 28a and stored in the Science Museum in London. These plans depict a machine with a mill (the CPU, capable of doing addition, subtraction, multiplication and division), a store (the memory), and the barrels (microcode for the mill operations). It's the closest thing to a computer as we know it (although the program and the data are stored separately and programs have no way of accessing anything other than fixed memory locations: i.e. there are no references or pointers). If you are following along and want some reading then go with the following: The Difference Engine by Doron Swade. It's an easy, quick read introduction to Babbage, the Engines and the reconstruction o

I wrote to Tony Hoare to ask his opinion on this idea and he was kind enough to reply: Would you be interested in doing an animation of the engine first? I've much enjoyed computer animations of the old Elliott 803, with the original tape decks, paper tape readers and punches, and all making the right motions and the right noises! Of course I also like revisiting the real machine, even if stationary. The simulation would be a good way of collecting money and enthusiasm for the real Engine. But the trouble with the real thing is that if you demonstrate it, it will wear out. OK for a private owner, but a bit disappointing as a museum piece -- unless supported by simulations. I assure you that even if the real thing is built, the simulation will be essential to check the design before construction can begin. And it will be the main intellectual challenge in the project -- and great fun. Clearly, he's correct. The first step in building the Analytical Engine would be t

Seriously, I write this blog for two simple reasons: the freebies and the groupies. Without them it wouldn't be worth it. And what great freebies: a DisplayLink USB video adapter and more RelaxZen than you can shake a stick at. And the groupies. Well I have the photos, but I'm not posting them. Which brings me to this week's awesome freebie: a copy of John Calcote's Autotools: A Practitioner's Guide To GNU Autoconf, Automake, AND Libtool . Yeah, that's what you get for living the GNU Make life and writing a self-published book about it. If there was ever a tool that needed a book it's Autoconf (and related scripts). Happily, Calcote has done a great job of describing, in detail, a collection of tools that can seem opaque at first glance (also at second glance). This book is vital for anyone who needs to work with Autotools and I wish I'd had it years ago. The final chapter (A catalog of tips and reusable solutions for creating great project

Here's a model of the Difference Engine No. 2 And here's part of the Analytical Engine More from the creator of these lovely devices .

I asked John Walker who maintains a lovely web site of information about the Analytical Engine whether he knew of any serious attempt to build it. He was kind enough to reply. To my knowledge, nobody has made a serious attempt to build the Analytical Engine or even a seriously scaled down version of it. I think the general consensus (which, in part, informed the various British commissions which decided not to fund the project) is that it is unlikely in the extreme that a machine which would be necessarily so large would not fall victim to "tolerance creep", where tolerances in individual components would eventually add to make large scale interfaces (for example, between the Mill and the Store) unreliable. Babbage was aware of this problem and addressed it in his papers. His solution was to design the machinery so that it would jam in case of error, but then the question is, how often would it jam? If it jammed every second and a typical computation took several hour

Normal people have a small part of their brain that acts as a sort of automatic limiter. They get some crazy idea like writing a book or campaigning for a government apology or calculating the number of legal track layouts for a cheap train set and their limiter goes: "Don't be ridiculous" and they go back to normal life. Unfortunately, I was born with that piece missing. So, it's not without trepidation that I say that it's time Britain built the Analytical Engine . After the wonderful reconstruction of the Difference Engine we need to finish Babbage's dream of a steam-powered, general-purpose computer. The Analytical Engine has all the hallmarks of a modern computer: it has a program (on punched cards), a CPU (called the 'mill') for doing calculations and it has memory. Of course, it's not electric, it's powered by steam. But the principles that underlie the Analytical Engine are the same that underlie the computer I'm writing

To keep things clean and manageable I've created a source code repository on Github for this project. You can find it here . The only thing committed so far is a skeleton directory structure and the LUA code for running the camera. Note that everything in the repository is covered by the General Public License, v2 .

So with a couple of hours to work on GAGA-1 this weekend I did one simple thing: painted the capsule fluorescent yellow. Most of the other high-altitude balloon projects that I've read about have used fairly simple capsules that are covered in duct tape, or simply left white. I decided to make the GAGA-1 capsule really visible for two reasons: 1. I want to be able to find it. Since the balloon will most likely come down somewhere in Norfolk or Suffolk (both of which are largely rural), it's going to end up in a field somewhere. The flight and recovery computers should tell me where, but I still want to be able to see it clearly when I get close. 2. If the capsule with its parachute should come down near people or vehicles, I want them to be able to see if coming. I'll be using a brightly coloured parachute, fluorescent rope and, now, a fluorescent capsule. (I'll do another blog post of safety later). The capsule is made of expanded polystyrene which is light an

In 1826 Charles Babbage realized that understanding the internal state of his engines was an arduous task and in an extensive paper on the subject ( On a method of expressing by signs the action of machinery ) he writes: In the construction of an engine, [...], I experienced great delay and inconvenience from the difficulty of ascertaining from the drawings the state of motion or rest of any individual part at any given instant in time: and if it became necessary to enquire into the state of several parts at the same moment the labour was much encreased. [...] The difficulty of retaining in mind all the cotemporaneous and successive movements of a complicated machine, and the still greater difficulty of properly timing movements which had already been provided for, induced me to seek for some method by which I might at the glance of the eye select any particular part, and find at any given time its state of motion or rest, its relation to the motions of any other part of the machine,

A quick tally of various components and their weights. I need to keep the entire thing under 1kg so that the balloon I plan to use (a 1200g latex sounding balloon ) can give sufficient lift for a fast ascent: 5m/s. Capsule 200g Camera 215g Arduino Duemilanove 28g Telit GSM862 34g 3.7V LiPo Battery 28g 4 AA Batteries 88g GSM Antenna 46g 2 x GPS Antenna 40g Lassen IQ GPS 20g That's roughly 700g leaving me 300g for bits of wiring, a PCB for the flight computer, the radio module, and some discrete components and the rope. Every thing about this project is a challenge: weight, extreme temperatures, dealing with the wind, a combination of radio and computer work, an autonomous camera, ...

The other thing that I did over the weekend was some initial work on the capsule. It consists of an expanded polystyrene box from Ferribox . Specifically, the XPS-2 which is a 245mm cube with an interior 150mm cube (i.e. very thick walls!) and weighs 200g (I'll dedicate another post to the weight budget but the whole thing needs to weigh less than 1kg). It has a fitted lid with a lip to keep it in place. Here's what it looks like: A quick sanity check of space inside shows that the cube will easily contain the recovery GPS (bottom right), main flight computer (top right) and camera (left). Clearly I'm not showing all the wiring, antennae, probes and power, but there's plenty of room: I plan to paint the capsule (with non-solvent based paint--those eat polystyrene) a very bright colour (probably fluorescent yellow) for easy recovery when it lands. The capsule will be attached to the balloon/parachute/radar reflector assembly by some nice nautical rope at each o

I couldn't take the uBASIC code for controlling the GAGA-1 camera any longer and I rewrote the entire thing in the other language that CHDK supports: Lua. This has resulted in a much better program with additional functionality: a proper log file stored on the camera's SD card, reading of battery levels and internal temperatures and a simple routine to check that the camera has enough memory space for the projected flight time. Last night I ran a test taking 10 pictures per minute with a 16Gb memory card. The result is a pair of drained Energizer Ultimate Lithium batteries, 2,766 tedious photographs out the back window of the house, and a log file indicating that the camera ran from 1704 to 0005 before failing. The camera actually took less than 10 pictures per minute taking a few seconds per image as the night wore on. The gap between cycles remained at 6 seconds. So the camera ran for 7h01m on new batteries and took a picture every 9.1s on average. The camera's lo

"Yes, I know. It's fine." Tonight was freeze test time for the GAGA-1 camera and it passed with flying colours. That was to be expected given that others have flown the A560 camera to the stratosphere without too much trouble. But I really wanted to convince myself that it was OK to stick a digital camera in the freezer. Here's the camera going into the freezer (which is set to -18C) at 2049. Wish it luck! Two hours later the camera is ice cold, covered in ice crystals, but still operating. The lens retracts and extends correctly and picture taking works without any obvious problems. And after three hours I put the camera out of its misery. It was still working fine. Should be good for the real flight. Here are its final moments of frozen captivity (I hit the off button and the lens and shutter closed):

When I first thought about building GAGA-1 I imagined building a single flight computer that would control everything: it would read GPS, transmit telemetry, send SMS messages and operate the camera. But that would have created an enormous risk of complete failure. If the main computer failed (and there are so many ways to fail: bad software, a hardware fault, loss of electrical power, loss due to low temperature/pressure) the entire flight would have been a failure: no pictures, no telemetry to aid recovery. In fact, the only thing that would have worked is the dumb latex balloon happily exploding at altitude. So I've opted for a design with three independent systems with no electrical connections between them and independent power. 1. Flight computer This main computer will receive data from the primary GPS, read internal and external temperatures, and transmit telemetry over the RTTY link. This is the Arduino-based system for which I am building a custom shield. The flig

I decided to spend the weekend doing some work on GAGA-1 and got the camera in fairly good shape. I'm using a Canon A560 (two, in fact, that I bought off eBay for about £35 each). There are lots of reasons to use this camera: it's lightweight (very important since I need to minimize the payload weight), it's been flown on high-altitude balloon projects before (e.g. by Robert Harrison ), it was recommended to me by the CU Spaceflight guys and it's hackable with CHDK . CHDK is an amazing project that lets you run new firmware on a wide range of Canon cameras that enable full control of the camera. For my purposes I'm using the uBASIC interpreter that's part of CHDK to script automatic photo taking (code below). First, a few notes on getting CHDK loaded on my A560 from a Mac (you should start by reading the Mac FAQ . 1. Get the correct build for the camera from here . I'm using the 'full' version. 2. Unzip the file from the command-line a

I'd probably overlooked this for a while, but The Geek Atlas is available as a Kindle book. It's in the US and UK Amazon stores.