information furnace dds

Information Furnace

The Information Furnace is a basement-installed PC-type device that integrates existing consumer home-control, infotainment, security, and communication technologies to provide in a transparent manner user-friendly access and value-added services. A modern home contains a large number of sophisticated devices and technologies. Access to these devices is currently provided through a wide variety of disparate interfaces. As a result, end-users face a bewildering array of confusing user-interfaces, access modes, and affordances. In addition, as most devices function in isolation, important opportunities to exploit synergies between their functionalities are lost. The information furnace distributes data, provides services, and controls an apartment's digital devices.

This directory contains a few of the software elements described in the paper presented at the 2002 SANE conference:
Diomidis Spinellis. The information furnace: User-friendly home control. In Proceedings of the 3rd International System Administration and Networking Conference SANE 2002, pages 145-174, Maastricht, The Netherlands, May 2002.

and in a companion journal article:
Diomidis Spinellis. The information furnace: Consolidated home control. Personal and Ubiquitous Computing, 7(1):53-69, 2003.

Parallel I/O device driver
DNARD/Shark MP3 player
Serial port monitor

The files do not comprise a complete software system, and will not work out of the box. The elements are provided in the hope that they may prove useful in building systems similar to the one described.

The linked pages do not contain navigation links. Use your browser's back button to return to this page.

Parallel I/O Device Driver

The source files in this section comprise a FreeBSD device driver for the Adaptec PCL-724 card. The PCL-724 card emulates the Intel 8255A programmable peripheral interface chip running in mode 0 (simple I/O). It provides two 8-bit ports (port A and port B) and two 4-bit ports (port C upper, port C lower). Each port can be individually programmed for input and (latched) output and appears at a different offset of the device's base I/O address. A separate register allows the configuration of ports for input or output. The device is so simple, that reliably probing for it when input data arrives at its terminals is impossible; therefore the kernel configuration has to specify the device's base address. The device driver provides four character devices that correspond to the card's I/O ports. Opening a device for read or write, automatically configures the corresponding hardware port for input or output. Initially all ports are set for input to avoid damaging external circuitry.

pbio.c - driver
pbioio.h - ioctl(2) include file
pbio.4 - mdoc(7) manual page

To configure the device, add a line like the following in you kernel configuration file:

# Parallel (8255 PPI) basic I/O (mode 0) port
device pbio0 at isa? port 0x360

To create the devices go into the /dev directory and run:

mknod c 32 0 pbio0a
mknod c 32 1 pbio0b
mknod c 32 2 pbio0ch
mknod c 32 3 pbio0cl

MP3 Player

The files in this section are used to have a DNARD/Shark device act as an MP3 player accessible through a remote-control. The Shark runs NetBSD 1.5 patched with Mark Foster's AV package to support the audio hardware and the infrared port. The Shark gets its initial configuration from the information furnace dhcpd(8) server and boots using TFTP; it subsequently mounts its file systems and the MP3 disk volume over NFS. A small shell script, run at startup time, allows one to use a remote control to select music. The irw command from the LIRC distribution reads remote control messages. These can be a number forming a CD, track, or music-type code, play, stop, previous, next, or pause. The play command starts an MP3 player process. All other commands are handled by sending signals to the MP3-player process: stop kills the player process; pause pauses it; previous and next send it the USR1 and USR2 signals respectively. I contributed patches to the MAD and mpg123 development efforts that enable both players to recognise these signals to move backwards and forwards in the current playlist. Note that the Shark's ARM processor does not provide hardware floating point support; the MAD player's integer-only decoding has proved to be more reliable than the corresponding mpg123 code.

Playlists are generated by a sed(1) command that prints the master playlist from the music part selected until its end. The master playlist contains the location of MP3 files, and, as comments, the number used to access the particular track or CD. I use 3 and 4-digit numbers for complete CDs and five-digit numbers for individual tracks:

# 521
# 10297
/vol/music/Classical/Bach/FrenchSuites/cd1/track01.mp3
# 10298
/vol/music/Classical/Bach/FrenchSuites/cd1/track02.mp3
# 10299
/vol/music/Classical/Bach/FrenchSuites/cd1/track03.mp3

As music is sorted and traversed according to its content, when the player finishes the selected track or CD, it will continue playing roughly similar content.

A separate function allows the shuffling of complete collections. These are defined as files in a separate directory. Each file contains a line specifying the collection number, and a sequence of lines containing CD numbers:

Playing the given collection will randomly shuffle the tracks from all CDs comprising the collection. Shuffling of music tracks is simply accomplished using the NetBSD shuffle(1) command.

The MP3 files of each CD are organised into a separate directory. The files are named following the trackNN.mp3 convention. Each directory also contains the disk's FreeDB identifier, and two automatically generated files used for indexing and cataloging the collection.

The index.txt (indexing for list creation) file contains:

DN: Disk number
TN: track number ^A File

Example:

# Index
DN 709
TN 12763^Atrack01.mp3
TN 12764^Atrack02.mp3
TN 12765^Atrack03.mp3
TN 12766^Atrack04.mp3
TN 12767^Atrack05.mp3
TN 12768^Atrack06.mp3
TN 12769^Atrack07.mp3
TN 12770^Atrack08.mp3
TN 12771^Atrack09.mp3
TN 12772^Atrack10.mp3
TN 12773^Atrack11.mp3

The info.txt (CDDB saved output) file contains:

DI: Disk Information
AL: Album name
GE: Genre
AR: Artist
NT: Number of tracks
DU: Duration
TR: Number ^A title ^A File

Example:

# Disk information
DI 8f0b650b 11 150 22570 29675 56235 64782 95550 115047 144962 157867 179202 196130 2911
AL A Chorus Line
GE soundtrack
AR Joseph Papp
NT 11
DU 2911
TR 01^AI Hope I Get It^Atrack01.mp3
TR 2^AI Can Do That^Atrack02.mp3
TR 3^AAt The Ballet^Atrack03.mp3
TR 4^ASing!^Atrack04.mp3
TR 5^AHello Twelve, Hello Thirteen, Hello Love^Atrack05.mp3
TR 6^ANothing^Atrack06.mp3
TR 7^AThe Music And The Mirror^Atrack07.mp3
TR 8^ADance: Ten; Looks: Three^Atrack08.mp3
TR 9^AOne^Atrack09.mp3
TR 10^AWhat I Did For Love^Atrack10.mp3
TR 11^AOne (Reprise)^Atrack11.mp3

Finally, the mklist program creates (using the above files) human and machine readable versions of the music collections: the list in HTML and LaTeX format, and the master playlist that mplay uses. All scripts expect the disk database to reside under /vol/db and individual music directories under /vol/music.

Serial Port Monitor

The montty serial port monitor allows you to share the monitoring of a serial port's output with programs that sporadically require complete control of the port. The scenario case in the information furnance involves accessing the serial port of an ISDN terminal adaptor (Intracom's NetMod) for occasional outbound PPP IP connections, and continously monitoring the port for obtaining the caller-id information (CLID) of incoming calls.

The montty program will run as a daemon, taking as arguments the serial line to monitor (e.g. cuaa0) and a sequence of initialisation strings to send to the line once it acquires control over it. Example (for obtaining CLID from Intracom's NetMod):

montty cuaa0 'AT\r\n' 'ATZ\r\n' 'ATS82=76\r\n'

Input read from the device is logged using the LOCAL0 logging facility.

The program works by polling for data on the device port and trying to acquire an exclusive lock to read it. If no lock can be acquired we assume that another program (e.g. the PPP daemon) is controlling the device and sleep. The initialisation string is only sent to the device after we detect that another program has messed with it. It has been tested under FreeBSD 4.1.

Reprise: a Different Type of Information Furnace

Diomidis Spinellis home page

Unless otherwise expressly stated, all original material on this page created by Diomidis Spinellis is licensed under a Creative Commons Attribution-Share Alike 3.0 Greece License.
Last modified: 2001-11-17