Hands-on with the Internet of Things – Part 2

This entry is the next part of a series in which I share my experience building a solar-powered camera node for a ZigBee mesh network. These posts are not intended to be a tutorial on ZigBee; there are lots of places to find that information, one of the most digestible being Building Wireless Sensor Networks by Robert Faludi.

With the parts gathered, the next step was to get the XBee modules communicating with each other. Just to be clear on the terminology I’m using: ZigBee is a communications protocol for low-power wireless mesh networking. The XBee modules I’m using are radio modules from Digi that use the ZigBee protocol. There are other XBee modules that use different communication protocols, but for this project it’s ZigBee I’m interested in.

IMG_0982
IMG_0983
IMG_0984

To begin, each XBee module needs to be configured according to its role in the network. A ZigBee network needs one Coordinator, which is a node that forms the network, hands out addresses to other nodes, and routes information between nodes. A Router node can join a network, send or receive information, and route information from other nodes. An End Device node can also join a network, but it sleeps most of the time, and only wakes up to send or receive information. It doesn’t route information from other nodes. The diagram below shows an example network with the three node types.

Part 2 diagrams.001

For this project, the Coordinator will be the node at the house, and the node to which all the remote nodes send images. The Coordinator can be anywhere on the network, but since it plays a vital role on the network, I thought it would make sense to give it the most reliable power source.

One of the nice features of a mesh network is that it can create new data paths if a Router node becomes unavailable, or if the signal strength of one of the available paths changes. For example, the End Device on the right-hand side of the diagram has two paths to choose from; if one of the Router nodes becomes unavailable, the other Router node can be used to send data to the Coordinator.

To get the XBee modules talking, I set up the simplest network possible, with a Coordinator and a Router, as shown in the diagram below.

The Coordinator will be the XBee module on the XBee Explorer USB dongle. The Router will be the XBee module on the Arduino shield.

To tell each module its role in the network, and update its firmware, we need to use a utility from Digi, called X-CTU. X-CTU only runs on Windows, unfortunately, so Mac users will need to use Fusion or VirtualBox to spin up a Windows VM. I used VirtualBox for this.

We can also use X-CTU to tell a module which PAN (Personal Area Network) it belongs to, and configure its destination address, along with stacks of other parameters. We can also use the module’s terminal mode to do that, with AT modem-like commands.

Terminal view of the coordinator 2

The modules have defined serial number addresses, as each ZigBee radio is uniquely identified. On my modules, the addresses are:

Coordinator address
High: 13A200
Low: 409959F7

Router address
High: 13A200
Low: 409959D6

I decided to use a PAN identifier of 2001.

For the purpose of this initial setup, I told the Router that it’s destination address is the Coordinator, and vice versa. In the screen shot above, you can see that I’m setting up the Coordinator and setting its destination address to that of the Router.

I programmed the Arduino to repeatedly send a simple-but-friendly message.

int index = 0;
void setup() {
  Serial.begin(9600);
}
void loop() {
  String message = "Hello " + String(index++);
  Serial.println(message);
  delay(5000);
}

A potential trap for newbies is that, by default, the XBee shield uses the Arduino’s hardware serial port, which is also used for programming the Arduino with new sketches (the program running on the Arduino). Initially I thought I would need to take off the XBee shield each time I needed to update the Ardiuno’s software, which was going to get annoying after a while. Then I discovered the DLINE / UART switch on the XBee shield. In the DLINE position, the hardware serial port is used for uploading sketches; in the UART position, the hardware serial port is used for talking to the XBee.

On the Mac connected to the Coordinator node, I wrote a simple Ruby script to receive and display the messages from the Arduino.

require 'serialport'
sp = SerialPort.new "/dev/cu.usbserial-A901JYV9", 9600, 8, 1, SerialPort::NONE
loop { puts sp.gets }

With this setup, I was able to move the Arduino to the other end of the house, and the message was received by the Coordinator without any hiccups. Admittedly the 30m distance wasn’t much of a challenge for the radio, but it did need to go through several walls, a TV, a bookshelf, and a fish tank.

All good so far; onward to sending images! In the next installment, I’m going to get the Arduino capturing images from the camera.

Want to know more about how DiUS can help you?

Offices

Melbourne
Level 3, 31 Queen St Melbourne, Victoria, 3000

Phone: 03 9008 5400

Sydney
The Commons

32 York St Sydney,

New South Wales, 2000

DiUS wishes to acknowledge the Traditional Custodians of the lands on which we work and gather at both our Melbourne and Sydney offices. We pay respect to Elders past, present and emerging and celebrate the diversity of Aboriginal peoples and their ongoing cultures and connections to the lands and waters of Australia.

Subscribe to updates from DiUS

Sign up to receive the latest news, insights and event invites from DiUS straight into your inbox.

© 2024 DiUS®. All rights reserved.

Privacy  |  Terms