Xbee network with a lot of nodes

I’m reading a book about Xbee and Arduino and I’d like to ask you some questions since all the examples in the book are always related to networks with few nodes.

If I have a mesh network with 1000 sensor nodes (distance between each node is 8 meters and each node uses Xbee PRO series 2), how many routers and coordinator units do I need?
I see that there are sensor nodes which simply read data from sensors and that these nodes can be configured as routers or base stations configured as coordinators.
Can the units configured as routers or coordinators execute any kind of operation?

For example, can I upload the same sketches on all my sensor nodes and then configured them as coordinators or routers?
Coordinators can act as coordinators also if they read data from sensors and send them on the network?

Thanks :slight_smile:

Can the units configured as routers or coordinators execute any kind of operation?

The same kinds of “operations” that end devices can. The “operations” are performed by the microcontroller, not by the radio.

For example, can I upload the same sketches on all my sensor nodes

You can’t upload a sketch to an XBee. If the XBee is attached to an Arduino, that is a different story. Perhaps you need to provide more details about your (proposed) hardware/configuration/network.

Yes, i know I can't upload code on xbee. Each of my sensor node has a xbee radio PRO Series 2 with Arduino UNO and a current sensor. Each node has to send the current reading to a base station and I'd like to read each sensor node values. Moreover, I would like to send a command which should be received by all the sensor nodes in order to let them shutdown a LED when I want.

The problem is that book cover simple examples where there are networks with two or three nodes. But, what about a network with 1000 sensor nodes? How many coordinators should I use in this case?

And what kind of device should I use if I want to read all the data exchanged over the network?

Each XBee Series 2 network must have exactly one coordinator. The rest of the nodes can be end devices or routers, as needed or desired. Refer to the product manual, but with a network of that size, some routers would be appropriate. An end device is really only needed if a node needs to sleep, e.g. to conserve power, else all the nodes could be routers (except the coordinator, which can do routing too.) I'd make the base station the coordinator (EDIT: That way the other nodes can send data to the coordinator without knowing its address. An address of zero is understood to be the coordinator. One less thing to program into 1000 nodes.) Broadcast messages can be sent to all nodes. Read the product manual carefully about using broadcast messages on large networks. If the average distance between nodes is 8m (or even several times that), then the PRO models are gross overkill.

The problem is that book cover simple examples where there are networks with two or three nodes. But, what about a network with 1000 sensor nodes?

The book does more than hint at this. It says that you need to experiment to determine an optimum number of end devices, routers, and coordinators. Actually, the number of coordinators is the easiest to determine. One per network.

The number of routers depends on the amount of data flowing, and how the devices are arranged. There is no easy answer. Pick some number. If that works, great. If not, change more end devices to routers. The hardware remains the same, so the cost does, too.

PaulS: The number of routers depends on the amount of data flowing, and how the devices are arranged. There is no easy answer. Pick some number. If that works, great. If not, change more end devices to routers. The hardware remains the same, so the cost does, too.

If there is not a specific reason to use end devices (i.e. sleeping nodes for power savings), then I'd use routers. That way there is also no worry about the child tables filling up.

[quote author=marcus barnet link=topic=112493.msg845466#msg845466 date=1341168489] Can the units configured as routers or coordinators execute any kind of operation? [/quote]

Basically, functionality is the same between end devices, routers, and coordinators, with a few exceptions. Only end devices can sleep. End devices cannot route data packets (because they may be sleeping). Only the coordinator can start the network.

Thanks for all the replies.

I do not need to use sleep function, so can i configure all nodes as routers and use a single coordinator? Do you think it would be a good idea?

[quote author=marcus barnet link=topic=112493.msg845550#msg845550 date=1341173447] Thanks for all the replies.

I do not need to use sleep function, so can i configure all nodes as routers and use a single coordinator? Do you think it would be a good idea? [/quote]

Yes, I think so, but if there are really 1000 nodes involved, I'd spend some serious time in the product manual to be sure the network is as efficient as possible. Bottom line, XBees are low-bandwidth devices. Depending on the physical layout of the network, the logical network topology, the data rates, etc. etc. some extraordinary steps may be in order. For instance, it may be advantageous to use non-sleeping end devices to limit the routing possibilities somewhat. Funneling data from 1000 nodes into a single coordinator might take a bit of planning, but again, understanding the data rates would be critical.

Sounds like a pretty interesting project, but it has at least a couple orders of magnitude more nodes than anything I've dealt with!

Really thanks for your support.

All I need is to read sensor data one time each hour or one time each three hours; i mean, that each sensor node has to send only a message per hour or a message each three or four hours.
The data sent from the sensor must contains just the values from the current sensor (each current sensor has a voltage output proportional to the measured current) and, may be, a character to specify that the data are related to current readings.

Moreover, I need to send a command to each node in order to shut off a LED which is present on each node.
(I’ll have to send this command one time per day).

Do you think it will be possible to use just a single coordinator for this kind of operations?

I think it's possible as long as all 1000 nodes don't have to send data at the same time. Data volume per node is small. Can the transmissions be spaced out over an hour's time? That would only be one transmission every 3.6 seconds on average, which seems quite reasonable.

What's the deal with shutting off the LED, what's that all about?

Do you mean if, for example, 500 nodes should send a message one hour after the other 500 nodes? The answer is yes and it's a great idea to decrease the amount of data sent at one time.

About the LED, I'd like to shut down the LED attached at each node by sending a remote command. I'd like to send a simple message like "OFF" to all nodes in order to shutdown all the LEDs. For this operation, I can send two different commands, one for each 500 nodes but these two commands can be spaced 5 minutes at max.

OK just trying to understand the bigger picture. When does the LED get turned on, and what does it indicate? Check out the product manual on broadcasts. There are some pitfalls, and delivery is not guaranteed. So that may not be the way to go for that.

I was thinking of spacing the data out even during the hour. I have a network where the coordinator is also the data concentrator. All nodes send their data to the coordinator. The coordinator has an RTC which is considered the master clock for the network (the coordinator's clock is synchronized via NTP, but that's not strictly necessary). Each node synchronizes its clock in turn with the coordinator and times its data transmission based on its XBee's Node Identifier (set via the NI command). The node identifiers contain a number (e.g. X0001) which defines when each node transmits its data.

So that scheme could work to keep the peak data rates down. I don't think I'd want 500 or even 100 nodes transmitting simultaneously. To really even it out, the nodes could be X0001 through X1000, where the number signifies how many seconds after the hour the node transmits data. If the data sent by the various nodes does not need to be closely correlated in time, then that would level the bandwidth requirements out, leave room for expansion, and also allow for retries in case of a transmission failure.

I said generally LED to not complicate the problem. In reality, each node is able to shutdown a LED lamp (120V) by using a relay and a transistor. The current sensor is needed to measure the current which the LED lamp uses during the normal operation. So, I need to send a shutdown command to all the nodes in order to turn off all the LED lamps at the end of each day.

Me too, I want to use the coordinator as the data concentrator and the idea to use the RTC server is very good even if it is a little bit complicated to implement under Arduino (at least, it is complicated for me).

All the nodes values does not need to be strictly correlated in time.

The time sync is fairly simple. Each node can send one of two packet types to the coordinator. One is a data packet with sensor readings, and the other is a time sync request packet. The latter causes the coordinator to send its current time back to the requesting node, which then sets its clock to the time sent.

Another approach with such a large number of nodes would be to just randomize the transmissions, that should also have the effect of spreading the traffic out over time.

As for turning lamps on 1000 nodes off at the end of the day, I assume that needs to happen nearly simultaneously, or maybe over a few minutes at most? I don't understand the broadcast limitations well enough to really know if it might work reliably. Some reading, research, and testing would be in order. Another approach would be for the coordinator to assume some fixed range of node names (X0001 to X1000 or whatever) and address each node individually using the DN command. 1000 nodes shouldn't take more than a few minutes I wouldn't think.

The physical layout of the 1000 nodes will be a factor in network design. The number of hops to get from the coordinator to any given node is probably an important parameter. There are related parameters that can be set in the XBees to tune network performance. I've never needed to do so, having worked only with small networks with minimal hops.

I'd search the Digi web site for best practices for large networks. I'd probably also call their tech support. If you're buying 1000 XBees, I'd bet they'd be happy to talk with you. My friend ordered just a few XBees and they gave him a call one day just to see how things were going or if he had any questions.

Very interesting project, keep us posted.

Recommendations here for networks with > 40 nodes. http://www.digi.com/wiki/developer/index.php/Large_ZigBee_Networks_and_Source_Routing

Several unique networks (PAN ID) could also be deployed, each with its own coordinator. Not sure what the pros and cons would be for your particular application.

Thank for the link and also for the suggestion about the different network names. In fact, If I uses, for example, two or three different PANID, I should have different network with different coordinators. Then, I could use a gateway to read data from each coordinator.

Can it be a solution?

Moreover, I've read the link and I think I should study a little bit the Many-to-One Routing aspect.

I suppose so, although I’m not sure what you mean by “gateway”.

Moreover, I’ve read the link and I think I should study a little bit the Many-to-One Routing aspect.

Agree. I read it quickly, but it will take some studying :~

With "gateway" I mean something line this from digi: http://www.digi.com/products/wireless-routers-gateways/routing-gateways/connectportx4#specs

I'm imaging to divide my 1000 sensor nodes into several different network which will have different PANID. Each PANID will have a single coordinator and, again, each PANID will be related to a particular group which will be labeled with a name. I'll use a gateway, like connectport X8, to connect to all the coordinators and to inspect data exchanged over all the different networks.

This will allow me to send and receive commands from only the groups (which are the networks) I want in order to decrease the data traffic and let the network be more reliable and simply to verify and locate.