I am designing an Xbee mesh network, planned size is around 10 nodes spread around 200 square metre area. It will be a combination of nodes reporting environmental data with actuators/loggers. I intend to have a single controller/logger to process the data from the network, however, I predict its location (and address) to change. I therefore would need a broadcast to be sent periodically from the current logger to ensure that the data is sent to the proper place
I have read that broadcast on the Xbee mesh network can really kill the performance, however, I was not able to find many details about specifics.
My question is then: would sending a broadcast every 60s in a mesh of around 10 nodes be feasible or would it put any strain on the network?
Best Answer
I would distinguish two types of broadcast:
Messages which are only sent to all nodes (and only those nodes) which are in direct range of the original transmitter
Messages which are sent to all nodes everywhere
A request to sending out the first type of broadcast will cause it to be transmitted the number of times specified by MT. The default is four transmissions, which means that right off the bat a broadcast sent with default settings will be more expensive than a unicast. Additionally, every node which hears a broadcast of the second type will end up transmitting it repeatedly, even if by the time it transmits the message everyone who could possibly hear it has already done so.
I consider it unfortunate that there's no way to indicate whether an individual broadcast--even one of the former type--should be considered "important" enough to merit repeated transmission. Reliable network route discovery requires that broadcasts be repeated enough to ensure that at least one copy will get through, but network diagnostics would be more effective if one could specify that a non-hop broadcast should be sent exactly once (if one sends 10 send-once no-hop broadcasts to a node over a 50% reliable link and asked how many it received, it would probably get about 5. If each broadcast request actually sends the message four times, then the recipient would have a better-than-even chance of getting all 10, thus providing no information about actual link reliability). Further, if every node knows that it's supposed to hear a broadcast network-status message within a given time-frame and can send out a no-hop broadcast if it doesn't, and if nearby nodes can send respond to that by sending a network status message to the node that didn't get it, then if one doesn't need to support routed messaging or synchronous sleep mode one may be able to reduce the amount of information transmitted by 75% when conditions are good by sending each broadcast message only once, while retaining reliable operation when conditions are bad.
In short, the use of Digi mesh-routing features requires that broadcast-related options be set in ways which make broadcasts inefficient. If you implement your own routing, retransmission, and sleep-control logic, broadcasts may be more efficient.
Returning to your scenario, one broadcast every minute is a low enough level of traffic that you probably shouldn't worry about it. The level of broadcasts to saturate the network using default settings would be somewhere around ten broadcasts per second divided by the size of the largest group of nodes that are all in within range of each other.