XBEE Interference Sources

Sal Ammoniac

I have a Propeller-based sensor package that sends telemetry to a data logger using XBEE modules (the 1 mW standard versions). The data stream is solid 99% of the time, but on occasion drops out completely or becomes severely corrupted for several minutes at a time before going back to normal.

The two XBEEs are separated by only a few feet, and signal strength measured at the receiving end is quite good. The installation is in a residential neighborhood with the usual mix of WiFi, cordless phone, and other assorted RF traffic.

What are the potential interference sources for XBEEs and is there anything that can be done to mitigate the interference (which is what I'm assuming is the cause of the data dropouts)?

R Baggett

I am having a similar problem. The symptoms are exactly the same!

I'll bet you're using virtual wire packets. (Although other methods in the Xbee object seem to work the same way...)

I think the problem is not RF interference, but a problem with the Xbee object. When decoding packets, the RxPacketNow object reads the serial stream until it's empty, then processes a packet. I think the problem is that we will eventually receive packets very close together, and the second or third packet gets read in with the first, but only the first one will be processed, and I can imagine that those additional bytes might occasionally look like more data, and make it appear to be garbled, or more usually, just disappear..

I'm looking at some possible fixes, but I haven't come up with anything elegant enough to share yet.

I hope Martin Hebel sees this and weighs in, so our 'fixes' are less likely to break something else.. or maybe I'm all wet and he can save me a lot of time??

Jay Kickliter

I haven't messed around with XBees in over a year. But I did write a very robust Spin interface for using 64 bit XBees in API mode. I have no idea where that code went, and might have deleted it like an idiot in a fit of Spring cleaning. Attached is a write up I did for a class. Not sure what you guys need, but it may help. I wrote it in a hurry to get a passing grade in the class, but I did my best to make it actually be useful to understanding the packet structure.

EDIT:

I should note that the interface I wrote borrowed heavily from one I found on the object exchange, and I modified and cleaned it up a little to handle the newer XBees that use 64 bit addresses, if I recall correctly. Also just noticed that most of the code is in the report I attached.

Post Edited (Jay Kickliter) : 5/3/2010 9:44:54 PM GMT

R Baggett

Thanks Jay, I'll look this over. My application is very specific, and this may well be just what I needed. I need to get my project working quickly, but I'll eventually try to merge it with Martin's excellent Xbee object If it turns out well enough (And, indeed if the problem is actually the object..)

Jay Kickliter

I was using higher power transceivers, but at close range I don't think it should be a problem. I can remember completely, but I think I did test if I was loosing any packets and wasn't. I originally tried using the virtual serial line mode, and all of my problems went away when I switched to API mode. You can throw a lot of data at it and it should keep up.

R Baggett

I've kludged together a quick version using SimpleSerial and directly disassembling the packet using info from Jay's paper and the Xbee manual. I guess I was just too lazy to do it before.. It's not very hard at all.

It carefully processes one packet at a time without any buffering. It's been running for about 3 hours now with 4 remote devices in a bustling factory environment complete with hundreds of robotic welders, and Wi-Fi, and 5 KW Microwaves and induction heaters.. a veritable RF nightmare.. and not a single lost packet!

Sal: If your application uses only one remote sensor reporting, simply increasing the baudrate may prevent the overrun problem.

Love the name! Solder on!!