Newbie Question regarding XBee Pro Version 1 Modules

Hello everybody, I have to build an application which uses the XBee Pro Version 1 modules but I am quite new to wireless networks and to the XBee chip mentioned. I am trying to decipher the manual but it is a little “rough” at times. So I would like to ask a few questions.

First some words about the application and the network topology.

  1. I need to form a chain in which an Xbee module talks only to its
    predecessor and it successor in the chain. There can be one network coordinator if necessary. The information each node has to exchange with its neighbours can be contained in 2 bytes.

Question : Do I need a network coordinator in this scenario ( is it mandatory ) ?

  1. Most importantly there might be more than a single network in the same space so I need a mechanism to force certain nodes to belong to a predetermined chain ( network ).

Question : Is this possible with the XBee module ? Can I for example fix the rf channel on which the modules communicate and thus use the 12 different channels for 12 different pans/networks in the same environment ?

If the answer to my last question is no, how can i force a node to communicate with only two particular neighbours and not interfere with all other nodes in nearby pans ?

I am very grateful to anyone that can shed some light on my doubts!

I’m not sure if 802.15.4 would be the best fit here. It sounds like you want to unicast basically in two directions, to the predecessor and successor, and that’s it.

That sounds like a linear wireless topology, and one which might work better with DigiMesh (since you’re talking about a chain of these, not just three modules, and 802.15.4 is point to multipoint only). Hopefully one of my collegues can add some additional input.

As for Digi personnel monitoring the forums, yes we do, but there’s a transition phase involved with these new forums where our e-mail notifications aren’t yet working quite right. We’re working the bugs out however, and forum responses should ramp up once we get them all worked out.

And as JohnF said… we try to hit every thread but there’s no guarantee. If an immediate issue with Digi equipment comes up, the best course of action is always to create a Support case either via our E-Service Web Portal (click on “Contact Digi Support”, lower right hand corner on the Support site), or give us a call with your serial number in hand so we can quickly identify which equipment you call about.

Series 1 XBees, in a “chain” as you say. I’d recommend changing to use peer-to-peer topology. No coordinator. Then each node can be configured with its upstream and downstream neighbor’s MAC address. Hard coded, making this a static network. So each node is a repeater. If you have alternate neighbors, hard-coded, the thing can be sort of self-healing/re-routing.

There are AT commands/registers to switch to peer-to-peer mode:
Disable coordinator role
Disable Association Required
Use only 64 bit MAC addresses

Also consider setting MAC mode to disable the Digi protocol that places two or so bytes in each packet payload.

as to not interfering wiht other nodes - 802.15.4 is a listen-before-transmitting (CSMA/CA) protocol, as is 802.11. So there shouldn’t be a problem other than slight increases in latency.

Thanks so much for the clear answers. Regarding the reply from “stevech” : if there are a total of let’s say 10 pans each made up of a chain of at least 10-20 nodes is there a way to calculate approximately altency for a single node ?
Do any of you have some pointers on documentation regarding the 802.15.4 standard ( I have the IEEE Standard documentes but I wanted something more readable for starters )?!
Thanks a lot

I’ll have a go at a response for you, but does the Digi staff read this too?

Roughly speaking…

Latency
n1 = medium access delay due to CSMA/CA. This is statistical, based on clear channel assessment. Clear channel means signal-present, from another 802.15.4 packet, an 802.11 packet if signal is strong enough (802.11 is 20MHz bandwidth, whereas 802.15.4 is 2MHz), or signal from some other transmitter. There is an exponential backoff (delay) algorithm, as in 802.11.

n2 = time to transmit the 802.15.4 packet - data length dependent. On the order of a millisecond or so. Plus time to get a MAC layer ACK (if enabled). A tenth of a millisecond or so.

So the per-hop latency is n2 (receive a packet) + n1 + n2 (retransmit packet).

you can turn off CSMA/CA, at the risk of higher packet retransmissions due to collisions.

As to simplified 802.15.4 literature— I guess I’d Google, see what’s on Zigbee’s web site, etc.

Oops - to the above, add the time to send the data from the XBee to a host microprocessor and then back again. I do this at 115Kbps using the Digi Binary API. That speed is little slower than the net yield of 802.15.5’s 256Kbps raw rate, without overhead.

Hi, I just got 5 brand new xBee modules to experiment with… Thanks a lot “stevech”. I am going to try all your above suggestions. Porbabely I will have to do some empirical measurements of latency and hope to have some results posted soon…
Marry Christmas to all for the time being…

@stevech: you asked whether Digi staff read these forums. They do, but they don’t promise to read or respond to every post because the forums are meant to let users support each other. For the most part questions posted here do tend to get answers, and if they don’t then a support request to Digi is the next step.

@babayaga: if you’re just starting out you may find my Unofficial FAQ and Cookbook (two separate documents) of some use. They’re on my web site.
They won’t answer your questions above, but they may help when other questions arise.

Hi all, I’ve got the cookbook and the faq for the xbee modules but what is troubleing me is not the inner workings of the modules but generally the possibility to do something like this :

PAN A : node 1 <–> node 2 <–> node 3 … etc…
PAN B : node 1 <–> node 2 <–> node 3 … etc…
.
.
etc…

First : is there a way to tell nodes on PAN A not to interfere with any other node on the rest of the PANs ( I am still confused about 802.15.4 : if I have less then 12 PANs can I force communication for each of my PANs on a different channel ( one of the 12 available channels as stated in Xbee documentation ) ?
Is it possible to isolate node 1 from node 3 and other further nodes along the chain on each PAN ( I doubt it but it is always good to ask :slight_smile: ).
If it is mission impossible to separate the various networks through forced channel assignment then what is the best protocol for least interference ( latency ) for a chained PAN as described above : DigiMesh as suggested by MST_616 or plain old 802.15.4 as suggested by stevech ? In DigiMesh is there packet acknowledgment and retry ? Do I need a master node ? Any comments and suggestions are welcome!
Thanks a lot guys!

Hi all, I’ve got the cookbook and the faq for the xbee modules but what is troubleing me is not the inner workings of the modules but generally the possibility to do something like this :

PAN A : node 1 <–> node 2 <–> node 3 … etc…
PAN B : node 1 <–> node 2 <–> node 3 … etc…
.
.
etc…

First : is there a way to tell nodes on PAN A not to interfere with any other node on the rest of the PANs ( I am still confused about 802.15.4 : if I have less then 12 PANs can I force communication for each of my PANs on a different channel ( one of the 12 available channels as stated in Xbee documentation ) ?
Is it possible to isolate node 1 from node 3 and other further nodes along the chain on each PAN ( I doubt it but it is always good to ask :slight_smile: ).
If it is mission impossible to separate the various networks through forced channel assignment then what is the best protocol for least interference ( latency ) for a chained PAN as described above : DigiMesh as suggested by MST_616 or plain old 802.15.4 as suggested by stevech ? In DigiMesh is there packet acknowledgment and retry ? Do I need a master node ? Any comments and suggestions are welcome!
Thanks a lot guys!

'15.4 PAN IDs are like 802.11/WiFi SSIDs. Any number may exist on any channel or channels.
Interference: '15.4 like 802.11 uses CSMA/CA (listen before transmitting).
Isolate node… Unclear what you mean.

By “isolating the node” I mean a way to shield a node from receiving any messages not belonging to its PAN. I mean physically. I do not mean that the messages are received and processed by a node but then discarded because the node is not the intended recepient. This stems from the following fear : if a have a large chain of nodes on a PAN and a lot of PANs in the same environment then a signle node would pass most of its time processing messages which are not intended for him, even though the “useful” information for this node is just 16bits from his two neighbours received every 100ms or so… So what i intend is a way to “isolate” physicaly each PAN from the others ( thats why I asked about the 12 channels : maybe each PAN could talk on a different frequency and thus would be non-existant in the eyes of the other PANs )…

Thanks a lot

802.15.4 radios normally ignore packets arriving and marked with a PAN ID (like SSID in 802.11) other than the intended PAN ID.

Ok lets say that the different PANs do not interfere with each other. What about the nodes on a single chain : if there are a 100 of them but any node can talk to just two neighbours what happens when a node is sending a message to its neighbour ? Do all the other nodes hear the message too but ignore it ? Since the protocol uses CSMD/CA in the worst case scenario a node has to back-off “number of nodes in the chain” times to speak! That means that at some point adding nodes to the linear chain makes the network totaly congested! Are you aware of some article/document testing different topologies for latency/throughput using the 802.15.4 ?
By the way : I have come across a network simulator called ns-2 which can be used for simulating 802.15.4… Anyone here used it before ? Any comments, suggestions regarding 802.15.4 simulation software ?!
Thanks a lot

I’ve been watching this thread without finding much that I can usefully contribute, but may I offer a few random thoughts?

First, what is the nature of this chain? I could imagine a need for a chain if the nodes in it were far enough apart that only direct neighbours could talk to each other at all, yet your concerns about interference seem to indicate that that isn’t the case. I think what I’m getting at here is that if we knew a bit more about your application we might be able to make other suggestions for the topology.

Assuming now that the nodes really do need to behave as a chain, I can’t see why there’s any need (or indeed possibility) to enforce the chain by use of channels or PAN ids. At any given moment in time, any single module can have only one PAN id and can be on only one channel. So if channels or PAN ids are used to construct the chain, individual modules must switch channel or PAN id in order to communicate up or down the chain.

For that to happen, we would have to assume that each XBee was connected to a processor of some sort which would handle the switching - XBees can’t change channels or PAN ids on their own.

Thing is, if each XBee has its own processor then it seems to me that the obvious way to create the effect of a chain is by making that processor direct each message to its correct partner by setting the destination address (DH/DL) parameters correctly for the message. If you do this, then in fact all the chains could have the same channel and PAN id. Every packet would be addressed to a unique module, so there would be no confusion.

I just said that every chain could share the same channel and PAN id, so here’s some amplification on that.

To take the PAN id first. All modules on a given channel will hear all packets sent on that channel, and each module must process the packet enough to discover whether the packet’s PAN id matches that of the module. If the PAN id doesn’t match, the packet is ignored. So if you’re worried about congestion, PAN ids probably don’t help.

In fact, my own understanding of the PAN id is that it’s a way of distinguishing “my” XBee network from “your” XBee network. Imagine that you set up your network, and unknown to you someone else in the same area is also using XBees for another application. If you have different PAN ids, your networks will not conflict. There are 65536 different PAN ids so if each of you chooses one at random there is very little likelihood of a clash.

The channel can be used to reduce congestion, because modules on different channels simply won’t hear packets sent on other channels. You could use this to improve data throughput by assigning different channels to different chains. However, the other reason for selecting channels is to avoid frequencies that have interference on them (it’s not just XBees that use these frequencies). So you could in principle find that setting all your XBees to use the channel that has the least interference would actually give a better throughput than using multiple channels. What I’m trying to imply here is that channels are not the best solution if you want to create a chain, because their more important use is to avoid interference.

One thing I haven’t seen in this thread is an estimate of how much data will be transmitted. Are we talking about video streams here (in which case no chance!), or are these modules transmitting a few bytes per day? Presumably somewhere between those extremes, but roughly where?

I know that this answer doesn’t directly address your questions. But I hope that if you can add any comments we’ll all get a better idea of how we can give you morehelp.

Ok lets say that the different PANs do not interfere with each other. What about the nodes on a single chain : if there are a 100 of them but any node can talk to just two neighbours what happens when a node is sending a message to its neighbour ? Do all the other nodes hear the message too but ignore it ? Since the protocol uses CSMD/CA in the worst case scenario a node has to back-off “number of nodes in the chain” times to speak! That means that at some point adding nodes to the linear chain makes the network totaly congested! Are you aware of some article/document testing different topologies for latency/throughput using the 802.15.4 ?
By the way : I have come across a network simulator called ns-2 which can be used for simulating 802.15.4… Anyone here used it before ? Any comments, suggestions regarding 802.15.4 simulation software ?!
Thanks a lot

Suggest you read up on the basics of 802.15.4. MAC addresses are used to address data packets, no matter the network protocol. Typical low power PAN use cases for which 802.15.4 is applicable don’t send at a high duty cycle or hundreds of packets per second per node. This isn’t 802.11.

CSMA/CA backoff times are small as compared to the average packet rate for one node, in typical uses.

Ok, I am going to elaborate a bit on the intended application and use of the Xbee-Pro modules.
The modules are going to be used together with a PIC micro. The intended usage for now is just is to replace serial cables. The xbee nodules are to be installed 10-20 meters apart in an industrial environment. The electronics on each board monitors the state of a machine processing wood. All machines are arranged in a chain each performing some processing on the wood material. When there is a problem with a machine it should warn through its Xbee module the previous and next machine in the chain to stop processing and just halt the conveyor belt. Thus the state of each machine is transmitted through the XBee to the predecessor and the successor in the chain ( payload, which is the state information, is about 2bytes ). The state should be transmitted to predecessor/successor every second. There is the possibility of more than one such conveyor belts ( chains ) in the same environment.
That should explain my above concerns regarding the “isolation” of each conveyor belt ( chain ) through different channel assignement and the concern that if there are “a lot” of Xbee-modules in the same chain maybe the requirement of 1 second communication might be impaired.
Secondly I am trying to figure out a nice way to enforce the “chain” topology yet use something like DHCP instead of manualy forcing the adresses of each node. From what I gether form the previous posts a coordinator is not needed. Also my understanding is that i will eventualy have to use the API command mode to be able to switch destination addresses on the fly !
Given these premises is it correct to force the communication channel to a given value ? Are my assumptions about using API mode correct ? Is the payload of 2bytes per second irrisory and as such should not be worried about ( when at most a 5/10 nodes could exist in the chain ) ?

Thanks for that explanation - it does make it easier to picture the situation.

For the “something like DHCP”, you could check out the NI and ND commands.

As far as I can see you won’t need a coordinator in the setup. You would use one if the nodes were battery-powered and you wanted them to sleep between transmissions, but it doesn’t sound like that’s the case here.

As for using channels to enforce separation, it isn’t necessary except that it might give you extra bandwidth. You can use the ED command to find out how noisy the environment is on different channels, and then operate on the quieter ones.

I think you will probably want to use API mode for the transmissions. It isn’t difficult once you get the hang of it. A while ago in this forum I posted a little Tcl program that decodes API packets for the 802.15.4 firmware. When you’re composing packets and want to check their correctness you might find it useful.

As for the question of whether the communication bandwidth will be enough, I’m not able to offer any help. But when you’ve worked out what packets you’ll be sending, I’m sure the excellent folks at Digi support would be happy to give an expert opinion. I suppose you’d have to bear in mind though that with any form of radio communication a sufficiently strong burst of interference could introduce arbitrary amounts of latency. One response to that would be to change the logic so that any machine will shut down if it fails to hear from its neighbour in a given time interval.

Hi, thank you very much for the support you are offering. Actually I have now both your faq.pdf and the xbee.pdf. They are going to be quite helpful. I am going to look for the tcl script to verify the data frames. Indeed I think I am going to be forced to use API mode in order to send data to two different nodes. I am going to try to force channel id + pan id + manualy assigned 16-bit address for each node. Then disable Digi header. Finally, as you suggest, no received message for a given timeout period means trouble so the alarm condition will be raised…
I hope to update this forum soon with results using such a setup…
For the time being I would like to thank all the folk that tried to give good advice : thanks a lot !