I’m going to describe the process I went through to get this working in the hope that it might be useful to anyone else trying to assemble an OpenWRT-based multi-camera server. Its a pity that relatively few devices are available that will run OpenWRT and have multiple USB 2.0 ports, but they do exist and I hope to show they are worth pursuing.

So, I bought a Logitech S5500 webcam, which was capable of 960 x 720, connected it to the router, installed OpenWRT and mjpg-streamer, and… got very mediocre results. The video stream kept breaking up, triggering Zoneminders alarms, and the image couldn’t be expanded much beyond 512 x 384 before the load on the Zoneminder machines CPU went over 1.0, indicating Imminent Problems. I assumed that the issue was with the Zoneminder machine being underpowered; it was a 256Mbyte 1.2GHz Pentium III.

So when I eventually replaced it with a nice new Pentium dual-core E6500 with 1Gbyte, I was surprised to find that the problems remained. Some checking of the Zoneminder logs soon turned up some evidence; repeated complaints of “Invalid JPEG file structure: two SOI markers”. So. Clearly either the camera, or mjpg-streamer was generating bad JPEGs…

There is a moral here; always Google your error messages. I omitted to do this, or wasn’t thorough enough.

So I proceeded to build the latest stable version of OpenWRT Backfire for the WL50oG. OpenWRTs build process has been steadily improving; here is all that was needed. I did this build on a Atom-based netbook running Ubuntu Lucid:

sudo apt-get update
sudo apt-get install subversion build-essential libncurses5-dev zlib1g-dev gawk flex git-core quilt
mkdir openwrt
cd openwrt
svn checkout svn://svn.openwrt.org/openwrt/branches/backfire

When svn completes its downloads you can edit buildsystem/feeds.conf.default and save some time and bandwidth by taking out feeds you won’t use.  For this build I commented out the feeds for LuCI and the Xwrt WebUI.

cd backfire
./scripts/feeds update -a
./scripts/feeds install -a
make defconfig
make menuconfig

This will present a menu interface, in which I selected the following items: (pressing space twice to set to ‘*’, not ‘M’). I could have done all the customisation of OpenWRT after building with the default settings, but its easy to do here. I didn’t want to use the wireless connectivity, and I wanted mjpg-streamer and the ability to write to external USB drives (in case I wanted to configure the router as a time-lapse camera system), so:

Target System: (Broadcom BCM947xx/953xx)
Target Profile: (ASUS WL-500g Premium v1 (Atheros WiFi))
Base System:
     select block-mount
     deselect dnsmasq, firewall
Network:
     deselect iptables,ppp,wpad-mini
Kernel modules:
     select USB support: kmod-usb-core, kmod-usb-storage, kmod-usb2, kmod-usb-video, kmod-uhci
     select Video Support; kmod-video-core, kmod-video-uvc
     select Filesystems->kmod-fs-vfat, kmod-nls-xxxx
Multimedia:
     select mjpg-streamer

make V=99 2>&1 | tee build.log | grep -i error

After this build (which may take some time, as it needs to download quite a lot of source), the firmware image can be found in backfire/bin/brcm47xx/openwrt-brcm47xx-squashfs.trx. The fancy make invocation ensures that if things go wrong the console should show errors and the build.log file has the complete log of the build.

Installing the image, given that OpenWRT was already running on the router, was easy. First, I set up an ftp server on the build machine with anonymous access enabled:

sudo useradd -d /home/ftp/ftp -s /bin/false ftp
sudo mkdir -p /home/ftp/upload
sudo apt-get install vsftpd
sudo vi /etc/vsftpd.conf

I edited the configuration to set anonymous_enable=YES, then restarted the server to get it to reread the configuration file.

sudo service vsftpd restart

and copied the image into the server directory so the router could find it:

cp bin/brcm47xx/openwrt-brcm47xx-squashfs.trx /home/ftp/ftp

From here its a matter of logging in to OpenWRT on the router, and telling it to load the image over ftp and update to it:

cd /tmp
wget ftp://192.168.2.3/openwrt-brcm47xx-squashfs.trx
sysupgrade /tmp/openwrt-brcm47xx-squashfs.trx

192.168.2.3 happened to be the address the development machine had been given by my DHCP server; your mileage may vary.

OpenWRT Backfire doesn’t actually have the latest version of mjpg-streamer, but it swiftly became apparent that it hadn’t solved the problem. So my next step was to add some code to mjpg-streamer to filter out bad frames, on the assumption that these were coming from the webcam. The JPEG format is well documented (the Wikipedia article is a good source), and it it isn’t difficult to parse the basic structure without diving into the compressed data. Two SOI markers should be easy to detect.

To cut a long story short, my filter code, once running on the router, didn’t find any such thing.

At this point I did what I should have done much earlier, which was to Google “zoneminder” and “Invalid JPEG file structure: two SOI markers” a bit more thoroughly. And there in the Zoneminder FAQ is the answer:

What causes “Invalid JPEG file structure: two SOI markers” from zmc (1.24.x)

Some settings that used to be global only are now per camera. On the Monitor Source tab, if you are using Remote Protocol “HTTP” and Remote Method “Simple”, try changing Remote Method to “Regexp”.

This was indeed the fix. It was nothing to do with the camera or mjpg-streamer, but an internal problem in Zoneminder. I could now use the camera, but after only a day of testing a new problem became apparent. Some webcams, and the S5500 is one of them, have trouble with darkness. Here is a sample frame from the S5500 at night.

Night, badly rendered.

The little 8×8 blocks in this image are a giveaway that this really is a problem with the JPEG encoding. This time it was easy to prove that it was coming from the webcam, whose internal processor evidently can’t encode a uniformly black frame. Unfortunately, it doesn’t produce a consistent image like the one shown above, but a kaliedoscopic variety of them. This triggers Zoneminders motion detection, and you wind up with huge alarm events that last for hours and eat up your storage.

Fortunately, this problem is common enough that mjpg-streamer has a solution. The bad frames are all relatively small, there being no detail to encode, so a simple size test can detect them. The -minimum-size parameter allows us to throw away frames that are smaller than a certain size, and a little testing quickly revealed that at 960 x 720, any frame under 21000 bytes could be assumed to be bad. So:

/usr/bin/mjpg_streamer -i "input_uvc.so -d /dev/video0 -r 960x720 -m 21000" -o "output_http.so -p 80"

should be the solution? Well, nearly. The trouble is that what mjpg-streamer does with the bad frames is skip over them and not return a result until it gets a good frame. Which is fine for occasional bad frames, but when the camera produces a continuous stream of them – at night – mjpg-streamer may not return a result for hours. Zoneminder doesn’t like this either, and is prone to disable the camera altogether. This problem is apparently addressed in Zoneminder 1.25, but I’m running 1.24.2, so another solution was needed. The easiest thing to do was to edit input_uvc.c in the mjpg-streamer source so that instead of skipping the frame, mjpg-streamer returned the last good frame that it had. This was a matter of changing the lines

        if(pcontext->videoIn->buf.bytesused < minimum_size) {
            DBG("dropping too small frame, assuming it as broken\n");
            continue;
        }

to:

        if(pcontext->videoIn->buf.bytesused < minimum_size) {
            DBG("dropping too small frame, assuming it as broken\n");
            /* Provide the previous frame, as this condition might last some time... */
            pthread_cond_broadcast(&pglobal->in[pcontext->id].db_update);
            continue;
        }

This change isn’t really suitable for all uses as it means that the camera server may return an image of what was visible several hours ago when the scene was adequately lit, rather than current darkness. A more elegant solution would be to return a synthetic JPEG that was just a uniform field of black, but this was a quick workaround for my purposes.

Changing the code in the OpenWRT source and getting it recompile without ignoring or overwriting the changes was a bit tricky. The combination of OpenWRTs interesting build system as it interacts with mjpg-streamers makefile means that just changing input_uvc.c deep down in the build_dir directory and doing a make won’t work. After some trial and error I wrote a script to do the rebuild:

#!/bin/sh
MJPGDIR="build_dir/target-mipsel_uClibc-0.9.30.1/mjpg-streamer-r136"
touch $MJPGDIR/mjpg_streamer.c
rm $MJPGDIR/ipkg-brcm47xx/mjpg-streamer/usr/lib/*.so
rm $MJPGDIR/*.so
make V=99 >build.log

Having fixed this, I bought a second webcam (a Logitech C905) as it was now clear the whole idea would work as intended. The differences between the two webcams when looking at the same scene were surprising. Here is the S5500:

The C905 wins on detail, but also has quite different colour rendering.

The final step was to get both webcams to start up when OpenWRT booted.

OpenWRTs initialisation is a little complicated, and is controlled by the files in /etc/rc.d, /etc/init.d, and /etc/config. The mjpg-streamer package includes appropriate entries in each of these directories to automatically start up a single instance, but there is nothing to prevent us from running two versions provided that we tell them to serve to different TCP ports. The two webcams appear as /dev/video0 and /dev/video1. So we edit /etc/config/mjpg-streamer and add a couple more config options for device2 and port2:

config mjpg-streamer core
        option device           "/dev/video0"
        option device2          "/dev/video1"
        option resolution       "960x720"
        option minimumsize      "21000"
        option fps              "10"
        option port             "80"
        option port2            "8080"                                
        option enabled          "true"

Then we add an entry in init.d; the easiest way is to duplicate the existing script:

cd /etc/init.d
cp mjpg-streamer mjpg-streamer2

and edit the second script to use the device2 and port2 options, plus its own PID file name.

#!/bin/sh /etc/rc.common
# Copyright (C) 2009 OpenWrt.org
START=50

SSD=start-stop-daemon
NAME=mjpg_streamer
PIDF=/var/run/$NAME.2.pid
PROG=/usr/bin/$NAME

start() {
        config_load mjpg-streamer
        config_get device core device2
        config_get resolution core resolution
        config_get fps core fps
        config_get port core port2
        config_get_bool enabled core enabled
        config_get minimumsize core minimumsize
        [ $enabled -gt 0 -a -c $device ] && sleep 3 && $SSD -S -m -p $PIDF -q -x $PROG\
         -- --input "input_uvc.so --device $device --fps $fps --resolution $resolution"\
         --output "output_http.so --port $port" &
}

stop() {
        $SSD -K -p $PIDF
}

Finally we need to add a link in the rc.d directory to the new init.d script:

cd /etc
ln rc.d/S50mjpg-streamer2 ../init.d/mjpg-streamer2

This will start up the WL500 with both cameras if both are present, and serve them on port 80 and port 8080. The images and movie streams can therefore be found at:

http://<IP address>/?action=snapshot

http://<IP address>:8080/?action=snapshot

and

http://<IP address>/?action=stream

http://<IP address>:8080/?action=stream

respectively. Entering the snapshot URLs above into Zoneminder has produced a working system. The only remaining issue was setting up  Zoneminder to minimise the CPU usage, which is an art in itself and better covered in the Zoneminder forums…

This post, however, is about a new idea I wanted to try, which was to install my old Telecom CDMA phone in the server cupboard and use it to send and receive text messages to and from the server.

On the face of it this didn’t look difficult. There is a Linux/Windows/MacOS package called gnokii that does practically everything with a phone, provided that the phone supports Bluetooth or has a data cable, that you could possibly want. My Nokia 6165i has Bluetooth, so the first step was to buy a cheap Bluetooth adapter (Dick Smith, $20), plug it in, and fire up Bluetooth support:

sudo apt-get install bluez

Once I had that, I turned on the phone, told it to be discoverable on Bluetooth (down in Settings/Connectivity/Bluetooth/Bluetooth Settings) and told Bluetooth to look for it:

hcitool scan

Scanning …
00:12:D1:3F:00:8F    Michael H 6165i

It found it! Now to get gnokii:

sudo apt-get install gnokii

The version of gnokii that comes with Ubuntu 10.04 is 0.6.28, which has its preferences in ~/.gnokiirc or /etc/gnokiirc. Later versions change this, but for the moment it was enough to edit the heavily commented /etc/gnokiirc and use the Bluetooth ID given by hcitool so that the following lines were active:

port = 00:12:d1:3f:00:8f
model = series40
connection = bluetooth

debug = on

Debug is useful if you run into problems, as I did…

gnokii –identify

should then talk to the phone, whereupon we run into our first problem. The phone needs to pair to the Bluetooth transceiver on the PC, and if we were running desktop Ubuntu a nice dialog would come up on the desktop as well as the phone, we enter the same PIN into each dialog and all would be well. But this is running on a file server and I can’t do that. Some Googling eventually found a solution, which is to use one of the bluez examples to get the PIN code handshake done:

sudo /usr/share/doc/bluez/examples/simple-agent hci0 00:12:d1:3f:00:8f
This prompts for the PIN code, you enter it, the phone prompts, you enter the same number, all is well.

Now sending a text message should be as simple as:

echo “This is a text message from the file server” | gnokii –sendsms number -r

But life isn’t that simple. It seems to work, but the text messages simply don’t go. It took a good deal of debugging, updating, and fiddling about before I discovered the simple truth:

gnokii doesn’t support CDMA phones. CDMA is an older technology and the commands to send text messages are there — but subtly different. The only thing that might have worked was using gnokii AT mode, which I could get at by changing model = series40 to model = AT in the preferences. But the answer to that is short and final:

PDU mode is not supported by the phone. This mobile supports only TEXT mode
while gnokii supports only PDU mode.
SMS Send failed (Unknown error – well better than nothing!!)

So there we are, it isn’t going to work. It wasn’t going to work for long anyway, as the old CDMA network is going to be turned off next year, so the next step is to buy a  GSM Bluetooth phone and try again (ones with cracked but otherwise functional screens can be had very cheap on Trademe, I  see…). I hope to extend this post with better news at some point in the future.

– Michael J A Hamel

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…

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.

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.

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.

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

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 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.