That’s quite true, but Kelvin Long, the project lead on Icarus, has highlighted a wonderful quote from Arthur Eddington’s 1927 book Stars and Atoms which nicely sums up my feelings on the matter too.

In ancient days two aviators procured to themselves wings. Daedalus flew safely through the middle air and was duly honoured on his landing. Icarus soared upwards to the sun till the wax melted which bound his wings and his flight ended in fiasco. In weighing their achievements, there is something to be said for Icarus. The classical authorities tell us that he was only “doing a stunt”, but I prefer to think of him as the man who brought to light a serious constructional defect in the flying-machines of his day. So, too, in Science. Cautious Daedalus will apply his theories where he feels confident they will safely go; but by his excess of caution their hidden weaknesses remain undiscovered. Icarus will strain his theories to the breaking-point till the weak joints gape. For the mere adventure? Perhaps partly; this is human nature. But if he is destined not yet to reach the sun and solve finally the riddle of its constitution, we may at least hope to learn from his journey some hints to build a better machine.

Rabbit Hole Day

This is my first public article for Icarus. I joined the team a few weeks ago, working primarily on the communication systems.

Project Icarus is a study being carried out by the Tau Zero Foundation and the British Interplanetary Society to update the original Project Daedalus design from the 1970s with the benefit of 30 years’ advance in science and technology.

While decades of science fiction have accustomed us to the idea that the human race is destined to live on in distant solar systems, the harsh reality is that travel to the stars is really very very hard. Ridiculously hard. Even the closest stars to the sun are so far away that it would take thousands of years for a small probe to arrive using our current propulsion systems. Our technology is not even remotely close to being able to send humans on such a voyage.

But should we let our present limitations bind our conception of what is possible? Can we establish the limits of what physics will allow, even if the engineering challenges are beyond daunting at this stage? And having sketched out the theoretically plausible, can we work out a plan of action for tackling these problems both experimentally and theoretically so we can, in the near term, make progress toward our goals?

Marc Millis headed NASA’s Breakthrough Propulsion Physics Project from 1996 to 2002. This project examined various technologies to see if they could be developed into plausible propulsion systems. When the project was wound up, Marc went on to set up the Tau Zero Foundation, wholly independent of the government. The foundation is pursuing similar aims, but has a much wider scope and is free of many of the limitations of the government-funded project.

The Frontiers of Propulsion Science (FOPS) book is the first major publication to summarize the wide variety of science that is being considered right now as the basis for possible future development into starship technology. It is published by the American Institute of Aeronautics and Astronautics (AIAA) as part of their Progress in Aeronautics and Astronautics series.

This book is ambitious. Millis acknowledges right from the start that while some of the science is well-accepted, the ability to turn it into actual technology is a very difficult engineering problem; and other science topics examined are extremely speculative, in that we simply have no idea yet how nature works in these areas.

FOPS provides a wide-ranging reference for researchers who are starting out in interstellar propulsion. It ranges from background material on how to formulate the rocket equation for different types of engines, to advanced rockets using plausible (but difficult) technologies such as fusion and antimatter, through to methods of exploiting the Zero Point Field to extract energy from the vacuum, and creation of warp bubbles. It also contains chapters showing negative analysis of techniques that have been widely discussed, but have not demonstrated any useful results in the lab.

This is not a book for the non-technical layman. For a start, it’s US$130! It also contains a lot of math and technical language. A reader with a solid technical background who enjoys this kind of detail will find a lot of interest within. However, the book is really aimed at managers, scientists, engineers and graduate students, to give them a good grounding in the status of the research. Millis has discussed plans to create a less technical version of the book for a more general audience.

From a personal perspective, I found two parts of the book most interesting. First, discussion of technologies that are not too far out. These are the kind of systems that we could plausibly build within the next twenty to fifty years. Despite the fact that we haven’t yet managed to achieve break-even fusion on Earth, the physics is sound, and I do not see any reason to believe that we won’t be able to achieve this in a starship. Someday.

The second aspect I find most interesting is discussion of the really way off technologies, such as wormholes and warp bubbles. Even if the physics ultimately turns out to allow such things to exist theoretically, they will be unbelievably hard to create, and it may even turn out to be technically impossible.

FOPS provides good background for both ends of the propulsion technology spectrum.

There is far too much material in the book for me to give more than a taste, so if you want to see a list of the topics covered, have a look at the Table of Contents.

After considering the limits of interstellar flight technology, examining the capabilities of various types of rockets and sails, Millis considers the prerequisites for space drive science. A “space drive” is a hypothetical propulsion system which apparently violates Newton’s third law of motion; it propels the ship forward without chucking stuff out of the back. Well, scientists are somewhat reluctant to throw out Newton III, so in fact we’re really talking about interactions with stuff such as space itself. This is one of the first ideas considered in FOPS that is truly speculative. We truly do not know whether this kind of drive is possible at all. Among the methods considered are: pushing on something in space, such as dark energy, dark matter or quantum vacuum fluctuations. Other ideas include inertial modification, somehow reducing the inertial mass of the ship, and field drives, exploiting properties of the gravitational field to propel the ship.

Eric Davis considers the possibility of manipulating the gravitational field. (The physical possibility, remember; we are constantly reminded throughout the book that engineering is a different game.) It appears that there are a large number of different techniques being considered for achieving this manipulation and creating antigravity. If this were simply a numbers game, one of these would be bound to work! Unfortunately, nature is not that kind to us.

Millis reminds us of some mechanical “antigravity” devices that have been proposed over the years. You may have seen such systems which are generally composed of gyroscopes on rods which are swung about in various fashions. If you’ve played with a decent sized gyro for a while, you’ll appreciate how easy it is to convince yourself that an antigravity drive can’t be too hard to build. It really does feel like there’s some strange force which could be exploited here. Alas, gyros do not violate Newton’s laws. In fact, we can explain how they work by using Newton. Millis takes us through a variety of such devices and explains why they don’t actually do what the inventors think they are doing. Lest you worry that null chapters are a waste of space, the point here is to show the kinds of errors that are easy to fall into, and how to avoid these traps.

Other chapters provide background of further technologies that have not demonstrated positive results, but continue to be promoted by some as potential propulsion devices. These include Yamishita’s electrogravitational machine, which was supposed to decrease in weight when activated, and the asymmetric capacitor thrusters of Biefeld and Brown.

G. Jordan Maclay’s chapter on Thrusting Against the Quantum Vacuum gives us our first major introduction to the Casimir effect. Maclay explains the theoretical possibility of pushing against the quantum vacuum using vibrating mirrors. Yes, it turns out that the force produced is truly pitiful, but a lot of the techniques in the speculative category are like this. We may yet find ways to increase the thrust by orders of magnitude to make it genuinely useful.

Jean-Luc Cambier introduces Stochastic Electrodynamics, and the idea that we might be able to manipulate inertial mass by manipulating the zero point field.

Eric Davis leaps into the really speculative stuff when he talks about Faster-than-Light Approaches in General Relativity. These ideas have become quite well known over the years with the popularity of Thorne’s wormholes and Alcubierre’s warp bubble. It seems that Einstein’s general theory of relativity does allow for these strange solutions that permit rapid transit faster than light. We have to be careful what we mean by “faster than light”, however. With these techniques, the ship is always moving at sub-light speed in its local frame. We are just exploiting some strange effects, such as dragging the frame along with us (in the case of the warp bubble) or taking a short cut (in the case of the wormhole). The net result is that the ship arrives at the destination sooner than a light beam travelling through normal space. Although these constructs are compatible with general relativity, we don’t know whether they are possible in reality. Firstly, we haven’t unified general relativity with quantum mechanics yet; such a unification may help or hinder us, depending on the details. Secondly, these constructs seem to demand use of “exotic” stuff, such as negative energy. Thirdly, according to Einstein’s special relativity, faster than light travel can be used effectively as a time machine, allowing violations of causality. Some loopholes are presented in FOPS, but I find them somewhat unconvincing at this stage. Right now, I think that physics will either allow the existence of time machines, or it will not allow faster than light travel. Of course, developments in physics are welcome to change my mind!

Energy sources are a major concern for any starship. Gary Bennett considers the more conventional power plants, such as radioisotope thermoelectric generators and fusion systems. Davis and H. Puthoff look at methods for extracting energy from the vacuum itself, using our old friend the Casimir effect.

Claudio Maccone (of whom I’ll write more at a future date) presents a chapter on the computational tools for performing general relativity calculations. He also introduces a set of well-thought out conventions that should be adopted by all propulsion researchers so that they are all talking the same language. This covers such aspects as the units of measurement, and sign convention for the metric.

Finally, Millis presents his chapter on Prioritizing Pioneering Research, borne of his experience in the Breakthrough Propulsion Physics Project. He covers important topics such as how breakthroughs happen, how we can prioritize our work to encourage “vision with rigor”, and what criteria should be used in the evaluation of projects.

FOPS is a fascinating book covering a vast range of topics. It is definitely the book to read for anyone embarking on research in the exciting field of interstellar propulsion.

As the description on the page says:

Ever wanted to get a real understanding of how RFID works? In this workshop, you’ll learn about the different classes of RFID devices. We’ll discuss what RFID can and can’t do, what devices are already on the market, and what kinds of future applications are possible. Then, using your own RFID reader and an Arduino microcontroller, you’ll learn how to move data from the tag to the screen to the database. You’ll learn how to read to and write from tags, and how creative thinking about RFID reader antennas can lead to all new devices.

And that’s exactly what we did.

The first task was to assemble the RFID read/write module and antenna on the breadboard.

With this circuit connected to the computer via a USB cable, it was possible to read a MIFARE RFID tag.

The next step was to write to the tag, and read the information back.

The next (slightly more tricky) task was to use a Mini Arduino board to host a small application that could read the RFID tag. The point of this is that the circuit then becomes independent from the computer; you can make a self-contained box that can read tags.

I chose the lazy method of just moving a few wires, while leaving the bulk of the circuit where it was, and adding the Arduino board below the RFID module.

Uploading the application to the Arduino was fairly simple. The GUI app running on the laptop (in Processing) simply takes the tag id, and looks it up in the ETech profile database. (The tag was associated with my profile during  conference registration.)

(I’m skipping over the problem caused by the fact that I hadn’t uploaded a photo to my profile page, and the GUI app didn’t handle this. A quick commenting-out of the relevant code fixed the problem.)

And here it is. The Arduino board is running an app that grabs the tag id. This is passed to the GUI app that then looks up the associated ETech profile and displays it.

This was a good fun workshop which served as a great introduction to both RFID and Arduino.

The code and circuits for this project are available at Tom’s site.

More on the same tutorial from The Daily ACK.

L=50 in Roman. The best tweet containing exactly 50 Ls will win. All tweets to contain the tag #L and none to exceed 140 character limit SF

Well, this sounded like fun! I decided to have a go.

A tweet containing “#L” has only 137 characters left for actual text, as there needs to be a space (or some other punctuation) after the “#L”. 50 Ls is a lot to get into that small amount of space in English.

I decided to use Python to help out.

First of all, I defined a function called L-density. This is the ratio of the number of Ls to the number of characters. To make the numbers easier to deal with (i.e. > 1) I inverted the definition so L-density becomes the ratio of the number of characters to the number of Ls. (Technically, I suppose it should be called L-sparseness, but that sounds ugly.)

The L-density required for the whole message is 137/50 = 2.74.

The L-density can also be applied to each word in the message. We want to choose words which ideally have an L-density < 2.74. In fact, as low as possible, so we can use the odd filler word (e.g. and, if, or) or bit of punctuation which uses up much needed space for Ls.

As each word requires a space or punctuation separator from the next word, we need to add one to the letter count of the word to get a useful measure of L-density. So the L-density of a word is defined as (number of characters + 1) / (number of Ls).

I wanted all English words with an L-density <= 2.74.

I grabbed a list of English words, and removed all words that do not contain ‘L’ at all.

Then I wrote a little Python script to calculate the L-density for each word, and output a list of the words in L-density order (starting with the most L-heavy words). It doesn’t bother printing out any word with an L-density > 2.74.

import sys
def sortfunc(a,b):
  if words[a] < words[b]:
    return -1
  elif words[a] > words[b]:
    return 1
  else:
    return 0
f = open('w.txt','r')
file = f.readlines()
words={}
for line in file:
  line=line.rstrip()
  length=len(line)+1 # +1 to account for space between words; short words are less use to us
  lcount=line.count('L')
  ldensity=1.0*length/lcount
  if ldensity <= 2.74:
    words[line] = ldensity
keys=words.keys()
keys.sort(sortfunc)
last=0
for key in keys:
  if words[key]<>last:
    print '-------------------------'
    last=words[key]
  print key

I ran this script on w.txt (my list of English words), and the output was:

LILL
LULL
LALL
LOLL
————————-
LULLS
LALLS
ILL
LILLS
ELL
ALL
ALLYL
LOLLS
LOLLY
ALLEL
————————-
BELLPULL
PELLMELL
LOBLOLLY
————————-
TALLOL
HALLAL

[etc.]

The horizontal lines separate batches of words with the same L-density.

The most L-heavy words are at the top of the list, so it makes sense to pick words from there if possible.

Now I needed a way to quickly check my composition as I wrote it. Another Python script came to the rescue:

import sys
f = open('try','r')
file = f.readlines()
for line in file:
  length=len(line)
  lcount=line.count('L') +line.count('l')
  print 'L count =',lcount
  print 'Length =',length
  print 'L-density =',1.0*length/lcount

All I had to to was open a text file called ‘try’, and check it by running this script whenever I wanted to see how I was doing. I was aiming for an L-count of 50, a length <= 137. While building up the composition, I had to aim to keep the L-density < 2.74, otherwise the first part would be L-sparse and I’d need to pick particularly L-dense words in the later part to make up the average.

This made the whole job a lot easier, as I could concentrate on picking the right words, and trying to weave a simplistic (but vaguely sensible) narrative into an SMS sized message.

I’m not claiming great literary merit for this, by the way. I’m better at code than I am at English composition (even bizarrely limited English composition). But it was fun creating simple tools to aid in the quest.

And here’s the result. Let’s see what Mr Fry thinks!

#L Lola hillbilly lolls @ mall mulls Lulu doll: fulfill illegally! Lull Jill 2 alley; kill Jill! Lily sell doll 2 Lola 4 Jill’s lolly. Gall!

UPDATE 2009-02-02: What fun! My entry didn’t win, but Stephen did call me ’smart’ when he saw this. (Contrary to popular belief, this was not shortly followed by the word ‘arse’.) The actual winner was rather good, though my favorite was the second place by @fiskerton:

Tetris v0.1 proved too easy: L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L

Recent events such as the Mediterranean cable cuts of December 2008 remind us that although the principle is true, in reality large sections of the net are actually connected to the other parts of the world by a small number of links, rather than a widespread grid of connections. These links are vulnerable, and just a few breaks can seriously impact connectivity in these regions. In his article It’s 2008 – Do You Know Where Your Internet Cables Are? (concerning a similar event earlier in the year) Alistair Croll explains the problem of having two key cables very close together, so both can easily be damaged by the same cause, whether because of a malicious act or by accident.

So while the internet is able to recover in a reasonable period of time after damage to the routers, it is more susceptible to the cutting of the links between the routers. Satellite links can take up some of the slack, but bandwidth is limited.

Thus the idea that the internet is resilient to damage is at least partially a myth. This concept is explored in Neal Stephenson’s novel Cryptonomicon, where the connectivity of undersea cables carrying internet traffic plays a key role in the plot.

As Croll says

The fact that these two cables — which are supposed to provide redundancy — were so close together should be cause for alarm. When companies build data centers, they go to great lengths to ensure that power supply into the data center comes from multiple directions in order to avoid interruptions. But geographic and technical constraints mean some places are particularly crowded, much like modern versions of the Suez and Panama canals. And with this concentration comes vulnerability.

While we may be able to make numerous improvements in the underlying internet protocols, the reality is that the internet is vulnerable to physical problems. There are some enhancements that could be made to the net that would alleviate these problems to some extent; more distributed caching of content around the world would mean that sites, or more importantly media, would still be accessible even though the ‘real’ site is unreachable. A ‘grid’ approach to media delivery is becoming popular, as content providers are reducing the demands on their own servers (and their links) by getting consumers to share the burden of transmitting files to other consumers, in a peer-to-peer system. These grids were not designed to make the internet as a whole more resilient, but it doesn’t take an enormous leap of imagination to see how an extension of the idea could have this effect.

Ultimately, the best way to get internet resilience is link redundancy. Lots of cables, lots of different links, all going via different physical routes, creating a more mesh-like network which can tolerate breaks.

I now have SETI@Home running on Ubuntu on my Dell XPS m1330. It’s not particularly difficult to set up, but if you want to try it yourself you may find these steps useful.

Ensure that you have the latest NVIDIA drivers installed.

sudo apt-get install envyng-core envyng-gtk envyng-qt

Then run Applications – System Tools – EnvyNG; install the latest NVIDIA drivers.

Download the latest BOINC Linux installation. (Note that at the time I tried it, the BOINC package available from the Ubuntu repos was very out of date, and did not support CUDA. If you have an old version installed, ensure that it is not running, otherwise the new installation will just attach to it. I uninstalled my old version just to be sure.)

When you have downloaded the BOINC client package, execute it. (You may have to ‘chmod +x’ it first.)

A directory called ‘BOINC’ will be created. Move this directory to a suitable location.

Then simply execute the run_manager script. It will take you through the process of attaching to your existing project settings, or setting up a new account.

In the BOINC Manager client, go to the Advanced view. In the Messages tab, you should see a couple of lines saying something like this:

CUDA devices found
Coprocessor: GeForce 8400M GS(1)

This means that the GPU has been found and will be used for processing the SETI@Home work units.

You should see some speed improvement as the GPU is contributing to the computation.

I’ve had good experiences and bad with WinMo over the years. On the good side, WinMo is very configurable and hackable. There are whole suites of packages available for tweaking your device to behave exactly the way you want it to. If the built-in config options are not enough, then the registry can be edited (at your risk!) to alter some of the hidden settings.

Unfortunately WinMo has let me down just too many times with crapness. To be fair, some of this isn’t purely the fault of the OS itself; the equipment manufacturers are also at fault.

Screen locking

I find it hard to believe that WinMo device designers actually use their products outside the lab. If they did, they would almost certainly notice a big problem with the way that screen locking is handled. (In this case, I’m talking only about Windows Mobile Professional, the touchscreen version.)

Basically, the screen locking design is completely broken in almost every WinMoPro device I’ve seen. I believe there are some simple rules that should be followed to ensure that screen locking works properly.

1. When the screen locks, it really locks. Completely. Totally. Don’t allow some functions to bypass the lock for convenience. For example, when an alarm rings, or there’s an incoming phone call, don’t allow the event to be processed (e.g. alarm dismissed, call answered or dropped) just by touching an area of the screen. Force the user to unlock the screen first in some way. Otherwise if the phone is in a pocket, or some container where it is getting brushed, nasty things can happen due to inadvertent button ‘pushes’. I’ve accidentally answered (or dropped) several calls in my pocket because of this, even though the screen has been nominally locked.

The unlock procedure can be screen-based. On the iPhone, you have to slide a button on the screen to unlock the device or answer a call. That’s fine because it’s an action that is very unlikely to occur due to random presses in your pocket.

(There is a third-party app for WinMoPro called S2U2 (“Slide To Unlock”) that does a similar job to this, but I find that it causes too much drain on the battery.)

The Asus P750, for all its faults, went part-way to solving this problem. It has a hardware screen lock; an actual physical toggle switch at the side that locks the screen and all the buttons. It does work well, but it is still a bit of an inconvenience to have to remember to lock the device manually when putting it in a pocket. Really, the lock should be activated automatically when the device is idle. Still, it’s better than nothing.

2. If the screen is locked, don’t allow random touches to keep it awake. Alarms and incoming calls can cause the device to wake up, leaving the touchscreen activated. If there’s a proper lock in place, at least the event won’t be processed accidentally. However, even if an inactivity timeout is set so that after (say) 30 seconds of no touches the device turns off again, random touches can keep the device awake forever – or at least until the battery is exhausted. Several times I’ve come back from lunch to discover that right at the start of my meal an alarm has rung, and my pocket has kept the device awake for the entire duration of lunch. I then have significantly less battery available for the rest of the day.

The way I think it should work is this: when the device wakes up and presents the user with some means to unlock the screen (sliding a control or pushing a couple of buttons in a particular order), start the inactivity timeout clock right away. Don’t reset the clock at all! If the user doesn’t unlock the screen within the timeout period, then suspend the device again. A timeout of 10 seconds would probably be enough. If they haven’t unlocked it within that time, then they probably don’t intend to.

Alarms

WinMo has had a problem with alarms for many years. For some reason, it is a bit unreliable at actually waking up when an alarm has been set. Most of the time it does work, but just occasionally it doesn’t.

I was amazed to discover that even in the latest WinMo edition (6.1, Pro and Standard) alarms are still not totally reliable. This really isn’t acceptable. Even a cheap Casio watch can get this right. I expect a several-hundred dollar phone to be able to wake up when I tell it to.

Email bug

WinMo 6.1 has a problem with sending emails. Briefly, if it ever is unable to connect to the specified SMTP server, then it will attempt to use the SMTP server of the network operator instead. If the operator has not specified an SMTP server then the email account settings are corrupted. Permanently. You can not send emails from that account on the phone again, unless you totally delete the account and create it again from scratch.

Microsoft eventually issued a ‘fix‘ for this problem. Which doesn’t work. After installing this fix, the problem was occurring just as often as before.

The email bug was the last straw. It happened one time too many, and I had a couple of days where I was hit by all of these problems in quick succession. That tipped me over the edge, and I immediately bought an iPhone.