Over the past week I’ve been playing with some very small machines intended as sensor network nodes. Paradoxically this has involved deploying a ridiculous amount of computing power. Most of my work on sensor networks is at the level of data and sensors, not hardware. I was feeling the need to get my hands dirty, so I bought an Arduino, an open-source prototyping platform that’s actually somewhat less capable than many of the nodes we work with. They’re basically a hobbyist platform and are often looked down upon by professionals as being toys. I think these criticisms are unfair. Firstly, Arduinos massively simplify software development by abstracting-away from a lot of the complexities that simply aren’t needed in many applications. Secondly, unlike a lot of sensor network hardware, they’re mainstream and will benefit from competition, economies of scale and the like in a way that more specialised kit probably never will. Thirdly, as the centres of an ecosystem of other boards they can focus on doing one function — co-ordination — and let the daughter boards focus on their their own functions, rather than tying everything together. In some ways this makes hardware more like software, and more amenable to software-like rapid development cycles. It means that each component can move up its own learning curve independently of the others, and not hold everything back to the speed of the slowest (and often hardest-to-improve) component. That has been the unfortunate outcome several times in the past: I’m reminded strongly of the demise of the Transputer, that lost its early lead by trying to be too integrated. (That’s an interesting story for another time.) One good example of Arduino  re-use is that it can interface to Zigbee radios, specifically to Digi’s range of XBee modules. Zigbee is the latest-and-greatest short-range wireless protocol, and Arduino kit can interface directly to it rather than relying on an integrated radio sub-system. They mesh together and do all sorts of other fun stuff that’s great for sensor systems, and I’m looking forward to understanding them better, However getting XBee radios to work often involves re-flashing their firmware to make sure they take on the appropriate role in the mesh network. The tool that Digi provide to do this (unhelpfully called X-CTU)  only runs on Windows. As might not be a complete surprise, I don’t have any Windows machines. I doubt I’m unusual in this: if you’re the sort of person who’s likely to play around with hobbyist hardware, there’s a reasonable chance that you run Linux and/or Mac OS X as your main or only operating systems. So building kit for the hobby hardware market that relies on Windows-only tools is short-sighted. And unnecessary: there are plenty of cross-platform user interface tools available for C, or they could just write it in Java. By a strange quirk I also don’t have an Intel-based Linux machine at the moment, so I was left in something of a quandary as to how to run the necessary firmware tools. Solving it takes us to the other end of the performance spectrum. The solution was to run X-CTU under the Wine emulator for Linux, with the Linux in question being a Debian installation running virtualised under VirtualBox on my Macbook Air. To put it another way, I created a virtual stand-alone PC on my Mac, within which I installed Linux, which therefore thought it was running on its own separate machine, within which I installed a Windows emulation layer and ran X-CTU — all to change the firmware on a radio with significantly less computational power than a central heating thermostat. It’s things like this that make one realise how ludicrously, insanely overpowered modern computers are. The Mac can run three-layer emulations like this without any problem at all, and can still do a load of other stuff simultaneously. And it’s a laptop, and not one noted for being massively powerful by modern standards. It seems rather perverse to need to deploy this kind of power to work with such tiny machines. I think there are several lessons. Computing power really is really, really cheap — so cheap that it’s not worth worrying about it, and we haven’t come close to hitting a plateau in practical terms yet. But this just highlights that programming sensor networks requires a completely different discipline and skill-set, which may not be common in programmers of more recent vintage. If this gap is going to remain — and I think it is — it’s something we need to consider in the ways we teach computer science.