Call for Papers: the 5th IEEE/ACM International Conference on Distributed Computing in Sensor Systems (DCOSS '09)

DCOSS is one of the premier conferences for sensor network research. It is intended to cover several aspects of distributed computing in sensor systems such as high level abstractions and models, systematic design methodologies, signal and information processing, algorithms, analysis and applications. Many of those who will be demonstrating are featured Crossbow customers.

Distributed sensor systems have become a highly active research area due to their potential for providing diverse new capabilities. Such systems allow intelligent dense monitoring of physical environments. The focus of this conference is on distributed computing issues in large-scale networked sensor systems (including algorithms, applications, systematic design techniques and tools, and in-network signal and information processing).

June 7 - 10, 2009, Marina Del Rey, USA                

IMPORTANT DATES
Submission Deadline: 11:59PM EST Jan 25, 2009
Notification: March 24, 2009
Camera Ready: March 31, 2009

Detailed submission guidelines coming soon on http://www.dcoss.org

Authors are invited to submit original unpublished manuscripts that demonstrate current research on computational aspects of distributed sensor systems. Topics of interest include but are not limited to:

• Computation and programming models
• Energy models, minimization, awareness
• Distributed collaborative information processing
• Detection and tracking
• Theoretical performance analysis: complexity, correctness, scalability
• Abstractions for modular design
• Fault tolerance and security
• Languages, operating systems
• Task allocation, reprogramming and reconfiguration
• Dynamic resource management
• Scalable, heterogeneous architectures (node and system-level)
• Middleware interfaces, communication and processing primitives
• Design, simulation and optimization tools for deployment and operation
• Design automation and application synthesis techniques
• Closed-loop control for sensing and actuation
•  Case studies: lessons from real world deployments
• Network coding and compression

The conference will be co-located with several closely related workshops,and will provide a forum for researchers and practitioners to present their contributions related to the above high-level aspects of distributed sensor systems. In addition to contributed papers, the meeting will also include keynote addresses by leading researchers, a panel discussion, and a poster session.

For more information click here.

Interface your OWN sensors to eKo!

Crossbow's new eKo system has not only brought wireless sensor networks into the heart of precision agriculture, the system now also offers a quick and easy solution for anyone wanting to incorporate wireless sensor networks into their own outdoor monitoring solution. Whether they are looking to use eKo for environmental monitoring and research, urban monitoring, pollution detection, etc., this system is on its way to being the wireless sensor networking solution for any outdoor sensing requirement regardless of sensor type. eKo is fully packaged for the elements, solar-powered and ready to use out-of-the-box. This platform now provides users with a solution that requires little effort for complete customization with the new ESB developer's kit. The first phase of this kit has now been released to all eKo users.

eKo nodes (EN2100) can interface to many different types of sensors. Each of the node’s four sensor ports has a 6-pin connector that programmably interfaces to either analog or digital sensors, and each port has the ability to support two different sensors. Crossbow has created a standard interface (ESB: Environmental Sensor Bus) to communicate with a wide variety of sensors through these ports. 

Phase 1 of Crossbow's ESB developer’s kit allows users to interface their own simple analog sensors that do not require any additional signal or power conditioning to the eKo node. Users will only need to program the self-identification EEPROM and wire the sensors to the connector. The EEPROM embedded in the sensor’s connector is read by the port during power-up, and this information tells the node how to communicate with the sensor and contains parameters such as the required operating voltage and power-up time. After the information is read, the node programmably changes the pins according to the ESB requirements.  To request details on using Phase 1 of the ESB Developer's kit with your eKo system, visit Crossbow's site here.

Phase 2 of this kit release will support simple analog sensors requiring additional signal conditioning and/or power conditioning. These sensors use the external interface circuit between the eKo node and the sensor. The self-identification EEPROM is embedded in the Switchcraft connector.

Phase 3 will provide support for complex digital sensors that require signal conditioning, power boost or intelligent communication. These sensors use an external interface circuit between the eKo node and the sensor. They do not require that the EEPROM is embedded in the cable as the self-identification information is contained in the microprocessor. 

As an example of interfacing a simple sensor to eKo, Crossbow has recently integrated the MaxBotix MaxSonar range finder along with an air temperature sensor on the same connector.  The MaxSonar is an accurate, very low cost, ultra-sonic range finder that can run directly from the eKo battery supply at very low current. Also, of interest is to measure the ambient air temperature at the same time. Both of these sensors can be wired to a single eKo port connector.

The entire assembly can easily be mounted in PVC pipe fixtures for outdoor deployment. Once the two sensors are wired a Dallas DS2431 1Wire EEPROM is mounted into the sensor Switchcraft connector. Finally the EEPROM is programmed with the self-identification information. This is done using a programming board and PC program from Dallas Semiconductor. A mating Switchcraft connector is wired to the board to allow the sensor cable to be attached directly and the EEPROM then programmed.

The simplicity of integrating unique sensors with eKo, a fully packaged ready-to-use outdoor wireless monitoring device, enables users to deploy wireless sensor networks quickly, easily and effectively in a way they never have before. To request details on Phase 1 of the ESB Developer's kit, visit Crossbow's site here.

The State of Wireless Sensor Networks

The continuous size and cost reduction of electronic devices is gradually making the vision of ubiquitous wireless sensors networks a reality. After almost a decade of extensive research, Wireless Sensor Networks (WSNs) are in the midst of the transition towards industrial deployment in various application domains such as automotive, environmental monitoring, health care, energy management, and building and industrial automation. BAIA presents a panel of outstanding experts from the academia and the industry who have played an essential role in the history and development of WSNs, including Crossbow's President/CEO, Mike Horton.

BAIA has organized an outstanding panel that will explore the state of wireless sensor networks on the evening of October 8th at UC Berkeley. Panelists include:

• Prof. David Culler, UC Berkeley, CTO and Co-Founder Arch Rock
• Mike Horton, CEO and Co-Founder Crossbow
• Prof. Raju Pandey, UC Davis, CTO and Co-Founder Synapsense
• Prof. Kris Pister, UC Berkeley, CTO and Co-Founder Dust Networks
• Dr. Joe Polastre, CTO and Co-Founder Sentilla
• Prof. Alberto Sangiovanni-Vincentelli, UC Berkeley, CTA and Co-Founder Cadence Design Systems

Questions addressed will include:

- What applications will drive the mass deployment of WSNs both in the short and in the long term?
- What players will be most successful in the WSN domain and what business model will they adopt?
- What are the main barriers before wide adoption of WSNs?
- When will the deployment of WSNs happen in large volumes?

The event is free, but limited to 100 attendees. Learn more and register here.

Imote2.Builder Kit featured in InfoWorld

InfoWorld has reviewed and featured Crossbow's Imote2.Builder kit in an article last week. The kit was reviewed by Strategic Developer Martin Heller who stated that, "The Imote2.Builder Kit makes creating wireless sensor networks a snap." From his article:

I spent several hours today exploring the Crossbow Imote2.Builder Kit, a "complete development environment for high performance wireless sensor networking (WSN) applications leveraging the Microsoft .NET Framework," as the company describes it.

(I'd never say "leveraging" and "Microsoft" in the same sentence myself if I could avoid it, because of Microsoft's rather checkered legal history of "leveraging" its near-monopoly -- but oops, I did it again. Back to Crossbow.)

The Imote2 .Builder Kit sells for $990 in the U.S. in small quantities. It includes three Imote2 processor boards, two Imote2 sensor boards, two battery boards, batteries, a USB cable, and software on CD-ROM. Obviously, individual boards are cheaper, especially in quantity.

Why so many boards? The processor boards also have radios, and can talk to each other using the 802.15.4 protocol. The Imote2 has an XScale CPU @ [13–416] MHz and a DSP, 256kB SRAM, 32 MB of SDRAM and 32 MB of FLASH, and baker's dozen of I/O ports of various stripes in addition to the radio and antenna. It has two pairs of connectors for sensor boards, a set for a "basic sensor board" on one side and an "advanced sensor board" on the other side. The flash image includes the .NET Micro Framework.

The sensor boards that come with the kit are of the basic variety, but I guess that refers to the connector they use: they actually have a 3d Accelerometer, an advanced temp/humidity sensor, a light sensor and 4 channel A/D.

The Imote2 software is an add-on to Microsoft Visual Studio 2005 (yes, 2005, not 2008) and .NET Micro Framework 2.0 (yes, 2.0, not 2.5). A 90-day trial version of Visual Studio 2005 Professional is provided with the kit.

I found the programming model for the Imote2 easy to understand, as I was already fluent in C# and familiar with Visual Studio 2005 and the .NET Micro Framework. I think I could build wireless sensor network applications with this kit very quickly: in days to weeks, depending on the complexity of the application.

The processors seem plenty fast. Debugging is trivially easy. The only trouble I had with the kit was a minor but annoying deployment issue: sometimes a board would stop taking downloads, and code deployment from Visual Studio would fail. I was always able to recover from this by stopping all the software on the PC that talked to the board, disconnecting the board from the USB bus, reconnecting and resetting the board, and restarting the software.

According to the company, this is most likely a problem with the Microsoft USBSPOT driver. Once I had a board programmed, it would be fine.

The picture at the top of this article is the hardware configuration for the most advanced demo in the kit, a star network in which two battery-powered CPU/sensor stacks transmit accelerometer data, one CPU board receives the signals and sends them over the USB cable, and the PC plots the live output, as shown at left. Overall, this is a very impressive kit.

Martin Heller is a Web and Windows programming consultant, is a Contributing Editor for InfoWorld. He develops databases, software and sites, and writes, edits and consults from his office in Andover, Massachusetts, as he has for over 20 years. For more information on Crossbow's Imote2.Builder kit, please contact sales or visit our website here.

Programming with the .Builder Jedi

by Martin Turon, Director of Wireless Software, Crossbow Technology, Inc.

Today we are lucky enough to have a quick lesson in programming using Crossbow's Imote2.Builder kit with Crossbow's Director of Wireless Software and our resident Programming Jedi - Martin Turon. Not only an expert in the field of wireless sensor networks, Martin has been instrumental in simplifying the WSN user experience with advancements in interface and server tools using his background in video game design, mobile phone software and operating systems. He is the current Chair of the ZigBee WSN group which is working to establish the standard for low-power routing while leading the Wireless software development team at Crossbow for future product enhancement. Martin obtained degrees from University of California, Berkeley in Electrical Engineering and Computer Science. He has also studied Artificial Intelligence at University of California, Los Angeles and received a certificate in Math for Financial Engineering from Haas Business School. Martin is an avid lover of indie rock and performs with various ad-hoc musical projects.

Embedded programming has historically involved pulling out your C compile, and writing detailed code that needs to carefully manage limited memory resources, hardware interrupts, and low-level bus interfaces. The benefits brought by newer high-level languages such as Java and C# have lagged entry into this space by about 5-10 years. The delay can be attributed to limits to memory and processing speeds within the space due to aggressive cost requirements, and a lack of tools and software support for embedded platforms compared to PC/server platforms. More recently, the J2ME and Windows CE platforms have made Java and C# respectively available to smart phone and PDA application developers. But both of these environments continue to limit the amount of control the developer has over low-level interrupts and hardware resources. The Microsoft .NET Micro environment that powers the Crossbow Imote2 .Builder kit allows programming an embedded device with C#, while providing native control over hardware resources such as the I2C, SPI, and UART buses. Programming a native IEEE 802.15.4 radio driver for example is possible in this environment, and the full source code for such an implementation is provided.

There are it seems endless sites that compare C# against Java. They can in many ways be considered the same language fundamentally, with C# being largely derived from its Java parent adding a few new keywords and constructs. The biggest difference comes with the libraries that the developer links to, which can be very different depending on the version and underlying platform that is chosen. C# does have one essential advantage however for the embedded developer, and that is native handling of unsigned types. In Java all variables are signed, so in order to manipulate a 16-bit ADC value for example one needs to jump through hoops:

// Java code to read little-endian unsigned 16-bit data: complex.
public short readShortLE() throws IOException {
     int w, wlo, whi;
     wlo = (0x000000FF & (int)super.readByte());
     whi = (0x000000FF & (int)super.readByte()) << 8;
     w = whi | wlo;
     return (short)w;
}

// C# code to read little-endian unsigned 16-bit data: simple.
public ushort readShortLE() {
    return super.readByte() | (super.readByte() << 8);
}

This example shows how much more intuitive and readable the embedded C# code is over Java due to the simple addition of ushort and uint types. Writing Java code that correctly handles unsigned types is actually fairly difficult to do, and the initial implementation of such code tends to have hidden bugs for certain portions of the data range.

In the following example, the start of a simple SPI-based sensor driver is presented. This driver sends low level commands over a SPI bus to a digital 3-axis accelerometer. The code shows how to initiate a SPI configuration and how to read and write registers over the bus. The example also includes creating a property API for accessing a particular register on the digital sensor, in this case Accel_X. On node conversions and intelligence can be easily written right into the driver within the property code block.

using System;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using Crossbow.platform.imote2;     
   
public class AccelerometerSensor
{
    internal enum Reg : byte
    {
       // Control
       CTRL_REG1 = 0x20,
       CTRL_REG2 = 0x21,
       // Accelerometer Data Registers
       OUTX_L = 0x28,
       OUTX_H = 0x29,
       // ...More commands left out for brevity..
    };          SPI                _spi;

    SPI.Configuration _spiConfig;        

    public void Initialize(SPI.Configuration spiConfig)
    {
       if (spiConfig == null)
       {
          _spiConfig = new SPI.Configuration(
              Pins.GPIO_PORT_SSP1_SFRM, // Chip select port
              false, // Chip select active state
              20, // Chip select setup time
              20, // Chip select hold time
              false, // Clock idle state
              true,  // Clock edge
              986, // Clock rate KHz (986KHz)
              SPI.SPI_module.SPI1 // SPI port connected to LIS3L02DQ
              );
       }
       else
       {
          _spiConfig = spiConfig;
       }
       try
       {
          _spi = new SPI(_spiConfig);
       }
       catch (Exception ee)
       {
          Debug.Print(ee.ToString()); 
       }             
       // Power up, no decimation, no self-test, enable x/y/z
       WriteReg(Reg.CTRL_REG1, 0xC7);
       WriteReg(Reg.CTRL_REG2, 0x04);
       // Normal, continuous, little-endian, 4-wire,
       // right justified, enable data-ready        
    } 

    internal void WriteReg(Reg reg, ushort data)
    {
       byte[] write = new byte[] { (byte)reg, (byte)(data) };
       try {
          _spi.Write(write);
       }
       catch (Exception ee)
       {
          Debug.Print(ee.ToString());
       }
    }

    internal byte ReadReg(Reg reg)
    {
       byte[] read  = new byte[1];
       byte[] write = new byte[] { (byte)((int)reg | 0x80), 0 };
       try
       {
          _spi.WriteRead(write, read, 1);
       }
       catch (Exception ee)
       {
         Debug.Print(ee.ToString());
       }
       return read[0];
    } 
   
    public ushort Accel_X
    {
       get {
          ushort accel_x = (ushort)ReadReg(Reg.OUTX_H) <<8;   
          accel_x |= (ushort)ReadReg(Reg.OUTX_L);
          return accel_x;
       }
    }
}

The Imote2 hardware provides arguably the highest performance mote platform while retaining good power characteristics, dwarfing other platforms with regard to processing speed, and memory and flash size (click on the table for more details).

This capable hardware coupled with the simple C# environment of Visual Studio and the Microsoft .NET Micro framework results in higher developer productivity. Creating advanced WSN (wireless sensor network) applications and test beds that involve in-network processing, high-speed sampling, and logging has never been easier.

The kit CD includes full C# source code for an Imote2 application that streams accelerometer data over the IEEE 802.15.4 radio. Two sample PC applications receive this data from an Imote2 base station and interpret it: MotePlot and MotePong. The former plots the real-time accelerometer data as a chart, and the later interprets the readings as control information to play a simple and familiar game.

To purchase a WSN-IMOTE2.Builder kit or receive further information on this platform, feel free to email Crossbow directly at sales@xbow.com. Additional details such as datasheets, manuals are available here on Crossbow's website. The Imote2.Builder simplifies and accelerates the design of wireless sensor applications. The level of performance and capability that the Imote2 brings to wireless sensor networks breaks the computational and memory limitations of current platforms by orders of magnitude for applications involving data-rich computations where there is a need for both high performance and high bandwidth.

HydroWatch - Following the Life Cycle of Water

In California, the word 'drought' has been thrown around more this year than I can ever remember. According to the California Department of Water Resources, the 2007 water year is on track to be one of the driest precipitation years on record in California history. This new development will soon affect all of us. In August, officials stated that they will cut water to Southern California farmers 30% by early next year and are drafting plans that could force residential water rationing for the first time in more than a decade. Our water supply is a commodity that we can not live without. Understanding and managing this resource is becoming a growing concern not only in California, but around the world.

Researchers at the Berkeley Institute of the Environment have taken the initiative to do what they can to understand and create solutions to help the future of the planet. Specifically, the HydroWatch project is designing a new framework for quantifying the incredibly complex pathways of water. By designing advanced new sensors that can monitor water above, within, and below plant canopies as well as in soils and streams, the team has a prototype system that can readily be replicated to investigate the effects of climate change and urban development on freshwater supply. The data they can gather will help to inform public policy and planning frameworks for California and beyond.

For most people, all we care to know is whether water will come out of the faucet when we turn the knob, but with the rapid pace of global warming, this may not always be true! In an effort to understand the complete life cycle of water, the researchers at HydroWatch hope to predict droughts, floods and water supply. By tracking water through the atmosphere, trees, soil, streams, oceans and back into the skies the data will provide better climate models for scientists and researchers. Inez Fung, a professor of earth and planetary science and of environmental science, policy and management at UC Berkeley, is the co-director of the Berkeley Institute of the Environment. As she noted, researchers have discovered that only 30-50% of the rain that falls on the Amazon comes from the ocean, the rest comes from recycled precipitation of the previous year. This type data would be integrated into a computer model incorporating atmospheric, surface and below ground variations of the life cycle of water serving as a benchmark for broader studies worldwide.

The HydroWatch center has deployed systems at two watersheds within the UC Natural Reserve System to set out water monitors that will send researchers real-time data on rain, air moisture, soil water content and stream flow via a wireless network and satellite uplink. This information combined with data on temperature, pressure and humidity will come from wireless sensor motes that will be placed in the tops of trees, embedded in the ground or scattered around the water shed. Before sensor networks, most environmental data was collected from small local areas infrequently, while wireless sensor networks allow data to be collected both at a higher frequency and over large spatial extents. These motes self-assemble into a wireless network that sends data to the UC Berkeley laboratories. The two California watersheds are along Elder Creek in the Angelo Coast Range Reserve and at the Sagehen Creek Field Station on the South Fork of the Eel River 20 miles north of Lake Tahoe. Other information will come from rain monitors that can chemically analyze the samples to determine where water fell and the particular area it originated from. As Fung states, "We have to plan for change in the water supply because of climate change and human actions." HydroWatch aims to track the Earth's hidden water and monitor the visible sources more intensely. The climate models and water life cycle data this project develops and collects will help to predict changes in California's water cycle and help the public be prepared for the impacts on California's economy should drought become something very real to all of us.

Is your Mote running UNIX yet?

by Ralph Kling, Chief Architect, Crossbow Technology, Inc.

Recently I have come across a very interesting research project at the University of Illinois at Urbana-Champaign. (For full disclosure the author of this article is a UIUC alumnus but in the interest of sportsmanship and balanced reporting I will keep the "Go Illini!" calls to a minimum.)

This project called LiteOS is being developed in the Computer Science Department by Professor Tarek Abdelzaher and his student Qing Cao. The goal is to provide a UNIX like operating and development environment for motes and sensor networks. A prototype implementation has been completed for the MICAz Mote. It includes an object oriented (C++ based) programming environment as well as run-time support for dynamic loading and execution of multiple threads. In addition, a file system which will be familiar to Unix/Linux users is provided as well.

The LiteOS environment consists of a PC based shell application and the Mote based runtime and file system routines. The shell implements a subset of UNIX commands such as Is, mkdir, ps, man, etc. These commands are used to interact with the file system and for process execution management. To install an application the user simply copies its executable to the file system on the target node. Remote files and directories are intuitively mapped into a network hierarchy tree. Changing the current working directory to the remote node transparently maps installation and execution commands to that node.

The shell and file system are quite responsive with average shell command execution times in the 100s of milliseconds. The file system read/write bandwidth is in the several kilobytes per second range, more than adequate for typical sensor network applications. At this time, eight concurrent threads are supported and the run-time system intelligently manages the memory map to install and remove threads without collisions.

The LiteOS team has ported the set of about 20 TinyOS demo apps (Blink, Oscilloscope, Surge, etc.). The source code size is substantially lower than the TinyOS equivalent for all applications since no component wiring is required and most of the actual work is handled by the run-time environment. The compiled code size for those applications is roughly equivalent to that of TinyOS which means that there is virtually no run-time penalty for the extra programming convenience that LiteOS affords.

Go Illini!

Dr. Ralph Kling is currently the Chief Architect of the Wireless Business Unit at Crossbow Technology. Ralph is leading the Wireless engineering team at Crossbow and is responsible for new product strategies, technical directions and Standards activities.

Previously, Ralph was Principal Architect and Director of Sensor Network Operation at Intel Corporate Research. In this capacity, he was responsible for ground-breaking research in the area of Wireless Sensor Network Platforms that resulted in such novel designs as the Intel Mote and Imote2. Before joining Intel Research, Ralph's previous assignments include managing the Itanium® Processor Family microarchitecture/ performance group and the Microprocessor Research Lab (MRL).

Ralph obtained his Master's and Ph.D. degrees from the University of Illinois at Urbana-Champaign. His thesis research focused on Simulated Evolution, a new global optimization method for integrated circuit designs. Prior to coming to the US on a Fulbright scholarship, Ralph studied Electrical Engineering in his hometown of Hanover in Germany. He enjoys skiing in the winter and beaches in the summer.

The Real Issue...

The following post is taken from DataWeek TechNews and written by a project manager at National Instruments. The article addresses the adoption of wireless sensor networks into mainstream and provides some thoughtful insight into current issues.

While wireless sensors have become a hot topic in recent years, many experts note that they remain underused commercially. Some cite confusion with the numerous proprietary and standard communication protocols as the cause, while others talk about lack of security. Companies such as Crossbow, are beginning to offer wireless sensor hardware that addresses some of those concerns, but one issue still frustrates potential users of this technology - software.Companies that provide hardware solutions typically offer network configuration and monitoring software, but the problem of allowing users to program multiple nodes at once with the same functionality has yet to be well addressed. In addition, the existing software may make sharing data among the nodes in the wireless sensor network simple, but challenges arise when users try to share that data on the rest of the network or publish it to the Web. This article discusses these and other software challenges that wireless sensor network users still face and offers potential solutions to these problems.

The current state of wireless sensor software

The software packages provided by today's wireless sensor vendors include the basics for performing wireless measurements - node configuration and management and data logging and display.

* Node configuration and management: nearly every wireless sensor vendor's software package provides some level of node configuration. For example, with Agile-Link software, a user can add a node to the system, manually put it to sleep or wake it up, and configure how fast it will stream data. Other ssoftware packages, such as Mote-View (Figure 1) from Crossbow Technology, also represent visually where the node is located on a floor plan of your facility. Most software packages also offer information on the state of each node, indicating whether the node is connected to the network and actively transmitting data.

* Data logging and display: all software packages display realtime wireless sensor data on a graph for monitoring purposes, but some such as Agile-Link also provide an interface for the user to set up basic datalogging. The user can then export data to Microsoft Excel or other spreadsheet packages for offline analysis.While these node management software tools are fairly intuitive even for beginners, they typically have fixed capabilities and lack several features that many users view as necessary for wireless sensor networks to be truly useful.

What is still missing

Wireless sensor technology has certainly come a long way in the past decade, but the software for programming and managing these nodes is still missing many of the fundamental pieces that would make it beneficial to real users, not just those experimenting with the technology. These boil down to three high-level features - node intelligence and automation, node aggregation, and integration with the rest of the enterprise.

* Node intelligence and automation: while the software packages mentioned above and others contain some basic features for configuring a node, none of them offer an intuitive method for users to customize their hardware nodes with additional intelligence, such as local analysis. Local analysis facilitates scenarios where higher-power gateway nodes aggregate and process data from several lower-power end nodes and pass minimal information, such as the result of a limit test, back to a central location. Another form of an intelligent node is one that can acquire data very fast (on the order of several kilosamples per second) and store it locally, passing back only parametric data. For example, a node might be embedded in a large machine to monitor its vibration levels. While it may be acquiring a large amount of raw data, it may only need to send a pass or fail indicator to the host indicating whether the machine is within required limits.

Crossbow has addressed this issue with the new Imote2  platform. This platform is a high performance node with local intelligence. It is built around the low power PXA271 XScale processor and integrates an 802.15.4 radio (CC2420) with a built-in 2.4GHz antenna, and it provides an extension board interfaces. The Imote2 delivers the next generation high-performance, high-capacity processor/radio platform that breaks computational and memory limitations of current platforms by orders of magnitude. It provides a high performance platform for advanced, compute intensive wireless sensor network applications such as digital imaging and industrial vibration monitoring.    

Most wireless sensor nodes today are still passive nodes that simply pass back the data they are hard-coded to provide. Very few have built-in intelligence for data analysis or automated power management. Those nodes that do have a way to incorporate additional intelligence use programming interfaces that are not nearly as simple as the node management interface described above, and users must often resort to low-level text-based programming. This is a less than ideal situation for engineers and scientists who may be experts in their fields but who are not embedded programmers.

* Node aggregation: the current node management software may work well for networks of 20 to 30 nodes, but when a government organisation or large corporation wants to implement a network of hundreds or thousands of nodes, the setup becomes extremely time-consuming. At this point, it becomes difficult to program each node individually, so software packages for programming and configuring nodes need to be able to aggregate them into groups and program an entire group at a time with the same function. For instance, an oil company may want to monitor the flow in its pipeline at many points. Since all nodes will essentially perform the same task, monitor flow and log or pass data back to a central location, the company could save time and money if they could program all nodes at once. This node aggregation capability creates a simple interface for developing redundant systems and speeds the configuration of very large networks. Wireless sensor technology cannot scale beyond research and small applications without this feature.

* Integration with the enterprise: before fully adopting wireless sensor technologies, most companies will demand the ability to easily integrate their sensor networks with the rest of the enterprise. This means not just providing a method for datalogging and offline analysis, but also offering a way to pass data directly between a hybrid network of wireless sensors and office systems that use different networking protocols (Figure 2 - Currently, most wireless sensor node data can only be logged to a spreadsheet, and no automated method exists for getting the data to the rest of the enterprise). This, in turn, requires online analysis capabilities. Being able to aggregate this data and provide access to it via a Web server is an optional but often important feature for companies whose employees are spread out across the globe or who want to give multiple internal consumers of the data easy access to it.

Crossbow has successfully demonstrated our ability to provide our customers with the ability to do enterprise integration. Our award winning  deployment with BP (British Petroleum) to do Wireless Sensor Networking for Condition Monitoring of Rotating Equipment on Oil Tankers highlighted the use of motes to tie sensors into a wireless network, which then could pass data to back-end systems. For this particular application, Crossbow provided this enterprise integration with Rockwell Enshare. The project's predictive maintenance system monitored the pumps and motors in the ship's starboard engine room. Nearly 150 accelerometers attached to the machinery provided vibration data to evaluate operating conditions, and wireless motes and gateways delivered the wireless communications used to send alerts when wear and tear was detected. 

A potential solution to much of the problem

Wireless sensor networks may seem to have a long way to go before their software can meet the majority of user needs, but a solution to some of these shortcomings actually exists today. Though it does not yet have the capability to program multiple nodes at once, a currently available software tool offers a way to program nodes, add intelligence, and integrate wireless sensor data with the rest of the enterprise. That tool is National Instruments' LabVIEW, an industry-standard graphical development environment for measurement and automation in the wired world.

* Node intelligence and automation: with the recently-released NI LabVIEW Embedded Development Module, users can program any 32-bit processor and, therefore, any wireless sensor based on a 32-bit processor. Using this tool, wireless sensor vendors can develop drivers for their wireless nodes so end users can program the nodes with LabVIEW. As a result, wireless sensor users can add custom intelligence to their nodes without complex register-level or text-based programming.

* Integration with the enterprise: NI LabVIEW and its toolkits offer compatibility with numerous networking protocols, such as TCP/IP and Bluetooth, and databases, such as Microsoft Access, SQL Server, and Oracle. As a result, a host computer can run a LabVIEW program to aggregate data from multiple wireless sensor nodes and automatically send it to other machines on the network or store it to a database. In addition, LabVIEW Full Development Systems and higher include a built-in Web server, so a host computer can aggregate data from the nodes and serve up the data in realtime to a website that clients of the data can access and even control through their web browser. (Figure 3 - LabVIEW provides database connectivity and a built-in Web server so that wireless sensor node data can easily integrate with the rest of the enterprise.) Even though LabVIEW cannot yet program multiple nodes at once, a user can build a standard configuration, save it, and download it to each node in turn.

Several top universities and many corporations already place heavy emphasis on wireless sensor technology research. As the buzz around wireless sensors continues to grow and hardware platforms and protocols proliferate, the software must scale to meet the needs of users who could most benefit from implementing them. By providing LabVIEW drivers for wireless sensors, manufacturers can open the door to a whole new set of users who require node intelligence and integration with the rest of their enterprises."

Crossbow has worked closely with National Instruments to provide the necessary tools customers need to successfully deploy wireless sensor networks quickly and easily. National Instruments (NI) provides free LABVIEW drivers for Crossbow wireless sensor networks, giving developers working with these devices the ability to fully integrate their wireless sensors into the LabVIEW graphical development environment. This free driver software works with several of the Crossbow sensor boards and includes communication functions and example programs compatible with these sensors. With the help of these drivers,  developers can start reading from their sensors within a matter of minutes, saving them time and resources because they do not have to write custom interfaces themselves.