Imote2

October 31, 2008

Crossbow Announces IMB400 Imote2 Multimedia Board

IMB400CA Building on its popular Imote2 advanced wireless sensor platform, Crossbow Technology announced the new Imote2 Multimedia Board (IMB400), an integrated camera sensor board that simplifies the capture of rich media content for wireless sensor network applications. The IMB400 board adds rich media capabilities to wireless sensor platforms. 

Ralph Kling, Chief Architect for Crossbow Technology said “For the first time visual and audio data can be easily added to wireless sensor applications. This opens up new possibilities for wireless sensor applications, including for example, surveillance, machine vision, object tracking, animal behavior surveys, and elder care monitoring in locations and environments that would otherwise be too costly to observe with traditional monitoring systems.”

The Imote2 Multimedia Board offers a compact, power efficient solution due to its integration of camera, audio and motion detection functionality into one platform. The built-in camera can handle high-quality images with resolutions up to 640x480 pixels and 30 fps, along with audio at sampling rates of up to 48kHz.
Instead of using compute intensive image analysis to detect motion, the IMB400 uses a Passive InfraRed (PIR) sensor to pick up movement, which then activates the camera allowing for its operation as a low power device. These images can subsequently be stored, locally processed and transmitted with accompanying sound.

In addition to the PIR sensor, key subsystems include a color image and video camera chip along with an audio capture and playback CODEC. The board is supported under TinyOS, with future support planned for Linux, SOS and the Microsoft .NET Micro Framework. For more information and to order this exciting new platform, visit Crossbow's site here.

September 19, 2008

iFit, UbiFit, Wii all be Fit

Ubfit_msp In today's world of excitement and constant stimulation it is sad to note that most people are not fit. We are constantly sitting - at work in our cubicles, at home in front of the TV, on the couch playing video games, staring into our computer screens without moving... the busy lives we lead do not allow us to focus on our fitness. This trend has been noticed by organizations, researchers and companies worldwide. It has even taken over the gaming world. As I turned off my Wii system the other night after a rousing session of Guitar Hero, I began to think about Nintendo's new Wii Fit device. The idea of the Wii Fit is to offer "an environment in which working out is less daunting and as a result enjoyable -- fun, even." Imagine having the capabilities of the Wii Fit in a mobile device that can monitor your activity all the time. The idea of fitness and self image is nothing new to society but with the various technologies being employed it is becoming even easier to improve your fitness and be aware of your body's activity. So why don't UbiFit...?

Imote2..Board Researchers at University of Washington and Intel Research Seattle have been investigating how ubiquitous computing can help encourage people to sustain an increased level of physical activity that can be determined by developing a device that can be used to monitor a person's physical activity and fitness. This change is only possible by sensing the person's physical activities (i.e. walking, sitting, etc.), modeling this information and supporting real-time awareness and feedback goals with automated journaling and methods to motivate sustained behavior changes. UbiFit is geared to improving fitness through mobile devices. Now instead of calculating the steps you took with your pedometer and logging how many miles you ran, etc., your UbiFit system will collect and store all of that data for you for real-time analysis. This unique mobile sensing platform is built around the Imote2 platform. The Imote2 is an advanced wireless platform designed for data rich wireless sensor networks requring a higher bandwidth than the traditional Mote devices. Its high performance capability and small size made it ideal for this application.

Ubifit_wearable_msp In the UbiFit project, researchers are investigating how ubiquitous computing can help encourage people to sustain an increased level of physical activity. Overweight and obesity, which are linked to several serious health problems, have become a global epidemic, affecting over one billion adults worldwide. While the medical community agrees that physical activity and fitness are essential to addressing this epidemic, many adults have difficulty increasing and then maintaining physical activity in their everyday lives. Enter UbiFit. Embedded activity recognition systems typically have three main components such as 1) a low-level sensing module that continuously gathers relevant information about activities using microphones, accelerometers, light sensors, 2) a feature processing and selection module that processes the raw sensor data into features that help discriminate between activities, and 3) a classification module that uses the features to infer what activity an individual or group of individuals is engaged in and analyze the data against the individuals set goals.

UbFit_gardenphone The sensor component of the UbiFit system consists of the 'Mobile Sensing Platform' (MSP). This device has ten built-in sensors such as a 3D accelerometer, 2D compass, barometer, humidity, visible light, infrared light, temperature with UART, GPIO breakouts for additional sensors. The wearable MSP devices have 2GB flash storage and uses the Linux OS. The raw data is collected from the sensors on the MSP and fed to the Imote2. This data is then sent to a cellular or PDA like device. The feature of the UbiFit system that makes it appealing to users is its client interface called UbiFit garden. The UbiFit garden uses the on-body sensing, real-time statistical modeling of the  activity data and its novel personal display to encourage physical activity. This is not limited to detecting a specific pre-planned physical activity such as using the Nintendo Wii Fit or Nike+ system. It is not just a physical activity detection device like a pedometer. The UbiFit garden encompasses all these areas and rolls it into an easy to use and carry personal fitness monitoring device. Set up to be background on a users cellular device, the UbiFit garden background blooms on the user's mobile phone providing key information at-a-glance such as whether they are having an active/inactive week, whether they have met their weekly goal, etc. and encouraging them to incorporate physical activity into everyday life.

For more details on this project visit their site here, and for more details on the Imote2 platform visit Crossbow's site here. Now, get up off of that couch, strap on those walking shoes and UbiFit!

Ubifit.Cartoon

April 29, 2008

Imote2.Builder Kit featured in InfoWorld

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:

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

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

April 07, 2008

Programming with the .Builder Jedi

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

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

Builderimote2 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;
       }
    }
}

Moteplatformcomparison_7

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.

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

March 24, 2008

Not just a pipe dream!

Pipenetpipeline1 US water facilities and those around the world are faced with mounting operational and maintenance costs as a result of aging pipeline infrastructures. The ability to monitor and control the infrastructure is no longer a pipe dream but is on its way to becoming reality thanks to wireless sensor networks. PipeNet, is a system designed by researchers at Imperial College in London and CSAIL at MIT in conjunction with Intel Research, to collect hydraulic and acoustic/vibration data at high sampling rates as well as use algorithms for analyzing this data to detect and locate leaks. A study by the EPA (Environmental Protection Agency) estimates that water utilities will need $277 billion over the next 20 years (2003-2023) to install, upgrade, and replace infrastructure. Unfortunately, identifying the high priority areas is a non-trivial task because of the scale and age of the pipeline infrastructures. Failures of large diameter bulk-water transmission pipelines are of greatest concern as these are supply critical systems. When these failures do occur, there are dire consequences including loss of life, severe interruptions in service, degraded fire fighting ability, damage to adjacent infrastructure and buildings, and of course the multi-million dollar repair bills.

Pipenetlabpipe PipeNet is a system based on wireless sensor networks which aims to detect, localize and quantify bursts and leaks and other anomalies in water transmission pipelines such as blockages and malfunctioning control valves. The system was based on Intel Motes (the 1st generation of the Imote2 devices available today) to provide remote monitoring in near real-time with support for high data rate time synchronized data collection from multiple locations. This is a significant change from current data acquisition practices of using portable data loggers with a low duty cycle and limited remote monitoring stations that do not have the capability to do local processing or high-bandwidth transmission.

PipenetwaterlevelThe Motes were responsible for the data collection, local signal processing and relaying of data to the second tier consisting of the Stargate platform that was to relay the data back to the backend server via a GPRS modem. A special sensor board was also designed to interface to the Mote to accommodate the various analog sensors used in PipeNet. The clusters contained pressure sensors and pH monitoring sensors combined with water level monitors and pressure monitors. The mote could be configured to trigger data acquisition on a channel remotely when a monitored channel exceeded some threshold. Acoustic and vibration data analysis was used to detect and locate small leaks which are difficult to identify with hydraulic data. Vibration signals collected showed differences in the mode of wave propagation if a leak was detected. Leaks also manifested themselves in the acoustic signal which propagates uniformly in both directions away from the leak by the escaping water flowing through the rupture in the pipeline.

Pipenettiers_3The Motes communicated from the manhole to the Stargate based gateway deployed on a nearby lamppost. The Stargate, the GPRS modem and 802.11 radio were powered from the power lines at the lamp post. The Intel Mote was connected to the Stargate through its UART interface acting as a bridge between the Stargate and the motes on the pipes. This cluster head was responsible for forming the sensor network, converting the configuration data coming from the Stargate and passing it to the correct sensor node as well as delivering the data collected via the reliable transport protocol to the Stargate where it was converted back into data files. These files were periodically sent to the backend server running in the lab via the GPRS link. The Stargate was equipped with an 802.11 link to facilitate drive-by access for on-site configuration and debugging as well. Data transfer was handled via standard Linux tools, and the data files were then loaded in a Postgres database that stored the individual sensor readings. This gave users the ability to browse these sensor readings by connecting to an Apache Web server running on the server. The web site used Google Maps/Google Earth to allow users to select and browse the sensor locations of interest. Once users selected a sensor location, they could retrieve data corresponding to a user-specified date / time range and sensor type to visualize the data.

Pipenetleakgraph_2 Using the leak localization algorithms they developed, the research team was able to localize leaks to within 30 cm. The long term monitoring of pressure and acoustic signals in particular pipes will also facilitate the development of more accurate pattern recognition and classification models in the future. The next revision of the PipeNet system is using the Imote2 platform which integrates many essential components to enable high performance and energy efficient data processing. The XScale processor on the Imote2 has dynamic voltage and frequency scaling capability to allow applications to balance performance and energy needs by selecting speeds between 13 and 624 MHz. In addition, the processor includes a DSP co-processor to accelerate common data analysis primitives (e.g FFT, compression) thereby greatly improving performance and energy efficiency. This performance advantage will allow users to carry out the analysis and data reduction in real-time, thus reducing storage and power. Finally, the Imote2 includes 32 MB of SDRAM and Flash enabling the decoupling of data collection and communication with a richer peripheral support that will provide higher data acquisition rates and improve sensor integration.

PipeNet is the future of pipeline monitoring providing the capability to automatically detect leaks and bursts of water in the transmission pipelines; real-time operation with few false alarms; inexpensive to produce, install, and maintain; high-frequency data collection; the ability to differentiate between sensor and system faults; and a flexible reusable data-flow based programming environment. This system will not only improve our ability to monitor large scale water supply systems, but to conserve our natural resources and use them efficiently.

Pipenetpipelinesun_2

June 18, 2007

Crossbow's Imote2 wins 'Best of Sensors Expo' award

BronzeawardsensorsexpoCrossbow Technology's Imote2 platform was nominated for the "Best of Sensors Expo" award in the 'Communications and Networking' category.  The "Best of Sensors Expo"€ Awards honor the most exciting new products on display at the Sensors Expo and Conference, which took place at the Donald E. Stephens Convention Center in Rosemont, IL, last week. On Wednesday, June 13th, the awards were announced and the Imote2 platform received a bronze award for its breakthrough capabilities.

The Imote2 platform, which was commercially available at the end of March, is a high-performance wireless sensor network node that provides a high-throughput processor and radio platform which breaks the computational and memory limitations of current platforms by orders of magnitude while enabling low-power operation for battery-powered sensor network applications. Crossbow also offers a companion sensor board with 3-axis accelerometer, temperature, humidity, light and four channels of user-customizable A/D input. Based on the Marvell PXA architecture, it supports a 250kb/s data rate with an IEEE 802.15.4 compliant 2.4GHz band radio.  Full 32-bit computing is supported at speeds up to 416 MHz.  The Imote2 provides the most extensive support for development environment / operating systems, including TinyOS, SOS, and Linux.  The Imote2 is used for advanced, compute-intensive wirelessBronzeawardwinners sensor applications such as digital imaging, industrial vibration monitoring, seismic and acoustic based signal processing, and machine condition monitoring. The Imote2 provides the highest performance, lowest power wireless sensor solution compared to existing alternatives in the market today.

At Sensors Expo, Crossbow announced the Imote2.Builder for the .NET Micro Framework, the Imote2 SDK based on the Microsoft .NET Micro Framework. The Imote2.Builder is the industry's first set of tools for accelerating the development of entirely new wireless sensor applications on the Marvell PXA hardware platform on which the Imote2 is built. The .Builder kit simplifies and accelerates the design of wireless sensor applications by combining two powerful ingredients to create a superior embedded design: Crossbow's Imote2 hardware module and the Microsoft .NET Micro Framework software. Together they provide new developers with an industry-leading development experience for rapid prototyping of wireless sensor applications by creating proof of concept in hours or days, not weeks or months, as well as quick, familiar debugging using Microsoft's Visual Studio environment to shiftScreenshotprojectview the focus to the code, not the tools. The Microsoft .NET Micro Framework combines the reliability and efficiency of managed code with the premier development tools of Microsoft Visual Studio to deliver exceptional productivity for developing embedded applications on small devices.

The award indicates Crossbow's continued efforts to provide our customers with cutting-edge leading technology that addresses the demands for wireless sensor networks in the market today. Crossbow's complete portfolio of research and development platforms, to our wide selection of commercial-grade hardware and software tools, give customers the ability to fulfill all their WSN product needs quickly and easily.

June 06, 2007

BehaviorScope - Using WSN to Recognize Human Behavior

YalecamerasensorboardAs pervasive as radios, sensors and computing devices are in our day-to-day lives, humans still do not have a solution for a computing system that can operate autonomously as it observes the environment and acts on its own data analysis. This future concept is being taken on by the BehaviorScope project at Yale University's Embedded Networks and Applications Lab (ENALAB) as it aims to create a new breed of intelligent sensor networks that can understand and respond to complex behaviors, especially of humans, taking place in the physical world. The goal of the BehaviorScope architecture is to compose a number of heterogeneous sensor nodes into an asynchronous distributed computer that acquires its instructions directly from the physical world. By following a process analogous to speech recognition in digital voice applications, the BehaviorScope tries to parse motion patterns (as well as other virtual patterns) taking place in space and time into a set of predefined actions. Using these recognitions, a sensor-actuator network will be able to respond to different behaviors to provide services.

Camerawsnconfiguration_3 Using a combination of sensing, data processing and middleware services, the BehaviorScope interprets simple low-level sensor data into complex high level activity interpretations. In addition to its interpretive power, this conversion of raw sensor data into a more compact semantic form dramatically reduces the amount of data a network has to transport allowing multiple nodes to reason together about an activity by exchanging low bandwidth symbolic information. The framework converts the sensor network into a rule-based system where appropriate combinations of rules provide the descriptions for complex behaviors the system needs to detect. Researchers at ENALAB have already demonstrated a prototype of the BehaviorScope executing on a lightweight network of camera sensor nodes that use the Imote2 nodes provided by Intel and Crossbow.

ExampledeploymentIn the current BehaviorScope deployments, a small network of privacy preserving camera sensor nodes track people around the house during the course of the day. The observations are used in the context of the building map to create detailed daily activity summaries and to generate alarms and cell phone notifications when safety conditions are violated. The ENALAB researchers are currently working with a team of doctors to create a comprehensive library of behaviors. Multiple instances of the system are deployed in different homes and behaviors are programmed using high level scripts that allow domain experts to concentrate on the applications functionality without having to worry about low-level node code. In addition to assisted living, the BehaviorScope architecture is expected to find applications in security, workplace safety, entertainment and other domains.

Difference aspects of the BehaviorScope project are currently funded by the National Science Foundation (NSF), the Machine Intelligence Community (MASINT) and through equipment donations by Intel and Crossbow. More information and updates on the project, including hardware and software releases can be obtained at the BehaviorScope website.

May 16, 2007

The Real Issue...

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

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

Figure2* 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.

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

Figure3 * 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. 

Crossbow Technology. Copyright 2008. All Rights Reserved. Company | Wireless | Inertial Systems | ēKo | Contact Us | Privacy | Terms of Use