Xbee Coordinator 2.5 reads fine, write... not so much

Wireless & IoT
1

I have 2 xbees. Both version 2.5.

One set as, Coordinator AT, the other as Router At.

The Router can send and receive data fine.

The Coordinator is having major issues sending data, but can receive fine.

It will drop 90+% of the serial data sent out.

I have 4 other routers, and they are all seeing this, so it is the Coordinator.

Anyone ever see this?

To test it

I have one arduino that is just constantly sending numbers… 0-255, back to 0. And an other one reading them and it fades an LED.

If I have the Coordinator sending, the router end does not get 90+ % of the numbers, and it jumps every 10 sec or so. If I pull the xbees and switch them, the Coordinator end fades perfectly.

2

Update…

So I flashed a second xbee to be the Coordinator.

(unplugged the other so it wouldn’t interfere)

Same exact issue.

What can the Coordinators read, but not write?

They are

XB24-B ZNET 2.5 Coordinator AT (tried firmware 1041 and 1047)

3

I’ve always had success when using one as a coordinator and the other as an end device. (It looks like you tried that in your first post).

There is a walk through at the link below. It starts out describing how to configure the settings of each module, and then moves on to using them with an Arduino. I realize that you may not be using them with an Arduino, but the “setup” portion of this may help.

http://antipastohw.blogspot.com/2009/01 … hield.html

4

Thanks. But same issue.

I am connected to arduinos. Tried 5 of them, and 5 Xbees.

It has to be be 100% my settings.

http://risdpedia.net/images/4/42/Xbee.png

AZRobbo:
I’ve always had success when using one as a coordinator and the other as an end device. (It looks like you tried that in your first post).

There is a walk through at the link below. It starts out describing how to configure the settings of each module, and then moves on to using them with an Arduino. I realize that you may not be using them with an Arduino, but the “setup” portion of this may help.

http://antipastohw.blogspot.com/2009/01 … hield.html

5

Since you’re having the same problem on 5 different devices, I would try contacting Digi support.

They may take a day or two to get to you, but I’ve been told they are good at helping out. (I’m also guessing that they would be much quicker than posting back and forth on this board.)

6

ameyer:
I have 2 xbees. Both version 2.5.

One set as, Coordinator AT, the other as Router At.

The Router can send and receive data fine.

The Coordinator is having major issues sending data, but can receive fine.

It will drop 90+% of the serial data sent out.

I have 4 other routers, and they are all seeing this, so it is the Coordinator.

Anyone ever see this?

To test it

I have one arduino that is just constantly sending numbers… 0-255, back to 0. And an other one reading them and it fades an LED.

If I have the Coordinator sending, the router end does not get 90+ % of the numbers, and it jumps every 10 sec or so. If I pull the xbees and switch them, the Coordinator end fades perfectly.

By drop, do you mean that a constant stream is missing a few bytes, or entire 100 byte blocks are missing? If you send more than about 100 bytes without some sort of hardware (CTS) or software (XOFF) handshaking, you lack flow control and can get buffer overruns.

Otherwise, RF based errors should cause an ACK timeout and you should detect that and retransmit or give up.

7

Im not 100% sure

Im sending serial lines constantly, and maybe 6 every 200 or so will come through.

Here is a video that documents it.

http://vimeo.com/3477523

and one focusing on the serial

http://vimeo.com/3494116

stevech:

ameyer:
I have 2 xbees. Both version 2.5.

One set as, Coordinator AT, the other as Router At.

The Router can send and receive data fine.

The Coordinator is having major issues sending data, but can receive fine.

It will drop 90+% of the serial data sent out.

I have 4 other routers, and they are all seeing this, so it is the Coordinator.

Anyone ever see this?

To test it

I have one arduino that is just constantly sending numbers… 0-255, back to 0. And an other one reading them and it fades an LED.

If I have the Coordinator sending, the router end does not get 90+ % of the numbers, and it jumps every 10 sec or so. If I pull the xbees and switch them, the Coordinator end fades perfectly.

By drop, do you mean that a constant stream is missing a few bytes, or entire 100 byte blocks are missing? If you send more than about 100 bytes without some sort of hardware (CTS) or software (XOFF) handshaking, you lack flow control and can get buffer overruns.

Otherwise, RF based errors should cause an ACK timeout and you should detect that and retransmit or give up.

8

how is CTS wired on the mainboard for each?

Is the option for ACK in the 802.15.4 turned on?

Is the serial data constant, back to back bytes or are there inter-character delays? At what baud rate?

(neat: I saw one of the videos; the other, like many on Vimeo, won’t play after repeated tries “Try later”, as if Vimeo is overloaded).

9

Im actually not sure about any of that.

Im using an arduino funnel on one end (has xbee shield built into it). On the other side right now, im just using the xbee explorer.

Im not sure what ACK is or how to switch it.

For this test. I am actually just sending serial ints.

On the arduino it is just this now (to make it even simpler)

int count = 0;

void setup()  { 
  Serial.begin(9600); 
} 
 
void loop() { 
  count ++;  
  Serial.println(count); 

}

stevech:
how is CTS wired on the mainboard for each?

Is the option for ACK in the 802.15.4 turned on?

Is the serial data constant, back to back bytes or are there inter-character delays? At what baud rate?

(neat: I saw one of the videos; the other, like many on Vimeo, won’t play after repeated tries “Try later”, as if Vimeo is overloaded).

10

ameyer:
Im actually not sure about any of that.

well, leave no stone unturned. It a’int magic

11

Hi guys, I’ve been experiencing similar troubles and would appreciate some help.

Basically my problem is the delay I experience between two xbee radios after having send a few bytes without any problems.

My setup consists of 2 Arduino XBee Shields each connected to a Duemilanove board.

I’ve removed the processors from Duemilanovas and connected them directly to a PC running X-CTU. I reset the modems and made the other one ZNET 2.5 ROUTER/END DEVICE AT firmware 1247 and the other one ZNET 2.5 COORDINATOR AT firmware 1047.

All the other settings are default. Then I short DOUT and DIN pins on the End Device XBee and start the terminal in X-CTU to the Coordinator. Now in the terminal I can see characters come back for the first ten or so bytes after which I start to see delays of five seconds or so before the bytes are returned.

So the actual question is what do you mean by the ACK option in the 802.15.4.? Could it have something to do with this? Any other ideas are more than welcome also.

Thanks.

PS. I attached some screenshots of the problem. In the first oneI press the k key about once a second on my PC. In the second one the three 32 byte packets go through nicely followed by a 10s timeout and then again the fast transmission of the next three packets.

http://i44.tinypic.com/2eq8g7a.jpg

http://i43.tinypic.com/2eghab8.jpg

12

Im having the exact same issue. Router is sending fine to coordinator, but not the other way round. Co-ordinator to router data stutters and delays, sometimes missing data entirely

Any solutions yet?

13

I had the same issue as well.

router/endpoint → coordinator = good

coordinator → router/endpoint = delays/dropped data, etc.

I found that if I explicitly set the destination for each module then the problem goes away.

By default the destination of the coordinator is 0xFFFF which is the broadcast address for the PAN. The default router/endpoint destination is 0x0 which is the coordinator. So this should work but it doesn’t seem to work very well.

If you set the DH and DL of each module to the SH and SL of the other, the problem should go away (at least it did for me).

On the coordinator:

Set DH to the router/endpoint’s SH

Set DL to the router/endpoint’s SL

On the router/endpoint:

Set DH to the coordinator’s SH

Set DL to the coordinator’s SL

Note that this kind of defeats the purpose of a mesh network and you can only have 2 devices talking to each other.

14

Thank you so so much!

15

So if i wanted a third xbee that sent (only) data to the coordinator, this is not possible?

so 3 xbees (a,b,c)

a = coordinater

b = router/end

c = router/end

I want…

C sending to A

A sending/receiving to B

possible?

Cheers

Ben

16

I think you meant:

B sending to A

A sending/receiving to C

otherwise it doesn’t make sense.

Either way, I don’t know what will happen if you try to add a third XBee as I’ve never tried it.

It’s probably worth contacting Digi and asking before you purchase another. I’ve been meaning contact them about the original issue but just haven’t had a chance (and the XBee’s are currently in another location).

17

XBee use IEEE 802.15.4. Every '15.4 device has a MAC address, just like every ethernet and WiFi (NIC) has a unique MAC address.

So if you don’t use a full network layer protocol like ZigBee, ISA 100 or 6LoWPAN, then you set the destination address to the MAC address of the intended node. Or use the broadcast address (though broadcast precludes using the inherent error correction via ACKs).

Most '15.4 based modules can use a “short” 16 bit address whereas the MAC address, actually called an OUI, are 64 bits.

The coordinator is really irrelevant in a network which does not use routers or gateways or meshing. No need to “associate”, unless you want the coordinator to try to queue frames until a sleeping end-node wakes up and polls.

18

This may be true but it doesn’t address the issue as there are many good reasons to use a coordinator and many situations where it is necessary.

So simply saying “don’t use a coordinator and the problem goes away” isn’t a workable solution.

19

etracer:
simply saying “don’t use a coordinator and the problem goes away” isn’t a workable solution.

who suggested that?