I have 2 XBee Pro Series 2.5 both set up as end devices in AT mode with no coodinator. About 80% of the time the data I send is received instantly. The other 20% of the time it can take between .5 and 3 seconds to receive the data. The data I send is 5 bytes. I have tried running it between 4800 and 9600 baud with the same results. The distance is only about 3 feet. Any ideas would be greatly appreciated.
are ACKs enabled? If so, perhaps you have a long ACK timeout setting. When an uncorrectable bit error happens, or a frame is lost, the sender has to timeout and re-send. Does the receiver show a strong signal?
another cause can be clear channel assessment delays. If there’s a persistent interfering signal on the channel you’ve chosen, the transmitting device will delay and try later. This delay is settable, but is usually quite short. Of course this delay can iterate if there’s interference.
A VERY busy WiFi system on/near the same freq could do this. The WiFi channel numbers are different than in 802.15.4. And remember that WiFi signals are 20MHz wide whereas 802.15.4 are just 2MHz wide.
Lastly, there’s a programmable delay for accumulating bytes before transmitting. This is to collect bytes and send as many as practical in a single 802.15.4 frame.
You seem to have communication working - but I thought it according to Digi’s architecture guidelines, that you always needed a coordinator device running. Is there any reason why you can’t make one of your devices a coordinator and one an end-point?
With that aside, there is a possibility of RF interference due to the missing Coordinator. During configuration, the Coordinator role performs a series of RF scans to look for RF interference and picks a channel accordingly (the freq. with the lowest noise). The end points inherit this channel when the join the PAN of the Coordinator.
Even as these devices move between environments, they will use whatever channel they were set to when they paired. So, for example, if they were originally configured in a very clean RF environment, and later moved to a different environment with more RF interference, this could cause RF interference. Which could lead to data corruption and re-transmits, and thus slowness.
Are the End Points in the same “RF environment” as they were in when originally paired to the Coordinator?
Thank you both very much for your help. I took AZRobbo’s advice and set up one as a coordinator. That didn’t work, but I started reading about addressing and it turns out I didn’t have the DH and DL addresses set up right. I thought those coresponded to the MY address not to the SH and SL. I am not sure why this would cause it to work 80% of the time, but I really don’t care 
Just so you know what you are reallying helping me with… I took an RC tank and I am setting it up so I can controll it from my computer using a WII mote and I have an infrared camera sitting on top of the turret. I was using bluetooth to talk from my PC to the tank, but the range of bluetooth is pretty terrible. So decided to use the xbee modules because they have a range up to a mile, which is more than the range of my camera so my next project is to increase the range of the camera. Then I am going to build some kind of helmit/hat to controll the turret when you turn or nod your head, like the apache helicopter. Thank goodness I married a woman that thinks this kind of thing is neat.
Cool - I’m glad you got it working!!
Even though it wasn’t the cause of probs this time, I would suggest that you keep one as Coord and one as EP, as it shouldnt hurt anything, and you will be adhering to the original intent of their architecture design.
Also, if you find the need to use more XBee devices in the future, I highly recommend that you look at using “802.15.4” XBees (Series 1). I have yet to run into a project that required the ‘mesh’ capabilities of the ZNet 2.5 XBees, and I think they just needlessly complicate things for 99% of the hobbyists who try to use them.
As technical folks, we tend to buy the latest version of things, thinking they’re somehow “better”. Unfortunately the Xbee versions are not upgrades, but rather different product lines. i.e. Series 1 is not getting phased out in lieu of Series 2. Digi has tried to address this by changing the names for Series 1 to “802.15.4”, and Series 2 to “ZNet 2.5” or “ZB” (depending on the firmware), to stop this confusion.
Unfortunately, a lot of damage has been done, as the old names get used everywhere; even at many vendors, including SparkFun. Thus, the technical write ups, and blog/forum posts continue to use the ‘old’ naming.
Sorry for this rant (which isn’t directed at you) - I just get annoyed when I see people having issues with XNet 2.5 (series 2) devices, when an 802.15.4 (series 1) device would have met their requirements, been easier to setup & configure, and likely not caused them the problems in the first place.
I agree. When I was looking at the modules I knew they were released a product line without mesh networking because it complicated things. I thought the newer version would be series 2.5 since that’s how versioning goes. But then after it shipped I was on digi’s website and they recommended new users using series 1. I was annoyed.