I discuss the usefulness of XBee broadcast here <link>, but there is a problem with this I didn't foresee. It seems that, if you get enough devices, the network gets flooded and becomes unreliable. You see, the beauty of XBees is that they implement mesh protocol such that you can have a message forwarded from XBee to XBee until it reaches its destination many hops away. This is a really good thing because an XBee at the far end of the house can communicate with another one at the opposite end.
I tested this several times by separating a couple of XBees to where they couldn't communicate, then completed the circuit by simply placing one in the middle to forward the data. This means I can go from my barn to my controller with a message without worrying about how far it is, or getting a high power version of the XBee.
The problem comes when a broadcast is transmitted by a device far away and is echoed by several of them to assure it gets to its destination. The Zigbee packet gets a little larger with each hop since it carries the routing information along with it and eventually, the channel is flooded with messages bouncing around.
Introducing the Freakduino Chibi.
I found this when I bought a new device to take a look at the network. This little device <link> is an IEEE 802.15.4 radio mounted with an Arduino compatible MCU. The little device can be programmed to listen in promiscuous mode such that it hears all the packets in range, and at my house this means almost all the devices can be monitored. There's also the possibility of hooking this into WireShark, but I couldn't get that to work reliably. What I did was simply set up a small program that will listen to any of my devices individually to see what traffic is passing through it and just sat back and observed what was going on one device at a time.
The Acid Pump would send a broadcast that was echoed by several devices trying to forward the message to some other device effectively more than doubling the traffic for each device. When they were all doing things, the channel was flooded with superfluous repeated messages such that collisions were constantly happening. There just wasn't enough dead air time for any of them to transmit. I lost messages because they overlapped each other and checksums were bad because the devices overlapped at times.
I'm still a big fan of broadcast, it definitely has its place. For example, a new device that you want to carefully monitor for a few days to be sure you got the set up correct, or a device that is having some problems and needs to be monitored. However, don't go nuts with it like I did. So, what you can do is set your code up to transmit in broadcast initially to get the bugs out then change it to a specific address when you're comfortable that it is working correctly. Then get a Freakduino Chibi to check it from time to time or when you suspect something might be wrong with it
![]()
![]()
I tested this several times by separating a couple of XBees to where they couldn't communicate, then completed the circuit by simply placing one in the middle to forward the data. This means I can go from my barn to my controller with a message without worrying about how far it is, or getting a high power version of the XBee.
The problem comes when a broadcast is transmitted by a device far away and is echoed by several of them to assure it gets to its destination. The Zigbee packet gets a little larger with each hop since it carries the routing information along with it and eventually, the channel is flooded with messages bouncing around.
Introducing the Freakduino Chibi.
I found this when I bought a new device to take a look at the network. This little device <link> is an IEEE 802.15.4 radio mounted with an Arduino compatible MCU. The little device can be programmed to listen in promiscuous mode such that it hears all the packets in range, and at my house this means almost all the devices can be monitored. There's also the possibility of hooking this into WireShark, but I couldn't get that to work reliably. What I did was simply set up a small program that will listen to any of my devices individually to see what traffic is passing through it and just sat back and observed what was going on one device at a time.
The Acid Pump would send a broadcast that was echoed by several devices trying to forward the message to some other device effectively more than doubling the traffic for each device. When they were all doing things, the channel was flooded with superfluous repeated messages such that collisions were constantly happening. There just wasn't enough dead air time for any of them to transmit. I lost messages because they overlapped each other and checksums were bad because the devices overlapped at times.
I'm still a big fan of broadcast, it definitely has its place. For example, a new device that you want to carefully monitor for a few days to be sure you got the set up correct, or a device that is having some problems and needs to be monitored. However, don't go nuts with it like I did. So, what you can do is set your code up to transmit in broadcast initially to get the bugs out then change it to a specific address when you're comfortable that it is working correctly. Then get a Freakduino Chibi to check it from time to time or when you suspect something might be wrong with it
As you can see, it is a little bigger than an Arduino, but that's OK since it has an optional enclosure that houses it nicely:
This is the combination I bought. Then, I took his example code, modified the heck out of it such that it could watch a particular device (even if the device was transmitting to a specific address) and was able to troubleshoot my network.
Of course it isn't perfect. The Freakduino only runs at 8MHz, so it's entirely possible for it to be unable to keep up with the traffic on a heavily loaded network like mine used to be, and there are probably a couple of problems with the library he provides to get you going, but that's the kind of thing we're best at.
So, I was able to cut the traffic down on my network by a huge amount, and I can monitor any device to see what is actually happening. Now, I have bandwidth to add even more devices.