They probably are, but you are circumventing that process. If you were to rely on the normal built in mesh routing, that’s what would be used, and you’d find your network terribly congested and sluggish, dropping a lot of data. So your end points may be filling up the routers routing tables, but it doesn’t matter, because you are bypassing them by using many-to-one and source routing.
Yes but the end must be “joined” and therefore in the local router table. As far as I can see. The data loop is:
end-node not polling/no entry in local router table
dio change occurs
end-node joins
router table accepts end-node
end-node sends dio message
router does many-to-one data xfer to controller
ack received by end node (?? not necessary)
end-node is told to unjoin
router forgets children
end-node not polling/no entry in local router table
dio change occurs
etc …
Simple enough, but I am a little concerned about the network traffic during joining/unjoining.
I’m not following you. What is this about un-joining? Just because you go into low power mode doesn’t mean you un-join the network. That would only happen if you completely powered down your whole device. And I don’t see any reason you’d tell the module to disconnect from the network.
I think you need to look more closely at the power management section of the manual. Since my devices are line powered, I don’t know much about that, but what I’ve read suggests that in low power mode, the modules turn off both transmitter and receiver for a period, then when they wake up, they are able to talk fairly close to immediately, which doesn’t sound like they have to rejoin the network.
HI!! im new in Xbee…I wanto to make a simple mesh, with 1 coordinador and 3 router, for example. I need that the coordinador talk with router 1 and router 1 talk with router 2 the message sent frmo coordinador.
I have Xbee serie 2Pro and Arduino. My program control one led, ok? Coord say: router2, turn on led, but the message is sent through router 1.
I dont know how to configure this. Please…Inthe future my mesh will have > 100 nodes…and i dont know how make this. I have read many things…but i dont understand very well… Thanks…
“I’m not following you. What is this about un-joining? Just because you go into low power mode doesn’t mean you un-join the network. That would only happen if you completely powered down your whole device. And I don’t see any reason you’d tell the module to disconnect from the network.”
By unjoin I meant a ZDO command; but I’ve decided to skip that.
My present proposed software architecture is to have the routers rapidly forget their routing table and the end-nodes poll very slowly.
Two possible modes are available.
- Let the end-nodes drop to idle, 15ma which I can endure; and set the “on-change” flag so it comes up and broadcast the DIO state. Unfortunately it also comes out of idle when the receiver detects valid (whatever that is) input. So in a busy situation the unit wouldn’t stay in idle mode often enough to save the battery. I am going to do the statistics.
- The alternate mode is sleep, which uses ua; but the unit is dead during sleep. Then when it wakes up it sends an DIO packet; or is told to; depending upon whether the DIO change command is effective/remembered during sleep. The problem is; I think that every time it wakes up it polls and rejoins. That’s a lot of traffic for 300-1000 nodes unless the rejoin is fast or not done very often. I have started the statistical analysis in my head, but haven’t carried it out yet.
Both methods will use the rejoin command; which seems to have a lighter loading than a raw join.
I would rather use alternative 1.
Despite having to serving up to 1000 nodes, I have a rather lenient problem. Each node only changes state about once every 5 minutes, and missing up to 10% of the state changes wouldn’t matter (It’s a monitor for a night club). But it would make a bad impression if the network stopped working.
Since it’s not a proprietary product I might make the code available. Right now I starting a Warnier-Orr design diagram. I have had good results with them before. Particularly with respect to debugging and maintenance.
Comments are more than welcome. I have to do this without a test-bed that has nodes anywhere comparable to the reality. And the actual installation will be 1000’s of miles away.
Ray
Really, in all “how many nodes”, the key questions is “how often do they speak?” Mesh like Zigbee are NOT speed demons - people who any 50 msec latency or the nuclear reactor explodes shouldn’t be using Zigbee 
My largest system today has perhaps 25 devices, and a few talk once per second or two, and most talk once per 10 to 30 minutes.
My networks are normally like yours, and I had no problems at that level. Problems started at about 30 nodes, and 60 became unworkable. That’s when I had to learn about the many-to-one routing, which cleared that up nicely. Plus, there are times when I need to do firmware updates over the radio, which really killed things (and still does, to tell the truth), but I make sure to do that when the system isn’t getting much use, and it isn’t all that often anyway.
I think your router SN/SP are not correctly set. These define how long a parent (aka: router) retains a child node before flushing it as gone.
Set it too small, and the child needs to rejoin every time it wakes.
Set them too high, and the parent rememebrs children far after they are gone.
I think your router SN/SP are not correctly set. These define how long a parent (aka: router) retains a child node before flushing it as gone.
If I am unwilling to buy enough routers to support 300-1000 end nodes at 1 router per 10 end-nodes; then I don’t have a choice. I have to take the rejoin time data hit. It would be nice if the routers transferred source-routing/many-to-one data packets without examining whether the end-node was a “child”, but I don’t think that is true.
Ray
So you are saying that you expect the ‘parents’ to prematurely discard the children entries they hold? This does force the child to issue 3 or 4 extra RF packets every time it wakes, and risks the child not being able to find any parent at all before it needs to sleep again.
This has nothing to do with ‘examining whether the end-node was a “child”’ or not. This is unrelated to routers forwarding packets in a mesh.
A parent holds buffers open & ready for a child to wake & transfer ASAP a packet - because the parent/child relationship is point-multipoint, not mesh. Each child needs a ‘parent’ (a single MAC) which it connects to rapidly upon waking. This miminized battery drain.
I have worked with several customer trying to do this - put SN/SP artifically low and force ‘thrashing’ of the parent/child relationship. They all have very bad reliability & robustness problems. It is nothing I admit works, so I wish you luck.
Each child needs a ‘parent’ (a single MAC) which it connects to rapidly upon waking. This miminized battery drain.
I interprete this to mean: unless the controller can reach every end-node, I need a router for every 10 end-nodes unless I am willing to tolerate some types of failures?
I have worked with several customer trying to do this - put SN/SP artifically low and force ‘thrashing’ of the parent/child relationship. They all have very bad reliability & robustness problems. It is nothing I admit works, so I wish you luck.
I can live with some missed events (up to 10% say), but not with system level crashes/tie-ups. What did the “bad reliability & robustness problems” consist of? Missed messages or the network wandering off into chaos?
Ray
The most common issue is some nodes appear to dissappear for long periods of time, so instead of sending in data once per hour, they might go away for many hours or even days.
With the current XBee firmware the non-coordinator routers support 12 kids. Yet you can’t control which parent a child links to, so even if you have say 24 children and 2 parents, there is nothing stopping an end-device which can see both parents from selecting the ‘wrong’ one, so you end up with 1 full parent with 12 children, 1 parent with only 7 children, and 5 children without a parent because they can only see the full-first parent.
Maybe ZigBee isn’t the right RF for you, as it was designed assuming some significant % of the nodes are fully powered and some sleep, but not all sleep. For example in home automation it’s very easy to see that perhaps 3/4 of the devices may be fully powered (like light switches) and only 1/4 are battery-sleepers (like a temperature or light sensor).
I personally hate batteries - my smoke detectors at home are all AC, and even my thermostats which use ZigBee are wired with 24vac as I think it was easier/cheaper to just pull a thermostat wire than spend eternity dealing with batteries.
Have you estimated the life-time cost of labor to change 1000 batteries every few years, over and over for the life of the product? If you could get your battery life up to 10 years, then I guess you could just treat the product as disposable. But that is very hard since batteries don’t even tend to last that long when NOT being used. Just put them on the shelf and a lot of batteries are dead in 5 to 7 years.
Thanks for the explanation. The connecting to the wrong parent is a problem; although perhaps I can live with it (or not).
The application is for clients in a night club. Batteries are probably required; they are in place now and have to be dealt with every night. There are attempts to minimize the handling in future versions; rechargeablity and connectors.
Let’s go over the router costs:
200 end-units * $20=$4000 end-node costs.
20 wall-routers * $60 =$1200 router costs.
Actually not as bad as I was thinking; 30% overhead.
I still have the problem with battery life but at least the routers can stay up without persistent rejoining.
If I leave the end-nodes in idle then I still have the continual waking up due to neighbors traffic.
If I put the units to sleep then I have to make sure DIO state changes are caught after waking up. Unless somebody knows I will do the research.
and so on…
I really have to do the statistics rather than just think about doing it.
Thanks again for the explanation.
Ray
Sorry for my late answer. I hope this is okay.
I’ve a similar problem. In my network are one coordinator and 12 sleepy end devices and one router (XBee-PRO ZB).
The first question: What is the meaning of “End-Points” in the post previously. Is it the same as “EndDevice” or is a End-Point something of the ZigBee stack.
I would like to change the I/O state of the End Devices. Before I switch it, I wake them all up via a Broadcast message. But after the wake up, some of the EndDevices connected via the Router to the network do not answer. I think it is something wrong with the route?!?!?!
Now refering to this thread I send a create source route before I send the unicast message to switch the I/O state. By the way I use RemoteATCommand (0x17) to switch.
How can I see if a route is correct? And the last question; In the manual of the XBee-Pro’s they say send the create source route with the destination address of the device. Is the device the router where the endDevices is connected to? Or do I have to send the create route record frame (0x21) to the EndDevice.
Every node in a ZigBee network has two addresses, namely
a 16-bit short network address and a 64-bit IEEE extended
address. The 16-bit network address is assigned to each node
dynamically by its parent coordinator/router upon joining
the network. This address is the only address that is used
for routing and data transmission. It is analogous to the IP
addresses that we use on the internet; whereas the extended
address is similar to the MAC address, which is a unique
identification of each device and is mostly fixed at the time
the device is manufactured.
reference:
http://netlab.cs.ucla.edu/wiki/files/06_SMC_heterogenity.pdf
The answer is approximately 30,000 - 65,000 routers. The problem is that no one has created a network much larger than 1000 nodes and even at that, the amount of just management traffic is a huge deal. Never mind your usable throughput.
Just understand that as you scale up so do too the amount of traffic needed just for network management does exponentially. As that occurs, so does the latency and the reduction of usable data or throughput.