More technical opinions on the Analytical Engine project

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 AE, is deciding exactly what it is!

The initial difficulty in building the engine will be around deciding what constitutes a Babbage AE. The initial approach will involve a research project and computer simulation of the AE hardware. From there the project can continue to the actual physical device.

What to use instead of a pie chart

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.

A quick chat with Doron Swade

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 constitute an authentic Analytical Engine as Babbage would have conceived it.

So to build the engine there would be three major steps (the first two would be iterative):

1. Decide on the design of an Analytical Engine from Babbage's plans.

2. Build a computer simulation of the working engine to verify operation.

3. Build the physical machine.

At all stages money would be needed. First to pay for the research on the authentic machine, and second for the building of the simulation. Finally, money would be needed for the full build. Nevertheless, I think there's a significant community component as well: much of the simulation could be built by volunteers once the plans had been studied.

Estimating the cost will be difficult, but I can give a lower bound: the Difference Engine No. 2 build cost about £250,000 in the late 1980s. If inflation is to be believed that's around £390,000 today (which is about $620,000). The Analytical Engine would be bigger and more complex and hence more expensive and more research is needed.

So, I'm guessing (and this will need to be verified) that to complete a physical machine with historical accuracy would costs a small number of millions of £.

Plan 28

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:

1. The Difference Engine by Doron Swade. It's an easy, quick read introduction to Babbage, the Engines and the reconstruction of Difference Engine No. 2. The latter reconstruction demonstrates that the construction techniques available to Babbage were sufficient and would have enabled the construction of the machine. The reconstruction cost £250,000 in the late 1980s.


2. The Little Engines that Could've. This is a PhD thesis by Bruce Collier and goes into a lot of detail about the operation of Babbage's engine. I turned those web pages into PDF and had it bound so I could sit and read it. The PDF is here.


3. Charles Babbage's Analytical Engine, 1838. IEEE article by the man who probably understood Babbage's Engines better than anyone in the 20th century, Allan Bromley. This article introduces the state of the machine as of 1838.


4. Babbage's Analytical Engine Plans 28 and 28a-The Programmer's Interface. Also by Allan Bromley this paper covers the Analytical Engine in 1847 when Babbage stopped working on it. In particular, it details the instruction set that would have been available to the programmer.


5. The Evolution of Babbage's Calculating Engines. More historical context from Allan Bromley putting the design of the Analytical Engine in context with the Difference Engines and modern computers.


6. Babbage's Analytical Engine Babbage's son, Major-General H. P. Babbage, describes his construction of part of the Analytical Engine.


7. The Analytical Engine Also by Babbage's son, this long paper describes the operation of the Analytical Engine as he understood it.


8. Of The Analytical Engine Charles Babbage's own description of the Analytical Engine from his autobiography.


9. Sketch of the Analytical Engine The famous paper translated by Ada Lovelace on which much of her fame rests.

And as a bonus, here are some pictures I took at the weekend in the Science Museum in London.

The first shows a trial portion of the Difference Engine:


Here are some punched cards prepared by Babbage that would have been used for programming the Analytical Engine:


And here's the trial section of the Analytical Engine that Babbage built:


And, finally, the mill of the Analyical Engine. This was built by Babbage's son after his father's death.

Another technical opinion on building the Analytical Engine

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 to create a working prototype on a computer so that bugs in its design (which will need to be reconstructed from fragments and incomplete descriptions) can be worked out and a viable machine created in some CAD package.

From that a real machine could be created. Looking at the plans for the Analytical Engine the minimum machine would likely to quite large: around the size of a steam locomotive.

So, any experts on building this type of simulation out there?

Autotools

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 projects) is fantastic because it dishes up a collection of practical, real solutions to problems users of Autotools will encounter. Above all, the book shows that it was written by someone who truly understands the set of tools, and thankfully is able to write clearly.

He doesn't shy away from getting into difficult details (like the M4 macro language) and chapters 8 and 9 are an exposition of the use of Autotools for an actual, large project showing what a real-world use of the tools looks like. Those 50 pages are probably the most valuable in the entire book.

Highly recommended for anyone who needs to use Autotools.

Babbage machines in Meccano

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.

First opinion on whether the Analytical Engine could be built

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 hours, a room full of people with log tables could out-compute the Analytical Engine.

I'd think it would be beyond crazy to try to raise the funds to construct the complete Analytical Engine. After the Singularity, when we're all 10^16 times as wealthy as at present and can build diamonoid machinery with atomic precision, I'd say go for it, but then tens of thousands of people will have done so within the first 24 hours after the Transition.

Gen. Henry P. Babbage's description of an attempt to build just a component of the Engine:

http://www.fourmilab.ch/babbage/hpb1910.html

is instructive of the problems of mechanical tolerances. We can build things much more precisely than in his day (although much of the progress in our technology has been in coping with sloppiness, not improving precision), but ultimately large scale computation depends upon robust digital storage which is immune to noise:

http://www.fourmilab.ch/documents/comp_mem_nat_life/

Any macroscopic mechanical system has at best a modest level of noise immunity, and when you imagine a machine the size of an auditorium with hundreds of thousands of parts, the challenge seems overwhelming.

I'm a balding engineer, and I've seen many great ideas founder on the rocky shore of reality. I think the British were *right* not to fund the Analytical Engine; it was a superb idea a century before its time.

So go prove me wrong.

(And ask yourself, as I often do, "What are the superb ideas we have today which are a century before their time?")

I shall continue to investigate. If you care about this topic you can follow the label babbage. If you have an informed technical opinion on this please contact me.

It's time to build the Analytical Engine

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 this on.


From Flickr user csixty4

What a marvel it would be to stand before this giant metal machine, powered by a steam engine, and running programs fed to it on a reel of punched cards. And what a great educational resource so that people can understand how computers work. One could even imagine holding competitions for people (including school children) to write programs to run on the engine. And it would be a way to celebrate both Charles Babbage and Ada Lovelace. How fantastic to be able to execute Lovelace's code!

From Flickr user gastev

Of course, Babbage and his family only ever made parts of the engine (see the picture above). But that shouldn't stop us from constructing it now. All that's needed is money. I'd imagine there are plenty of people who'd want to work on the project.

Unfortunately, I think it would cost a lot of money. The construction of a second Difference Engine for Nathan Myhrvold is said to have cost $1m and that was after all the hard work of figuring out how to make it was completed. It also took years.

But that shouldn't hold us back.

If sufficient money could be raised I'd jump at the chance to run this project as a charity that would donate the completed machine to either London's Science Museum or the National Museum of Computing. Clearly, I can't do this in my free time (and nor could others) so sufficient money would need to be raised to pay a reasonable salary to those involved. And I'd imagine that the materials cost would be very large as well.

Am I mad? Would you donate to make the Analytical Engine an oily, steamy, brass and iron reality? Can we live up to Lovelace's words when she wrote: "We may say most aptly, that the Analytical Engine weaves algebraical patterns just as the Jacquard-loom weaves flowers and leaves. "

PS A commenter asked about pledging money to the project. I'm not quite ready to start accepting cash! :-) But people can pledge by either sending me an email or simply writing a comment here. That'll give me an idea of interest in doing this.

PPS UPDATE. Please visit Plan 28 for more on this topic.

GAGA-1 Source Code Repository

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.

GAGA-1: Capsule paint job

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 and insulating, but a pain to cut and paint. It's not possible to use any solvent-based paints because they eat polystyrene in seconds. Here's a shot of a polystyrene ball sprayed briefly with paint. Note the ball next to it for comparison.


That damage was done in under five minutes.

So, to paint polystyrene you need to do two things: use a water based paint and get that paint to stick. To get it to stick the polystyrene should be prepared by sanding it. I tried two things: sanding with fine wire wool (bad idea because the wire wool sticks to the polystyrene and is impossible to remove) and sanding with 240 grit sandpaper.

The sandpaper worked great. In no time at all the surface was ready for painting. I used unthinned acrylic paint from a local art shop.


And here's the final result. These pictures don't capture the full 'my eyes, my eye!' brightness of the fluorescent paint. Here you can see the yellow but not how fluorescent it is. With this paint job it should be visible.


Of course, painting the capsule adds to the weight, but I think that's going to be offset by the holes that I need to cut in it for the camera lens and antennae.



Once the paint has had time to really dry I am going to stencil on contact information so that if the capsule is lost someone can get in contact if they find it.

Babbage's Debugger

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, and if necessary trace back the sources of its movement through all its successive stages to the original moving power.

In the paper he goes on to develop a notation that allows him to draw something similar to a sequence diagram for a machine. But his diagram is at a very low level: it describes the motion of individual parts of a machine.


And he uses the notation to analyze the operation of a clock, drawing a large picture of the motion of each part of the clock and how motion of one piece influences another. From the diagram he is able to trace back the movement of the clock's minute hand to its original source of power.


He concluded by saying:

The signs [...] will form as it were an universal language; and to those who become skilful in their use, they will supply the means of writing down at sight even the most complicated machine, and of understanding the order and succession of the movements of any engine of which they possess the drawings and the mechanical notation. In contriving machinery, in which it is necessary that numerous wheels and levers, deriving their motion from distant part of the engine, should concur at some instant of time, or in some precise order, for the proper performance of a particular operation, it furnishes important assistance; and I have myself experienced the advantages of its application to my own calculating engine, when all other methods appeared nearly hopeless.

Since, at that time, Babbage was concerned with creating non-programmable machines such as the Difference Engine, his notation is the closest thing possible to a debugger. It allowed him to understand the state of the machine at any moment in time and trace back how that state was reached.

Clearly, that's not quite the same thing as the way debuggers are used today, but for Babbage he needed to debug prior to making the machine. He was using a form of static analysis to ensure that a machine would work.

GAGA-1: Weight Budget

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, ...

GAGA-1: The Capsule

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 of the four corners. I have some strong, light-weight rope like this:


Since the stratosphere is at -55C there's clearly some temperature change to be worried about, hence the insulated box. Like everything else in GAGA-1 I've been testing and this weekend I did a rough and ready test of expected internal temperatures by abusing physics wildly and using my home freezer.


Here's the physics abuse: suppose the capsule is launched at ground level at 20C and rises at a constant rate to an altitude where the temperature is -55C and that the temperature gradient between ground and sky is constant then the average temperature encountered is (20 + -55) / 2 = -17.5C. Convenientely my freezer is at -18C so I decided to shove the box in the freezer for two hours to see what happens. Inside the box was a digital thermometer transmitting the temperature to an external monitor. I wrote down the temperature every 15 minutes.

Here's a chart of the actual temperatures (green) and the predicted temperature trend using Newton's Law of Cooling (red). X-axis is elapsed time in minutes, Y-axis is internal temperature in C.


Given a maximum flight time of 3 hours the prediction would be for the internal temperature to drop to somewhere close to -15C. That's acceptable.

As well as abusing physics this calculation ignores two other pertinent facts:

1. There's actually a source of heat inside the capsule: the electronics. The camera, GPS and radio transmitter all heat up while operating so there will be some internal warming.

2. The box won't be completely sealed as holes will be pierced for the four antennae and the camera lens.

Will be interesting to see how the temperature really drops on the day.

GAGA-1: 2,766 tedious photographs and a log file

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 log file begins:

20100911170411,GAGA Camera Control
20100911170411,Self-check started
20100911170411,Assert property (49) -32764 == -32764 (Not in manual mode)
20100911170411,Assert property (5) 0 == 0 (AF Assist Beam should be Off)
20100911170412,Assert property (6) 0 == 0 (Focus Mode should be Normal)
20100911170412,Assert property (8) 0 == 0 (AiAF Mode should be On)
20100911170412,Assert property (21) 0 == 0 (Auto Rotate should be Off)
20100911170412,Assert property (29) 0 == 0 (Bracket Mode should be None)
20100911170412,Assert property (57) 0 == 0 (Picture Mode should be Superfine)
20100911170412,Assert property (66) 0 == 0 (Date Stamp should be Off)
20100911170412,Assert property (95) 0 == 0 (Digital Zoom should be None)
20100911170412,Assert property (102) 0 == 0 (Drive Mode should be Single)
20100911170412,Assert property (133) 0 == 0 (Manual Focus Mode should be Off)
20100911170413,Assert property (143) 2 == 2 (Flash Mode should be Off)
20100911170413,Assert property (149) 100 == 100 (ISO Mode should be 100)
20100911170413,Assert property (218) 0 == 0 (Picture Size should be L)
20100911170413,Assert property (268) 0 == 0 (White Balance Mode should be Auto)
20100911170413,Assert 2010 > 2009 (Unexpected year)
20100911170413,Assert 17 > 6 (Hour appears too early)
20100911170413,Assert 17 < 20 (Hour appears too late)
20100911170413,Assert 3138 > 2700 (Batteries seem low)
20100911170413,Assert 5078 > 1800 (Insufficient card space)
20100911170413,Self-check complete
20100911170424,Starting picture capture
20100911170426,Picture 1 taken
20100911170426,Temperatures: 34, 34, 30
20100911170426,Battery level 3017
20100911170434,Picture 2 taken
20100911170434,Temperatures: 34, 34, 30
20100911170434,Battery level 2983
20100911170442,Picture 3 taken

The time stamp is YYYYMMDDhhmmss. The three temperatures are the optical components, the CCD and the battery compartment. The camera was warm when I started because I'd been playingwith it. The battery level is in mV.

The temperature peaked early on and then settled down to a steady warm glow: the camera was warm to the touch while running. This'll be a little different on the flight since the external temperature of the capsule will drop to -55C. Here's a chart showing the CCD and Battery temperatures:

The battery declined steadily throughout the run:



And here's the code for anyone who wants to try the same thing:

-- GAGA Camera Control Code
--
-- Copyright (c) 2010 John Graham-Cumming
--
-- Performs the following steps:
--
-- Performs a self-check
-- Waits for a predetermined amount of time
-- Enters loop doing the following:
--   Take a number of photographs in succession
--   Wait a predetermined amount of time

--[[
@title GAGA Camera Control

@param s Start-up delay (secs)
@default s 10

@param c Pictures per iteration 
@default c 1

@param i Iteration delay (secs)
@default i 6

@param f Flight time (hrs)
@default f 3

]]

function stamp()
    return string.format("%4d%02d%02d%02d%02d%02d",
    get_time("Y"),
    get_time("M"),
    get_time("D"),
    get_time("h"),
    get_time("m"),
    get_time("s"))
end

ok = 1

function log(m)
  print(m)
  l = io.open("A/gaga.log", "ab")
  if ( l ~= nil ) then
    l:write(string.format("%s,%s\n", stamp(), m))
    l:close()
  end
end

function assert_error(e)
  play_sound(6)
  er = string.format("ERROR: %s", e)
  log( er )
  ok = 0  
end

function assert_prop(p, v, m)
  pp = get_prop(p)
  log( string.format("Assert property (%i) %i == %i (%s)", p, pp, v, m))
  if ( pp ~= v ) then
    assert_error(m)
  end
end

function assert_eq(a, b, m)
  log( string.format("Assert %i == %i (%s)", a, b, m))
  if ( a ~= b ) then
    assert_error(m)
  end
end

function assert_gt(a, b, m)
  log( string.format("Assert %i > %i (%s)", a, b, m))
  if ( a <= b ) then
    assert_error(m)
  end
end

function assert_lt(a, b, m)
  log( string.format("Assert %i < %i (%s)", a, b, m))
  if ( a >= b ) then
    assert_error(m)
  end
end

-- The sleep function uses microseconds do the s and i need
-- to be converted

ns = (f * 60 * 60 * c) / i
s = s * 1000
i = i * 1000

log( "GAGA Camera Control" )

-- Now enter a self-check of the manual mode settings

log( "Self-check started" )

assert_prop( 49, -32764, "Not in manual mode" )
assert_prop(  5,      0, "AF Assist Beam should be Off" )
assert_prop(  6,      0, "Focus Mode should be Normal" )
assert_prop(  8,      0, "AiAF Mode should be On" )
assert_prop( 21,      0, "Auto Rotate should be Off" )
assert_prop( 29,      0, "Bracket Mode should be None" )
assert_prop( 57,      0, "Picture Mode should be Superfine" )
assert_prop( 66,      0, "Date Stamp should be Off" )
assert_prop( 95,      0, "Digital Zoom should be None" )
assert_prop( 102,      0, "Drive Mode should be Single" )
assert_prop( 133,      0, "Manual Focus Mode should be Off" )
assert_prop( 143,      2, "Flash Mode should be Off" )
assert_prop( 149,    100, "ISO Mode should be 100" )
assert_prop( 218,      0, "Picture Size should be L" )
assert_prop( 268,      0, "White Balance Mode should be Auto" )
assert_gt( get_time("Y"), 2009, "Unexpected year" )
assert_gt( get_time("h"), 6, "Hour appears too early" )
assert_lt( get_time("h"), 20, "Hour appears too late" )
assert_gt( get_vbatt(), 3000, "Batteries seem low" )
assert_gt( get_jpg_count(), ns, "Insufficient card space" )

log( "Self-check complete" )

if ( ok == 1 ) then
  sleep(s)
  log( "Starting picture capture" )

  n = 0

  while ( 1 )  do
    tc = c
    while ( tc > 0 ) do
      shoot()
      n = n + 1
      log( string.format("Picture %i taken", n ))
      tc = tc - 1
    end
    log( string.format("Temperatures: %i, %i, %i",
        get_temperature(0), get_temperature(1), get_temperature(2) ))
    log( string.format("Battery level %i", get_vbatt()))
    sleep(i)
  end
end

log( "Done" )

The only remaining worry was that the camera was showing the 'shake' symbol while taking pictures. This turned out to be simply because night was falling and I have the camera locked into manual mode at ISO 100 with no flash. The shake symbol was a warning of a low f-stop and long shutter open period. Will be a bit different in the ever sunny stratosphere.

GAGA-1: "Honey, there's a camera in the freezer"

"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):

GAGA-1: Redundancy and Independence

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 flight computer will transmit telemetry via an antenna on the bottom of GAGA-1 (since its primary use will be in flight we'll have a clear view of the capsule's underside). The GPS antenna will be on the top so that it 'points' towards the GPS satellites.

2. Recovery computer

This secondary computer will have an independent GPS and a GSM modem for low altitude telemetry. While the balloon is below 3km it will transmit its position and altitude using SMS messaging via an external antenna mounted on the top of GAGA-1 (since its intended to be used on and near the ground). This separate board will use it's own 3.7v battery from an old cell phone.

3. Camera

I've previously described the camera which will operate automatically throughout the flight.

The flight goals are as follows:

1. Safe recovery: hence the two independent computers for telemetry and GPS using independent GPS modules and different transmission methods.

2. Photography: the camera could fail, but I can't afford the weight budget of two cameras for this flight so I've done extensive testing on the camera itself.

3. Constant tracking: the flight computer will transmit RTTY as has been used by many others to track their flights. I hope to have constant RTTY data available so that the flight can be tracked continuously (since that's part of the fun).

The flight can survive a loss of either computer, and if both computers failed I'd still have balloon flight prediction and a mobile number stencilled on the box to aid recovery.

GAGA-1: Camera Hacking

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 and not from Archive Utility otherwise Mac OS X adds Extended Attributes (specifically, com.apple.quarantine) that mess everything up. I just did unzip a560-100a-0.9.9-933-full.zip.

3. Use SDMInst to format and upload to the SD Card. You only need to do this once, after that you can mess around with adding scripts in CHDK/SCRIPTS on the SD card directly using the normal Mac file system.

4. Set write protect/lock on the SD card. Put card in camera. You will see a special CHDK splash screen indicating that you are running the firmware from the card and not from the camera. Click the 'direct print' button on the camera and you enter ALT mode.

5. In ALT mode you have access to all of CHDK's functions. Here's what happens when you hit MENU on ALT mode:


Since I'm working with a custom script (called GAGA-1.BAS) I load it from the Scripting parameters menu item. Once loaded the parameters for that script are visible in the menu:


My script has three parameters: a start-up delay that gives me time to do a quick visual check of the camera and insert it into the box before it starts operating, the number of pictures to take in a burst and the delay between bursts. The camera will sleep for five minutes, wake up and take three pictures and then go back to sleeping for another five minutes.

Once back on the main screen the GAGA Camera Control script is mentioned at the bottom of the screen. This indicates that simply hitting the shutter button will start the script.


The 'opt' value top-right is the temperature of the optical parts of the camera. I expect this will drop when GAGA-1 hits the stratosphere. It's possible to get and log these values so I may add a log file to the SD card recording the temperature drop.

And here's what that looks like: start-up of the script, self-check and taking a few shots:



I ran a full test with new Duracell batteries (the ordinary gold-topped ones) today and the camera took 61 photographs at maximum resolution, running continuously for 103 minutes. This is ok, but not good enough. Most balloon flights will be in the 120 to 180 minute range so I need extend the time.

One big problem was that I had the display shut off set at three minutes, with a five minute wake up that meant the LCD was on 3/5 of the time wasting a lot of battery. The next test will be done with the minimum time (20 seconds). The next test also needs to use the right batteries: Energizer Lithium Ultimate.

I fully expect to get to 180 minutes with five minute wake-ups taking 10 pictures at a time with that combination. But, as with everything else in GAGA-1, it'll need testing.

Here's the script itself. The actual photographing code is a tiny loop towards the end which uses the CHDK shoot command to take a picture. Everything else is self-test using the property cases to ensure that I don't mess up. The idea is that the camera is manually configured (and in Manual Mode). The script checks that there's nothing silly going on (like the flash being enabled).

rem GAGA Camera Control Code
rem
rem Copyright (c) 2010 John Graham-Cumming
rem
rem Performs the following steps:
rem
rem Performs a self-check
rem Waits for a predetermined amount of time
rem Enters loop doing the following:
rem   Take a number of photographs in succession
rem   Wait a predetermined amount of time

@title GAGA Camera Control

@param s Start-up delay (secs)
@default s 10

@param c Pictures per iteration 
@default c 10

@param i Iteration delay (secs)
@default i 300

rem The sleep command uses microseconds do the s and i need
rem to be converted

s=s*1000
i=i*1000

print "GAGA Camera Control"
sleep s

rem Now enter a self-check of the manual mode settings

print "Self-check started"

p=get_prop 49
if p <> -32764 then
  print "ERROR: Not in manual mode"
  goto "fail"
endif

p=get_prop 5
if p <> 0 then
   print "ERROR: AF Assist Beam should be Off"
   goto "fail"
endif

p=get_prop 6
if p <> 0 then
   print "ERROR: Focus Mode should be Normal"
   goto "fail"
endif

p=get_prop 8
if p <> 0 then
   print "ERROR: AiAF Mode should be On"
   goto "fail"
endif

p=get_prop 21
if p <> 0 then
   print "ERROR: Auto Rotate should be Off"
   goto "fail"
endif

p=get_prop 29
if p <> 0 then
   print "ERROR: Bracket Mode should be None"
   goto "fail"
endif

p=get_prop 57
if p <> 0 then
   print "ERROR: Picture Mode should be Superfine"
   goto "fail"
endif

p=get_prop 66
if p <> 0 then
   print "ERROR: Date Stamp should be Off"
   goto "fail"
endif

p=get_prop 95
if p <> 0 then
   print "ERROR: Digital Zoom should be None"
   goto "fail"
endif

p=get_prop 102
if p <> 0 then
   print "ERROR: Drive Mode should be Single"
   goto "fail"
endif

p=get_prop 133
if p <> 0 then
   print "ERROR: Manual Focus Mode should be Off"
   goto "fail"
endif

p=get_prop 143
if p <> 2 then
   print "ERROR: Flash Mode should be Off"
   goto "fail"
endif

p=get_prop 149
if p <> 100 then
   print "ERROR: ISO Mode should be 100"
   goto "fail"
endif

p=get_prop 218
if p <> 0 then
   print "ERROR: Picture Size should be L"
   goto "fail"
endif

p=get_prop 268
if p <> 0 then
   print "ERROR: White Balance Mode should be Auto"
   goto "fail"
endif

v=get_vbatt
if v < 3000 then
   print "ERROR: Batteries below 3V"
   goto "fail"
endif

print "Self-check complete"
print "Starting picture capture"

n=0

:loop 
for a=1 to c
    shoot
    n=n+1
    print "Picture", n, "taken"
next a
sleep i

goto "loop"

:fail
print "GAGA Camera Failed"
end

:done
print "GAGA Camera Done"
end

Remaining TODOs:

0. Buy larger SD card
1. Rerun Duracell battery test with faster LCD cut off time
2. Run test with Energizer Lithium Ultimate batteries
3. Run freeze test at -18C
4. Make self-check happen before initial delay
5. Figure out whether the display shut off and auto shut down can be self-checked
6. Can we check that RAW mode is off?
7. Is it possible to check that there's space on the SD card? Check that the date/time seems sensible?

UPDATE. Ran test using Energizer Lithium Ultimate batteries. What a difference some lithium makes! Instead of 103m the test ran for 451 minutes (over 7.5 hours). This was taking 3 pictures every 5 minutes. The camera took a total of 264 shots before I stopped it. At that point the battery was running low with the Canon indicator flashing.

The display shut off time was set at 20 seconds and I disabled RAW photo-capture.

The Geek Atlas now available for Kindle

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.