Structural Health Monitoring

Part 2 – Software

 
The Illinois Structural Health Monitoring Project (ISHMP) introduced earlier is working to develop an inexpensive means for continuous and reliable SHM (Structural Health Monitoring) using dense arrays of wireless smart sensors. Researchers have designed, developed, and tested sensors to produce the high-fidelity data required for SHM that can be manufactured very cheaply. Their research has also produced an enabling customizable software framework that greatly reduces both the complexity and time for development of SHM applications for smart sensor platforms.

The ISHMP Services Toolsuite provides an open-source software library of customizable services and examples of SHM applications utilizing wireless smart sensor networks (WSSNs). The ISHMP provides users with a collection of guides to help those who are new to Crossbow’s Imote2 platform, its operating system or programming languages.

As with many wireless sensor platforms, the ISHMP Services Toolsuite on the Imote2 employs TinyOS as the operating system. TinyOS is tailored to the specific constraints of sensor network applications and occupies a small memory footprint, while efficiently supporting complex programs. TinyOS applications are implemented in NesC, a C-like programming language which supports the concurrency model of TinyOS. While TinyOS has been adopted by many sensor network applications and has quite a large user-community, it can be a daunting undertaking for engineers lacking such specific programming experience to develop code for their applications. To alleviate this problem, the ISHMP Services Toolsuite was designed assuming that the typical user will have limited background in computer science. Rather, the user is expected to be familiar with basic Windows operation and have a desire for a smart SHM system that can be installed easily and operated reliably.

 
The ISHMP Services Toolsuite employs a Service-Oriented Architecture (SOA) that lends itself to further expansion, customization, and development of WSSN applications for SHM. It provides complete applications that facilitate common tasks throughout the design, testing, deployment, and monitoring of the SHM system, while utilities offer a set of basic testing and debugging commands to be included with existing applications. The SHM Services Toolsuite includes utilities for resetting nodes remotely, listing the nodes within communication range of the local node, testing radio communication performance, and changing the radio channel and power for local and remote nodes. Specific services and tools currently available include the following:

Foundation Services: The foundation services provide commonly used wireless sensor functionalities that are required to support higher-level applications. These services include basic communication and sensing functionalities.

• Unified Sensing is a TinyOS-based sensing interface for Imote2 that supports various sensor boards including Crossbow ITS400 and Illinois SHM-A. Unified Sensing service provides precise, variable-resolution time stamping of sensor data that can be used to synchronize sensor data from different sensor nodes.
• Time Synchronization is a network-wide service for synchronizing the local clocks that sensor nodes in the network locally have.
• Reliable Communication ensures reliable data communication in a wireless sensor network. Data loss, a common problem in the wireless communication, is handled by the Reliable Communication service.
• Remote Command provides an efficient means for nodes to interact with each other. A command message is delivered to receiver nodes that process the designated tasks, and returns the list of responsive nodes and requested data to the sensor node. Remote Command allows the fault tolerant features to be easily implemented in sensor applications.
• Reliable Multi-Hop Communication provides the beta-implementation of any-to-any reliable multi-hop routing for sensor network applications. Multi-hop communication is essential for monitoring of large structures, where all sensors cannot be deployed within direct communication range of a small number of base stations.

Application Services: The application services provide the numerical algorithms necessary to implement SHM applications on the Imote2s and may also be used independently.

• Synchronized Sensing resamples the sensor data, providing synchronized data. Although the local clocks are synchronized by the Time Synchronization service, the sensing start time and the sampling rate vary from sensor to sensor with a certain amount of error. The unsynchronized sensor data is synchronized by retroactive resampling using the SyncSensing service.
• CFE estimates correlation functions between two arrays of synchronized data.
• CPSD estimates cross power spectral density between two array of synchronized data.
• RD performs the Random Decrement method to estimate unscaled impulse response functions.
• ERA estimates modal properties (i.e., natural frequency, damping factor, and mode shapes) using the Eigensystem Realization Algorithm (ERA). NExT allows the correlation functions estimated from the CFE service to be used in the ERA service.
• SSI performs the covariance-driven Stochastic Subspace Identification (SSI) for modal property estimation.
• FDD performs the Frequency Domain Decomposition (FDD) algorithm for modal property estimation.
• SDLV performs the Stochastic Damage Locating Vector (SDLV) method for damage localization.
• SDDLV performs the Stochastic Dynamic Damage Locating Vector (SDDLV) method for damage localization.

Tools and Utilities: The tools and utilities provide network testing and debugging capabilities that are necessary in any large-scale or long-term WSSN deployment. These tools facilitate evaluation of the network conditions at the structure to determine appropriate values of adjustable system parameters, and assess power consumption and longevity issues.

• LocalSensing collects sensor data from the single Imote2 connected to the PC. This tool is useful for testing new sensor board hardware as well as driver software.
• imote2comm is a terminal program that provides an interface between the PC and the Imote2 through the Crossbow IIB2400 interface board. This tool is frequently used to run the application in the ISHMP Toolsuite.
• TestServices combines numerical services, CFE, ERA, and SDLV, and performs damage detection from user-defined acceleration signals. TestServices is an application example that illustrates how the numerical services can be combined.
• TestRadio allows testing the raw bidirectional communication between a local node and remote nodes.
• RemoteSensing is an implementation of the centralized data acquisition approach that collects synchronized sensor data from a network of sensors to the base station. Time Synchronization and Synchronized Sensing services used in RemoteSensing for the synchronized sensor data.
• SensingUnit, a service component that performs synchronized or unsynchronized sensing, is particularly useful for SHM application development
• IndependentProcessingPSD is an implementation of the independent processing that decentrally estimates the power spectral densities in each node.
• DecentralizedDataAggregation is an application for the data acquisition and processing on decentralized hierarchical sensor network.

Continuous and Autonomous Monitoring Services: These services provide for continuous and autonomous WSSN operation while maintaining power efficiency.

• SnoozeAlarm provides sleep cycle functionality, which greatly reduces long-term power consumption. Sensors sleep for a period of time and then wake up for a relatively short period, during which they can interact with the network. The duty cycle is configurable by the user.
• ThresholdSentry allows a subset of the network to act as “sentry” nodes that are awakened periodically to sense data for a short period of time, determine if an interesting event is in progress, and notify the base station.
• AutoMonitor is a high-level network management application that coordinates each of its components in response to various events. It schedules sensing, data transfer, and ThresholdSentry operation according to a user-specified policy, allowing the network to operate unattended.

In addition, a library of supporting numerical functions that are common to many SHM algorithms is provided including Fast Fourier transform (FFT), singular value decomposition, eigenvalue analysis, etc. Documentation is provided for each service and test application, giving specific requirements and formats of the inputs and outputs for the service. More detailed information regarding the service-oriented architecture of the ISHMP Services Toolsuite can be found here.

To illustrate how SOA of the ISHMP Services Toolsuite lends itself to further expansion and in the development of WSSN applications for SHM, consider the figure below, which shows how the system identification method can be swapped out in an SHM application. In keeping with the SOA framework, these interchangeable services share the same input and output parameters.

 
In its current form, the ISHMP Services Toolsuite requires application programmers to simply provide the code necessary to interconnect the services and tools in a way that makes sense for their applications. In general terms, this code serves the following functions:
        • Run service X at node A
        • Send a control message to node B to run service Y
        • Send results from B to A
        • Run service Z on node A taking as inputs the outputs of services X and Y

Full-scale Integration
As described in the initial post, the software and hardware developed in this research has enabled the deployment of the smart SHM system on the Jindo Bridge in South Korea. This effort is part of a trilateral collaboration between the USA (University of Illinois at Urbana-Champaign), South Korea (Korean Advanced Institute of Science and Technology, KAIST), and Japan (University of Tokyo).

In total, 70 Imote2 sensor nodes with SHM-A sensor boards have been installed on Jindo Bridge. This SHM system constitutes the largest deployment of wireless smart sensors for civil infrastructure monitoring to date and demonstrates the suitability of the Imote2 smart sensor platform, the SHM-A sensor board, and the ISHMP software for full-scale, continuous, autonomous structural health monitoring. The figure shown below shows the measured data from WSSN on the Jindo Bridge.

 
The figure below compares computational model predictions (inset) with the experimentally determined frequencies and mode shapes obtained using the frequency domain decomposition method. As can be seen, the agreement is excellent.
 

In summary, the ISHMP Services Toolsuite provides an extensive set of middleware services, utilities, and tools that enable creation of complex, data-intensive WSSN applications for structural health monitoring. This SOA-based approach creates a framework which allows application programmers to more easily create applications for SHM systems. As a result, the framework allows more researchers, and ultimately application engineers, to design and implement successful SHM systems without the requirement of understanding how the underlying middleware and numerical services are implemented.

For information on installing the Toolsuite, visit the ISHMP site here.
For more details on the Imote2 platform, visit MEMSIC site here.

The Illinois SHM Project Services Toolsuite software is open source, but not public domain. The license, a copy of which is also included in the software distribution, allows for unlimited use and modification of the software for non-commercial purposes. Unless otherwise stated, the software and source code in the package is licensed under the OSL Software License (see LICENSE.txt), and is free for non-commercial distribution. Also included are modified files from TinyOS (BSD and Intel Open Source licenses) and LAPACK 3.0 (no formal license, free for redistribution); these licenses are indicated at the top of the respective files.

 

In a BLIP, pervasive IP has arrived.

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

IPv6 was invented in 1998, over ten years ago, yet less than 1% of devices use it.

Why is IPv6 important?

The first answer is "lots of addresses".

Think of your PC and the RAM memory inside. Until recently, 32-bit processors were pervasive, and you couldn't put more than 4GB (4 billion bytes) of memory in them because of the limits in 32-bit address spaces. Now most new computers are 64-bit, and they can address 18 quintillion bytes. The Internet will eventually be forced to "upgrade" its address space as well. Currently over 99% of devices use IPv4 which uses 32-bit IP addresses that are most commonly displayed as 4 bytes in decimal: 192.168.1.100. If you want to host a web server to the world, you typically claim a static IP and one of the 4 billion possibilities is yours forever. But the population of the world is 6.7 billion, so there aren't enough to go around! And what if everyone wants multiple devices that can be uniquely addressed to serve some critical information like a cluster of wireless sensor nodes?

IPv6 is clearly the answer. It provides a 128-bit address space allowing for over 240 undecillion uniquely addressable devices. To put that in perspective, the soon-to-be 6.8 billion people in the world will each be able to have over 300 million subnets with over 18 quintillion devices in each one. That is a total of over 50 octillion uniquely addressable devices per person!  Note: The unallocated address pools in IPv4 are anticipated to be exhausted in 2012.

Which leads to the second answer: "government mandates".

In May 2009, the Federal CIO Council of the US government issued an official roadmap for IPv6 adoption. The report provides a detailed overview of the technology, it's benefits, tips on the various services and how to transition. It also tasks other government agencies with developing concrete plans for how they will deploy IPv6 and requires quarterly review of their progress.

"We can't keep operating in an IPv4 world when we're talking about sensor networks, wireless communications and mobile networks. We need more IP addresses - globally unique IP addresses - and that's what IPv6 provides. We need a target network architecture that's scalable, secure and stable." - Pete Tseronis, Federal IPv6 Working Group Chair and Deputy Associate CIO of the Department of Energy

Since the release of this document, a flurry of articles regarding IPv6 adoption has been written up in the press.

---

How can big IPv6 addresses fit on tiny motes?

Almost in anticipation of the recent uptick in IPv6 adoption, back in March some researchers at UC Berkeley released an Open Source implementation of IPv6 running on TinyOS 2.x called BLIP (Berkeley Low-power Internet Protocol). The BLIP stack runs on mote-class hardware, specifically the TelosB and MicaZ. How did they manage to fit a protocol that uses 128-bit addresses onto a platform with only 4KB of RAM? Well, beyond the fact that Stephen Dawson-Haggerty and other contributors are really really smart, the IETF has had a number of efforts to define ways for IPv6 to run on lossy, low bandwidth links for a while. The IETF timeline follows:

RFC 1883,2460 - IPv6 Specification
RFC 1885,4443 - ICMPv6 Internet control message protocol
RFC 3142 - IPv6-to-IPv4 translation
RFC 3315,4580,4649,4704 - DHCPv6 Dynamic, automatic address assignment
RFC 4861 - Neighbor Discovery
RFC 4862 - Stateless Addr Autoconf
RFC 4944 - IPv6 over IEEE 802.15.4 (6LowPAN) 

Drafts: HYDRO routing (part of ROLL [routing over low-power, lossy links] effort)

Papers: IP is dead, long live IP,  Extended Internet Architecture PhD Thesis by Jonathan Hui

---

Why is it cool?

IPv6 running on motes is cool because it really leverages what IPv6 was designed for -- ubiquitous computing.  Imagine a day when all of your appliances and consumer electronics will be able to talk to each other and provide you real time data on their energy usage, health, etc.  The ZigBee alliance has recently signed up to define a specification for an IPv6 stack in addition to an RF4CE stack for remote controls and consumer electronics.  Similar to how WiFi is integrated into all sorts of products today and just works, ZigBee may make it so cheap, tiny devices of the future can provide direct IPv6 connectivity over low-power, low-bandwidth radios.

---

What is the status of BLIP?  When will it be released?

BLIP is a work in progress.  It is currently fully supported on the TelosB platform and works on MICAz when compiled in a memory-constrained mode.  It is being folded into the TinyOS 2.x core with a slated release date of late August 2009.  The version in contrib/berkeley/blip is the correct one to use, however, as that one will actually build without manually adding radio stack modifications that are still being negotiated.  IRIS support is in the works as well with the initial port being done by European researchers Miklos Maroti and Lars Schor.  An improved release candidate of BLIP is slated to be pushed into contrib as early as next week.

---

Where can the BLIP source code be found?  How do you use it?

1) Download Xubuntos 2.1 VMware image (Howto)
2) Start the VM, login as:
  username: xubuntos
  password: tinyos
3) Start a Terminal
4) Prepare your VM to run BLIP as follows:

- Install IPv6 tools:

    sudo apt-get install netcat6

- Update tinyos-2.x trees from CVS:

    cd /opt
    # hit return for anonymous password
    cvs -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos login
    cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co -P tinyos-2.x
    cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co -P tinyos-2.x-contrib/berkeley

- Add a simple environment setup script

cd /opt/tinyos-2.x-contrib/berkeley/blip
cat <<-EOF > setenv
export TOSROOT=/opt/tinyos-2.x
export TOSDIR=/opt/tinyos-2.x/tos
export LOWPAN_ROOT=$PWD
export TOSMAKE_PATH="$LOWPAN_ROOT/support/make"
EOF

- Build the driver

    cd /opt/tinyos-2.x/support/sdk/c/sf
    ./bootstrap
    ./configure
    make
    cd /opt/tinyos-2.x-contrib/berkeley/blip/support/sdk/c/blip
    make

- Patch motelist to handle mib520 for micaz discovery

cd ~
cat <<-EOF > motelist-linux.mib520.patch
--- motelist-linux	2006-12-12 10:23:01.000000000 -0800
+++ /usr/bin/motelist	2009-05-19 11:28:26.000000000 -0700
@@ -61,7 +61,10 @@ sub scan_sysfs {
 
 # Scan /sys/bus/usb/drivers/usb for FTDI devices
 my @ftdidevs =
- grep { (\$_->{UsbVendor}||"") eq "0403" && (\$_->{UsbProduct}||"") eq "6001" }
+ grep { (\$_->{UsbVendor}||"") eq "0403" && 
+ (((\$_->{UsbProduct}||"") eq "6001") || 
+ ((\$_->{UsbProduct}||"") eq "6010")) 
+ }
 map { {
 SysPath => \$_,
 UsbVendor => snarf("\$_/idVendor",1),
EOF
cd /usr/bin
sudo patch -p0 < motelist-linux.mib520.patch

- Download Blip.micaz.patch

 - Patch the blip contrib sources to add automatic micaz support
and fix some build issues.

    cd /opt/tinyos-2.x-contrib/berkeley/blip
    patch -p0 < ~/blip.micaz.patch

5) Use your prepared VM to build and deploy BLIP:

- Enable the BLIP build environment:

    cd /opt/tinyos-2.x-contrib/berkeley/blip
    source setenv

- Build the UDPEcho app and base station for telosb and micaz:

    cd /opt/tinyos-2.x-contrib/berkeley/blip/apps/UDPEcho
    make telosb blip
    make micaz blip

    cd /opt/tinyos-2.x-contrib/berkeley/blip/apps/IPBaseStation
    make blip telosb
    make blip micaz

- Connect a TelosB via USB, and flash it with the base station code
(Install FTDI drivers if needed)
(Accept TelosB device when dialog appears)
(Right click USB device in lower right of VM and select connect)

    motelist # find ttyUSB port to use
    cd /opt/tinyos-2.x-contrib/berkeley/blip/apps/IPBaseStation
    make blip telosb install,64 bsl,/dev/ttyUSB0

- Connect a MicaZ via USB, and flash it with the remote node code
  (Install FTDI drivers if needed)
  (Accept MIB520 device when dialog appears)
  (Right click USB device in lower right of VM and select connect)

 	 
    motelist # find ttyUSB port to use
    cd /opt/tinyos-2.x-contrib/berkeley/blip/apps/UDPEcho
    make blip micaz install,1 mib520,/dev/ttyUSB0

6) Fire up Linux network driver to communicate with BLIP network:

- Start the ip-driver

    cd /opt/tinyos-2.x-contrib/berkeley/blip/support/sdk/c/blip
    sudo ./ip-driver /dev/ttyUSB0 telosb
    # password: tinyos	 
    # blip console commands:
    # blip:xubuntos-tinyos> help
    # blip:xubuntos-tinyos> log WARN
    # blip:xubuntos-tinyos> routes	

7) Use standard IPv6 tools to access the remote BLIP nodes:

    # Ping - base station and remote node
    ping6 2001:470:1f04:56d::64
    ping6 2001:470:1f04:56d::1

    # Access shell on remote node
    nc6 2001:470:1f04:56d::1

Note that BLIP ships with support for pinging a node with standard the ping6 tool, shelling into a node with netcat (the shell is a custom one, not ssh, type help to see available commands), and over-the-air reprogramming of nodes with a deluge-like interface.  BLIP is an exciting software development for the TinyOS community and users of TelosB, MICAz, and soon IRIS platforms.  We encourage you to try it and track its rapid development.

Martin Turon is Crossbow's Director of Wireless Software. 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.

Special Presentation at Sensors Expo

On June 8th at 9AM, attendees at the Sensors Expo in Chicago, IL, will have the opportunity to hear from Crossbow's Dr. Ralph Kling. Dr. Kling will be be giving a talk entitled Rich Data Types for Sensor Networks. If you are in the Chicago area or will be attending the 2009 Sensors Expo, be sure to hear Dr. Kling's presentation on the current state of sensor networking technology and how advancements in local data processing, sensor data fusion and the conversion of data to meaningful information is expanding the horizon for how and where WSNs may be deployed.

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

For more information on the Sensors Expo, click here.
For more information on Crossbow's wireless sensor network products, click here.

Details regarding Dr. Kling's presentation will be posted in the next week.

802.15.4 vs ZigBee - What's the difference?

The Wireless Sensor Network Research group (WSNRG) has published a new article titled 802.15.4 vs ZigBee which helps people understand and distinguish between all the communications technologies that are used in the WSN field: 802.15.4, ZigBee, Mesh protocols, 2.4GHz, 868MHz and 900MHz bands… This document compares both IEEE 802.15.4 and ZigBee technologies while explaining the main characteristics of each.

To summarize 802.15.4 vs ZigBee: 

• 802.15.4 is thought to be a protocol to get point to point and energy efficient communications.
• ZigBee defines extra services (start topology routing, encryption, application services) over 802.15.4.
• ZigBee creates semi-centralized networks where just the end devices can sleep
• Different completely distributed mesh algorithms are being used over 802.15.4 which is the protocol used to create.

Read the article here.

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.