XBee range issues (interference/noise)

Wireless & IoT
1

I have been experimenting with my XBees, first I had the Controller XBee on a breakout connected to the Raspberry Pi, and the second connected to my Android phone with a serial adapter on a breadboard.

With this setup I was able to take the phone-connected XBee across the house, even downstairs and outside and still send and receive data.

Having been happy with this, I moved the Controller onto a Slice of Pi (http://shop.ciseco.co.uk/slice-of-pi-ad … pberry-pi/) and my Router onto a breadboard connected to an Arduino Pro Mini using proto (jumper) wires.

With this setup, I was now getting no more than 6 feet of range! First move was to re-wire the breadboard with flat wires against the board, and I gained an extra few feet, say five or six, of range.

Can anybody make suggestions how I can find first off, identify which of the two device is having the issue, the one mounted on the Pi with Slice of Pi or the one on the breadboard (I suspect it’s the breadboard one) and then how I can solve the problem that is having a HUGE effect on the range of my communications?

I read the XBee datasheet which suggested noise filter caps across the VCC and GND of the XBee of 100uF and 8.2nF. I didn’t have exactly an 8.2nF but did have an 8nF so I used that (ceramic) and my electrolytic caps havn’t arrived yet so I don’t have the 100uF in place yet. Can I use multiples of the cap sizes? Because I do have 82nF ceramic caps.

2

I’ll guess that the XBee interface you are using is the Serial port. There is nothing with this that should limit range.

Exactly which XBee modules are you using? The Firmware version is very good for module ID so post this.

Which antenna is on the XBee’s?

Is the antennas in the clear and not near any of the other circuits?

Is there any other RF device (WiFi, Bluetooth, etc) near either XBee? Does the R-Pi have a WiFi module?

Keep any of these RF devices at least a foot away from the XBee.

The XBee’s do have an RSSI register (received signal strength) that can be read. Write some code to read this register from each XBee. This can help determine which is not working but maybe not since it could be on the transmitter or receiver side.

There could also be an RF output power register in your XBees. Read the value to ensure this setting hasn’t been changed to a lower power.

Re-setup your first configuration and test to see if they still work as they first did. If they do still have good range then its the new setup that has an issue. If the range is greatly decreased running with the first setup then one or both of the XBees have a problem.

Lastly: The XBees are 3.3V devices and a Voltage greater than 3.6V on any pin can damage them. Did you ensure that you Slice of Pi (the R-Pi is 3.3V logic so is ok directly to the XBee) and the Arduino Pro are 3.3V logic level signals to the XBee? Is the Arduino Pro 5V or 3.3V?

3

waltr:
I’ll guess that the XBee interface you are using is the Serial port. There is nothing with this that should limit range.

Exactly which XBee modules are you using? The Firmware version is very good for module ID so post this.

Which antenna is on the XBee’s?

Is the antennas in the clear and not near any of the other circuits?

Is there any other RF device (WiFi, Bluetooth, etc) near either XBee? Does the R-Pi have a WiFi module?

Keep any of these RF devices at least a foot away from the XBee.

The XBee’s do have an RSSI register (received signal strength) that can be read. Write some code to read this register from each XBee. This can help determine which is not working but maybe not since it could be on the transmitter or receiver side.

There could also be an RF output power register in your XBees. Read the value to ensure this setting hasn’t been changed to a lower power.

Re-setup your first configuration and test to see if they still work as they first did. If they do still have good range then its the new setup that has an issue. If the range is greatly decreased running with the first setup then one or both of the XBees have a problem.

Lastly: The XBees are 3.3V devices and a Voltage greater than 3.6V on any pin can damage them. Did you ensure that you Slice of Pi (the R-Pi is 3.3V logic so is ok directly to the XBee) and the Arduino Pro are 3.3V logic level signals to the XBee? Is the Arduino Pro 5V or 3.3V?

The modules are the the XB24-Z7WIT-004, 2.4GHz, 2mW whip antenna. Both are running the latest firmware as of about 24 hours ago, I don’t have the firmware numbers off the top of my head because I’m not at home, but the model number should be sufficient to identify them.

The antennas are upright and clear of any other wiring or circuitry.

The R-Pi DOES have a Wi-Fi dongle attached, which with the initial setup would have been over a foot away, but is now only the distance of the length of the R-Pi away. I hadn’t considered this, but I can easily unplug it when I get home and test the transmission since I can see RSSI via an L.E.D on my adapter boards.

There IS an output power option on my modules, I’m not sure what it’s set to, currently (again, I’m not at home) but I can say that I have factory reset BOTH devices since it originally worked, so it’s possible this was lowered from what it was set to originally (I didn’t check what the setting was before, just that it existed).

As for the 3V3, I’m an Electronic Engineer, so I’ve got this one covered. The XBee on the Arduino board is running from a regulated source which I’ve measured at a steady 3.25V alongside a 3V3 Arduino Pro Mini. The Raspberry-Pi’s GPIO is 3V3 logic-level, the boards (slice of pi) power comes from the 3V3 pin on the Pi.

So, from your response, my first port of call will be to unplug the Wi-Fi transceiver from the RPi and see how this affects RX/TX, second, failing that, I’ll revert to the original setup on the R-Pi end (i.e. the XBee is on a breadboard at the end of a ribbon cable, about a foot from the RPi), then I’ll restore the Pi to the Slice of Pi and test the original setup arduino end, which was XBee only, via serial interface to my Android phone, and finally, to the complete original setup.

Before all that, I’ll check that the output power of both device is set to the max value supported (2mW).

Thanks, and I’ll get back to you soon as I have had a look.

4

Ok, I’ve just spent the last few hours eliminating the hardware issues, did all of that described above only to find it still didn’t work.

So next I switched to checking software. First thing I realised was that my Coordinator is now running API firmware not AT firmware. Soon as I switched back to AT firmware, presto, I can get my long range signals back, and it works all the way outside the house again.

So, the new problem is, why does API mode totally kill my range? The XBees are practically useless to me if I can’t use them in API mode.

5

API vs AT command mode should not make a difference.

The XB24-Z7WIT-004 modules I believe are running ZigBee protocol and the change from AT to API the firm must be changed. Did you write the correct firmware for that module? Did you do this with X-CTU?

Post the two Firmware versions you used.

Another thing to try is an older API firmware version, just one version back in case there is a bug in the latest version.

Also, check the power setting from X-CTU (PL & PM) with API and AT firmware. Its possible that the API firmware set a lower power level to startup with. You can dump (Save Profile) the XBee parameters and post them here.

Since the range came back with the AT firmware the XBee hardware is fine. Just need to discover what is different between the modes.

6

waltr:
API vs AT command mode should not make a difference.

The XB24-Z7WIT-004 modules I believe are running ZigBee protocol and the change from AT to API the firm must be changed. Did you write the correct firmware for that module? Did you do this with X-CTU?

Post the two Firmware versions you used.

Another thing to try is an older API firmware version, just one version back in case there is a bug in the latest version.

Also, check the power setting from X-CTU (PL & PM) with API and AT firmware. Its possible that the API firmware set a lower power level to startup with. You can dump (Save Profile) the XBee parameters and post them here.

Since the range came back with the AT firmware the XBee hardware is fine. Just need to discover what is different between the modes.

Ok, problem solved, I hope this will be useful to someone else so I’ll spit it out here. I got in touch with Digi support, who, might I add, offered the best customer/technical support I have ever dealt with! Props to Digi.

So, from the beginning; It turns out that when you flash a new firmware to the coordinator, it created a new network, regardless of whether or not the PANID still matches, it is a new network.

What this meant was that my router was on the wrong network, and hence, the wrong channel. This is where the important part comes in, and I’m roughly paraphrasing here because I left the transcript at home; XBees can communicate at up to 12 channels off from the “correct” channel at short distances. This resonated with me because, surely if it was “new network” alone, they wouldn’t communicate at all right? Right!

So, the solution I was given was that once you update firmware on a coordinator, you MUST issue an ATNR1 to every node (router) in the network. Also, you should issue an ATJV1 to enable channel verification (so it will switch channels automatically if it finds it’s on a bad channel (i.e. wrong “network”).

Having made this simple change, (issue ATNR1, then ATJV1, and ATWR (write, don’t forget the write)), took the router across the house and voila, we have lift-off.

I’ll do a simple write up of this at some point on my blog because I think it’s a pretty critical, non-documented thing that would otherwise drive you (as it has me) crazy.

7

Ahhh…I almost thought of it being a network issue but was trying to eliminate other possibilities.

Very good you contacted Digi and got this to work.

Thanks for posting the solution. I might need this info in the future when I forget about this.

8

waltr:
Ahhh…I almost thought of it being a network issue but was trying to eliminate other possibilities.

Very good you contacted Digi and got this to work.

Thanks for posting the solution. I might need this info in the future when I forget about this.

Yeh, no problem, thanks again for your help.

As for posting the solution, there is nothing worse than traversing the internet and finding a forum with the same problem you have, only to find the OP clearly solved their problem and just never bothered to come back and explain how!

I’m much more impressed with the XBees (than I was before, based on no information) after this debacle, knowing that even with all the potential RF issues of building on breadboards, and potential noise from the Arduino on the same board, coupled with the R-Pi and it’s WiFi adapter only 10cm away from the XBee, and yet I can still get more than enough range through a wall or two (RSSI LED still lights brightly, as opposed to weak signal lighting it dimly)!

9

Yes, you really do learn once there is a problem that needs to be solved.

I too have been impressed with XBees and the ZigBee protocol. They do just work well and the newtwork can be configured is many ways.