For any interested geeks in the audience, here's some more technical detail on the Chumby and my use of it as a high-tech alarm clock.

The Chumby is essentially a small ARM Linux device, with a touchscreen, speakers, two USB ports on the back, built-in wi-fi, and a couple of sillier peripherals such as a ‘squeeze sensor’ and an accelerometer. The latter two are unimpressive: when I tried the accelerometer I had to shake the thing really quite hard before it would register at all, and the squeeze sensor is just a microswitch at the top of the flexible leather case which they fondly hope will be triggered by most squeezing actions, but in fact the only way to reliably trigger it is to feel for the actual microswitch under the cover and press it.

So my first problem (well, my first after finding a UK power supply for the thing, which turned out not to be too hard) was to get it talking to my entirely wired Ethernet. I had googled up some plausible-looking instructions which involved filling one of its USB ports with a USB Ethernet dongle, and filling the other with a USB pen-drive containing an appropriate startup script to cause it to use said dongle in preference to its in-built wi-fi. Unfortunately, the instructions didn't work: it was able to send packets, but not receive them. It turns out, according to a forum post from a Chumby developer, that this is because a subsequent release of the Chumby firmware broke that mode of use. Apparently accidentally, and they claim they'll have it fixed in the next firmware release, but at least for the moment my Chumby is a wi-fi only device. Hence, my temporary solution has been to borrow a wireless access point from senji. (Rather to my surprise: I'd expected nobody would have one they weren't actually using, so I'd have to resort to spending money).

I had been able to write the bulk of my alarm clock program ahead of time, because the Chumby provides a custom Flash player and is mostly geared to running graphical applications with that; nearly all of its graphical interface is written in Flash, as far as I can tell. So I downloaded some dodgy free Flash authoring tools, hastily taught myself enough ActionScript to get by, and was able to write a working clock program in advance by testing it in a web browser; when the Chumby arrived I only needed extremely minor tweaks before it was basically working on that too.

(I found Flash pretty irritating to write. The other alternative would be to figure out how the Chumby's Flash player talks to the various hardware, and write my alarm clock as a native ARM Linux application instead of in Flash. But I'd vaguely prefer to have it in Flash for the moment, because that makes it easier for other Chumby owners to use it once I've got it finished enough to publish.)

In its standard running mode, the Chumby expects to download a collection of Flash ‘widgets’ from its home website (you can upload your own easily), and then it provides a convenient control-panel interface to switch between them. So I was vaguely hoping that I'd be able to have it run my alarm clock widget most of the time, but be able to switch to other modes on occasion.

However, there turned out to be a show-stopping problem with that: the display backlight is very bright in its default mode, and really needs to be in dimmed mode for use in a darkened bedroom. The Flash player does provide a hacky custom API for accessing Chumby-specific features like the LCD dimmer control, but that API isn't available to widgets it downloads from the web, on security grounds! This is clearly barmy: it's not a bad idea in principle to prevent web-downloaded widgets from altering your Chumby's systemwide settings, but it is thoroughly silly to consider the LCD brightness to be a systemwide setting. Rather, the LCD brightness should be considered part of the display, and widgets can control how they are displayed. In other words, any widget should be free to set its own brightness, and the setting should only last until you switch to a different widget.

The solution to this turns out to be not to run your widget as a web download. Instead, the Flash file for the widget goes on a pen drive, with (again) one of those startup scripts to activate it. Stick that in the Chumby, and when it boots up it will now be a single-function device running only my alarm clock (and an NTP client). Which is basically what I wanted, so fair enough; but it is faintly annoying that I can't also make use of all its other whizzy features if I ever happen to want them. (Or rather, I can, but only by pulling out the pen drive and rebooting.)

The final problem is the as yet unexplained glitches while playing sound. Yesterday I thought this was a frequency problem: the sound seemed higher-pitched than it should have been, and had big gaps in it, so my guess was that one piece of code was feeding sound at the correct rate to another piece of code which was playing it at twice the correct rate, leading to big gaps when the latter ran out of data and had to wait for the next block. However, after double-checking what the pitch should have been, I now no longer believe this, and my next guess is that it's a mixing confusion caused by the fact that my program is trying to start playing each alarm beep over the top of the remains of the previous one. So this evening I plan to try redesigning the alarm mechanism so that it's never playing more than one piece of sound data at a time, and see if that helps.

(I'm not helped in all this by the fact that the free Flash authoring software appears not to get sound quite right when writing out Flash files: testing on a web browser, the first second and a bit of any sound I try to play is chopped off, and I haven't yet worked out whether the same amount is lost on the Chumby. Bah.)