Wireless Sensor Networks

The ZigBee protocol is a popular way of creating wireless sensor networks. It automatically forms networks that can heal themselves and provide routing.

Digi International manufactures a wide range of XBee-branded radios. For our sensor network, we will use the series 2 that support the full ZigBee protocol. Since we are located in Europe, 10mW is the maximum transmission power allowed per device.

ZigBee devices can be configured as Coordinator, Router or End Device, depending on their role in the network. Each network must have 1 and only 1 coordinator.  The others, depending on the topology and number of devices, will be configured as Router or End Device. In our network, we will configure the other devices as End Device and use a star-topology with the Coordinator as central hub.

An XBee can be connected to sensors and actuators. For our remote sensor nodes, we will connect a light sensor and a movement sensor (Passive Infra-Red). Furthermore, we will periodically send remote AT commands to the end devices to query their temperature (an XBee PRO feature) and their supply voltage.

EndDevice1     EndDevice2

The coordinator is connected to a microcontroller (a GHI Spider running .NET Micro Framework) that serves as the brain of the sensor network and a gateway to the internet.  End Devices are configured to periodically wake up, poll their sensors and send the data to the microcontroller. The movement sensor can also awake the XBee when movement is detected, so that the microcontroller is notified instantly.

In addition, some sensors are connected directly to the microcontroller: barometer, light, temperature and current. The microcontroller uses a WiFi module to send the collected sensor data to a repository on the web.


To access our data, we send it to thingspeak.com. For our network, we create a channel per end device. Each channel has four fields representing the four sensors of the end device: light, temperature, movement and supply voltage. ThingSpeak allows us to view our data in configurable graphs and react to certain conditions, for example send a tweet when movement is detected in a certain room. ThingSpeak functionality is also exposed by REST web services that easily integrate with your own applications.

The challenge is to make sense of it all. A huge amount of data is collected by the sensor network and simple graphs often don’t reveal useful information very clearly. New websites such as Open.Sen.se focus on creating (web) applications to process the raw data from the wireless sensor network and create new data, more useful than the raw bits sent by a sensor.

The microcontroller  uses the coordinator to send remote commands to the end devices to query their temperature and supply voltage. When actuators (switches, motors, …) are connected to the remote end devices, the microcontroller  can also control these using remote AT commands. You could, for example, use a switch in an Open.Sen.se application and when the switch is toggled, a value is written to an output feed that the microcontroller  polls using simple HTTP GET calls. When the microcontroller  notices a new value for the switch’s output feed, it sends the appropriate command to the remote end device, instructing it to change the value on the corresponding output pin.

The .NET Micro Framework and AIS

As it says on their website, the .NET Micro Framework is .NET for small and resource constrained devices. It offers a complete and innovative development and execution environment that brings the productivity of modern computing tools to this class of devices.

So we’ve tried it with AIS. We used the FEZ Cobra from GHI Electronics with the 3.5” touch screen:

cobra1       cobra2

Then we added a GPS receiver and implemented an embedded AIS vessel plotter. The GPS we used is the FV-M8 model from San Jose Navigation:


The device we used runs on 6V. This can be provided by batteries or an adapter. The GPS also needs a small backup battery. Without an external backup battery, the GPS will execute a cold start after every turn on. Anything between 2V and 5V should do to achieve fast GPS start-ups.

We wired the GPS to the UEXT connector pins (3.3V, GND, COM1TX and COM1RX) and supplied the backup battery power as mentioned before. Optionally, an external GPS antenna could be used, or the position could be retrieved from an external GPS device.

The vessel plotter we implemented supports dynamic, static and voyage related information, plots vessels in vicinity of your own position, has 9 range scales (0.1 Nm to 10 Nm), has a configurable proximity alarm (.05 Nm to 10 Nm with mandatory confirmation), has “target lost” indication, shows extended ship information and visualizes Rate Of Turn, Heading, Course Over Ground and projected routes of vessels.

WP_000345       WP_000346

The FEZ Cobra board has several options for receiving an AIS stream. With the ethernet port or the optional Wi-Fi module, the AIS stream could be dispatched directly to the device, for example using AIS Dispatcher.

Since the EMX module supports USB Host, another option could be to connect a receiver – such as the MarineGadget AIS receiver – to the USB port of the device. These approaches would require a .NET Micro Framework AIS parser implementation to process the AIS stream on the device.

Alternatively, the AIS data could be retrieved using web service calls. We will use this approach and make REST HTTP calls to our AIS web services. Again, there are several options to do this. We could add a wireless module and call the services over Wi-Fi, we could add a cellular radio module to reach the services over the internet, or we could just use the ethernet port on the device to connect to services on a LAN or on the internet, which is what we did here.