xbee constantly resetting or timing out?

XBee & XBee Gateway XBee - 802.15.4
1

Xbee Pro Series 1 modules running 10E6 firmware. Programming through X-CTU version 5.2.7.5. Remote Xbee programmed through “remote configuration” of X-CTU (not direct hookup).

Hi,
I have a network of only two xbees. One is a base station, the other is remote. 5 DIO lines are transmitted from the base station to the remote (a high signal on a base station pin produces a high signal on a remote xbee pin). One ADC line trasmits an analog voltage from the remote xbee back to the base station which is output as pwm.

Everything seems to work okay, finally. However, I do notice that approx. every six and a half seconds all outputs and the analog line “blip” low, then go high again.

For instance, my analog line is connected to an LCD that reads a value from a sensor at the remote xbee. Every six and a half seconds, the displayed value drops to zero for a split second. Additionally, I see all of the DIO’s drop to zero momentarily as well.

Four of my DIO inputs are from a microcontroller and one from a toggle switch. If, for example, the toggle switch is switched high, the xbee output pin on the remote xbee will read high for approx. 6.5 seconds, then momentarily low, then high again. Repeat. The ADC input is from a remote sensor, yet all six transmitting pins are blipping at once which makes me think it is xbee related and not micro/toggle/sensor related.

Variables:

base module:

AP=1
PR=0
D7=3
D6=3
D5=3
D4=3
D3=3
IU=0
IT=1
IC=FF
IR=3C
IA=FFFF
T0-T7=FF
P0=1
P1=2
PT=FF
RP=28

Remote module:

AP=0
PR=0
D7=4
D6=4
D5=4
D4=4
D3=4
D1=2
IU=0
IT=1
IC=0
IR=70
IA=FFFF
T0-T7=FF
P0=1
P1=0
PT=FF
RP=28

Any ideas for how to remove this signal interruption? I have never had a problem with power supplies but could this be power supply related? Or timeout related? Or sample rate related? Attached is a schematic of my layout.

Thanks.

2

I can’t diagnose a specific cause for the problem, so instead here are a few random thoughts. Maybe one of them will help, maybe not.

First, 10e6 is now becoming a fairly old firmware version. I see from the Digi site that 1xec is now out, and my first suggestion is to upgrade to that and then try again. Even if it doesn’t solve the problem it will greatly enhance your street cred with the fine folks at Digi support if it proves necessary to contact them directly about the issue :slight_smile:

I’ve looked at your schematic and settings, and I can’t see anything obviously wrong. However, if a firmware upgrade doesn’t fix it then read on.

  1. On the remote, your settings for D3-D7 are 4 (digital output low). Try changing that to 5 (digital output high) and see whether the “blip to 0” changes to a “blip to 1”. If it does, it would indicate a timeout avenue to explore.

  2. In your settings I can’t see anything that would cause an action every six and a half seconds. Is that a reliably repeatable figure? If so I can construct what I believe is a possible - though highly unlikely - scenario.

The scenario builds on the observation that on each XBee you have the IA parameter set to 0xffff. The scenario also builds on the assumption that all the parameters you didn’t list are still at their default values. The IA value of 0xffff means that each XBee will accept a line state setting command from any source. If there’s another XBee in your vicinity that’s also set to the default channel, PANid etc, AND if that XBee has been programmed to broadcast its line states every six and a half seconds, then your XBees will accept that broadcast.

It would be safer all round to set each XBee’s IA parameter to the address of the other XBee. Then at least the unlikely scenario would be eliminated.

Perhaps you’d like to try these thoughts first and then report back on whether you’ve found a solution.

When you do report back, here’s a small suggestion. If the problem is still happening, could you save the settings for each XBee into a .pro file (using X-CTU), and then attach the.pro files to the post? By all means also put the non-default settings into the post as you did before - it’s just that the .pro file contains more info and I have a little program here that can make use of it.

3

I will take your advice and update the firmware later today on the two xbee modules. However, when talking to Digi Tech support, neither person I talked to mentioned this as a possible issue. When I update the firmware (which requires removing the xbees from their assemblies), I will save the .pro files.

In the meantime, to answer your questions:

  1. Setting D3-D7 to 5 (output high) made the ULN2803A driver inoperable. This was an avenue that I previously tried. It was constantly trying to switch on every relay, but I suspect the resistors to GND acted to suppress it, resulting in all relays and associated motors constantly clicking and buzzing. Kind of like repeated shorting.

Side note: I don’t have a scope handy to view with certainty what is going on and am sort of guessing here. But I’ve heard the same sorts of sounds from relays on other projects.

  1. The building I work in is ours alone, surrounded by fields and either houses or vacant properties. In our building my xbees are the only two in operation. In addition, I have tested the network on different days, and it always yields the same result.

In terms of six and a half seconds, this was measured watching with a stopwatch for numbers on a LCD to change (my sensor display). While the exact duration might be a little off, I am certain the high-low-high action is cyclical with constant duration.

I’ll get back to you with more when I update the firmware.

Thanks for the response.
Blake

4

Okay, went ahead and installed new firmware on both modules. They now have 10EC. Attached are the .pro files.

I do note that the LED attached to the RSSI pin of my remote module is constantly on, until in blinks off momentarily every ~6.5 sec, corresponding to a momentary loss of function (with relays, etc.). The RSSI LED on the control station xbee however, seems to blink at random. This could be do to the differing RP values.

Let me see if I have this straight: If I were to set up the network with addressing, SH and SL are given, and ID and MY I assign myself. What numbers specifically do I put in DH and DL?

My thoughts (please tell me if I’m right or wrong): There are two ways to do addressing, long and short. In the long method, I set the DH and DL of the remote xbee exactly to the SH and SL of the base xbee respectively, and vice versa.

In the short method, I set the DL of the remote to the MY of the base, and the DH to “0”, and the DL of the base to the MY of the remote, and again the DH of the base to “0”. Question: What should I set MY to, and should the two xbees have the same or different MYs?

Finally, one last thought. Could having change detect AND sample rate both set cause an issue? Should I lose change detect?

Thanks,
Blake

5

Hmm.

This six and a half second thing is still unexplained. How about hanging a resistor and LED across the power supply? If that blinks, then that’s the problem. Of course, if it doesn’t blink it doesn’t rule out the power supply because any spike might be too short. Maybe you could rig up a “poor man’s scope” with a diode, a resistor and a capacitor - but try the LED first.

In the .pro files, you have DH, DL and MY set to zero at both ends, which can’t be right. Try setting DL to 1234 and MY to 5678 at one end, and DL to 5678 and MY to 1234 at the other end. Choose your own 16-bit numbers at random, avoiding 0xfffe and 0xffff. Now the two XBees will use short addresses and each will talk to the other.

Page 4-2 of the cookbook goes into more detail on addressing, though you have it pretty much right in your explanation. The key point is that each module has its own address, and all modules must have different addresses.

Having change detect and sample rate both active should be fine, though from another of your posts I think you’ve already discovered that.

6

Checked the power supplies with an LED and saw nothing, and changed the DL and MY for both modules and the problem continues.

In terms of power supplies, I don’t really think this is the issue because I have been using these supplies for years with other microcontrollers and have never had the same problem.

The power supply is a TDK Lambda DLP180-24-1/E (datasheet: http://us.tdk-lambda.com/lp/ftp/Specs/dlp.pdf), which outputs 24VDC which is then sent through a LM317 regulator. My LM317 has .1uF on the input and 10uF on output.

I’m interested but unfamiliar with what you mean about the diode, resistor, cap “poor man’s scope” but did a google search and found nothing conclusive.

Digi tech support says they are unable to replicate the issue. I can’t imagine what this could be other than maybe all xbees do this but it is unnoticed unless a motor or display is attached?

Blake

7

I think we’ve reached the point where desperate measures are needed…

This is what I’d be doing now in your position (and I have been there from time to time, as have we all).

  1. Tell yourself that if this is an XBee problem, then you’re the only person in the world to have discovered it. Also tell yourself that if the fine folks at Digi support have never heard of it, it isn’t an XBee problem. Repeat until you’re convinced that it isn’t an XBee problem. [1]

  2. Strip the problem down. Start by disconnecting the microcontroller and the remote relays, and see whether the problem persists if you just use the toggle switch.

  3. As well as disconnecting the relays, disconnect any motors and anything else that has inductance.

  4. No luck? Disconnect the display and try again.

  5. If the problem is still there, keep removing stuff until it goes away.

  6. Put things back one by one until the problem reappears.

If you can reproduce the problem with a circuit simple enough for me to breadboard, then post the circuit and we can both have a go at it.

[1] It could still be an XBee problem. It’s the mindset that matters :slight_smile:

On the poor man’s scope, I’m not surprised you didn’t find it on google because it was an off-the-cuff invention. I fully take your point about the power supply being an unlikely culprit, but just for completeness I’ll explain what I was thinking. I’ve never tested this idea by the way.

I’ll try to describe the circuit I had in mind.

Draw two horizontal lines for the 3.3v rail and the ground rail.

From the 3.3v rail, draw a 100k resistor. Call its free end A.
From A, draw a 47uF capacitor whose other end is connected to the ground rail.
Between the 3.3v rail and A, connect a diode such that it’s reverse biased.
Connect a voltmeter across the capacitor.

When power is applied, the capacitor will charge up through the resistor. The time constant of that combination is of the order of 5 seconds, so it will take a while to be fully charged. Since the diode is reverse biased, it has no effect on anything.

If a short drop in power happens, the diode will become forward biased and will discharge the capacitor through the rest of the circuitry. This discharge will be rapid. (The diode must be rated to carry the current that the rest of the circuitry normally takes.) After the spike, the capacitor will slowly recharge through the resistor, allowing the effect to be seen on the voltmeter.

Having said that, it all seems like an unnecessary complication. If there’s a spike, it’s too short for the LED to show it: say less than a twentieth of a second. A bigger capacitor across the power rails would guarantee to supply power over such a period, and would be easy to do.

Mm. Let’s just agree to forget that I ever mentioned the idea.

BTW, please don’t take umbrage if any of the above sounds like teaching grandma to suck eggs. I mean no offence.

8

I appreciate the help and the second opinion. I find reviewing the basics sometimes helps to see problems in a different way.

I have pulled wires to see if any relays or extraneous components were causing the problem, but not in any systematic way. I’ll try pulling parts today, one by one, and see if anything changes.

I’ll also try that voltage drop sensor diode thing and see if it works.

Blake

9

Removing all microcontroller or switch input from the transmitter and all relays from the output did not affect anything. The only things still connected were a bunch of resistors on the transmitter, an RSSI LED on both xbees, and the ULN chip on the receiver.

10

And the problem is still there? Wow!

Well, I don’t have a ULN chip. If you also pull that and the problem still remains, you should be left with a circuit that I can try to reproduce.

This is an interesting brain-teaser. I’m still willing to help but I need to make some demands :slight_smile:

What I would want:

  1. The circuit schematic of the minimal system that reproduces the unwanted effect. The circuit schematic needs to have enough detail for me to build it on a breadboard. If I don’t have all the parts to hand, we’ll have to negotiate.
  2. The .pro files from the minimal system that exhibits the effect. Not the .pro files you posted earlier - I’m asking for the ones that go with the minimal system that exhibits the effect.
  3. A description of what happens with the minimal system, and how that differs from what you expected would happen.
11

Ok, so I pulled the chip, and all inputs and outputs, except power. I also left the one switch input to the xbee so I could see if anything was still happening, and on the output, in place of the ULN chip, I put an LED.

Usually on the output the RSSI light is steady on, and blinks out momentarily when our situation happens. However, with this setup, it started staying off for a few seconds, or flickering a bit, even though my two stations were right next to each other. When the six and a half seconds came around, the RSSI light and the temporary output LED both flickered as expected.

Attached are images and schematics of my two setups.

12

By the way, I had the control side made up on a solderless breadboard until Friday. After soldering it all together, same issues.

i guess if it works fine for you, it’s got to be my power supply. I guess I’ll try to find a different one and try it soon. Only other thing is the antennas. I just grabbed two off of some old routers. But that couldn’t cause what we’re seeing I don’t think.

13

Could be the power supply or could be the antennae. Or it could be something else.

It doesn’t yet work fine for me because I haven’t been able to try it. You need to provide a description of how to reproduce the problem such that others can experience it.

What’s with this antennas comment though? Why would you expect antennas from old routers to work? And what are they connected to?

14

Okay. I’m not sure what you mean by provide a description of how to reproduce the problem. Above are schematics, photos of my setup, and pro files for the two xbees. This problem doesn’t arise from a certain set of commands. As long as the setup is powered, you can see the RSSI flicker every time it resets. Also, you could use the toggle switch shown in the setup to turn on the “test LED” shown connected to pin 4 of the remote xbee. When I do this I see this LED flicker at the exact moment the RSSI led does.

Additionally, I have had this problem whether or not this was breadboarded or soldered, so i suspect it doesn’t have to do with how physical components are soldered or placed.

About the antennas. As seen in the photos, I have the xbees with a u.fl connector. I have the Sparkfun u.fl to rp-sma connector (seen here: http://www.sparkfun.com/products/662) and then yes I have attached an unspecified unknown rubber ducky antenna to both xbees. These antennas were taken off of routers so that I could quickly test whether the system worked. I am using these two xbees at 5-10 feet apart. Could these antennas really cause an issue? What antenna would you recommend? I looked at the list in the back of the manual and the first listed part number looks identical (from a google search) to the ones I’m using.

Thanks,
Blake

15

"“Okay. I’m not sure what you mean by provide a description of how to reproduce the problem.”

What I mean is that you need to specify a simple circuiit that I can build, with components that I have to hand. I have a few XBees and a collection of resistors and capacitors. I also have plenty of power supplies, and a large collection of transistors and LEDs. And a few breadboards.

You’ve published what you have and that’s great. If you want more help, you need to narrrow down the problem so that others can reproduce it.

Your circuits involve components that I don’t have. I’ll keep trying to help if you can eliminate those components.

16

This should be what you’re looking for I think. If this doesn’t reproduce the problem then I don’t know what else it could be. The only parts eliminated from these schematics are some plastic connectors.

It seems it will then fall on the power supply once again, or the antenna. Thoughts on the antenna?

17

I have not looked through all of this thread, but being devil’s advocate and looking at your photo … your unit seems pretty ‘capacitor poor’. I have a design (no photo on this machine to show you), but it sas 2 x 100uF caps after the regular … you have only 1x1 uF per your schematic.

The Digi XBIB board has: 1x3.3nF, 1x100uF, and 1x10uF after its regulator … yes, it is a switching regulator, but your external 24vdc probably also is a switcher with a very noisy output since industrial things - and relays slamming on/off - don’t care much about clean 24vdc power. In fact, 24vdc and clean-power are pretty much mutually exclusive!

When the XBee 'powers up the TX", it’s current draw jumps by an order of 10 times, which could be causing brown-outs - or when a 24vdc relay latches on or off, you could get a strange high-voltage-but-low-energy transient surge in through your regulator.

Just some guesses, but having better local capactor (1 or 2 electrolitics and a few smaller multilayer/ceramics) would help buffer this unset to the power equation Power=Amp*Volts.

18

Thanks, Lynnl for the response. I added a 220uF electrolytic cap to each xbee power input per your suggestions. On the remote xbee, this is in addition to a 1uF and a .1 uF. On the control xbee, this is in addition to a 10uF and a .1uF.

The addition of the 220uF caps did not solve the problem. Perhaps I could have gone further, but I was surprised by how cyclical the resetting was.

I have finally gotten the problem to stop. At a loss for what to do, and because my indication of the problem was a blink on the RSSI LED, I wanted the try a rangefind with X-CTU between my chips. However, rangefind didn’t work, of course. This was because the remote xbee must bounce back a signal it receives. I had not tied my DIN to DOUT on the remote xbee because my application never used serial, only DIO pins. I soldered the DIN to the DOUT and suddenly no more blinking of the RSSI, and no more momentary blips on my DIO lines.

Does this make sense to anyone?

Thanks to John and Lynnl for the help through this. I hope this thread and the attached schematics help someone else starting out with xbees. I guess the big tip here is to tie your serial lines together if you are only using DIO pins?

19

If I understand correctly, the failure happens when DIN and DOUT on the remote are disconnected, and is cured by connecting DIN to DOUT.

That sounds as though the DIN pin may be picking up noise, causing continuous transmissions. I see from your last .pro files that at each end you have the PR parameter set to 0, disabling all pullup resistors. It would be interesting to know what happens if you set bit 7 of PR to 1 at each end, thus enabling the pullup resistor on DIN. Then try the circuit again with DIN and DOUT not connected, and see whether that cures it.

(edit) Or just tie DIN to ground.

20

Good point. When I have a chance to do this I will let you know and post the result. May not be for a while though…