| My professional interests |
|
Computing Law Education Science and research |
| My leisure interests |
|
Martial arts Heritage railways Garden railways Motorcycles DIY |
| Downloads |
|
Linux downloads Windows downloads Java downloads Perl downloads Home automation downloads |
| About me |
|
Home & family My CV |
| Site info |
|
Contact the author Download policy Keyword index |
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:
- play common audio files and Internet radio streams (MP3, ShoutCast, RealMedia, AAC);
- support Wireless networking with DHCP (no end-user configuration);
- do ordinary PC things: Web, e-mail, play chess, etc;
- run silently, at least most of the time, and consume so little power when idling that it would not be an affront to the environment to leave it switched on;
- need no start-up or shut-down procedure -- it must be safe to pull the plug at any time;
- support infra-red (or similar) remote control for media playback.
- have a built-in speaker
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.
- The Epia motherboard has only a high-impedance, line-level audio output. It can't even drive headphones, let alone a speaker. This necessitates an amplifier inside the box. This generates heat (albeit only a little with the amplifier circuit I used) but, more significantly, it is extremely difficult to prevent interference from the motherboard and PSU leading to a dreadful sound quality
- In general, wood is a poor conductor of heat, as well as electricity. This makes cooling difficult.
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 |
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. |
 
|
| 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.
| Search |
| Shameless plug |
 By the author of this site. Buy on-line from Amazon USA | UK |
| Editorial |
So you want to be a university lecturer? Read this first! Speak like your boss: new developments in managerese |
| Computing features |
|
File handling in the Linux kernel: an in-depth look at how Linux handles files, filesystems, and file I/O
All sorts of Linux stuff Confused about CLASSPATH? answers are here First steps in EJB using jBoss (recently revised for jBoss 3.2) |