next up previous
Next: Conclusions Up: Habitat Monitoring Previous: Tiered Architecture


Experimental Platforms

Our initial testbed consisted of 5 Toshiba Libretto 50CT laptops running RedHat 6.0 with radiometrix transceivers [RPC]. After our initial experiences with those laptops, we gradually clarified our requirements for the testbed:

At the same time we realized that one size did not fit all, and that we would need to work in an heterogeneous environment with nodes of different capabilities, as described in the previous section.

In this section we describe the hardware and software developed for our experimental platforms.

Hardware platform


The PC104 nodes are our ``high end'' nodes of our tiered sensor architecture. We chose to use off-shelf PC-104-based products to replace the Librettos. PC-104 is a well supported standard [104] and compatible with desktop PCs. They can be designed for low power applications and equipped with processors ranging from 386 to Pentium II and from memory ranging from 0MB RAM to 64MB and more. There is a full spectrum of PC-104 peripheral devices including digital I/O, sensors, actuators, most of which are compatible. Before settling on the PC-104, we also considered the following alternatives:

The final factor that led us to PC-104 products is their ability to support almost all PC software. We chose Linux as our operating system because it is one of the most widely supported open source operating systems. We spent time evaluating different distributions or distribution building tools such as LEX, and CCLinux [CCL]. However, we decided to use our homebrew distribution based on a 2.2.12 Kernel and glibc2.1. It also contains some utility programs for management and configuration. It is binary-compatible to RedHat 6.1, thus we can develop and debug our applications on desktops/laptops, and later move to our PC-104 based testbed easily.

We are currently using an Advanced Digital Logic MSM486SN16 (Figure 2). Its features include: (1) AMD ElanSC400, 3.3V, 66MHz CPU, (2) 16MB RAM, 8kBytes (1st Level) Cache, (3) Hard Disk (E-IDE), (4) Floppy Disk Interface (3.5"), (5) COM1(optional SIR IrDA mode), COM2, COM3 and LPT1, LCD-Character Interface, Key Matrix Scanner, (6) RTC with Battery Back-up, Watchdog with Power Failure Detection, Power Management (Suspend/Sleep), (7) Form Factor: PC/104 (3.6" x 3.8" x 0.6"), (8) BUS: PC/104 (ISA), (9) MSFLASH16 from ADL. 16MB IDE Flash Disk, and (10) Power: 5VDC only, 600mA/3W.

Figure 2: Our prototype PC104-based sensor node.

Most of PC104 devices require a strict 5V power supply (as little as 5.25V will cause damange to the MSM486SN16). We therefore designed a PCB power board for MSM486SN16, including: (1) Power Supply, 9-18V to 5V converter, (2) Infrared transceiver for IrDA or Optical Serial Asynchronous Communication, (3) Speaker Amplifier, and (4) Prototype Area. The size of the board and its standoff configuration are the same as PC104 boards for easy stacking.

Radio Subsystem

We are currently using a Radio Packet Controller [RPC] at 418Mhz. We have a small adaptor designed to attach the RPC module to the PC104 system. We wrote a kernel mode driver to use the RPC via the parallel port (see software section). The next generation of this hardware will use an RF Monolithics radio instead and will provide variable power transmission and signal strength measurement.


Tags are untethered devices that have a small enough form factor to be easily attached to objects that are of human scale. We term this form-factor ``velcroable,'' meaning that the device is small enough and light enough to be attached to another object using Velcro brand fasteners.

The scale of tags puts them into an approximate one-to-one correspondence with human-scale objects, such as furniture, shipping packages, laptop computers, and specific regions in a room on a scale of humans, e.g. a 2 square meter patch of the upper left wall. The tags are untethered so that they can recede into the background, performing their tasks with minimal disruption of the environment and minimal infrastructure requirements. This untethered requirement bounds the capability of a tag: the energy available to it is limited by its form factor while its capabilities are bounded by the energy cost of its task.

In our system, tags are implemented with a modular architecture. This is desirable for development purposes, and it leaves room to improve efficiency through integration. The modules that compose a tag are a loosely coupled system connected by a bus. Each module has local computational capability, implemented by a microcontroller that is interfaced to local resources such as sensors, actuators, communications hardware, or memory. In many respects, each module can operate standalone, only waking up another module when the resources that module controls are needed for its task.

The requirements of the bus are relaxed to accommodate long duty cycles. In our architecture, a master module stays on all the time at very low clock rates and acts as a central point of coordination. Other modules may operate on fixed or variable duty cycles. For example, a sensor module might be operating in a low-power vigilant mode, and when a particular condition is detected, it wakes up the RF board and reports the event. The RF board may then test the channel to see if any other tags are reporting, before reporting an event itself.

We are currently developing several components of the tag platform:

The tag implementation favors COTS, simplicity of design and flexibility, over optimization of the hardware design. Our tags require a modular architecture. Each module has an inexpensive processor and connects to other modules via a system bus. Modules may be powered down via software controlled switches on each board. None of the modules require complex design. However, modularity would allow for other types of sensors to be added as the outcome of other research projects now or in the future.

We envision that the following modules will be needed in order to get a useful experimental platform:


Motes are the smallest components of our tiered sensor architecture. Where tags are on a scale comparable to human scale, motes are much smaller and much more numerous. Motes are envisioned to be small enough to float in the air [Pister99] or to be attached in large numbers to a surface [Abelson99]. The cost of motes is intended to be small enough that they are entirely disposable. The technology to produce motes is thought to come from the area of MEMS.

Motes communicate with macro-scale objects through low power RF and through visible light. Through extensive integration, low power RF can be included on the same silicon die as the mote itself, and the antenna may serve as a ``tail'' that enables it to float in an air current. Another possible communication technique uses steerable corner-cube reflectors to reflect laser light shined on a collection of motes. A third communication technique uses a steerable mirror to point a laser beam. All of these options rely on MEMS technology to provide this functionality in such a small package.

Although motes the size of dust motes are still a long way off, current research is progressing using very small and simple devices that integrate a microcontroller with sensors and a radio on a small board.

We are using the mote developed by Kris Pister at UC Berkeley [Pister99], shown in Figure 4.

Figure 4: Pister's ``COTS Mote'', developed at U.C. Berkeley [Pister99]


Radiometrix Device Drivers

This package [RDD] contains a Linux device driver for the RPC (Radio Packet Controller) model of radio manufactured by Radiometrix. The RPC is a fairly low power, self-contained, short-range, plug-on radio. It has been a critical part of our testbed infrastructure for implementation and validation of directed diffusion and other algorithms.


Emlog [EML] is a Linux kernel module that makes it easy to access the most recent (and only the most recent) output from a process. It works just like ``tail -f'' on a log file, except that the storage required never grows. This is very important for our logging and debugging facilities in embedded systems where there isn't enough memory or disk space for keeping complete log files, but the most recent debugging messages are sometimes needed (e.g., after an error is observed).


Parapin [PAR] makes it easy to write C code under Linux that controls individual pins on a PC parallel port. This kind of control is very useful for electronics projects that use the PC's parallel port as a generic digital I/O interface. Parapin goes to great lengths to insulate the programmer from the somewhat complex parallel port programming interface provided by the PC hardware, making it easy to use the parallel port for digital I/O. By the same token, this abstraction also makes Parapin less useful in applications that need to actually use the parallel port as a parallel port (e.g., for talking to a printer).

next up previous
Next: Conclusions Up: Habitat Monitoring Previous: Tiered Architecture