I have an application where I have one master device and many (1 to 50) node devices. The node devices operate independently, however I need to reliably stop their functions on demand or if there is a problem with the master. So i thought the best idea would be a 'dead man’s switch, I get the master device to send a “Go” command every 1000ms, and the nodes continue to operate so long as they keep receiving this. Simple.
So I go and order a load of XBee Series 2 for the job. One is set up as co-ordinator, the others as router/end devices. Network creation is all fine and router/end to co-ordinator data is flowing super fast and reliably. However co-ordinator to router/end broadcast messages are somewhat unreliable in terms of timing. l’m sending one every second (a simple “GO”), and it will send regularly for a few seconds and then pause for a bit (up to 10 seconds) and then dump through a load "Go"s, obviously this ain’t gonna work for my purpose, as the nodes will detect a loss in comms when there isn’t one, its just the broadcast method being slow!
I have read a bit about it, and as far as I can find out the Broadcast method is VERY SLOW because of the MESH network overhead. This is a real blow
So it looks like i should have bought series 1 devices rather than 2. Only problem with that is would all nodes have to be within range of the master? Or can i use the DigiMesh firmware on them?
I’ve only used the Series 2 and have never tried something with that timing constraint. I have a felling that even the Series 1’s won’t meet your requirements. But hopefully, Stevec will jump in with the info.
I’ve just chatted to digi, and they seem to think series 1 will do the job, even with the digiMesh firmware, so i may get away with using 1mw rather than 60mw.
I met the same problem on series 2, since some time i have to use broadcast. It’s impossible to know every nodes’ address (for some new join nodes) and send them unicast packets one by one.
What’s the solution for this problem? does series 1 help?
With an API mode interface the Host software can send a ‘Node discovery’ to the Coordinator to get the first set the Nodes then a ‘Node discovery’ to these until there aren’t any more nodes. From these ‘Node discovery’ replies the Host software builds a Node connection table of all the Nodes in the Network.
Yes, it is a solution. Whereas, it does increase packet exchange and application need manaully handle these by itself (building extra neighbour address table).
With Series 1, and would it not also be true for series 2, one can trigger at the MAC layer a transmission to the FFFF destination (broadcast) to all in-range nodes? Any node can do so.
Do the nodes check the TX Status after sending data? I’m making an assumption, that if the master is having trouble, then the transmission won’t be successful and the node could know that by checking the status. Maybe that doesn’t work because the trouble is of some other non-network-related kind. In that case a network “problem” could be forced by causing the coordinator to leave the network. I’m not finding a command specifically for that, but what if the coordinator’s PAN ID were changed. Then none of the nodes could communicate with it. So if the master node is having problems, have it switch its XBee’s PAN ID to something else and the nodes will get the message by virtue of the fact that their transmissions will fail. When the master is “ok” again, switch it back to the “real” PAN ID. No “GO” command needed. If the nodes’ transmissions “GO” then all is well. 50 nodes sounds like a good sized network, so it may take a bit to re-establish the network, I have no idea how long, I think I’m up to five nodes here
This is a real blow
then all is well. 50 nodes sounds like a good sized network, so it may take a bit to re-establish the network, I have no idea how long, I think I’m up to five nodes here 