Sign In Start Free Trial
Account

Add to playlist

Create a Playlist

Modal Close icon
You need to login to use this feature.
  • Book Overview & Buying Building Wireless Sensor Networks Using Arduino
  • Table Of Contents Toc
Building Wireless Sensor Networks Using Arduino

Building Wireless Sensor Networks Using Arduino

By : Matthijs Kooijman
4.2 (11)
close
close
Building Wireless Sensor Networks Using Arduino

Building Wireless Sensor Networks Using Arduino

4.2 (11)
By: Matthijs Kooijman

Overview of this book

Arduino has been established as the de facto standard microcontroller programming platform, being used for one-off do-it-yourself projects as well as prototypes for actual products. By providing a myriad of libraries, the Arduino community has made it very easy to interact with pretty much any piece of hardware out there. XBee offers a great range of low-power wireless solutions that are easy to work with, by taking all of the complexity of wireless (mesh) networking out of your hands and letting you focus on what to send without worrying about the how. Building wireless sensor networks is cost-effective as well as efficient as it will be done with Arduino support. The book starts with a brief introduction to various wireless protocols, concepts, and the XBee hardware that enables their use. Then the book expands to explain the Arduino boards to you, letting them read and send sensor data, collect that data centrally, and then even control your home from the Internet. Moving further more advanced topics such as interacting through the standard Zigbee Home Automation protocol, or making your application power-efficient are covered. By the end of the book, you will have all the tools needed to build complete, real-world solutions.
Table of Contents (8 chapters)
close
close

Starting and joining a network

To start sending data between your XBee modules, they all have to be joined to the same network first. In the previous examples, you have used a single coordinator and router, which together have automatically formed a network. In this section, you will learn a bit more about how these networks are formed and how addressing works.

The ZigBee protocol defines three different device types: coordinator, router, and end device. These are explained next:

  • A coordinator starts a network and allows other devices to join it. It otherwise acts as a normal router. Each network must have exactly one coordinator.
  • A router joins an existing network and will forward (route) packets on behalf of other members in the network, creating a mesh network. However, to maintain this routing functionality, routers cannot enter sleep mode and should usually be mains-powered.
  • An end device is more limited: it cannot do routing itself, instead relying on a router (or the coordinator) to route its messages to their destination. Unlike routers, end devices can sleep to save power.

A typical network might look like this:

Starting and joining a network

Note that the coordinator and routers can talk to each other (when they are close enough), but each end device can only talk to a single router (or the coordinator).

In the first chapters, you will use a single coordinator and one or more routers. In Chapter 6, Finishing Touches, end devices will be discussed in more detail.

In ZigBee, a network is identified by a PAN (Personal Area Network) identifier. When a coordinator is first started with its default settings, it will automatically start a new, unencrypted network by selecting a random PAN ID and a random channel. When a router or end device module starts, it will start scanning all channels for existing networks that allow new modules to join, select one, and join it. In the default configuration, coordinators and routers allow new devices to join the network without restriction.

There are a few related read-only configuration values supported, shown under the Networking category in XCTU:

Starting and joining a network

In the preceding screenshot, you can see the OP value. This is the Operating PAN ID: the PAN ID of the network created by the coordinator (or, on a router or end device, the PAN ID of the network successfully joined). The CH Operating Channel value shows the channel number selected by the coordinator (you might need to click on the Refresh button at the top to see the most recent values here).

Note that there is a second operating PAN ID here: OI. OP is a 64-bit long version, which is used in scan requests, beacons, and network joining, but OI is a 16-bit short version, which is used in most packets to save transmission time. If two different networks happen to have selected the same 16-bit PAN ID, the network can detect this and the conflict can be resolved by switching to a new 16-bit PAN ID. The 64-bit PAN ID will never change (unless of course the coordinator leaves the network, starts a new one, and ID is not set).

Also note the ID configuration value. This allows preconfiguring the 64-bit PAN ID on your modules by using a non-zero value. On a coordinator, this means the started network gets this 64-bit PAN ID. On routers and end devices, this means that the module will only join networks with a matching PAN ID and will ignore all others. Preconfiguring a PAN ID can help to prevent unexpected behavior (consider the case where your neighbor is also running a ZigBee network, and your nodes are joining his network instead of yours).

Go ahead and select some random 64-bit number for your network. This can be some easy to remember number, or whatever you like (unlike encryption keys, there is no security benefit of having a true random number here). Configure this number in the ID configuration value on both nodes. Changing the ID value on your modules will automatically cause them to leave their current network and create (or try to join) a new network.

You will see that, after this (and refreshing the configuration values in XCTU), the OP value (Operating 64-bit PAN ID) is set to the value you configured, but the OI value (Operating 16-bit PAN ID) is now different from before.

Module addressing

In addition to a PAN ID for the entire network, each module also has two addresses of its own. Using these addresses, modules will only receive data that is intended for them, and they can identify the sender of any data they receive.

The two different addresses for each module are:

  • A 64-bit extended address. This address is preconfigured in all XBee modules in the factory and can never be changed. These addresses are also called EUI-64 (Extended Unique Identifier). These identifiers are distributed by the IEEE, ensuring that every one of them is guaranteed to be globally unique (similar to MAC addresses in Ethernet adapters).

    The 64-bit address of your XBee modules can be found by looking at the SH and SL configuration values (which contain the upper and lower 32 bits of the address respectively), and is also printed on a sticker on the module itself (16 hexadecimal digits).

  • A 16-bit short address. This address is used in normal communications and is assigned to a module when it joins the network. Normally, this address does not change until the module leaves the network again, but there is a chance that two modules could end up with the same short address, in which case both modules will get a new short address assigned automatically.

    The coordinator always gets the 0x0000 short address, while 0xfffe is reserved for specifying an unknown address (this is usually used when the 64-bit address is known, but not the 16-bit address).

    The short address assigned to a module can be found by looking at the MY configuration value.

Network scanning and remote configuration

To verify that all devices have been connected to the same network properly, or to find out more about how they are connected, you can use the network scanning feature in XCTU. This feature can be accessed in two ways. The most extensive one is by switching to the Network working mode at the top right:

Network scanning and remote configuration

Start a network scan using the Scan the radio module network button:

Network scanning and remote configuration

Alternatively, you can also directly click on the Discover radio nodes button next to a connected module in the list on the left. The former method shows more details about the network, such as a graph containing links, and shows all devices found. The latter method shows detected nodes in a list and only shows XBee modules.

To help identify nodes, the NI (Node Identifier) configuration value in the Addressing section can be used. This is just a human-readable name for this XBee module, which can help you tell them apart (though it is not shown in the network scan with the 6.2.0 version of XCTU, unfortunately).

In addition to discovering remote devices, you can also configure any remote XBee modules, just as if you are connected directly to them. To do so, double-click the device in the graph, or select it in the discovery list, and click on Add selected devices. Go ahead and explore these XCTU features; they might come in handy later.

The Commissioning button and LEDs

Some XBee adapters or shields have a commissioning button, which can be used for some limited interaction with the module (such as briefly allowing new devices to join the network or doing a factory reset—see the product manual for details). Such a button simply connects to the AD0/DIO0 pin on one side and GND on the other, shorting them together when the button is pressed. If your setup does not have a button, it is easy to add one, or simply use a jumper wire to briefly make the connection to emulate a button press. Also, note that some adapters have a reset button (to reset the XBee and/or Arduino), so be sure to check what kind of button you have.

More commonly, adapters and shields have a LED connected to the XBee Associate/DIO5 pin (the associate LED) and/or the RSSI/DIO10 pin (the RSSI LED). The associate LED is lit continuously when a device is not joined to a network, but slowly blinks when the XBee module is successfully joined. It can also be used for more advanced diagnostics together with the commissioning button; see the product manual for details. The RSSI LED indicates the signal strength of the most recently received signal (the better the signal, the brighter the LED).

Both LEDs and the commissioning button can be disabled through the XBee configuration (to save power, or allow reusing the pin for a different purpose), but are enabled by default (though there will not always be a button or LED connected, of course).

CONTINUE READING
83
Tech Concepts
36
Programming languages
73
Tech Tools
Icon Unlimited access to the largest independent learning library in tech of over 8,000 expert-authored tech books and videos.
Icon Innovative learning tools, including AI book assistants, code context explainers, and text-to-speech.
Icon 50+ new titles added per month and exclusive early access to books as they are being written.
Building Wireless Sensor Networks Using Arduino
notes
bookmark Notes and Bookmarks search Search in title playlist Add to playlist font-size Font size

Change the font size

margin-width Margin width

Change margin width

day-mode Day/Sepia/Night Modes

Change background colour

Close icon Search
Country selected

Close icon Your notes and bookmarks

Confirmation

Modal Close icon
claim successful

Buy this book with your credits?

Modal Close icon
Are you sure you want to buy this book with one of your credits?
Close
YES, BUY

Submit Your Feedback

Modal Close icon
Modal Close icon
Modal Close icon