The K-Zone: The breadbox PC

Overview

This is a Linux-based, mini-ITX PC, built in a breadbox. It is specifically designed to be a media/Internet radio player, but supports light-duty desktop computer operations as well.
      There's nothing special about the breadbox itself -- it's just a wooden box of about the right size to fit a mini-ITX motherboard, hardisk, PCI wireless ethernet board, speaker, and amplifier parts. I could have used a proprietary mini-ITX case, of course; but I wouldn't do something in a simple, inexpensive way if there were a difficult, expensive way to do it that was more geeky.
      My main design requirements, apart from fitting into the breadbox, were that the unit shoud: The ability to play at least some video files would be an advantage, but I didn't really envisage this unit being used for video, so this wasn't a priority.
      The silent running requirement was particularly problematic, because although fanless mini-ITX motherboard/CPU combinations are available, the case also contains a large hard disk drive, and an amplifier for the built-in speaker. The power-supply is not perfectly efficient, either. More of this later.

A couple of rather awkward problems had to be overcome to make the breadbox computer work.

Coomponent selection

For the breadbox PC I used an EPIA 5000 mini-ITX motherboard which has a VIA Eden 500 MHz C3 CPU. It just fits into the width of the breadbox with about 5mm to spare, and is mounted on the usual brass spacers which, in this case, I have screwed directly to the wooden base of the box.
      Wood is not a terribly good conductor of electricity, and I had to run wires from the PSU ground to the brass spacers and to the metal parts of the rear panel connectors to control audio interference. With a metal case this would not be necessary, as the case itself would provide the conductive path. I have to confess that it took me quite a few hours of probing to find the best place to ground the metal parts. Unsurprisingly, the motherboard ground-plane arrangements are not terribly well documented.

At present the motherboard/CPU is running with 256 Mb RAM, which seems more than adequate. I imagine that this combination would not run Microsoft Windows terribly well (although, I confess, I haven't tried), but it works fine with Linux, if you aren't in a particular hurry. There's no problem playing any kind of audio, streamed or locally, and it turns out that playback of MPEG2 and MPEG4 video is possible, albeit with some frame-dropping. Web browsing and word processing work OK, but sedately.
      The great advantage of the EPIA 5000 is that it is designed to run without a CPU fan. Not only is the power dissipation very low (never more than about 20W), but the CPU is designed to tolerate higher temperatures than usual. That doesn't mean that the system can run indefinitely with no forced cooling, but it certainly makes cooling design easier.
      The power supply I chose is a PicoPSU 80W unit, which is amazingly small. It has no leads, but instead plugs directly into the motherboard power connector. Apart from its size, the other compelling feature of this PSU is the manufacturer's claim of 96% efficiency. I don't know if it really is this efficient in a practical system, but it certainly doesn't generate much heat. The PicoPSU needs a single external 12V supply, which I got from a laptop power brick I happened to have lying around.

For a hard drive, I chose a 160Gb Seagate 2.5" drive, which was rated to be powered by a USB bus. To run in this mode of operation, the power requirements are presumably less than 6W. In practice, this drive does not get more than warm even under full load. I have configued the OS to put it to sleep after 30 seconds of idle.
      At idle, my measurements show that the unit consumes about 10W. That's one UK unit of electricity every four days or so.

The infra-red receiver is a small intergrated IR receiver, connected to the serial port following the method described by Igor Cesko. The Linux LIRC project has a driver for receivers of this type -- it is lirc_serial.ko. This kernel module has to be initialized with the option type=4 to enable compatibility with Cesko's design.

Selection of a wireless network adapter was something of a problem. Support in Linux for 54mbits/sec PCI wireless adapters is, in general, not terribly good. Certain chipsets are well supported, but if you buy a proprietary card, it's not easy to tell what chipset it uses. In the end, I bought a Toshiba-branded card from an eBay seller who was prepared to state that it was based on an Atheros device, which is one of the few chips that has good Linux support (from the madwifi project). The card has a built-in antenna which, as luck would have it, ended up rather too close to the metal mass of the built-in speaker for comfort. In time it may be necessary to extend the antenna wiring to allow the antenna to be placed outside the case and further from metal parts; but so far signal strength doesn't seem to be too badly affected.

The loudspeaker is a bog-standardard 5W unit from Maplin, and the amplifiers are somewhat modified general-purpose modules from Cebek (about a quid each on eBay).

The breadbox itself cost ten quid from the local Dunelm Mill. Switches, cables, connectors, etc., were mostly scavenged from other stuff that I found in my attic.

Construction

There's surprisingly little room inside the breadbox once it starts to fill up with components. The hard disk is mounted on the front panel next to the motherboard IDE connector. The IDE cable wasn't very long, and I didn't want it trailing all over the box anyway, as it would impede airflow. The switches and the wiring to the switches occupy most of the rest of the space at the front of the case, along with the PSU. Ideally I should have liked the loudspeaker at the front, but this just wasn't practical with the size constraints, so it's mounted on the back panel above the IO connectors.

Because you can see through the fan vent into the case, I thought it would be more interesting to make a feature of the insides, rather than trying to hide them
On the basis that a large fan can spin more slowly for a given airflow than a small one, and therefore be quieter, the top part of the box is largely taken up with a 120cm `silent' fan. The fan is on the top, rather than the sides or back, because this puts its case opening directly over the CPU heatsink. On the basis that hot air rises, my intuition was that the big hole in the top of the case would provide convective ventilation from the heatsink even when the fan wasn't running. With the ventilation hole being where it is, of course, you can see into the case. So I felt duty-bound to make the inside interesting. Or, at least, tidy. So all the internal wiring is done with trendy glow-in-the-dark cables (or glow-in-the-dark sleeving around the non-standard cables, of which there are many). There is a small UV LED excitor to drive the glowing effect -- a cold-cathode excitor would be way too big for a case this size, and the LED unit consumes only milliamps and generates negligible heat.

The fan is mounted on a perspex tray which can be removed completely for access to the motherboard, etc. The fan mountings are silicone rubber pegs which are supposed to dampen vibrations and prevent resonance. These pegs are designed to push into a thin metal case through the same holes that would normally hold the fan bolts. Happily the pegs have flat ends, and a drop of Superglue on each made a strong mounting to the perspex tray.
      The silicone pegs really do work surprisingly well, and are worth the (gulp) quid each they cost. The mounting actually cost more than the fan itself. But, when mounted in the case, the fan isn't noticeably louder than when when held in the hand. The fan is not silent -- no fan ever is -- but, happily, it rarely needs to run.
      There are two reasons for making the fan tray out of perspex. First, it allows people to see the trendy glow-in-the-dark wiring when the lid is removed. Second, and less trivially, it makes it a lot easier to insert connectors (video, ethernet, etc) into the IO ports on the motherboard, because you can take the lid off and see what you're doing. The fact that the motherboard is mounted in the middle of the box, and not at one end, makes IO access rather awkward otherwise.

There is a reason why the motherboard is mounted where it is: most of the IO ports are routed back into the computer itself. For example, the audio output goes back to the amplifiers, while the serial port is connected to the IR receiver. Short of soldering direct to the motherboard, there is no elegant way to make these connections when the IO panel is right at the back of the case. In the breadbox PC, there is about a two-inch spacing between the IO ports and the rear of the box, which ensures that none of the internally-routed cables protrude out of the back, while still allowing access (just about) for the video cable, etc. $-para-% The cutout for the IO panel serves as the main air intake, although I've drilled a grid of holes along the side of the box as well. With the fan off, hot air rises from the CPU heatsink, drawing cool air in from the rear and sides, which flows over the motherboard.
Back view of the breadbox computer, showing the loudspeaker and its switch. The Epia motherboard only provides one audio output, so manual switching is the only straightforward way to allow the headphones to be in use with the build-in speaker off. The motherboard is set in from the back of the case, because most of the IO connectors are routed internally, and there is no need for routine access.
The speaker and headphone amplifiers are mounted on another persex tray below the fan tray, and the fan controller (see below) is on another perspex tray that hangs from that. The amplifier tray is positioned to make the connections to the motherboard audio output as short as possible. If these connections are longer, even though the cable is screened, they pick up interference from the motherboard. This tray slides into wooden runners and can also be removed, after disconnecting the amplifier circuits. If I were less lazy, I would have made a single, multiway connector from the amplifier and fan controller to the PSU, fan, motherboard, speaker, and headphone socket. As I am very lazy indeed, there are about two dozen individual connections to disconnect, which makes removing the amplifier tray a bit of a drag.

Inside the breakbox computer. The fan is mounted on a tray consisting of a perspex plate on a wooden frame. This allows the lid of the breadbox to be removed without any trailing wires. Being perspex, you can see through the tray, and there is an LED UV excitor (right) to make all the wiring glow in the dark

Cooling and fan control

I wanted a computer that would run silently, and consume a minimum of power. In practise, it's difficult to get enough heat out of the box to allow silent running in all conditions.
      Actually, that's not quite true: my tests suggest that, with only convective ventilation -- warm air rising from the CPU heatsink out of the ventilation hole in the top of the case -- the CPU (heatsink) temperature does eventually settle, even on full load. The problem is that it settles at around 70 Celsius. I can't work out what the CPU die temperature is because, although there is a temperature sensor accessible over the i2c bus, the value it records does not make sense when interpreted using Via's own calibration figures. If Via is to be believed, the die temperature is about 200 Celcius. It isn't, of course; but it could be 80-90 Celcius, considering how small the heatsink is. It's impressive that the unit tolerates this temperature with no obvious ill effects; but it can't be healthy in the long term.
      Moreover, when the CPU is this hot, it warms up everything else, including the hard disk, the audio amplifier, and the PSU -- none of which have any cooling of their own.
      At idle -- or Web surfing or e-mailing, which amount to much the same thing -- the situation is somewhat different. On test the CPU heatsink temperature settles around 20 degrees above ambient temperature -- about 40 Celsius at a typical room temperature. This is a reasonable temperature, and one that doesn't need any forced cooling. When playing a networked MP3 stream using XMMS, the CPU heatsink temperature settles around 25 degrees above ambient. Again, not a particular problem.

In short, most of the time a fan is not necessary. The fan needs to be running when (say) watching video or compiling a Linux kernel. For audio and desktop PC-type usage, it doesn't. None of the commercially-available fan controllers seemed to do what I wanted, which was to deliver s ahort blast of full fan every so often, and have the fan still the rest of the time. Most commercial units expect to run the fan slowly at low temperatures, and increase the fan speed gradually as temperature increases. But that doesn't give silent operation.
      So I built my own fan controller, using a thermistor, and op-amp as a comparator, a couple of transistors and a relay. In a sense, the relay is over-the-top -- a modest transistor can easily handle the 100mA or so the fan draws. But using a relay in such a way that the coil is energised to turn the fan off, gives fail-safe operation: most likely if the fan controller fails it will result in the fan running all the time, not stopped.

Audio amplifiers

Before starting this project, I simply had no idea how difficult it would be to get an audio amplifier working in a wooden PC. The problem is that the power and ground lines from the PSU are absolutely filthy with audio-frequency and radio-frequency noise, as is the groundplane on the motherboard. If it weren't for the fact that I had already cut a bloody great hole in the case, I might well have given up on getting a loudspeaker to work.
      It turned out to be necessary to filter the power supply to the amplifier circuits. However, it wasn't possible to filter the ground, because no part of the unit is `earthed' in the conventional sense, so there isn't a reference against which to filter the backplane/PSU ground. Amplification is necessary not just for the internal speaker, but also for the outphone output -- the Epia audio output is a very high-impedance source. If the breadbox is connected to an external hi-fi amplifier, these problems mostly go away, except for the remaining -- insoluble -- problem that the quality of the Epia integrated audio is pretty poor to start with.
      The trick in getting the audio to work -- apart from filtering everything -- was adjusting the gain of the amplifiers to be as low as possible, while still getting reasonable volume. The problem with the Epia audio is not that it can't generate a large voltage swing, but that it can't deliver any significant current. So a voltage gain of about x5 was adequate for the speaker, and x1 for the headphones.
      In spite of my best efforts, the sound quality from the built-in speaker can at best be described as `fair'. The fundamental problem is that the breadbox is not physically large enough to seal off an decent air volume for a speaker chamber. Having the speaker in the main body of the box means that sound can get out not just from the front of the speaker cone (which is what we want) but from all the ventilation holes as well. So what you hear is a mixture of in-phase and out-of-phase sound. It's OK for listening to Radio 4, but hi-fi it isn't.

Linux issues

The Linux installation on the breadbox PC is built from scratch, not based on any standard distribution. The reason for that is that none of the usual Linux distributions is really suitable for what is, in essence, an appliance rather than a PC. I was looking for a start-up time of less than 30 seconds, and a shutdown time of zero (that is, throwing the switch).
      The 160Gb disk is divided into three partitions: a small root partition, a small home partition, and a very large general partition for media storage. All but the home partition are mounted read-only, but the media partition can be remounted read-write at run-time for installing new media. All are formatted as ext3 since I have found it quite tolerant of inelegant shutdowns in the past.
      In fact, mounting most of the filespace read-only largely removes the need for an orderly shut-down procedure. There simply isn't anything to shut down. The slight exception is the home partition, which is where user preferences (e.g., for the Web browser) are stored. I'm not overly worried about this -- if it becomes necessary to reformat this partition, I have a script that sets everthing to defaults.
      Because the root partition is read-only, some place other than the root filesystem has to be made available to store temporary files. The /tmp and /var directories are both mapped to ramdisks, and files in /etc than have to be writeable are symlinked to files in the writable home partition. An example of such a file is /etc/resolv.conf, which is written by the DHCP client when it retrieves the name of a DNS server from the DHCP server. The /dev files are also read-only, which presents a problem for software that expects to be able to write in this directory. An example is the lircd infra-red receiver daemon, which creates a named socket in /dev for communication with its clients. It was necessary to recompile this software to create its volatile files in /tmp instead. Well-coded applications that use LIRC (e.g., VLC, xmms) aren't affected by this change, because they all use the LIRC client library, which is compiled from the same source. Modern Linux distributions use udev which gets around this problem by constructing the /dev directories and its devices dynamically at runtime. However, udev is painfully slow to start up, so I'm doing things the old fashioned way.

The Linux kernel is the latest available at the time (2.6.31), compiled to match exactly the hardware in the computer, plus some USB support. This, again, is to minimize start-up time, as the kernel doesn't have to waste time searching for non-existent hardware. To make USB work properly normally requires the overhead of the USB hot-plug infrastructure but, as it happens, I'm not too bothered about USB support on this machine, as the motherboard only supports USB1.1 anyway.

The boot loader (grub, as it happens, but I doubt it makes much difference) is configured to pass the identity of a custom init process to the kernel. init is, in fact, a single shell script which initializes all the hardware, creates the essential directories under /tmp and /var, and starts an X session as an unprivileged user. At the same time as starting X, the `init' script spawns another script concurrently, which finishes the rest of the initialization, which can be quite slow (getting network identity from DHCP, starting the printing service, etc). Since the computer is basically useable as soon as the X window manager kicks in, the time-to-usefulness is improved by the doing the initialization this way.

The standard Xorg `vesa' driver works on the Epia boards, and if you install an ordinary Linux distribution that's probably what you'll get by default. But VIA provide an accelerated driver for the Epia graphics device, and using this allows the XV extension to work. XV provides two-dimensional hardware screen scaling and colourspace conversion, and makes a huge difference to the quality of video playback. Using VLC and the Via Xorg driver makes MPEG4 (Divx, xvid) playback a realistic proposition. What you won't get, on a 500MHz system, is any video post-processing, so the picture can look a bit rough, particularly with low-bitrate recordings.
      The X window manager is icewm, which offers a good compromise between start-up time, resource usage, and functionality. I don't want the enormous overheads of running Gnome on a 500MHz system, but there are some Gnome-based applications which are quite useful in a media player, particularly the Nautilus file manager. The VLC media player also uses GTK, which is closely linked to Gnome. Getting these applications to work properly without a full Gnone session in progress was a bit fiddly, involving a fair amount of tweaking of configuration files. But it's do-able.

As for media playback itself, xmms, xine, and VLC all work fine on this machine. mplayer does not work, at least in any of the binary versions I tried. Most likely these versions are compiled to take advantage of CPU features that don't exist on the C3 CPU, but I couldn't be bothered with the hassle of building it from source. For most purposes I use VLC, which can handle most audio and video files I have. It also has good network streaming support, for Internet radio applications. Unlike xmms (so far as I can tell), VLC supports Windows Media Player streams that use the mms: protocol, and it actually works. This makes it possible to listen to BBC Internet broadcasts, which are only distributed it Windows Media and RealAudio formats, neither of which are particularly Linux-friendly.

Conclusion

The total cost of this project was about £200, but some of the parts were second-hand or from on-line auctions. It took about a week of evenings to adapt the wooden case to its new function and assemble the parts in it, then a further week of evenings to install and tweak all the software. A large part of the latter week was spent in trying various wireless adapters that ultimately turned out not to work. Designing and integrating the electronic bits -- amplifiers, fan controllers, etc -- took another week. A certain amount of experience with a soldering iron is required for this part of the job.
      The breadbox PC works reasonably well as a media player and light-duty desktop computer. A bonus is that, because of its very low power consumption and single 12V power supply, it can run on a motorcycle battery, and this should give about 20 hours of light use, assuming that the battery has to power a screen as well. It's not exactly a laptop, but it will fit in a rucksack.
©1994-2006 Kevin Boone, all rights reserved