Electronic – XBee-PRO broadcast configuration

Use the fastest bit-rate you can afford, so that the transmitter doesn't have to be switched on longer than necessary. Using lower bit-rates doesn't make any difference in power, but it will in energy, since it takes longer to transmit.

It also helps to use a single transmission to send for instance 100 kB than to switch the device 10 times on and off to send each time a block of 10 kB. That's because the transmitter has a non-negligible settling time, and if you transmit in 10 blocks it would dissipate power during 10 times this settling time, otherwise just once.

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.