2. System Overview

2.1. WSN Basics

Let’s look at a few scenarios:

  • A diabetic patient has to take insulin injections regularly but sometimes forgets if she has already taken her dosage. Using a reed switch, a system can be developed to monitor insulin intakes and give timely reminders if the patient forgets to take her dosage.
  • On a farmland or even in urban rooftop gardens, it is possible that we forget to water the plants or give too much water. What happens when we go on long holidays? Soil moisture sensors can be attached to the soil. These can be integrated to an automated watering system.
  • A manufacturer claims that your water heater is energy efficient but you suspect it is consuming too much. In this case, you can connect a voltage and current sensor to the power socket. Power consumption can be monitored accurately. Usage patterns over weeks and months can be plotted and analyzed. You can even figure out how much more energy is required in winter than in summer.
  • You have a pet that likes to go out often through the pet door/flap. The problem is you don’t know if he is in or out. You would also like to know how many times in a day he goes out. A reed switch can help in tracking the open/close operations of the pet door. It can also tell the direction in which the door has been opened.
  • Summers can be harsh these days. You like to bring up the blinds in the mornings and bring them down in the afternoons. The problem is that both you and your spouse are out at work. A simple system based on predetermined timers should work. A better solution could be based on a combination of temperature sensor and ambient light sensor. The blinds can then be rolled up or down depending on the conditions.
  • In many developing countries water is a problem. Water is often stored in overhead tanks and underground sumps. People have to regulate water usage depending on availability. Sometimes water has to be pumped from underground sumps to overhead tanks. It is difficult to tell how much water is left in storage. A pressure sensor can indicate water levels. Water levels can be tracked regularly to inform usage patterns. Leaks can be identified.

The above scenarios have one thing in common. All of them require sensors. These are devices that sense real-world parameters such as temperature, humidity, light intensity, pressure, weight, magnetic fields, and many more. Sensing is only part of the equation. The next step is to communicate the data so that users can benefit from it. For the purpose of connectivity and data transmission, wireless comes into play. Thus, a Wireless Sensor Network (WSN) is a network of sensors interconnected via wireless technology.

These are the days when devices are becoming smart. They can sense the world around them and pass this information around. Many devices connected into a system can enable smart decision making. So soil moisture sensors not only sense moisture, but because they are linked to intelligent software, they can also trigger an automatic plant watering system. Often these devices are called nodes or motes. Often motes do basic processing, filtering and formatting of data locally before they are transmitted into the network.

WiSense has developed motes to enable smart applications both at device level and system level. Each mote has a microcontroller for local processing. We use Texas Instruments’ MSP430G2955 microcontroller. Each mote also has a radio module that provides wireless connectivity. We use Texas Instruments’ CC2520 ultra low power radio. This operates on IEEE standard 802.15.4 PHY and MAC layers. With this platform, it becomes easier for developers to focus on their applications without worrying about either hardware design or radio performance.

Figure 1: WiSense Network Architecture

_images/WSN-NwArch.png

Figure 1 gives the network architecture of a WSN as enabled by WiSense platform. The firmware elements provided by WiSense include:

  • Reduced Function Device (RFD): This is basically a smart mote that has sensors and minimal firmware code for wireless connectivity and local processing. An RFD joins the network by connecting to the coordinator. Once sensor data is available, it transmits the same to the coordinator.
  • Full Function Device (FFD): This is similar to an RFD in that it can also have sensors attached to it. Beyond that, an FFD device can also serve as intermediate relay node for the purpose of message routing. Often an RFD has no direct wireless link to the coordinator. Therefore it sends data to a neighbouring FFD, which takes care of routing that data to its neighbouring FFDs. This chain continues until the coordinator is reached. In networking terminology, this is called mesh routing, which is fully support by the WiSense platform.
  • PAN Coordinator (COORD): The coordinator is the master in the network. It is the centralized control point in the network. Multiple networks can exist in the same location but there will be only one coordinator per network. RFDs and FFDs associate with the coordinator when they join that particular network. Coordinator assigns each node a PAN address that’s valid within the network. This is usually a short address and more energy efficient than using a long IP address.
  • Gateway (GW): Gateway functionality is usually co-located with the coordinator. Messages send from RFDs and FFDs are destined to the coordinator. Control messages are processed by the coordinator but sensor data is usually sent to the gateway for transmission towards LAN/WAN. The gateway can have its own control messages, which are sent to nodes via the coordinator. The gateway can implement many different interfaces to the LAN/WAN. At its simplest, the gateway has a wired UART interface to a computer where data is stored, analyzed and visualized. In a more complex scenario, gateway has a Wi-Fi interface to LAN where an enterprise server handles all transactions. This server can also use the Internet to send notifications to users on their smartphones and tablets.

There are two ways to view sensor data coming from many devices across the network:

  • For a small network, xively provides cloud storage and live graphs of incoming data.
  • For a large network or something that requires customized data handling and visualization, WiSense provides a software for network management (NM) and network operations and maintenance (OAM). This comes with powerful tools for data visualization and analysis. Users can customize this software to their requirements. This software is named WiSight.

2.2. WiSense Architecture

2.2.1. Hardware

Figure 2 shows the hardware architecture. The microcontroller and radio are interfaced via SPI and GPIO. Sensors can be interfaced in many ways: SPI, I2C, GPIO or UART. UART is typically used today by the gateway. EEPROM must be programmed with a 64-bit identity before the device is commissioned into the network. It is the operator’s responsibility to ensure that each device has a unique identity within the network.

Figure 2: Hardware Architecture Diagram

_images/HwArch.png

Figure 3 shows the controller board. The connectors are stackable, which means that all WiSense boards can be stacked on top of one another. On the other side of this board (not shown in picture) are 4-wire JTAG pins for programming and debugging. A 3-pin UART interface sits next to the JTAG interface. Pinout details are documented in section Hardware API.

Figure 3: MSP430G2955 Controller Board

_images/wsc2520-labels.png

Figure 4 shows the radio module. For wireless operation, an antenna is required. In Figure 4, the antenna is etched on the PCB. WiSense sells two more antenna variants: chip antenna mounted on the board, whip antenna that can be attached to the board via a threaded connector.

The actual radio board is soldered on top of a base board fitted with two basic sensors: a temperature sensor and an ambient light sensor. On the other side of this board (not shown in picture) is a CR2032 coin cell battery holder.

Figure 4: CC2520 Radio Module

_images/wsr2520p-labels.png

2.2.2. Software

Figure 5 illustrates the layers of WiSense software stack. WiSense provides implementation of all these layers. Adaptation layer provides an easy way for applications to use the radio without worrying about low-level details.

Figure 5: Software Stack

_images/SwStack.png

2.3. WiSense Advantage

2.3.1. Modular Design

The hardware platform is modular in design. This means that as an application developer, you can pick and choose what you want. Because WiSense nodes are not monolithic, you are not forced to buy what you don’t require. You have the freedom to customize, redesign and reuse. It also means that the same hardware can be used as RFD, FFD or coordinator. This is determined at the time of programming each device.

Figure 6 shows how complementary modules can be stacked to form a WiSense mote. Sensor board is a special board on which as many as eight sensors can be soldered. However, the base board of radio modules too can have two basic sensors as shown in Figure 4. Coin cell battery holder is usually at the bottom side of sensor board and radio base board. Either one can be used depending on the mote configuration.

The hardware shown on the right side of Figure 6 is a radio module stacked on top of a microcontroller board. When compared against Figure 4, we can see that this mote uses a whip antenna rather than a PCB antenna. The sensors are also missing since they are optional. It is common to omit the sensors for the coordinator.

Figure 6: Stacking of Hardware Modules

_images/HwStacking.jpg

2.3.2. Mesh Routing

Motes that are far away from the coordinator can still be part of the network. They communicate via intermediate nodes (FFDs) using our implementation of mesh routing. Thus the route between a remote mote and the coordinator is formed via multiple hops. Our routing algorithm is based on Ad hoc On-Demand Distance Vector (AODV), RFC 3561.

Figure 7 illustrates an example of a route from RFD R0 to the coordinator.

Figure 7: Multihop Mesh Routing

_images/WSN-Route.png

2.3.3. Software Simplicity

Often we are asked what operating systems (OS) can be used on the WiSense platform. Contiki OS has proven itself to be popular for motes. The problem is that Contiki requires close to 100 KB of code memory and 5 KB of RAM [Oikonomou-2011]. Also, to run any OS there is a power penalty that can be prohibitive for motes running on only a coin cell battery.

The approach we have adopted is to keep the design so simple that we can do away with OS. Each mote runs a simple loop. Within that loop it constantly checks for pending events. RFDs process any pending events and go back to sleep, thus conserving precious power. For FFDs and the coordinator, the same loop brings simplicity to both design and run-time execution.

2.3.4. WiSight

WiSight is for network management (NM) and operations and maintenance (OAM). With this, an operator can monitor all devices on the network. Reporting intervals can be configured. Sensors can be disabled if required. Some nodes may be temporarily disabled for maintenance and during this time neighbours will automatically determine alternative routes. Change of routes can be visualized on WiSight. Alarms are highlighted for operator’s attention.

Once data is collected at the server, WiSight brings this data to life by plotting them. Data from various sensors are analyzed and correlated. This makes it easy for anyone to get the complete system up and running without worrying about user frontend. WiSight simplifies network management and data visualization.

Figure 8: WiSight Screenshots

_images/wsngui.png

2.3.5. Open Source

WiSense platform is open source. We don’t keep the source code a secret. You are welcome to reuse, modify and redistribute the code. This includes firmware code for the motes as well as WiSight code. You might want to read our licensing policy.

2.3.6. Building a Developer Community

Our aim is to build a developer community of enthusiasts, hobbyists and serious technology tinkerers. We provide the platform, and the community builds applications for a world of smart and connected devices.