My Netbook runneth over; dual booting Ubuntu on the Eee 1000HA

I have recently acquired one of the newly popular netbook machines, an Asus Eee 1000HA. This is one of a startling variety of Asus Eee models which seem to be being turned out as quickly as Asus can come up with new arrangements of netbook components. This particular version has a 10″ screen, 1G of RAM and a 160G hard drive. It comes with Windows XP.

Windows XP is all very well, but I wanted to try running Linux on the Eee as well. 160G of hard drive is more than enough to run two different operating systems, so why not? There are several Linux distributions specifically designed for the Eee, so this should be easy, you might think. As it turns out, its not completely straightforward. Hence this post.

Installation

The first hurdle you encounter is that the Eee doesn’t have an optical drive, so there is no way to burn a CD and boot from it, which is the usual way to install Linux. The 1000HA does however have USB ports and an SD card slot. It turns out it is capable of booting from either a USB flash drive or an SD card; I happened to have an 4Gbyte SDHC card which I acquired for backup already in the SD slot. I decided to install the aptly-named Eeebuntu 2.0 Standard distribution via this card.

So, under Windows, it was simply a matter of downloading the eebuntu-2.0-standard.iso file (880Mbyte). The .iso file is an archive file containing a bootable disk image, so you can’t just copy it onto the SD card and expect it to boot. An application called UNetbootin is needed to unpack it onto the SD card correctly; I downloaded unetbootin-windows-312.exe and ran it. UNetbootin presents a single window where you can select Diskimage format, and browse to select the eebuntu .iso file. The SD card appears as a USB drive at letter I:\ (UNetbootin is clever enough to preselect this for you). Clicking on OK sets UNetbootin running copying the .iso across to the SD card, which takes several minutes and may appear to hang at the extra-large filesystem.squashfs file.

Once this process completes, click on the ‘Reboot Now’ option that UNetbootin conveniently presents and as soon as Windows has shut down, hold down the ESC key. As the Eee starts up it should bring up the boot device menu. The SD card is described rather misleadingly as “USB:Single Flash Reader”. Select this and the UNetbootin menu will follow. Select ‘Default’, or wait for it select itself for you, and the Eeebuntu splash screen should follow. After a moment or so the Eeebuntu desktop comes up with the ‘Install’ icon at the top left. Opening this starts the installer. This asks some straightforward questions up to the point where it asks how to partition the disk.

Here we need to be a bit careful, because the disk layout is not quite what the installer expects. Asus for some reason divides the disk into three usable partitions; the first 80Gbyte partition contains Windows XP and all its associated files. The second is also formatted for Windows, but is empty and appears under XP as the D: drive. The third is a recovery partition for booting from when Windows borks itself as it sometimes does. The installer will default to resizing the first Windows partition to 17.5Gbyte and installing Eeebuntu in the remaining space. This is workable, but not very even-handed. I prefer to install Eeebuntu over the unused second Windows partition. To do this — assuming that your D: drive under XP is empty —  select the Manual option and click Forward.

In the next dialog, select the second partition (/dev/sda2, about 65711Mbyte) and click on ‘Delete partition’. This is necessary because the partition is formatted for NTFS, which Ubuntu can’t install to. You will also need a swap partition, and we must make space for that.  Select the resulting free space and click ‘New partition’. Make a logical swap area partition that is larger than your RAM size (1024Mbyte in my case) I used a rather arbitrary 3000 Mbyte. Then make a logical ext3 partition with a mount point of ‘/’ covering the remaining 62709 Mbytes. These should be /dev/sda5 and /dev/sda6. Select the format checkbox for the ext3 partition. Click Forward only after checking the above carefully as a mistake here could ruin your Windows install.

After answering a few more questions the install should run smoothly. On restarting (you can ignore the instruction to remove the nonexistent disc and close the nonexistent tray and just hit Enter) the Eee should display the Grub boot menu that allows you to select Ubuntu (or just wait and it will default to Ubuntu itself)

Assorted fixes

All is not completely plain sailing with Eeebuntu from the start, however.

Your first stop should be to plug into a wired LAN with Internet access and run the Update Manager. This will offer to do a bunch of updates (151 when I tried). For some reason it will complain that these can’t be authenticated when you click on Apply; you have to ignore this and apply anyway. Restart.

Under Applications/System Tools you will find an application called Eeebuntu Config. You should run it. It doesn’t have a setting for the Eee 1000HA (or it didn’t when I tried, you might get an updated version) I selected the 1000H, clicked on ALL and Execute. This runs a bunch of scripts that should customise Ubuntu better for the Eee.

If you start Firefox you may be startled by a license agreement for an add-on called DownThemAll, which you have to accept as it comes up again and again if you try to decline it. This was mistakenly added to Eeebuntu when it was built. You can remove it by accepting the license agreement, then clicking Disable and Restart Firefox in the Add-ons window that comes up when you do so.

The grub boot menu can be made friendlier (and you can pick what it defaults to and when) by editing /boot/grub/menu.lst. This needs to be done with supervisor privileges; I started a terminal session and entered ’sudo gedit /boot/grub/menu.lst’ which gives you a nice visual editor. The file is reasonable self-explanatory.

The mouse pointer when busy is for some reason a rather ugly monochrome wristwatch instead of the normal Ubuntu rotating pattern. I haven’t been able to figure out why so far.

Wireless performance is, irritatingly enough, not very good. Signal strengths are lower and performance is spottier than Windows XP, by a considerable margin. You might wonder how such a thing is possible. It turns out to be because the open-source ath5k drivers for the onboard 802.11 wireless card don’t work very well – Atheros, who make the wireless chip, don’t distribute detailed information about it, or driver source code. So the open-source driver has been written in the dark, as it were, and its a wonder that it works at all. There is actually an end-user solution to this which involves using a tool called ndiswrapper to run the XP drivers inside Linux. But getting that working is another story…

A Battery-powered Time-Lapse Camera

Introduction

The time-lapse camera system described in my earlier post is fine where mains power is available, but for remote locations and longer durations it rather falls down. At 5-6W power consumption it will flatten even a large wet-cell lead-acid battery in 3-4 days. Taking pictures less frequently does little to reduce the power consumption as the camera and NSLU2 run all the time.

Unless we turn the system off — or rather, get it to turn itself off. The NSLU2 has an onboard power supply switch controlled by a separate piece of circuitry that turns power on to the main processor when the power button is pressed. The power button cannot, however, turn the switch off. Instead the switch is designed so that the processor itself has to commit electronic suicide and turn its own power off by sending a signal to the switch. In the ‘off’ state — which as you can see, isn’t really off — only the power switch circuitry uses power, and it uses very little, only 1.3mA. The main processor and anything connected to the USB ports are simply disconnected from the supply voltage. So turning the power off is easy – OpenWRT provides the poweroff command, which does just what it says. The question then becomes, how do we turn the power back on at regular intervals?

A hardware modification

The NSLU2 has an X1205 real-time clock chip that keeps the time and date. It runs continuously, even when the power supply is physically unplugged – that is its 3V battery in the middle of the board. This chip has an alarm facility; it has a pin that can be programmed to send an interrupt signal to the main processor at a specific time and date, up to a year ahead. On the NSLU2 board, this interrupt signal pin is not connected to anything. If we connect it to ‘on’ input of the power supply switch, the X1205 can turn the NSLU2 on when the alarm time is reached. This turns out to be a fairly simple hardware mod. A wire connecting pin 3 of the X1205 to the U15 side of R94 will do the job. The wire has to run from one side of the board to the other, and requires a fine-tipped soldering iron as R94 and the X1205 are both surface mount devices. The photographs below show where it goes.

Software changes

Having added this wire, all we need is some software to set the alarm time and all sorts of interesting possibilities appear. The software turned out to be a little more complicated than I had expected, as it turned out that the low-level Linux driver for the X1205 wasn’t quite working properly. It didn’t correctly set the alarm values or provide a way to enable the interrupt pin. Nor, having fixed the driver, is there a standard Linux tool for setting up the alarm in the way we need. Fortunately there is a program out there called rtcwake that does nearly the job we want, and I was able to modify it to make a similar program I have called rtcalarm.

With rtcalarm, the fixed driver, and the wire in place, we can now have the NSLU2 turn on, take a single photo, and turn itself off again at any interval. Well, almost any interval. It takes a little over a minute to start up, so the smallest sensible interval would be longer than that, say 90 seconds. The longer the interval, the lower the power consumption.

There was one small remaining problem with this setup. When the time came to make a movie out of the contents of the flash drive, the file renaming strategy described in my earlier post on time-lapse cameras no longer worked. Now the serial number part of the filename is always 000000000, because MJPG-streamer is being restarted every time. The solution to this was to make a small change to the output_file plugin of MJPG-streamer to omit the serial number and the underscore characters separating the time fields. The file names now have the form yyyyymmddmmhhss.jpg. This makes converting them to movies with QuickTime Pro straightforward – no file name changes are required.

The end result: a power-cycling time-lapse camera

An OpenWRT firmware build with the rtcalarm tool and the driver patch, openwrt-nslu2-uvc-webcam3.bin is available here. It provides the same three modes as the build described in A MegaPixel Time-Lapse Camera System – webcam, dual webcam, and time-lapse. In time-lapse mode, however, it now requires the hardware mod, and takes pictures every six minutes, turning itself off for five minutes out of six.

The net power consumption of the new time-lapse mode is a little tricky to work out, as the camera only starts using power quite late in the boot-photograph-shutdown cycle, so the full 1100mA is only used for about ten seconds at the end. I used a data acquisition system to monitor the current draw at 5V over a single photo cycle, and it looks like this:

This shows that it takes 47.6 A/secs to take a photo, if I can be excused for employing such units. The profile above is for a unit not connected to Ethernet. With Ethernet, power use is slightly higher but the cycle runs some ten seconds shorter and uses 44.6 A/secs. At 5V thats 238W/secs per photo with no network. With these figures in hand, we can estimate how many photos we can get from a battery. For example, a 12V 7AH gel cell running the NSLU2 through my switching voltage regulator contains 12×7 = 84W/hours. If the regulator is 88% efficient we get 73.9W/hours delivered to the NSLU2, which is 266112W/secs and therefore about 1118 photos. This number is largely independent of the interval between photos, because the power consumption of the NSLU2 while off is so low.

Internal details

This build is based on a later version of the OpenWRT trunk, revision 11566. It has a later version (r63) of the MJPG-streamer software, which has some bug fixes and should behave better when streaming to a web browser. I had to apply a patch I found here to the /sbin/usb-storage script to get the flash drive to mount correctly at power-on. As usual, most of the controlling code is in /etc/init.d/done. The only exception is the script at /root/whoa which sets the RTC alarm and turns the power off. If you want to change the number of seconds between pictures, edit the rtcalarm command in this script. The /root/whoa script is called by the MJPG-streamer output_file plugin via the -c option

The source for the rtcalarm tool can be found here, along with the patched rtc-x1205.c driver and the other patches.

An Efficient Voltage Regulator

Voltage regulators are circuits for converting one DC voltage to another, and these days they are pretty easy to make. There are a wide variety of integrated circuits that make the job very simple. In this case, I wanted to run the NSLU2/QuickCam combination that I have been posting about from a 12V battery. It draws somewhere in the range of 600-1100mA, depending on whether or not the camera is running, so I need something that can convert an input that could be up to 15V (if the battery is being charged at the time), down to 5V, at up to 1.2A.

A Megapixel Time-lapse Camera System

Introduction
The NSLU2 running OpenWRT and the QuickCam Pro 9000 combine to make a very versatile device. In this post I’m going to describe how to use them as a time-lapse camera which takes photos every ten seconds at 1600×1200 resolution and stores them on a flash drive. The photos occupy anywhere from 80K to 400K each depending on the complexity of the scene. This means that around 10,000 to 15,000 will fit on a 4GByte flash drive, corresponding to 20-40 hours of coverage. All that is required is an NSLU2, a UVC-compatible webcam, a flash drive, and an OpenWRT firmware build, which is available here. A brief sample movie (30 seconds, 8.5Mbytes, DivX) is available here.

Further notes on the NSLU2 and QuickCam Pro 9000

I have been playing around with the webcam firmware that was the subject of my last post and have a number of random notes that I should put up here on using it.

A High-Resolution IP Webcam

Web cams are fairly ubiquitous things these days and by no means expensive. They can be good or bad depending on how much money you want to spend, but there is one almost-universal rule, which is that they connect to a host PC over USB. IP-based cameras that connect to a LAN via an RJ45 connector or wirelessly over 802.11 are quite a bit more useful, because they can be put almost anywhere, but they tend to cost a surprising amount and not provide much resolution. A low-end one like the LevelOne FCS1030 is NZ$260, and they go a lot more expensive than that. For example, the wireless D-Link DCS5300 sells for NZ$930 and it only does 320×240 pixels.

A Proportional 12V Fan Controller

The Ubuntu machine covered in my previous post lives in a cupboard with a wireless router and a DSL modem. Its not a very big cupboard, and… it gets rather warm in there. Even though the computer doesn’t use a lot of power, the heat doesn’t have anywhere much to go. Thats not good for longevity or reliability. I made a couple of 100mm diameter vents of the kind you use to vent clothes dryers, high and low, from the back of the cupboard into an adjacent storage room, but convection just didn’t seem to be doing enough, especially on warm days.

The answer was, of course, to add a fan.

Ubuntu! Part Two: The Gathering

Apt makes adding things to an Ubuntu install very easy. Almost too easy.

Ubuntu! Its fun to say!

We have a fairly standard home networking setup – a DSL modem, a wireless router, and a hub distributing 100BaseT to some RJ-45 sockets scattered about the house. The modem and the router both have firewalls and web interfaces to them, but neither of them are very versatile. For example, one thing they can’t do is log traffic on a per-IP basis, so when we start using 500Mbytes/day they can’t tell me which machine in the house it is coming from. We have a bandwidth cap, above which our ISP chops us back to 64Kbits up and down, so that can be important. Nor can the DSL modem firewall send mail to me logging firewall rejects, so sometimes when something doesn’t work it can be difficult to tell whether its the PC, the firewall, or something broken in the outside world. A proper firewall can do all these things and a lot more, as I know from running an OpenBSD-based firewall for my employer for the last ten years. And the firewalls in DSL modems don’t have such a great reputation for security. Holes have been found in some. Our modem has an additional peculiarity; it insists on running a DNS cache and providing its own address as a DNS server to local machines. Unfortunately the cache isn’t all that great and falls over every two or three days. The only solution is to turn the modem off and on, which is a bit vexing.

So that was one reason to look at installing a separate stand-alone machine to act as a firewall.

Ripple control noise suppressor

Ripple control is a technique used by electricity companies to control loads. Its rather primitive, but that’s because it dates back to Before Computers, and its still done today with ingenious electromechanical hardware. The idea is that the electricity company can reduce peak loads by broadcasting signals over the mains wiring, that switch off consumer’s appliances. This may sound like a Bad Idea – why would anyone agree to it? But there are some sorts of quite substantial loads which can be switched on or off by the electricity company without causing any grief, the prime example being household water heating. The thermal mass and insulation of your hot water cylinder mean that it doesn’t matter if the power is switched off to it for an hour or so. So all hot water cylinders are required to be on a seperate ripple-controlled circuit, which is what one of those mysterious boxes in your household fuse box is doing. And every day, the electricity company sends out signals to turn it on and off. They also send out different signals to turn on or off various industrial loads, street lighting, and so on.