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:

• Small in Dimensions.
• Low-Power (long lifetime).
• Moderate Computing Resources
• Flexible I/O capability.
• Well-supported Operating System.

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

PC104

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:

• Laptops. Those real PCs are expensive, and have unnecessary devices for our testbed such as LCD display, IDE Hard drive, etc., each of which consume significant power.

• Palm [PAL] and other PDAs. Even though they have a compact form factor, they have inadequate computing power for our applications. Another drawback is that they usually use vendor-specific operating systems, applications and devices, and are thus difficult to extend with new hardware and software capabilities. They also have often-unnecessary and power-hungry displays.

• TINI [TIN] and ucsimm [UCS]. These small devices are promising platforms, small and cheap with support for open source OS (UClinux for ucsimm) or standardized virtual machine (Java for TINI). However, they are still in their preliminary stage and do not provide the full functionality of the Linux development environment.

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

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 master module. This module hosts a number of services that most tag systems will need, including a real time clock, an EEPROM memory, and three UARTs for communication to external devices such as a larger PC-104 based system or an external sensor module. The master module can operate at a very slow clock rate for power savings, or at a high rate when precise coordination is required. It also has a pair of interrupt lines connecting to each of the other modules in the system. During times of high power expenditure, these interrupt lines are used for precise timing and synchronization, while during times of minimal power expenditure, they are used to wake up a module so that it can prepare to receive a message on the serial data bus.

• Radio controller module. This module provides a radio network interface. An RFM baseband radio is incorporated into this module driven by a micro-controller. The micro-controller implements a MAC layer as well as other protocol components. A large (32K) SRAM is also included on the radio module, enabling the storage of state pertaining to higher layer protocols. The simplest applications envisioned, such as a simple beaconing or sensor reporting system, may be implemented directly in the radio controller, eliminating the need for other external components.

  Figure 3: Prototype radio controller module for use with our ``tag'' platform.

  

• Sensor interface module. This module has a variety of on-board sensors and several actuators, interfaced to a micro-controller. The micro-controller can perform simple analysis of the sensor data as it streams into the system, and can watch for certain characteristic events. It can also record time series, possibly sending them over the bus to the SRAM in the radio module or storing them into the master module EEPROM. The sensor module will also feature a remote low-power wakeup device that can wake up the processor when a certain frequency of sound is detected. This enables most of the devices to be completely off, waiting to be waked up by one of the few left on when an event occurs.

• CPU or DSP module. Some applications may require more computational power and more memory when an event occurs. To handle these cases, a computational module can be developed. This module would be invoked when necessary to perform a complex calculation and then resume sleeping.

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:

• Power supply/host interface module. This module provides a real time clock, regulated power to the bus and one or more serial interfaces for debugging/logging output, or for interfacing to a host processor such as a SENSIT node or PC.

• Radio controller module. This module provides a radio network interface to other modules in the system. An RFM baseband radio is incorporated into this module with a micro-controller to drive it. The simplest applications envisioned may be implemented directly in the radio controller, eliminating the need for other external components.

• Sensor sampling and storage module. The simplest form of this module samples from an A/D converter and stores the resulting time series in a serial memory. After sampling, the data can be loaded over the bus into another module to process it. A more powerful version with a faster CPU will be developed as part of the development of an acoustic ranging sensor based on ultrasound.

• Remote wakeup module. This module provides a way for a node to be ``awakened'' from a very low-power sleep state. For such a module to be useful, the wakeup module must consume far less energy than the node it is awakening. A trivial example of a wakeup module is an ``on/off'' button. We plan to leverage other existing technology, such as a module that can wake nodes up in response to high-energy RF pulses.

Motes

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]

Software

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

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

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