I’m sorry if this is too basic, but could not find a conclusive answer in the threads and documents so…
We are building a mesh-networking application using XBee-Pro ZB firmware. We intend to have one coordinator and all other nodes will be routers (no sleep, so no end-devices).
Our application is currently using API interface on the corrdinator and transparent mode on the device modules.
So, the question is: how many nodes such a network may have (from the coordinator/routers firmware/hardware perspective)?
I also have an application with 300-1000 end devices.
Since I am just beginning I would like an explicit statement that all of the termination/“end devices” can be routers with the “change state” mode set.
In other words I want to collect (slow) switch changes from 1000 people that can be moving around.
The power consumption doesn’t appear to be a problem right now.
Ray
If you don’t do anything special at all, in my experience things start breaking down at about 30 routers. Using the AR command, supposedly you can get more, but to be cautious I limit my networks to about that many. It helps the routers find the coordinator more efficiently. But for hundreds, you’ll have to use more advanced routing techniques where the device behind the coordinator handle some of the work. The manual covers how to do it, but I don’t have it in front of me now and don’t remember what it is called. I believe Digi also had a white paper about it. I seem to recall they were running 1,000 nodes. Since I never need more than about 60 in the biggest extreme, I never bothered implementing that.
Actually I have reevaluated the power consumption.
If I were to configure end devices to wake up and transmit on change, and that occurred no more ofter than once every three minutes; how few routers would I need?
I read something about many-to-one routing and source routing on the XBEE ZB version manual, still figuring how to implement. Do you think that with such routing mechanism it would be possible to reach 100+ nodes?
Additionally, I’ve seen somewhere that there is no hop limit on the XBEE ZB version… so my main concern is if it would be possible to implement a ‘string’ network of 100+ XBEEs
Hi darworm,
Can you give me the exact name of that manual? I have a collection of manuals and papers on my computer; but straightening out what applies to what is a little confusing.
Ray
I can’t find it, but it is covered in the main manual. Look under Source Routing.
In short, the Many-To-One routing (using the AR command) lets all of your nodes know how to connect to your coordinator. But for your coordinator to talk to a specific node, without burdening the network with discovery packets (which limits the maximum number of nodes by clogging the bandwidth), your coordinator must use source routing. All that means is that the first time you send a message to a node, you do it the way you always have. When it responds, though (or it if talks to you first), the message will include a list of all the hops it took to get there. You store this, and next time you want to talk to that node, you specify those hops with a Create Source Route frame before you send the message. This means that no discovery packets need be sent, and you can support more nodes.
Thanks, that is an excellent start!
I guess I should be embarrassed about not finding but it, but Ii am grateful. Hopefully I can trace out the documentation to specifics. Having just watched Jeopardy; maybe we need open-source versions that can emulate Watson:)
Although I am sure google will implement the techniques soon.
Ray
I went trought the ZB manual and from there we can see that:
Max payload is 84 bytes. You can increase it using the NP command (API transmit frame can be up to 255 bytes) but in this case your transmitter will fragment the message into many pieces reassembled at the receiver.
If using security, your max payload is reduced by 9 bytes (some pages indicates 4 bytes instead)
each hop you have to consider consumes 2 bytes of your payload
So, thinking loud, without fragmenting and with security, and considering a very small message of 5 bytes, you should have 84 - 5 - 9 = 70 bytes / 2 = 35 hops that can be defined in the message for source routing.
If we could go up to 255 bytes, then it would be much better… ~120 hops… but dont know the latency impacts of doing fragmentation.
Do you think this calculation sounds correct?
On the other side, do you think a broadcast could go over more then 50-100 hops?
"Because the handling of source routing is automatic when using a ConnectPort X gateway it can be difficult to determine what the maximum payload size should be. It is recommended to use the value returned from ‘NP’ less the maximum source routing overhead (10 hops, or 20 bytes). "
I don’t know if that maximum of 10 hops is the maximum for the module, or only the maximum for the ConnectPort’s implementation of source routing. I can’t find anything in the 0x21 or 0xA1 commands that indicate any maximum values.
However, unless you are using the devices as a daisy chain instead of a cloud, ten hops is a lot of nodes.
I can’t help any more than this. I’ve not implemented source routing, because I found I don’t need it. My coordinator is more of a data collector that only occasionally needs to talk to a node as a message originator, so I didn’t need to do it. I just looked at it when I started having troubles with over 30 nodes, which was cured with the AR command to enable Many to One routing.
If you send a payload > then 84 bytes (and it should not exceed what NP informs) fragmentation should take place. That’s what I understand from the manual.
On the other side, just found this on the manual for source routing…
“The XBee can buffer one source route that includes up to 10 hops
(excluding source and destination).”
That should be the limitation in terms of hops when using source routing.
For broadcasts, it’s not clear for me what are the limitations on the network size.
Well I have dug down a little.
In order to service 1000 end nodes I need 100 routers?
This is in a nightclub and, aside from putting me over budget, seems a little strange.
Alternately I can have a smaller number of routers that forget about the infrequent end-nodes; and have the end-nodes rejoin when a button gets pushed.
Is this correct?
Does anybody know how much disruption (network traffic) rejoins cause?
Do your end nodes need to be low power, where they turn themselves off for a period of time? If not, just use 1000 routers. I’ve never used an end point only, I always use routers, but my devices are line powered and always on.
And really, you don’t need one router for every 10 end points, anyway. The number of hops is all about range, it isn’t some rigid limitation. If all of your end points are within range of the coordinator, then with source routing, you shouldn’t need any routers at all. But if one of the nodes out on the edge can’t quite reach the coordinator, then it can hop through a router that is within range of both. The only time you must have routers in between is when some of your nodes are out of range of the coordinator. Because the intermediate hops have to be available all the time, they can’t be in low power mode, which means they must be routers. End points in low power mode can’t relay the messages, because they never see it in the first place.
So how many routers you need really depends on your application. You say you are in a nightclub. That probably means you are going to have servers with wireless table side order entry, or maybe wireless payment. In this case, your devices will probably be end points so they won’t drain the battery, and your coordinator is in the back office hooked to the main PC. If the farthest corners of the nightclub are out of range of the office, you might need to put in a few Zigbee Wall Routers between the office and the dead areas. But certainly not one for every ten devices. All they are for is to extend the range so that your end devices can reach the back office.
Yeap, they need to be low power. 8x50ma for 6-8 hours eat too far into the 2XAA budget; but the idle current of 15ma most of the time (99%) is doable; I hope. There are other electronics that need to be supplied.
I don’t know how to estimate the power drain if they are all routers.
You do have a point about the distances. If I can force most of the end-nodes (or perhaps routers) to access the coordinator, that might work. Is there a way to do that? It does seem to me that that maintaining the join when you are using many-to-one mode isn’t necessary logically; but that’s where we are. I don’t really need source routing; it’s basically one way. I suppose a repeater rather than a router would work. I didn’t see one.
There are two stories also in the building.
Using the routers as effectors: don’t the routers still have a 10 client limit even if they are associated with other routers?
I forgot to say: Thanks for replying!
"
But certainly not one for every ten devices. All they are for is to extend the range so that your end devices can reach the back office.
"
I don’t understand that. Is there a way to just set them up as repeaters?
The end points will use many-to-one routing, since they only ever talk to the coordinator, so the router’s routing tables aren’t really used. When the coordinator sends its periodic AR, the end points will either see it directly (and thus talk directly to the coordinator when they need to talk) or see the relay from a router, in which case they will send their message to the router telling it how to route it, so that the routers internal routing tables aren’t used at all.
Since the coordinator is using source routing, it doesn’t use the routing tables built into the module either, it is using the ones in the PC. When the PC needs to send a message, it looks at its source route for that node, sends it to the coordinator then sends the message. If that is direct to the end point, fine, if it needs to relay through a router, the message contains how to route itself, again not needing any internal routing tables.
So in essence, when you combine many-to-one routing with source routing, you are effectively setting them up as repeaters. Each end point only has to remember one route to the coordinator, the PC with the coordinator remembers all of the routes to the end points, and the “routers” never actually do any routing at all, they simply follow the orders on how to route the message from either the end point or the coordinator.