Friday, March 30, 2007

Rice University work in Wireless Sensor Network Arena

I recently had the opportunity to visit with the Rice University team working on wireless sensor networks. I met with Farinaz Koushanfar and others who under the direction of Richard Baraniuk work on wireless sensor network research. They combed through numerous conference papers to research the applications and find out what software API would make for the most efficient implementation of those applications. The first lesson they found is that most applications described in the conference papers were never actually implemented but in most cases were only simulated.

What should the software API accomplish? The first response was to describe a target node set by a set of characteristics such as geography (e.g. all the nodes on Level 2), functionality (e.g. all the temperature reading nodes), condition (e.g. all the nodes that have full memories), etc.

Also, distances need to be measured in both physical distance and the number of hops to reach the destination. Sometimes, one can program the physical distance into the system while other times, one doesn’t know the exact distance but wants to make several hops (from one unit to the next) to reach the destination.

Since the nodes can move in some applications, it’s important to know where the nodes are right now – so localization is important.

To conserve energy, the software API may want to implement different receive modes. For example, a node can act as an intermediate communicator which simply passes data along, or it could act as an aggregator by collecting data from other nodes, or it could act as an analyzer which applies an algorithm to the collected data.

In a resource-constrained environment like a wireless network, the user needs the ability to adjust the “Level of effort” so he can tradeoff reliability vs. best effort. If the data still does not reach its destination, then some action can be taken such as changing the spreading code, or increasing the signal power.

It’s interesting to note that most applications the Rice team investigated require major reliability.

Finally, the team mentioned the need for a hierarchical API to describe the various classes of devices and levels (i.e. gateways, hubs, and nodes). This gives the user the ability to place the code at the right level to perform the application.


Best regards,
Hall T.

Sunday, March 25, 2007

Rice Business Plan Competition– Emerging Technologies on Display

One of my favorite events of the year is the Rice Business Plan Competition held in Houston every spring. It’s the largest collegiate business plan competition. This year the prizes topped $345K, which far outstrips last year’s $200K awards. In fact, every one of the 36 participants received some funding. Last year, I blogged on the Sadoway method which was a new technique for developing titanium which came from MIT.

This year the field of 36 plans from around the world looks even better. It’s a great view into current university-based research labs as it shows what’s moving into productization. Technologies include Life Science, Medical Devices, Software, Wireless, and more. I’m a judge of the competition in the Life Science flight. Startups apply new technologies to improve medical device performance in the area of appendectomies, breast cancer tumor removal, and heart disease detection. There’s also improve materials using nanotechnology to create anti-bacterial materials for medical devices such as catheters. The judging criteria are “Vote for the company you would most likely invest your money.” This provides quite a range of investing interests since Life Science investors look at the size of the market and the technology offered while non-Life Science investors tend to give more weight to payback timelines and risk mitigation.

One of the interesting companies presenting was Omega Sensors who proposed a MEMS-based technology which they acquired from the military for precise accelerometer measurements. It’s not clear how this technology compares to Crossbow’s accelerometers.

The University of Texas team made the finals with their nanotechnology-based drug delivery system called Nanotaxi which targets diseased cells. Nanolevel materials carrying therapeutic drugs, attaches to the ligands of a cell and then enters the cell. Once inside, if it detects a certain enzyme, the lid dissolves and releases the payload of therapeutic drug into the cell.

The MIT team promoted a new antibacterial coating that could be applied to medical devices such as catheters for reducing infections. The material did not cause drug resistance in the bacteria and did not degrade over time. Although still in the research phase the technology sounded compelling.

The winner of the Rice Business Plan competition came Johns Hopkins team called ResuRx which is a name play on “Resurrect” as their plan involved testing drugs previously discovered and then finding a new use for those drugs. By securing a “new method of use” they could claim the drug as their own and not have to go through extensive FDA trials since the drug has already been cleared.

Best regards,
Hall T.

Friday, March 16, 2007

Municipal-wide WiFi – an Update

In my last post on municipal-wide Wifi, several cities such as Anaheim, Arlington, Long Beach, and others were starting to rollout their Wifi services. The process continues to accelerate as city managers understand the benefits of wireless networking throughout the city. Public safety comes in near the top of the list. Based on this blog report it appears public safety services is easier to gain approval than others. Through high performance mesh networks such as Firetide’s system video surveillance can be implemented at a lower cost.

For those new to wireless mesh networks here’s a site that describes the technology behind it. Unlike a wireless network found in the nearby coffee shop which uses a single wireless router communicating with endpoints such as laptops and PDAs, a municipal-wide deployment uses a mesh network in which each router node connected to the internet can communicate with at least two other nodes. This creates a “cloud” of wireless coverage that can allow a user to tap into the network. Another slant on it comes from this post which brings optic fiber into the mix and describes how wireless mesh networks combined with fiber optic links can optimize the overall performance of the system.

In looking at the list of the 10 most connected cities, the US doesn’t even show up until position 7 and that is a combination of several cities. Asia dominates the list with Seoul, Tokyo, Taipei, and Singapore leading the pack followed by Sweden.

Several social forces are at play in the rollout of municipal wireless networks. The Institute for the Future lists three forces here. They include the

1. Guaranteeing citizens’ role as content providers
2. Finding a balance for location privacy
3. Enabling the Internet of Things

They fear that cities rolling out the network will give too much bandwidth to the advertisers and not enough to the users who can provide content (think Craigslist). The post goes on to emphasize that while today’s wireless network is primarily used on laptops and PDAs, the network of the future will connect things such as wireless sensor network nodes (reading temperatures, monitoring environmental factors, and more. They call this the “Enabling the Internet of Things.”

As we move forward with deploying wireless sensor network systems for industrial, safety, and other uses, we may want to monitor the decisions by municipal groups who are deploying these networks.

A rich resource of information on the topic can be found at Muniwireless.com.

For virtual instrumentation, this is an interesting area to watch as the investment into equipment grows and networks become commonplace. Virtual instrumentation leverages commercial off-the-shelf technologies. Mesh network and its implementation in municipal-wide deployments provide a promising foundation upon which virtual instrumentation solutions could run.

Best regards,
Hall T.

Friday, March 09, 2007

Moteiv’s FIRE – Intelligent Fire Information & Rescue Equipment

A new application for wireless sensor networks comes from a startup out of Berkeley called Moteiv which makes a wireless sensor network system for firefighters. Called FIRE, which stands for intelligent Fire Information & Rescue Equipment, it uses wireless sensor network technology to tell a firefighter where he is in a building even if visibility is obscured by smoke or fire. CNN ran a story on them recently. You can see the full video on YouTube here. The system monitors a building for smoke, fire, temperature, and other factors. It sends the signals to a laptop outside the building so commanders can see the position of their people and the condition of the building.

They offer three products. The Tmote Sky costs $78 per node and provides an 802.15.4 radio and sensors for temperature, humidity, and solar radiation. The Tmote Invent is a low-cost version of Tmote Sky and is designed for building automation applications. It comes with light, accelerometer, sound, and humidity sensors. They also offer the Tmote Connect which is a gateway device. All of the devices come with a TinyOS software support.

To enable software for their devices they took a copy of the open source TinyOS and made a modified version called Boomerang. You can get a free download here. In my visit to Berkeley last week several researchers indicated they use TinyOS because it’s open source and free, but they found support less than standard in some cases.

Moteiv appears to be filling a niche for those who want an unbundled solution such as what Crossbow offers. In researching Moteiv I came across an interesting paper in which the authors take a spreadsheet approach to managing the nodes in a sensor network. They used Moteiv nodes for their application. An Excel spreadsheet was modified to perform data acquisition and processing, programming the deployed nodes, and managing the run-time system of the network. I think this approach highlights the nature of managing a wireless sensor network as a technical data management challenge rather than a programming challenge.


Best regards,
Hall T.

Friday, March 02, 2007

Discussion with Bill Kaiser, UCLA on Body Area Networks

I had the opportunity to return to UCLA and visit Bill Kaiser and his work in the CENS (Center for Embedded Network Systems). In my last post, I talked about the LEAP platform they built using a dual-processor architecture. It contained a high-performance processor and a low-power consumption processor. Based on the application at hand, it would use one or the other and thus conserve battery life.

In today’s discussion we focused on the applications coming up. Bill mentioned three of them:

1. Structural Health Monitoring -- measuring building stress under various loads (seismic, wind, etc). It must be battery powered for disaster scenarios.
2. Marine – sequencing power to communication systems with on-board sensors attached to buoys. The node needs a power scheduling system to preserve power and reduce maintenance cost.
3. Biomedical – using handheld devices with wearable sensors to monitor a person’s biomedical signals. By using appropriate duty-cycling he can conserve power on the node. They need an easy-to-use programming language for users in this area to implement their own systems. There’s increasing support throughout the campus for this application area.

Philips and Qualcomm are both pursuing a body area network system to provide bandwidth for high quality transmission of CD-quality audio over short range. Bill indicated that in just a few years, anyone with a medical condition will have a handheld device (a cell phone comes to mind) that would communicate with wearable sensors detecting heart rate, and other body signals. Standards are coming into place now through a Body Area Network (BAN) interest group within the 802.15 committee.
Here’s a PowerPoint slide set that outlines the applications and a few proposed requirements. This area is gaining increasing attention due to the progress of wireless sensor networks, wireless standards, and low power processors. Here’s an article showing a multi-tiered architecture for a telemedicine application.

Along with medical data come security requirements for protecting that data. Encryption and authentication become key elements in providing a viable system. Also, keeping the data in a meaningful form that can be archived and retrieved for future purposes comes up.

It’s an interesting area, and it certainly has the attention of a large number of departments at UCLA. Going forward, this will become a key application drawing substantial resources.

Best regards,
Hall T.