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…

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.

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.

The simplest way of doing this is with a linear regulator IC, and a circuit like this:

The LM317 is actually an adjustable regulator whose output voltage is defined by the two resistors. The values shown yield 5V. The trouble with this design is that although its very simple – five parts – there is another component required which isn’t shown. Its a substantial chunk of metal that has to be bolted to the LM317 to act as a heatsink. It needs to dissipate up to 12W. This really means buying the LM317K version of the regulator and using a heatsink rated at 2°C/W or better, which is going to be a chunk of finned aluminium at least 100mm long. This has to be mounted somewhere and ventilated, and the regulator has to be bolted to it with an insulating pad and isolating washers. The simple circuit has turned into a piece of engineering, and all because its only 42% efficient at 12V. More than half of the energy supplied is being turned into heat. If we are running from a battery this is not good news.

We can, however, do much better than this, by using a switching regulator IC. These used to be very tricky things to use, but modern parts have simplified the process to the point where they are relatively easy to apply. They do require some care in component selection and layout, but in return efficiencies are far higher, and no heatsink is needed. The circuit I have built is based on the National Semiconductor LM2672, and has all of nine components. It looks like this:

This design is about 88% efficient at 1A: 12V at 480mA in produces 5V at 1A out. The minimum input voltage at 1A is 7V, the maximum voltage before component changes would be advisable is 15V. The enable input can be left floating, or used to disable the regulator, if required, by pulling it down to ground. In the disabled state the regulator draws only 100μA. Enabled, but with nothing connected, the quiescent draw is 3.4mA. Again, its adjustable – the output voltage is set by R1 and R2.

I built this on a 46mm x 28mm piece of single-sided PCB material in about 30 minutes using a miniature electric hand tool to drill holes and rout channels on the copper side of the PCB. That was actually the easy part. The tricky bit is getting hold of the right components and putting them in the right places.

I think because switching regulators have had a reputation for being difficult in the past, they aren’t commonly used, so the components aren’t commonly about – so they aren’t often used, and so on. You will need to go to a larger electronics retailer to get the parts, and although none of them are particularly expensive, you will need to take care about the specifications of nearly all of them.

The LM2672N-ADJ is an 8-pin DIP package. Take care not to get the surface mount version, the LM2672M-ADJ, unless you like that kind of thing.

The 1N5822 Schottky diode is widely available in a DO27 package, but in this case you actually want the surface mount version for reasons I will explain shortly.

The 330μF (or more) input capacitor should be rated at 25V (or more) and at least 600mA ripple current. If the supplier doesn’t specify the ripple current, you should assume its not adequate. Good capacitors have a ripple current specification.

The 220μF output capacitor should be rated at 10V or more, and must be a high-frequency type with a low ESR at 100kHz. I used a Panasonic FC series part, EEUFC1A221, which manages 0.25Ω at 100kHz. The FM series are better, if you can get them.

C2 and C3 must be high-frequency ceramic types, preferably X7R. C2 can be more than 0.1μF, but C3 must be 0.01μF.

The inductor must be a type intended for use in switching power supplies, with a current rating of at least 1.4A. I used a TDK part, SLF12575T-330M3R2-PF, from RS Components. Its rated at 3.2A so was a bit of overkill and is larger than necessary. It is also surface mount which meant running a couple of wire loops through the board to solder it to, as it would have been awkward having it on the copper side.

The two resistors can be any 1/8W type.

Having got hold of the specified bits, the other critical consideration is the board layout. If this isn’t right, the regulator can be unstable in various exciting ways. Fortunately National Semiconductor have a comprehensive application note on the subject, AN-1229. Two components need to be as close as possible to the IC; the 0.1μF capacitor, C2, and the 1N5822 diode. The easiest way to achieve this is to mount the capacitor right beside pins 6 and 7, and the diode on the underside of the board right beside pins 6 and 8. The rest of the layout follows the National Semiconductor notes. Here is the back of the PCB before soldering, and the front after mounting the components.

The surface-mount 1N5822 is soldered onto the back of the board, directly under the IC, bridging the horizontal channel visible in the photo.

I have now built a couple of these and they seem to perform very well. They are probably best suited to digital circuitry as there is about 35mV of switching noise at 240kHz on the outputs, although this could presumably be filtered pretty effectively with an LC filter if it was a problem.

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.

A simple hardware mod

The first step in building this arrangement is to bypass a hardware limitation of the NSLU2. As provided, only one of the two USB ports has power. If we want to attach both a webcam and a flash drive, we need both ports to supply power. The solution is a very simple hardware mod (a single jumper) which is described here. A good description of how to open the case can be found here.

Installing the firmware

This process is described in “A High-Resolution IP Camera”, but for completeness here it is again. You will need:

1. An NSLU2
2. A host computer, best running Linux
3. The firmware image, openwrt-nslu2-uvc-webcam2.bin

You will need to run a tool called UpSlug2 to install the firmware. UpSlug2 is described here. I would recommend running it from Linux. I used my Ubuntu machine, but booting a Knoppix Live CD on a Windows machine should work fine. Under Ubuntu, getting UpSlug2 is as simple as:

apt-get install upslug2

The next step is to power-up the NSLU2 in “upgrade mode”. It should be connected to the same LAN as your Linux machine, but do not plug in the camera or flash drive at this stage. Use a straightened paper clip or other thin probe inserted in the Reset hole at the back of the NSLU2. Apply gentle pressure and the reset switch will click in. Hold it down and press the power button at the front. The Ready/Status LED will come on orange, but after nine or ten seconds will turn red. Release the reset switch as soon as this happens. The Ready/Status LED should start alternating red and green, indicating that the device is ready to upgrade. Now issue the command:

sudo upslug2 --image="openwrt-nslu2-uvc-webcam2.bin"

If all is well and UpSlug2 can find the NSLU2 you should see a nice animated summary of the upgrade process, which will take about one minute twenty seconds. When it finishes you should wait for about two more minutes for it to perform initial setup – eventually the Disk 1 and Disk 2 LEDs should go out and the Ready/Status come on red. You can then disconnect the power, plug in the webcam and the flash drive, and power it up again. After about 60 seconds the red ring light on the camera, indicating that it is recording, should come on.

Recording images

Once the firmware is installed, the NSLU2 will start recording images as soon as it has started up. The recording is done with Tom Stöveken’s versatile MJPG-streamer software. MJPG-streamer is capable of writing images to external storage at regular intervals. It names each image with a rather long but unique name of the form:

year-month-day-hour-minute-second-picture-serialnum.jpg

e.g 2008_05_11_08_38_50_picture_000000046.jpg.

The serialnum increments by 1 for each successive image. The firmware has been set up to write these files to a normal flash drive filesystem; that is, in MS-DOS or more properly FAT32 format. Its not the worlds best filesystem, but it is ubiquitous and works with almost everything. Most flash drives come formatted this way, so should work immediately. Note that the firmware does not make subdirectories; all the files are written to the top directory of the drive. There are limits to how many files can be placed in one directory like this – officially 65536 is the limit for FAT32, but I haven’t tested this and would advise caution.

The firmware makes use of the LEDs on the NSLU2 to describe its status. It will look at what resources are available when it starts up, and select one of the following four modes:

- No-camera mode. If no UVC-compatible webcam is found, the Ready/Status LED will turn red and nothing interesting will happen.

- IP-camera mode, where it streams the camera images to a web page. This is pretty much the same as the system described in my earlier post “A High-Resolution IP Camera”. The Ready/Status LED will be green and the Disk 1 LED will be on.

- Dual IP-camera mode. If it finds two cameras, it will try to stream both of them to two separate web pages. The second web page is at the same address as the first, but on port 8080. The Ready/Status LED will be green and both the Disk 1 and Disk 2 LED will come on. I haven’t actually tested this as I only have one camera.

- Time-lapse camera mode, which is the main subject of this post. In this case no web page will be available and the NSLU2 will start storing images on the flash drive every ten seconds. The Ready/Status LED will be green, the Disk 2 LED will come on, and you should see activity every ten seconds on the flash drive’s LED (if it has one).

The Ethernet LED will, in all modes, as usual, indicate whether or not the NSLU2 is connected to a LAN. In time-lapse camera mode the NSLU2 does not need to be connected to a LAN and can operate independently.

Time-lapse camera mode runs at the full 1600×1200 resolution of the camera, which is possible because we are only processing an image every ten seconds. The NSLU2 can’t cope with these images at much speed (see this post for a discussion of why). The disadvantage of the high resolution is that it can’t do a web page as well. MJPG-streamer is quite capable of doing both, but the resolution has to be reduced to 960 x 720 in JPEG mode, and as I expect the time-lapse mode to be used for unattended long-term recording, I have adopted the higher resolution.

Trouble at mill; filling up the disk

It would be nice to be able to delete the oldest images once the flash drive filled up, so that the camera could run continuously and keep only the new images. This turns out to be difficult to do. With 10,000 files on the drive, the ‘ls’ command that would find the oldest becomes glacially slow, taking over twenty minutes to complete. It also risks crashing the NSLU2. Instead, I have installed a script that checks for a nearly-full drive and issues the ‘poweroff’ command when there is only 15Mbytes free.

Viewing the images

A flash drive with 13,859 JPEGs on it is not actually a very usable thing. Even though the images are labelled with dates and times, looking through them is tedious at best. A much better way of reviewing them is to turn them into a movie. I spent some time looking for the best way to do this, and in the end discovered that Apple’s QuickTime Pro software has an “Open Image Sequence…” command that does a very good job of it indeed. Its also a good tool for viewing, single-stepping, rewinding, editing and generally working with time-lapse movies, and I can recommend it as worth the money (US$30). The only piece of trickery required is that QuickTime Pro expects to be pointed at the first file of a series of files with numerical sequence numbers for names, and the date prefixed onto the file names by MJPG-streamer confuses it. This is best dealt with by applying a shell script to strip off the date prefix. Writing one that runs at a reasonable speed and can cope with 20,000 files in one directory turned out to be a little tricky, but eventually I found the powerful incantation:

find . -name '*.jpg' -print | sed 's/.*_picture_\(.*\).jpg$/mv "&" "\1.jpg"/' | sh

This can strip paint off bargeboards at twenty metres and will convert about 12,000 filenames a minute on my Mac Mini. For ease of use under Mac OS X I have packaged it up into an AppleScript application that will convert folders of files that are dropped onto it. It is available here. Be warned that if there are multiple sequences in the folder (i.e more than one file that ends with 0000001.jpg) the earlier ones will be overwritten. Quicktime Pro also seems to object to the zero-size .jpg files that the recording process sometimes leaves at the end – you should remove these manually. To strip date prefixes under Windows, I am advised that the Cygwin environment will probably support the incantation above.

Internal details and making changes

openwrt-nslu2-uvc-webcam2.bin is a normal build of a selection of packages from OpenWRT Kamikaze taken from the current ‘trunk’, with a couple of simple shell scripts added. The main script can be found in /etc/init.d/done. Checking for “disk full” is done by a second script which can be found in /root/stopwhenfull, and the cron entry that runs it every three minutes is added to /etc/crontabs/root by the ‘done’ script. A copy of the two scripts and a list of the packages in use can be found here. You can telnet directly into the OpenWRT shell, which has no password. You should set a password and use ssh thereafter.

Many things can be changed if you log in and edit the scripts. The time between images is controlled by the -d parameter to mjpg_streamer (in milliseconds). I wouldn’t advise setting it to less than five seconds at 1600×1200 on the Pro 9000, as the NSLU2 is likely to crash. Image size is controlled by the -r parameter and image type by -y. The stopwhenfull script assumes that you won’t generate more than 5Mbytes/minute and should be adjusted if this is not the case.

The firmware does not have to write to a flash drive, but is not likely to work with a USB hard drive as they are usually formatted with NTFS or somesuch, which it does not understand. It does understand the Linux ext3 filesystem, though, which might be more suitable for larger applications anyway, as it doesn’t seem to have a limit to the number of files that can be in one directory.

The firmware includes an NTP client which will try to keep accurate time if the NSLU2 can find Internet access. As provided it will keep UTC time. If you aren’t in the Greenwich time zone you will need to add an appropriate /etc/TZ file for your timezone taken from here.

I have experimented with Samba and vsftpd with the idea of being able to look at the images on the flash drive as they are recorded over the LAN connection. Performance in both cases turns out to be somewhere between glacial and completely fossilised if there are very many files on the disk. I have left vsftpd in as it can be useful for checking that the images are OK just after startup, but I can’t recommend using it once there are more than a few hundred images. To use vsftpd you will need to login over telnet and set a root password, then use that password and the username ‘root’ to gain access over ftp. The firmware uses DHCP to obtain an IP address, as described in “A High-Resolution IP Camera”.

Limitations and improvements

The firmware as it stands has a few deficiencies which I would like to address.

- There is no way of turning the NSLU2 off, which would be a good idea, as its not really very nice to just unplug the flash drive as it runs. With any luck OpenWRT will someday get the power button working as an off switch.

- The focus controls on the QuickCam aren’t accessible in time-lapse mode. The camera can actually focus down to a few centimetres and it would be useful for studying very small slow things if the focus was available.

- A simple web page that at least gave a static image would be handy in time-lapse mode for checking the field of view.

- A better way of storing files than the present single directory would be nice, and the best way to do it would be to modify MJPG-streamer.

- Battery-driven operation is possible but a bit demanding; the combination of the NSLU2, the Quickcam Pro 9000, and a 4GByte flash drive draws 900-1100 mA at 5V while recording, which is rather a lot for batteries. I want to look into reducing this for remote recording applications.

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.

Power-on and Power off
The NSLU2 running OpenWRT has some odd characteristics. First, it will not automatically turn on when power is applied, and you can’t make it do so without modifying the hardware (see here for a lengthy discussion of how to do so). You have to press the power-on button to get it to start up. Thats true of the NSLU2 generally and not OpenWRTs fault. Second, under OpenWRT, pressing the power button again won’t turn it off. Thats something that isn’t implemented, yet, in OpenWRT. Pressing the reset button will turn it off, but thats kind of awkward. Logging in (see below) and issuing the “poweroff” command will do so too.
I’m looking into ways of reducing the boot time from the present 55 seconds from power-on to first image, but I don’t expect to get it down to less than 30 seconds.

Resolution
In my first post I skated lightly over the question of why the QuickCam is running at 960×720 if its supposed to be capable of doing 1600×1200. The answer turns out to be a bit complicated. The QuickCam can generate images in two formats, an uncompressed one known as YUY2, and a compressed form, M-JPEG. Compressing the images is quite hard work for the camera, and at the maximum resolution it simply can’t do it, either because it takes too long or it doesn’t have enough onboard RAM. And the difference in size between the compressed and uncompressed images is pretty huge, as you can see in the following table. These are all the available image formats >= 640×480 for the Pro 9000:

The problem with the YUY2 format is that its simply huge and generates 12-20 Mbytes/second. We can’t move this over 100Mbit Ethernet, which will do 10-12 MBytes/second, tops. Even if we did, browsers don’t understand it. It is possible to ask MJPG-streamer to read YUY2 and do the compression to MJPEG itself, but its hard work for the NSLU2 as well. At 1600×1200 it generates one image about every five seconds and seems to buffer about six images, so what you see is thirty seconds in the past. It also falls over with segmentation faults fairly frequently (less frequently with lower quality images). So full resolution is pretty much limited to snapshots (another subject I want to get into). The 960×720 JPEGs direct from the camera are pretty heavily compressed and the quality of the picture does suffer a bit. Less severe compression doesn’t seem to be available from the camera, but I’m hoping I can find a way of getting it.

Autofocus
The Pro 9000 has a variable focus control. This is unusual on webcams, and allows it to focus on objects as little as 4-5 cm away. The MJPG-streamer software has an option that automates focusing, but having experimented with it I have not activated it in the firmware build. The reason for this is that the default focus seems to manage perfectly well between about 30cm and infinity, and the auto-focus is a bit painful to watch. It operates by checking the sharpness of the picture every ten seconds or so. If the sharpness deteriorates, it triggers a procedure that runs through the whole range of focus settings, and then picks the sharpest one. This works, but it can take at least ten seconds, and is easily fooled by movement. Unless you need this facility, its probably best left turned off.

Note that the manual focus controls in MJPG-streamer work just fine and let you focus down to a few centimeters.

Modifying the camera

If you want to know how to take the Pro 9000 apart, mount it in a box, and do things like attach a large lens to it you can photograph, say, craters on the moon, look no further than here

Low-level firmware access
If you have some Linux experience and want to get in and add packages or change settings, you can telnet into the firmware and edit the configuration files with vi. The firmware will advise you to set a secure root password, and thereafter you will need to log in using ssh and that password (this is, incidentally, essential if you are going to make the camera visible to the Internet at all). To switch to a static IP at 192.168.1.2, for example, you would edit /etc/config/network and change the line

	option proto dhcp

to

	option proto    static

        option ipaddr   192.168.1.2

        option netmask  255.255.255.0

The startup commands that run MJPG-streamer are in /etc/init.d/done. MJPG-streamer takes the following parameters:

-i | –input “< input-plugin.so > [parameters]“
-o | –output “< output-plugin.so > [parameters]“
[-h | --help ]……..: display this help
[-v | --version ]…..: display version information
[-b | --background]…: fork to the background, daemon mode

The UVC input plugin, input_uvc.so, takes these parameters:

[-d | --device ]…….: video device to open (your camera)
[-r | --resolution ]…: the resolution of the video device, can be one of the following strings:
QSIF QCIF CGA QVGA CIF VGA SVGA XGA SXGA
or a custom value like 640×480
[-f | --fps ]……….: frames per second
[-y | --yuv ]……….: enable YUYV format and disable MJPEG mode
[-q | --quality ]……: JPEG compression quality in percent (activates YUYV format, disables MJPEG)
[-m | --minimum_size ].: drop frames smaller then this limit, useful if the webcam produces small-sized garbage frames which may happen under low light conditions
[-n | --no_dynctrl ]…: do not initialise dynctrls of Linux-UVC driver

The output HTTP plugin, output_http.so, takes these parameters:

[-w | --www ]………..: folder that contains webpages in a flat hierarchy (no subfolders)
[-p | --port ]……….: TCP port for this HTTP server
[-c | --credentials ]…: ask for “username:password” on connect
[-n | --nocommands ]….: disable execution of commands

The file output plugin, output_file.so, takes:

[-f | --folder ]……..: folder to save pictures
[-d | --delay ]………: delay after saving pictures in ms
[-b | --bytes ]………: save only on change in picture-size
[-c | --command ]…….: execute command after saving picture

And the autofocus output plugin, output_autofocus.so takes just

[-d | --delay ]………: delay after saving pictures in ms

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.

After all, IP cameras have a processor in them, and do web serving, and that… well, that really isn’t a reason for them to be expensive. Some sort of premium seems to go on anything connected with the security industry.

As an illustration of this, the Linksys NSLU2 is a little network storage controller which does web and file serving. It sells here for about NZ$145. Its a complete computer with a 266MHz RISC CPU, 8M of flash and 32M of RAM, two USB ports, and an RJ-45 connector. Not much by todays standards, but not very many years ago those would have been respectable specs for a desktop. It runs off a 5V plugpack. The really interesting thing about it is that the open source community has developed something like five alternative firmware distributions for it which are very capable, and can do almost anything that the hardware will allow. Including acting as a camera server for an attached webcam.

Webcams have also made some interesting strides forward recently. A number of new webcams with true resolutions greater than 1 megapixel have appeared, and a standard for USB web cameras has finally been agreed on. This standard, known as the USB Video Class or UVC, means that newer webcams no longer require proprietary drivers but will work with a generic UVC driver. The Logitech Quickcam Pro 9000 is a good example of a UVC camera, capable of up to 1600×1200 pixels complete with optics to match. It sells here for about NZ$128.

I have been working on combining these two devices with one of the open-source firmwares that has the rather disconcerting name of OpenWRT Kamikaze. Despite the name it has proved to be quite reliable and full-featured, although not terribly well documented, as it is constantly being worked on and improved. Recently it has got to the point where it can easily make the NSLU2 and the QuickCam 9000 work together to make a high-resolution IP camera server, for a total of NZ$275. As it stands the combination is only suitable for indoor use, and it has some limitations, but it still produces a very good image for the money and it works with any web browser — or with my Linux-based ZoneMinder security camera software. If you want indoor high-resolution imaging over a LAN, this could be quite useful. Compiling OpenWRT and selecting the necessary bits is a bit involved and can take a few hours, so I am making the end product, a firmware build called openwrt-nslu2-uvc-webcam1.bin, available here.

To use it yourself you will need:

1. An NSLU2
2. A UVC-compatible webcam such as the QuickCam 9000
3. A host computer running Linux
4. The firmware image
5. Access to a DHCP server on your LAN

Installing the replacement firmware on the NSLU2 is a Bit Technical, but not difficult. You will need to run a tool called UpSlug2 to install the firmware. UpSlug2 is described here. I would recommend running it from Linux. I used my Ubuntu machine, but booting a Knoppix Live CD on a Windows machine should work fine. UpSlug2 can also be used directly under Mac OS X: see here. Under Ubuntu, getting UpSlug2 is as simple as

apt-get install upslug2

The next step is to power-up the NSLU2 in “upgrade mode”. It should be connected to the same LAN as your Linux machine, but do not plug the camera in at this stage. Use a straightened paper clip or other thin probe inserted in the Reset hole at the back of the NSLU2. Apply gentle pressure and the reset switch will click in. Hold it down and press the power button at the front. The Ready/Status LED will come on orange, but after nine or ten seconds will turn red. Release the reset switch as soon as this happens. The Ready/Status LED should start alternating red and green, indicating that the device is ready to upgrade. Now issue the command:

sudo upslug2 --image="openwrt-nslu2-uvc-webcam1.bin"

If all is well and UpSlug2 can find the NSLU2 you should see a nice animated summary of the upgrade process, which will take about one minute twenty seconds. When it finishes you should wait for three more minutes for it to perform initial setup. You can then disconnect the power, plug in the USB webcam (to the USB port nearest the LAN socket – the other one isn’t powered), and power it up again. After about 55 seconds the red ring light on the camera indicating that it is recording should come on.

The firmware has been set to use DHCP to dynamically determine its IP address. This has the advantage of working in almost all network setups, but it does mean that you will need access to the DHCP server log on your local LAN to find out what IP address it has been given. The logs should show a DHCP discover/offer/request/ack sequence at the time the NSLU2 powers up, which will tell you what IP address it was given.

The log will also give its Ethernet or MAC address (which is on a label on the outside of the box as well, if you still have it). If you have access to the DHCP servers configuration files, you can tell the DHCP server to give the NSLU2 with that Ethernet address a consistent IP address at which it can always be found.

Once you have the IP address, use any web browser to go to http://<IP address> (e.g http://192.168.10.154) and you will find an About page for the M-JPEG streamer software, offering various forms of static or moving images from the webcam, which is running at a resolution of 960×720. For an unadorned single frame, try http://<IP address>/?action=snapshot.

A sample image looks like this

Which is not bad for a webcam at all. A bit fuzzy around the edges, but resolution in the middle is fine. Your cat may look different.

This firmware should work with any UVC-compatible webcam, which includes a number of models from Logitech, Creative, Philips, and other manufacturers. A list of compatible ones can be found here [Warning; the Microsoft Lifecam NX-6000 is listed, but I am told it doesn't work]. The firmware will not work on anything other than an NSLU2. I intend in due course to describe how to build the firmware in another post, but I had to build the “trunk” version to do this and I’m hoping that a formal release of OpenWRT that supports the mjpg-streamer package that makes this possible will come out and make the whole process much easier.

The NSLU2/QuickCam combination is a powerful one that could obviously be used for a good deal more than a simple image server. The NSLU2 isn’t powerful enough to run anything like the ZoneMinder software except at low resolutions, but it could still be used as a stand-alone remote survey camera with a few additions. I also intend to post about this in the future.

I won’t actually be using this camera with my ZoneMinder setup because it is a bit too demanding. IP cameras require more CPU cycles from ZoneMinder than directly-connected cameras, because ZoneMinder has to decode the JPEG format that the images are sent over the network in. My 1.2GHz Pentium III can only just manage 4 frames a second from this camera at 640×480 with not enough margin to handle another camera. I would guess that if you wanted to use several of these with a ZoneMinder setup nothing short of a 2.5GHz dual-core CPU would be enough.

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. The PC can provide 12V power, and a standard 92mm PC case fan will fit nicely into the upper vent. Sort of an out-of-case fan. The only disadvantage is the sound of the fan running all the time. And the solution to that is a fan controller, preferably a proportional one which would run the fan only as fast as it needed to to stop the air in the cupboard exceeding some reasonable temperature. It is perhaps a bit of overkill for this particular location, but the design could be useful in other places as well, like an HTPC.

Fan controllers aren’t difficult to come by, but they seem to me to be surprisingly expensive for what they are. Proportional controllers used to be quite complicated things before microprocessors came along, but now the necessary algorithm can be coded into something very small indeed. I already had an appropriate part, the PIC12F675. This is an 8-pin chip that has a complete processor, 64 bytes of RAM, 1K of flash memory, and an A/D converter. Its one disadvantage is that it has to be programmed in assembler, but I have some experience with the PIC family and this application is simple enough it was worth putting up with assembly language to get the job done. I also had a temperature sensor, the LM34. It puts out 10mV per degree F, which the PIC can read directly to an accuracy of about half a degree F. More than good enough.

Now, the 12F675 may have an A/D to read the temperature with, but it doesn’t have a D/A converter to generate a voltage to drive the fan with. We can make a virtue of this, though. Fans and motors – and the circuitry that drives them – work more efficiently if driven with pulses of power rather than continuous voltages. To increase the speed of the fan, we generate more pulses, or make the pulses wider. This technique, called pulse-width modulation (PWM) is very widely used. The 12F675 can generate pulses just fine, so we drive a small power MOSFET with one pin and we are done.

So my first circuit could hardly have been much simpler, and looked like this:

The three-pin standard PC fan connectors at the input and output carry a speed signal back to the PC, which can be useful if it lets you monitor the fans.

This design certainly works, and controls temperature, and uses very few components, but unfortunately — it isn’t very quiet. The pulses that drive the fan are generated at a frequency of 2kHz and below, which is in the audio range. The fan motor resonates with the pulses and makes various high-pitched squealing sounds. This isn’t very restful.

The solution is to add another component or two to turn the pulses into a linear drive. What I ended up with was this:

Here the 10K resistor and 1uF capacitor act as an integrator that converts the pulse train into a continuous voltage over the range 0-5V. The op amp and the power transistor convert the 0-5V into 0-12V and provide enough power to drive the fan. The 22uF capacitor across the output stabilises things, and we get a nice continuous voltage range. This isn’t as efficient — but its much quieter. I have also added some LEDs attached to the spare I/O pins for debugging. These tell me if the fan is meant to be off (green) or full on (red), plus a yellow one that just blinks to show that the CPU is actually working.

The code that runs all this was assembled with the free MicroChip MPLAB system, and can be found here. The code is best considered in two parts, the PWM generator and the temperature-to-speed code. They communicate only through the Speed variable but are otherwise quite separate.

The PWM generator is interrupt-driven at a fixed rate of about 3900Hz. The frequency isn’t critical and happens to be what the Timer0 hardware in the PIC can easily generate. The generator makes use of a clever idea that appears in quite a few algorithms, which is to focus not on calculating an ideal result, but on tracking the error created by its approximation of that result. Here we want to convert the Speed value, which is between 0 and 127, into a stream of pulses where the density of high pulses runs from 0/127 (no pulses) to 127/127 (always on). Instead of trying to work out patterns of 1’s and 0’s to generate the required density, the code simply accumulates an error value. The error represents the difference between the Speed value (which it can’t generate) and the actual 0 or 127 that it can generate by doing or not doing a pulse. At each interrupt, it looks at the error and decides to generate a pulse if it is negative and no pulse if it is positive. It then updates the error to reflect what it has done, by adding the difference between the generated value and Speed. If it did a pulse it adds 127-Speed, and if there was no pulse it adds 0-Speed – or in other words, subtracts Speed.

The temperature-to-speed code uses the same idea. It runs much less frequently – the temperature can’t be expected to change very quickly. It also uses 16-bit values and arithmetic so it can cope with the 10-bit A/D conversion result. It determines the difference between the actual and target temperatures and adds it to an accumulated error value. When the error value reaches a positive threshold it increments the fan speed and subtracts the threshold from the error. If the error goes below a negative threshold it decrements the fan speed and adds the threshold to the error. By adjusting the threshold and the frequency at which the code runs it is easy to make the fan react appropriately slowly.

The calculated speed is limited to a suitable range by checking it against a minimum value before decrementing and a maximum value before incrementing, which is where things get slightly more complicated. It would be nice to run the fan through 128 speed steps from stopped to full speed, but real fans won’t do that. Real fans have a minimum voltage that they will spin at. For 12V case fans it is usually around 5V, but you should check your fan specifications. Below the minimum voltage, the fan will stall, and sit there heating up and possibly damaging itself. The code deals with this by separating the calculated fan speed, FSpeed, from the actual fan speed, Speed. The calculated FSpeed is incremented and decremented over the range kMinSpeed to kMaxSpeed, and Speed is an exact copy of it — except when FSpeed equals kMinSpeed. Then we set Speed to zero, and the fan stops. A further detail is that the code makes sure that the fan starts when FSpeed goes from stopped to kMinSpeed+1 by actually setting Speed to a higher value, defined in kStartSpeed, for one time interval before falling back to kMinSpeed+1.

This design and code should be adaptable to a wide range of different parts. Any temperature sensor should work with it with a few adjustments. The power transistor isn’t critical; the TIP 127 is actually a Darlington, but it doesn’t need to be. A BD140 would be fine. I put a small heatsink on it, but I’m not sure its necessary unless the fan is running slowly in a hot environment, which shouldn’t happen.

Apt makes adding things to an Ubuntu install very easy. Almost too easy. The first step was to check that it had the repositories set up right in /etc/apt/sources.list. Its inclined to comment out things if it can’t reach them, and if you don’t want to leave the CD in the drive its a good idea to comment that out, or it will ask for it. Its also worth checking that the line

net.ipv4.conf.default.forwarding=1

in /etc/sysctl.conf is uncommented. Without it no routing will happen.

Then we need to get everything up to date:

apt-get update
apt-get upgrade

The first requisite for a router like this is a DHCP server, so it can hand out IP addresses to client machines and tell them where to get DNS service and how to get out to the Internet. This was pretty simple:

apt-get install dhcp3-server

and edit /etc/dhcp3/dhcpd.conf to say:

ddns-update-style none;
default-lease-time 86400;
max-lease-time 86400;
# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.authoritative;
# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).

log-facility local7;
option domain-name-servers 10.11.12.1;
option broadcast-address 10.11.12.255;
option routers 10.11.12.1;

# Allow for up to 10 dynamic devices
subnet 10.11.12.0 netmask 255.255.255.0 {
interface eth1;
range 10.11.12.2 10.11.12.12;
}

# Fixed addresses for known hardware
host FirstPC {
hardware ethernet 00:0A:E6:83:0C:55;
fixed-address 10.11.12.17;
}

host BlackSilverPC {
hardware ethernet 00:0C:76:CD:82:61;
fixed-address 10.11.12.18;
}

The “host” clauses above are a nice way to give known computers the same IP addresses every time they start up, which helps in tracking who is using bandwidth, while the “subnet” clause allows arbitrary new computers to connect to a pool of free addresses.

Having the router act as a DNS cache is not a bad idea, as long as its done properly. Having selected DNS service when Ubuntu was being installed, the only other thing we need to do is to tell bind where to get it from. In /etc/bind/named.conf.options we uncomment the forwarders section and add our ISPs nameservers:

forwarders {
     191.202.34.3
     191.202.34.4
};

Ubuntu has a comprehensive firewall built-in, called iptables, but it isn’t terribly friendly to set up. I thought I would try shorewall, which is a front end that hides a lot of the details. It comes with a bunch of example setups, and the two-interfaces one is just about right:

apt-get install shorewall
cd /usr/share/doc/shorewall/examples/two-interfaces
cp * /etc/shorewall

Editing this a bit to reflect my arbitrary prejudices gives the following for /etc/shorewall/rules

#------------------- Firewall rules ---------------------
# Policy is to reject everything not specifically permitted here
# Accept DNS connections from the firewall to the network

DNS/ACCEPT      $FW             net   # Let the firewall make outgoing http so we can apt-get
ACCEPT          $FW             net             tcp     www,https   # Let the firewall do NTP so we can sync time
ACCEPT          $FW             net             udp     ntp

# Let the firewall send mail
ACCEPT          $FW             net             tcp     smtp,smtps

#Let the firewall send BOOTP datagram and get replies
ACCEPT          $FW             loc             UDP     68
ACCEPT          loc             $FW             UDP     67

# Local machines use the firewall as a DNS server
DNS/ACCEPT      loc             $FW

# Accept SSH connections from the local network for administration
SSH/ACCEPT      loc             $FW

# Allow locals to ping us
Ping/ACCEPT     loc             $FW

# Reject Ping from the "bad" net zone.. and prevent your log from being flooded..
Ping/REJECT     net             $FW

# But otherwise let the firewall do ICMP
ACCEPT          $FW             loc             icmp
ACCEPT          $FW             net             icmp

#------------------- Local net rules -------------------
# Policy is to allow everything not specifically forbidden here
# Force local machines to use the router as their nameserver
DNS/REJECT      loc             net

# Do not let NetBIOS protocols out because they are evil
REJECT          loc             net             tcp     137,445
REJECT          loc             net             udp     137:139

# Do not let low-port UDP out generally, with an exception for NTP
REJECT          loc             net             udp     0:122
REJECT          loc             net             udp     124:1024

#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

If I add a file called “accounting” in /etc/shorewall, it will do per-IP traffic measurement:

#ACTION CHAIN   SOURCE                  DESTINATION             PROTOCOL        DEST            SOURCE#                                                                               PORT            PORT# Overall Internet traffic counts
COUNT  -       eth0                     -                      all
COUNT  -       -                        eth0                   all # By-machine breakdown
DONE   -       192.168.1.32            eth0                    all             -               -
DONE   -       eth0                    192.168.1.32            all             -               -
DONE   -       10.11.12.1              eth0                    all             -               -
DONE   -       eth0                    10.11.12.1              all             -               -
DONE   -       eth1:10.11.12.2         eth0                    all             -               -
DONE   -       eth0                    eth1:10.11.12.2         all             -               -
DONE   -       eth1:10.11.12.3         eth0                    all             -               -
DONE   -       eth0                    eth1:10.11.12.3         all             -               -
DONE   -       eth1:10.11.12.4         eth0                    all             -               -
DONE   -       eth0                    eth1:10.11.12.4         all             -               -

etc…
Making shorewall run requires a little more effort, as they want you to be quite sure you have configured it first. In /etc/shorewall/shorewall.conf you have to set

STARTUP_ENABLED=Yes

and in /etc/default/shorewall set

startup=1

From there a

shorewall start

command will check the rule set and either tell you whats wrong with it or activate it.

Its nice to have accurate time on a security system, which is as simple as:

apt-get install ntp

It would also be nice to get e-mail from the system to assure us that all is well. First we need a mailer. We don’t need anything as advanced – or complicated – as exim4 or sendmail, just something that can forward mail to our ISPs mail server.

apt-get install nullmailer

Then we need to make a file called /etc/nullmailer/remotes that contains one line with the name of our ISPs mail server:

smtp.myisp.co.nz

and another file called /etc/nullmailer/adminaddr which should contain your e-mail address. Administrative emails will then get forwarded to you instead of getting lost or hanging around in a queue.
Now if we add this line to /etc/rc.local

date | mail -s "Starting up" myname@myisp.co.nz

… we will get mail (with a timestamp in it) every time the system restarts, which shouldn’t happen often (or at all). Something a bit more detailed from the firewall would be nice. This is easily done with a shell script. If we become root:

sudo -i

and make a file called daily in /root that looks like:

#!/bin/sh
/sbin/shorewall show log > outgoing
/sbin/shorewall show accounting >> outgoing
/sbin/shorewall reset
mail -s "Logs" myname@myisp.co.nz < outgoing

then its only a matter of making it executable:

chmod a+x daily

and installing a crontab entry for it:

crontab -u root -e

In the editor window we insert the line:

00 02 * * * /root/daily

to get the script to run every day at 2am. It will send a summary of the days firewall rejects and traffic, broken down by IP.
We now have a router, a DHCP server, a monitored firewall, and a DNS cache. If it ever stops working, you’ll certainly know about it. It should be utterly reliable – my system has run without a hitch since I set it up and has only been down during power failures.

Installing ZoneMinder isn’t very difficult, but a bit more complicated. I found this set of commands on one of the ZoneMinder forums, and they work just fine for Gutsy Gibbon. ZoneMinder is available via apt, so:

apt-get install zoneminder

… this will ask for a mysql password which you can make anything reasonably secure and you won’t need to know again. From there we need to do a few vaguely magical incantations:

ln -s /etc/zm/apache.conf /etc/apache2/conf.d/zoneminder.conf
apache2ctl restart
chmod 4755 /usr/bin/zmfix
zmfix -a
chown www-data.www-data /usr/share/zoneminder/temp

Zoneminder uses more shared memory than most programs, so its a good idea to edit /etc/sysctl.conf and add

kernel.shmall = 134217728
kernel.shmmax = 134217728

After a restart the ZoneMinder console can be found with a web browser at http://<firewall address>/zm. From this point, literally everything else is done in a civilised manner from the web console, where you can set up cameras, define motion-sensing zones, and so on. Theres a pretty good manual available from the website, and the whole package works very well. Some of the web interface can be a bit obscure, but the defaults generally work and the online forums are very helpful.

The only thing that held me up for a bit was that the bttv driver that connects the ImpactVCB card to the system had to be explicitly told how to deal with a PAL camera. The ImpactVCB card came with an NTSC crystal, which wasn’t really right because we use PAL here. This caused trouble because the driver quite sensibly assumes that the attached cameras use the same video standard as the card. The card can actually switch standards, but you have to explicitly tell it to do so by adding

options bttv pll=1

to /etc/modprobe.d/options. After that it just worked…

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. The other was Zoneminder. Zoneminder is another piece of security software, but of a different kind altogether. It does motion detection on video cameras attached to the PC, analyses the results, and records them. And it does it very well indeed. Its free, open source software that runs under Linux. I try not to be paranoid about crime, and burglary isn’t very common in New Zealand, but when I was in my twenties our family home was burgled and my fathers extensive stamp collection stolen. About six months later the police arrested the two men responsible and recovered much of the collection, but that was mostly due to a piece of good luck and some clever detective work by a small-town constable. Initially the police had no leads at all, because although the burglary was in broad daylight, no-one saw the thieves, or remembered them if they did. So I have always thought that a camera that automatically recorded everything that passed in and out of the house would be a good idea. Systems to do this have always been available, but anything to do with video security seems to cost the earth. Zoneminder does not.

Running a combined router/firewall/security camera system under Linux is a Bit Technical, but as I hope to show it wasn’t that difficult, and it expanded beyond that quite easily. I’m by no means a Linux expert, or even an experienced user. I do have some background in Unix system administration, but it has never been my main job. Selecting a Linux distribution to use was made easy by a brief experience I had earlier in the year with our Japanese exchange student. He needed a machine to do web browsing and mail on. In Japanese would be nice. We had an old Athlon XP based machine running Windows 2000, but a brief look at the complexity of installing a Japanese language kit on that put me off. I didn’t want to buy another copy of XP for the purpose, and there were copies of the Ubuntu Feisty Fawn desktop installer about at work. So as an experiment, and expecting problems, given my previous encounters with Linux on the desktop, I tried it. And it worked, largely flawlessly and quite reliably. In Japanese. Or so our student assures me.

The next step was to buy a suitable host machine. Practically anything with two Ethernet ports can be a router and firewall but ZoneMinder needs a bit of CPU grunt and RAM to work in. Comparing umpteen images a second to see if anything has changed requires some resources. For the 3-4 cameras I was thinking of, a 1GHz CPU and 512M of RAM seemed to be a good idea, although its difficult to generalise. On the other hand, the host needed to be as small and as low-power as possible, because it was going to be on all the time and live in a cupboard with no keyboard or screen. I could have built something out of parts, but it would have cost $600-$700 which was too expensive for an experiment. It would be better to recycle on old machine. After some searching on TradeMe (a New Zealand auction site like Ebay), I picked up an old HP Vectra XE310 for $100 plus $30 shipping.

The Vectra is just about ideal for this job. It has 512M of RAM, a 40G hard drive, and a 1.2GHz Pentium III Tualatin in it, which is one of the last Pentium III’s made before the power-hungry Pentium IV NetBurst architecture came along. So the CPU is reasonably quick (about the same as a 1.8GHz PIV) and relatively low-power, about 25W. Because the Vectra is a business machine built by HP, its very solid, excellent documentation is available online, and its almost worthless because it won’t play games and there is no way of making it play games; no AGP slot. But it does have onboard Ethernet and three PCI slots. A cheap Realtek Ethernet card goes in one PCI slot, and a Hauppauge ImpactVCB video capture card in another, and we are done, for a total cost of about $250. Another $200 spent on TradeMe got me a nice second-hand Samsung video camera for indoors, and a “vandal-proof” outdoor dome camera. I spent another $20-$30 on cable and BNC connectors and had some fun installing cables and ducting to appropriate places.

The next step was to install the current Ubuntu server release (Gutsy Gibbon – where do they get these names from?) on the HP Vectra, which meant downloading the .iso image, burning it to a CD, and booting the Vectra from it. The install process asked a few sensible questions (I asked it to install OpenSSH and DNS server software) , and the whole process nearly worked perfectly. The one problem turned out to be a thing called ACPI, which is a standard used to tell the operating system about the power-saving technologies available on the machine, via tables and p-code that lives in the BIOS firmware. ACPI is not a friendly standard – for example, see this rant. Remarks about it being designed by a bunch of monkeys on LSD have been made. Unfortunately the Vectra’s BIOS was written in the early days of ACPI and seems to have broken some of the rules, as far as they can be understood. Ubuntu as provided has difficulties with this, and by the time it gives up trying to understand it has borked the Ethernet ports by misconfiguring their interrupt lines.

I figured out that the Ethernet ports were broken by the fact that one was missing from the output of ifconfig, and by looking at the output of dmesg, which contained agitated remarks like:

[   45.834622] PCI BIOS passed nonexistent PCI bus 1!
[   45.834627] PCI BIOS passed nonexistent PCI bus 0!
[   45.834631] PCI: No IRQ known for interrupt pin A of device 0000:01:08.0. Probably buggy MP table.

One of the standard pieces of advice for dealing with ACPI problems, which seem tobe particularly bad on laptops, is to update the BIOS, but HP only produced one version for the XE310, so that was out. Some Googling eventually found a workaround, which is to tell the Linux kernel to abandon ACPI for some purposes by adding pci=noacpi to the end of the kernel boot line in /boot/grub/menu.lst.

This was a bit of a disappointing start. ACPI is obviously pretty nasty, but Ubuntu couldn’t even hint at what the problem was, it just couldn’t network. I had to read the log files and do something pretty obscure to get my hardware to work.

The next step was to set up static routing tables to tell the system what networks it was connected to. One Ethernet port talks to the DSL modem, and the other to the household net. The network IP numbers could be arbitrary RFC1918 addresses, as long as the DSL modem would work with them. It was set up to use 192.168.1.1, so I made its network 192.168.1.0, assigned the household net to 10.11.12.0 and set up /etc/network/interfaces as:

 # The external network interface
auto eth0
iface eth0 inet static
address 192.168.1.32
network 192.168.1.0
netmask 255.255.255.0
gateway 192.168.1.1

# The local network interface
auto eth1
iface eth1 inet static
address 10.11.12.1
network 10.11.12.0
netmask 255.255.255.0

I also needed to tell the system where to get DNS services, which was a matter of entering my ISP’s nameserver addresses into /etc/resolv.conf

nameserver 127.0.0.1
nameserver 191.202.34.3
nameserver 191.202.34.4

Having done this and restarted, the Internet was immediately visible, and the process of installing packages could begin.The machine could also be deprived of its keyboard and monitor and stuffed in the cupboard, because from here on everything can be done by logging into it over ssh from my Mac.

I’ll split this post into at least two parts, so installing packages will be covered in Ubuntu Part Two, The Gathering.

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.

So far, so good. The electricity company gets to reduce peak loads, which is important to them as peak loads define how much they need to have of everything – generators, transmission lines, the lot. However, the design of the system is, as I said, a bit primitive. The signals that they superimpose on the 240V 50Hz mains have to be (a) low enough in frequency that can be detected by electromechanical means and (b) small enough they they don’t interfere with the operations of normal appliances. This means frequencies down in the 100-1000Hz range, which also happen to be audible frequencies. Now, whatever signal they use is going to attenuate as it travels through overhead wires and transformers and so on to get to you, so to get a reliable minimum signal to their furthest consumers, they have to apply a rather larger signal than the minimum at the injection point, which will typically be in a substation somewhere.

The upshot of this is that depending on how close you are to a substation – and a few other factors – you may well be able to hear the ripple control signals, as the transformers or motor windings of your switched-on appliances resonate with them. If you hear a series of buzzing or humming noises that switch on and off at intervals of a few seconds and occur at regular times of the day, you are probably hearing ripple control signals.

The reason I’m posting about this is that ripple control noise can actually be rather annoying. In our case we had installed a ceiling fan over our bed, which was great, until it became clear that if we left it on overnight, it resonated quite loudly in a silent bedroom when the ripple control came on. At 11pm. And 5am. And 6am. Unfortunately, I’m a rather light sleeper, and after being woken up a few times I was fairly motivated to Do Something About It.

Electricians – or at least the ones we have asked – look rather blank when asked about remedies for this sort of thing. There certainly aren’t any aftermarket filters for ripple control noise that can be fitted to vulnerable appliances. There are any number of mains filter devices, but they seem to invariably operate at radio frequencies, which are way above the audio frequencies used by ripple control.

If the noise couldn’t be filtered out, the only other solution would be to turn the fan off. We could have used a timer to do this, but that would require a suitable electronic timer that could do at least three “dead times” a day, and an electrician to install it into the fixed wiring. This would cost at least a couple of hundred dollars, and it assumes that the electricity company are going to do ripple control at the same times each day. It would still be prone to waking us up if some emergency signalling was necessary at, say, 3am. A much better solution would be to detect the signals when they actually happened, and turn the fan off. So I designed and built a device to do this, mostly using parts from my junk box.

The schematic and construction details of the device are here.