Why won’t it work?
I stare at the screen
of the hateful machine

I check all the details
in the documentation
While the error prevails
with my growing frustration

I stare at the screen
of the hateful machine
Why won’t it work?

I read through the code
Line after line
Will it explode?
It all looks fine

Why won’t it work?

Can this not be solved by logic
Rather than a gin and tonic?

I go for a walk
to clear my head
I wonder which detail
I could have misread

Why won’t it work?

I don’t believe it
I try it once more
The testing reveals
That it’s broken for sure

I stare at the screen
of the hateful machine
Why won’t it work?

After hours and hours
using all of my powers
I can prove that nothing is wrong
Why won’t it work?

My eyes are red
It’s time for bed
I take a break
And eat some bread

I stare at the screen
of the hateful machine
Why won’t it work?

My ideas exhausted
I ask for assistance
This has to be better
than endless persistence

I explain the problem
from the beginning
My head is spinning
He listens

Words pass my mouth
at such a pace
Desperately trying
not to lose face

As I realise that something
just isn’t quite right
I dig a bit deeper
Because this just might

Be the answer, the light
The end of the fight
With wishful delight
I forsee
the end of the night

I fix and I test
and, embarrassed, I jest
that a schoolboy would make
this sort of mistake

But it works now
<yawn>
I’m going to bed
In the morning once more
I’ll be using my head

I’ll write the next feature
And pray the next bug,
That most nasty creature,
Won’t be so smug

I dream:
“Why won’t it work?”

So I wrote a script to log in on my behalf. While it’s logged in, it may as well do something useful, so it downloads the PDF versions of my bills, skipping bills which it has already downloaded.

It’s in perl and uses WWW::Mechanize to do most of the work.

You can pull the source code using monotone from mtn.coolfactor.org (branch org.coolfactor.scraping.orange) or you can browse it here.

The parts required are:

* A laser
* A beam splitter
* Two mirrors
* Lenses for magnification
* Miscellaneous bits and pieces for mounting/alignment

I had with me a (very) cheap laser pointer. Sellotape kept the button held down so that the laser would stay on, and it rested comfortably upon a Greg Egan novel.

For a beam splitter, I eventually managed to find a CD jewel case. Hardly great optics, but it did split the beam.

I tried using CDs for mirrors initially until somebody managed to find a couple of hard drive platters. CDs are effective mirrors in a way, but the hard drive platters are far better for this.

There was a nearby drawer containing chunky electrolytic capacitors which made ideal objects to make stands out of. Sellotape and Blu-tack made it fairly easy to stand one of the mirrors up, and Blu-tack and a Helping Hand borrowed from the soldering station held the other mirror in such a way that it was possible to make fine adjustments to it.

The magnifying glass from the Helping Hands (again mounted with Blu-tack and capacitors) diverged the beam a little bit. Because the optical components are less than ideal, it’s necessary to magnify the image of the beam in order to see interference patterns in it.

There were a couple of hemispherical lenses lying around which served to further magnify the beam. One right after the first lens (again supported with a capacitor and Blu-tack) and another one Blu-tacked on top of a pint glass projected the beam onto a make-shift screen consisting of an A3 sheet of paper stuck to a floor-standing lamp.

Without using the sorts of optics that one would expect to find in a laser optics laboratory, this was never going to be perfect, but after turning the lights off we did notice that there were in fact interference fringes visible which moved around with the (quite considerable) noise and vibration in the room.

Here’s the setup:

I found a fog machine so that I could take a photograph of the beam in the dark:

Finally, if you look carefully you can see the interference fringes here. The camera unfortunately doesn’t do a great job of picking this up. You’re looking for moving fringes (from tiny movements of the experiment) rather than the places where the whole beam moves quickly as a result of larger movements:

My latest approach has been to use a digital camera and apply computer vision techniques. To this end, I’ve been been playing with OpenCV.

Early results are encouraging. I threw together a simple 6×9 chessboard image on a piece of A4 paper and took several photographs of it. This is a pretty standard technique for camera calibration, and there seem to be a fair few examples of this around on the web. OpenCV has some nice functions to find such chessboards in images and then to use the results to estimate the camera parameters.

So I had a go. I threw my test images at it, obtained the camera parameters, and then used them to reproject an array of cubes onto the original images. I’m rather impressed by the accuracy, which is far greater than I’d imagined. Here is the result. Click for high-resolution images if you don’t mind waiting a while for them to load.

It’s a fairly old machine and as such doesn’t have SATA, but that’s not a showstopper. One PCI SATA card later, and a couple of 2TB SATA hard drives, and it’s good to go. In theory.

Except the SATA card was failing to recognise the hard drives.

I wanted to see if upgrading the BIOS in the SATA card would help, but unfortunately while I could find a newer BIOS image from the chipset manufacturer, the card manufacturer had used an unsupported flash chip and so their flash utility wouldn’t work. The card manufacturer hasn’t published their own on their website, so no go there.

I also wanted to see if upgrading the BIOS in the motherboard would help. It was hard finding a floppy disc that wasn’t unformattable due to age, and the BIOS is old enough that while it can boot from a USB floppy drive, it didn’t like the modern USB memory stick that I tried. Eventually I found a floppy that just about worked, and got the BIOS upgraded.

That didn’t help.

I then noticed that I had another machine with the exact same motherboard. I plugged the SATA card into that one, and lo and behold it recognised the drive.

I stripped the machines down to more or less the bare minimum, swapped every component I could (even down to the power supply) and still, one machine found the hard drives, and the other didn’t. After swapping the motherboards, neither worked.

Eventually, after a lot of head-scratching, I discovered the difference.

One of the machines was used as a desktop PC, and hence had a mouse plugged in.

Plugging a mouse into the server made it spring into life, and for as long as a mouse is plugged in, it reliably detects the SATA drives and boots happily.

To say that I am confused by this behaviour is an understatement. But there you have it, a mouse makes SATA go.

The motherboard in question is an ASRock K7S8X. The SATA card is a Lycom ST-125 (based on the Silicon Image 3124 chip). The drives are WD Caviar Green 2TB.

If you think you can explain this behaviour, please do leave a comment.

So as of now, my new photo gallery is available at http://www.coolfactor.org/photos/.

So I bought one.

To have a little play with it, I knocked up a simple parallel port I2C interface on some breadboard, using a bunch of random NPN transistors that I had lying around. It doesn’t help that the parallel port on my PC (like most PCs) runs at 5V and the Wii Motion Plus wants 3V3, but that’s what transistors and breadboard are for, after all.

I2C interface on breadboard

What are the LEDs for, you may ask? Well, I had to figure out which parallel port pin was hooked up to which wire somehow, didn’t I? It was easier to recycle and old cable knocked up years ago for another hack than to go out and get a new 25 pin D plug and spend time with the soldering iron.

The Wii Motion Plus is the small white thing in the background, just in front of the power supply.

So I implemented some simple I2C bitbanging code and after shaking the last of the bugs out, I was ecstatic to see some numbers coming out of it that seemed to represent the physics of what I was doing to the device.

Obviously, I couldn’t leave it at that. I wanted to know how it behaved in a slightly more complex test case. So after speeding up the I2C code a bit to get closer-to-realtime readings, I devised a cunning demonstration.

I used SDL and OpenGL to knock up a cube, rotating around its centre. Instead of various non-interactive pretty spinning things that you can do with a cube to make a demo, in this case I integrated the readings from the Wii Motion Plus to form a rotation matrix. Rotating the Wii Motion Plus causes similar rotation to apply to the cube.

After guessing at some scaling factors, I got “close enough”, and I was rather impressed with the responsiveness of it all. Other than the few times when the wires fell out while I was moving it, the system was responsive and quite intuitive. It did drift a little, as expected with a gyro and also as expected when I’m not taking samples as often as I could. I think a proper hardware or microcontroller I2C implementation would be less prone to overload and be able to integrate more accurately.

Here’s the video:

Update: You can pull the source code using monotone from mtn.coolfactor.org (branch org.coolfactor.demo.wiimotionplus), or you can browse it here.

Note: This isn’t polished code, it’s just a hack. It works for the purpose of my demo, but it may not work for yours.

As it turns out, the power supply is known to be a bit flaky. Again, dodgy electrolytic capacitors. Who’d have thought it, eh?

The challenge this time was cracking the case open. It’s a wall-wart power supply, and these things are generally glued shut from the inside. With the aid of a (very) sharp knife, I managed to cut open enough of it to stand a chance of prising the rest apart.

And lo, another popped 1000uF 10V capacitor.

NSLU2 power supply cracked open

See the bulge on the green capacitor on the far left? Exactly.

After making sure that the large 400 volt capacitor was discharged (yes, really), I replaced the popped capacitor with one I had lying around, and (very) carefully gave it a whirl. Perfect.

Since there’s another capacitor of the same type on the board, and since I didn’t use a brand new component to replace it, I didn’t really fancy sticking the thing back together with glue. But copious amounts of electrical tape should do the trick for now.

The power supply re-assembled

The slug lives.

Fortunately for me, I came across this blog post which gave a very good introduction to the concepts involved, while being down to earth enough that it didn’t require prior comprehension of monads.

Armed with this new level of understanding, I thought the best way to apply it would be to attempt an implementation of the UNIX sort program.

Now, there are plenty of noddy implementations of sort around on the web. Most of them look something like this:

main :: IO ()
main = interact (unlines . sort . lines)

This is all well and good, but actually it’s not much good for understanding I/O. It just takes a single input stream, sorts it and outputs it. The magic is all wrapped up in interact, so it’s all invisible and rather boring.

Now, real UNIX sort takes a bunch of filenames as arguments, and sorts them all into one giant output. That sounds more interesting. So let’s now have a play with Haskell’s do notation.

main :: IO ()
main = do
     x <- getArgs
     y <- mapM (readFile) x
     (putStr . unlines . sort . lines . concat) y

That's more like it. Let's take a closer look.

Essentially, each line in the do block takes values which are wrapped in a monad and passes them into the next line nicely unwrapped. So, getArgs returns type IO [String], and readFile takes FilePath, which is compatible with String. The do block does the job of extracting the [String] from IO [String].

mapM is just like map, but deals with functions returning monadic types. By the time we get to use y, it has type [String] where each string is the contents of a file.

Then we compose a function to apply to the list. I could have written the last line as putStr (unlines (sort (lines (concat y)))), but I find the brackets ugly. putStr has type String -> IO (), which takes the string we want to print and returns the IO () that Main needs.

I find this code fairly straightforward to understand (and Haskell's powerful type checker made sure that by the time it compiled it was correct) but I wanted to check my understanding of the magic of the do block by rewriting it as a one-liner.

main :: IO ()
main = getArgs >>= mapM (readFile) >>= putStr . unlines . sort . lines . concat

This is a bit harder to understand than the do block at first sight, but not immensely so once you realise the parallel. The do construct is just syntactic sugar, and this is more or less what it is translated to. For details of why, and of what >>= means, refer to the tutorial I linked to above.

It can also be written the other way round:

main :: IO ()
main = putStr . unlines . sort . lines . concat =<< mapM (readFile) =<< getArgs

I'm not sure which one is easier to read.

It's also possible to nicely separate out the monadic nastiness from the pure function dealing with strings:

main :: IO ()
main = forallfiles transform

forallfiles :: (String -> String) -> IO ()
forallfiles f = getArgs >>= mapM (readFile) >>= putStr . f . concat

transform :: String -> String
transform = (unlines . sort . lines)

While forallfiles might not be the best name in the world for this, it does at least wrap up the nastiness into a single function, leaving transform as a pure function operating on a String. Pure functions are the staple of functional programming, and it is nice to keep as much of the program pure as possible. If transform were more substantial, this would likely make the program easier to understand and to maintain.

So what about this IO () type? Well, the easiest way to think about it is as an opaque type just representing some kind of I/O. And what is I/O? Well, I/O is actually a change in the state of the outside world. It's quite easy to imagine that with putStr. The world (let's say your screen) before putStr is as it is, after putStr the screen has an extra string printed at the bottom. The change in the state of the world is the outputting of the string, and it is that change that is returned from the function.

But what about input? Well, the answer is that input is also returned in the IO () type. For example, getArgs has type IO [String]. There is no input to the function. The [String] part gets passed on to something more useful (in this case, mapM (readFile)) and the IO () part is taken care of by the monad. It is this IO () part that represents the change of state of the outside world. But what actually is this change of state? Well, in this case it's the fact that the arguments have been got. In this case it just helps with the ordering of the function evaluation by providing a data dependency that the monad can use to sequence the I/O. If we were reading a line from a file though, it could represent something more concrete like the read pointer in the file.

Ultimately though, it's not important exactly what gets wrapped up in IO (). That's why it's opaque. But every function that does any I/O at all will return that type, and the return values (ie changes in the state of the outside world) will be combined by the IO monad in the right order. What this represents is ensuring that all the I/O (and hence any computations necessary to support that I/O) is done in the right order.

Of course, it's entirely likely that there isn't any real data being passed around in IO (). The compiler is probably being clever and doing the ordering that the monad does in such a way that it's safe for functions which return IO () to have side effects, so that there is no way in which a function can have side effects without being ordered safely by the compiler. I think that's a pretty neat way of wrapping up side effects in return values, even if it's hard to understand at first.

This is by no means a formal exploration of monads or the full extent of Haskell's I/O system. There are plenty of texts covering that already. But writing this has helped me to understand it a bit better, so hopefully it will help you too.

The constantly increased temperature in the case rapidly caused the failure of a head in the hard drive. Unfortunately, I only had a partial backup of the data so I was quite keen to recover as much as possible from the failed device.

After I’d spent a few days trying to grab things with dd and friends with partial success, it became evident that it would become more and more difficult to grab more data off it as time went by. So I decided to call in the professionals.

I found a local outfit here in Peterborough called PCImage and their price was favourable compared to the competition in Cambridge and they were local, so I left my drive with them. After letting their equipment try to drag as much data off the drive as it could, they eventually took the drive apart and replaced the head stack in order to take a proper image.

They managed to produce a 100% error-free image of the drive this way, and they were very helpful indeed. And because it turned out to be easier to replace the head stack than to let the imager continue its futile effort, they were nice enough to not charge me extra for replacing the heads.

The server’s been up and running happily with a nice shiny new drive, a newer version of NetBSD and all of my data back where it should be.

Thanks, PCImage!