Why do I see large delays when I am sending packets to the Broadcast address of 0xFFFF?
When a packet is sent to the broadcast address, the radio keeps a table identifying which packets have been sent. By doing so, this prevents a rebroadcast of a packet that has already been transmitted.
The Broadcast table is dynamic and is independent of packet size. It only consists of a record of the packet IDs of the packets that the module has transmitted and is tracked by all Coordinator and Router radios in the network (end nodes do not repeat broadcasts). The module limits the broadcast traffic to about 8 broadcasts in any 9-second window, so any NWK layer broadcast activity (APS broadcasts, APS multicasts, route discoveries, ZDO announcements or broadcast requests, PAN ID / channel / NWK key update notifications) by any node, even one with a 1-hop radius, will count against this limit. If any node encounters more than this amount of broadcast traffic, it will discard the packet because it can't be tracked against the list of known broadcasts. The protocol does not want to risk repeating an old broadcast and propagate it unnecessarily - which otherwise could potentially create a broadcast storm and lock up the network.
Zigbee networks are not ideal for high data throughput but if constant, streaming type data is desired, it is recommended that you use Unicast addressing and limit the number of hops in the network.
Last updated: Aug 23, 2017