XBee Interference from Propeller?

Ken Gracey

Hey there,

Just moved an RF setup with the XBee24 (lowest power, chip antenna) RF device from a Propeller PDB to a Propeller Proto Board. Now it doesn't function as well - a portion of the data sent between the two XBee modules is corrupt. The Propeller is within 2 cm of the XBee module. Somehow the Tx and Rx seem to agree on the data as being good, however (assuming they have the built-in error checking). Worked nearly flawlessly on the PPDB, however.

Do you think the Propeller could be causing interference with the XBee device due to close proximity, or not?

I'm using the transparent mode, 9600 bps straight-through without error checking, checksums, etc.

Any input from RF rookies and gurus is most appreciated. I'll be back in about an hour.

Thanks,

Ken Gracey

Invent-O-Doc

Not sure. I have had XBee modules very close to SX chips and on the prop PDB with no problems but have never tried them on the protoboard. I can say from experience, however, that the XBee with the little whip antenna has worked much better for me than the chip antenna unit, which I had only one but it was always flaky.

Could the fractal pattern antenna be picking some RF interference from the propeller chip that other packagings don't? (Whip, ext. antenna) Just a thought. Let us know the outcome whatever the problem turns out to be!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

---

Thomas Talbot, MD
Gunpowder, MD, USA

Ken Gracey

Thomas,

Probably an issue. I need to get Xbee modules with a better antenna, pretty quickly. Might as well go for the higher-power ones at this stage, too.

What confuses me is that these little guys have their own internal handshaking, data verification, etc. but it seems that they still slip some bad bytes through to eachother. Maybe the configuration utility from Digi gives me some kind of control over the checksum routines in the module. I need to take a look at that.

Thanks for the help.

Ken Gracey

Mike Green

Something is screwy. The X-Bees do all their own error checking and retries no matter what mode you put them in. Transparent mode does all the error checking, buffering, and retries. Perhaps you have a bad connection between the X-Bee and the Prop. The frequency used (2.4GHz) is way beyond what the Prop can generate by more than an order of magnitude. Maybe you have noise on the power source for the X-Bee and that's corrupting the data. Add some power filtering.

Ken Gracey

@Mike. The claim that they do all of their own error checking and garbage management is real, huh? No crud should get through in this case.

It's a real simple connection to the Prop and I'm even working at 9600 bps. I don't see any visible resets on the XBee module but I'll add some filtering to the power supply. Just a big cap across Vss/Vdd is probably what you'd recommend.

This setup worked fine on the PPDB, but on the Prop Proto Board it's just not the same: lots of errors coming across the link. I still need to setup a serial debug session on the receiver side to see that I'm actually receiving bad data. I think the power supply on the PPDB is more stable and higher current, however.

With my programming skills it is very possible that my problem lies in the receiver Spin code. I'll get into this a bit more tonight after I get the kids to bed. Just finished Mandarin lessons so I need a break from Spin for a few hours.

Thanks, Ken Gracey

Ken Gracey

The "something screwy" Mike spoke about was my coding on the transmitter side. I had a waitcnt statement between each byte, but none on the receiver side. For whatever reason this caused the Xbee modules to act up.

These modules act like a live wire - couldn't be easier to use them.

I'll post the whole code and project when I'm all done. The issues I experienced with these modules were mostly related to configuration and setup. I'll share my results, FWIW.

Ken Gracey
Parallax Inc.

P.S. Did I tell you that we'll soon be selling these to you?

noobmuncher

Oh that will be cool.

Tracy Allen

Hi Ken,

Watch out for the packetization timeout. It is set using the ATRO command, and the default is 3 character times, or about 3 milliseconds at 9600 baud. The XBEE hangs onto the characters sent by the host so long as they keep coming at intervals less than that, or until the buffer fills up to 100 characters. Then it sends the chars in the buffer as a single wireless packet. In general you want all the characters in a single message to travel together in the same packet. That is especially true if multiple XBEEs are sending data asynchronously. The protocol ensures that single packets from each XBEE always get through in one piece. But the protocol is not inherently good at reassembling split packets. That couldn't have anything to do with the difference between the PDB and the ProtoBoard, but I think its better to keep the inter-byte WAITCNT delays less than the RO timeouts.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Rayman

Is it the USB protoboard? And, are you using pins 30&31?

Maybe the FTDI chip is messing with you? (Just guessing...)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

Ken Gracey

Rayman, yes it is the USB Prop Proto Board, but I am not using P30/31. The problem was solved and it was the timing of sender bytes. I had a waitcnt that exceeded the XBee's timeout as described by Tracy Allen, above.

Thanks for all the help!

Ken

Rayman

Any idea why the difference between the 2 types of boards?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

Tracy Allen

That is a curious issue, why it worked with the PDB and not the Proto board with the same code.

Ken, are these XBEEs the "original" 802.15.4 series 1 devices, XB24-A? One can easily become confused, because Digi makes two different hardware platforms running at least 4 different firmware versions, all of which plug into the same socket but are otherwise incompatible and are all called "XBEE". The series 1 devices run either the 802.15.4 or the Digimesh firmware, and the series 2 devices run either the ZNET or the ZB firmware, and the series 2 devices are further distinguished by the need for separate firmware for the coordinators vs router/endpoints. If Parallax is going to sell them, please make it very clear which flavor it is.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Invent-O-Doc

Glad to hear that it worked out, Ken.

That may be a good idea to go with the 60mW XBee PRO if distance or interfering objects are a concern. Now only does it kick out more power, but it has a much more sensitive receiver. I don't have nearly the technical proficiency as many of the people on the forums, but find that those XBees just plain work with minimal configuration. Never tried frame mode though, I stay transparent.
Looking forward to see what you are working on.

Thomas

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

---

Tom Talbot
New Market, MD, USA

Ken Gracey

@Invent-O-Doc: I look forward to sharing the whole project. Transparent mode is just so easy I didn't bother with the framed mode.

@Tracy: the problem turns out to not be associated with my board of choice. I was also having problems on the Propeller PDB now that I think about it. I was running the same code with the waitcnt in excess of XBee timeout on the Prop Proto Board. Once I got the waitcnts under control it couldn't have been easier. I've not seen an error packet for three days! And the robot even survived being chased around by Chip's crawling baby who provided a mobile object avoidance issue for me. When we start selling these I'll be absolutely certain that Chris and I sort out "what's what" and provide a well-done comparison table.

Thanks for all of the help. These little modules are super nice to work with.

Ken Gracey

fullspeceng

For short range distance, I've used the RN-41 from Roving Networks for easy bluetooth.

Bluetooth is nicer to communicate with a PC because you only need to buy 1 unit. $25 is pretty cheap and runs around 300kbps with hardware handshaking.

I think with the Xbee units it was $50 each or $100 a pair but it's been a while since I checked it out.

I know the Xbee 9600baud unit had amazing range though. Like a mile or something.

sylvie369

I know this isn't quite the right place for this, but since Ken is now an XBee expert, I thought I'd ask.

I'm designing a board that will include an XBee transmitting data it gets from a 5V TTL-level source. I've got the 3.3V power and ground set up correctly, but I need to match the level from that 5V serial source to the XBee's DIN (data in) pin.

Will a simple 10K resistor in series do it? (you know, like we use to connect 5V devices to Prop input pins?)

I know that Martin at Selmaware uses a buffer chip, but I suspect that's largely because he's interfacing to so many pins. My board will ONLY use the XBee's DIN pin, so I'm hoping I can just use one resistor.

BillDer

@ken,
Just came across this thread because I just got my xbee's and I can't seem to get them to work. You were going to post the finished code that works with them. But I don't see it here. I downloaded the xbee object code and just want to do a hello world but it keeps hanging when I use the prof. dev. board for the prop and when I move it to another custom board I have the prop reboots when ever I try to send "hello world". So I would like to try code that I know works.