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.
I have a question that I have not found an answer for and I'm guessing that you already have run the experiment that I am thinking about doing. Say you want to broadcast a remoteAtCommandRequest from 1 xBee say your coordinator, to get the battery voltage from all of your other xbee nodes. How do you handle all of the responses? Do you just try and parse all of the data to an Arduino and hope that you don't miss a packet? Or do you just have to give the command out to one node, handle the response, and then go on to the nest node? I honestly don't even know how big the Rx buffer on an xBee is (wondering if a bunch of packets could be stored on the xBee until the MCU can comb through all of the data). I'm building a jeopardy style game show buzzer system for a few of my friends that have a zainy trivia show. It's an interesting xBee application to have a many to one network where all of the nodes are controlled by people that can all send a packet at once and have to see which of them sent the packet first, a lot harder than having everything sent at nice timely intervals. And the system is running stably at 115200!
ReplyDeleteavid reader
Dave
Digi doesn't say specifically how big the rx and tx bufffers are; probably because they change from software release to release. There have been a number of folk that experimented with it and it appears the buffers are around 130 or so bytes in effective length. By effective I mean the XBee itself also puts things in there to send such as retries and forwards. That's why they enable the hardware controls so data input can be stopped if necessary.
ReplyDeleteSo, basically, the quicker you can get the stuff out, the less likely you are to fill up the rx buffer. The slower you stuff stuff in, you less likely you are to fill up the tx buffer.
I have my sensors set up to transmit on a periodic basis and never seem to miss a packet from them. At least not anymore. When I was using them all in broadcast, the multiple retransmissions to get the data all around the network would flood it. Checksum errors abounded. I have a couple of long messages, by long I mean around 50 characters of payload. Those messages were torn to shreds by the various devices eating up airtime trying to forward them.
In your case, there may be some tough problems to overcome. The XBee will listen to see if there is traffic on the RF, if there is, it will wait and try again. These delays are small, but may make the results invalid for two people hitting the button at almost exactly the same time.
Dave,
DeleteI am new to blogging and may not be using proper etiquette, but let me say I admire your hardware and software expertise and the clear, excellent way you write.
For a home network of 5 XBees, can one be designated the master and the others be designated slaves? Can data and commands be transmitted over the whole network? The message rate need not be high.
If you have discussed this question or can refer me to something already available on the web, just say so and save your valuable time. A thousand thanks.
Bill, Yes, they certainly can. They aren't called master and slave, their endpoints, routers and coordinator (only one of these). I have a network of about 12 of them that take care of various things around the house and report status back to a Raspberry Pi that does the work of coordinating the devices and logging stuff so I can look at it later.
DeleteNo, there's no one place where I talk about this specifically, but the entire site (well mostly) deals with how I started this stuff and developed it to where it is now ... mistakes and all. Take a look around and especially the tab up top about XBees. After a bit of reading, you'll start to get it. If you have questions, drop me a note. My email in in the "about me" cleverly disguised so the spambots don't target me.
Hi
ReplyDeletejust saw your blog and must confess it is wonderful. i want to ask how can i send and receive message simultaneously using two xbees
Depends on what you mean by simultaneous. The XBee can only send, or receive at any given time, but it can switch between the two really fast. If you need true duplex operation, you can't do it with only two XBees.
Delete