Xbee AT mode multipoint...

Using Arduino Networking, Protocols, and Devices
1

I have several Xbee S2 modules, one running Coordinator AT firmware USB'ed to the computer via an explorer, the rest Router AT firmware on shields with temperature sensing circuits on Unos. All PAN IDs the same, DH & DL on all routers set to SH & SL of coordinator. All Arduinos respond correctly over serial port. No problem talking to first router with it's address configured in the coordinator, responds as expected. However, I can not talk to any of the other modules by changing the coordinator's DH & DL to their address. Set destination back to first router and they talk again. ATND only finds first router even when a different destination is configured and saved. I have reconfigured and rechecked configurations many times and live in the country with no other Xbees for miles.

Several sources have said some people go for a long time before jumping into API mode, but every point-to-multipoint example or tutorial I've seen uses API mode. Is it possible to switch routers in AT mode? Are there examples of what I am trying to do?

Although the slowness of switching to AT command mode and guard times between commands is not a concern, I will eventually use API mode. For right now, I am trying to understand why my current approach doesn't work.

2

Assumptions
Your Co-ordinator and Router 1 seem to communicate properly but no connection with rest of the Routers

I am assuming you are having a problem with broadcasting
https://forum.sparkfun.com/viewtopic.php?f=13&t=33632

I too was facing problems with broadcasting

For Broadcasting - One Coordinator Many Routers

Coordinator Config Commands
+++
ATRE
ATWR

ATID 2001
ATDH 0
ATDL FFFF
ATWR

Note : For Router to work in broadcast mode
ATDH should be set to 0
ATDL should be set to FFFF

Router Config Commands
+++
ATRE
ATWR

ATID 2001
ATDH 0013A200
ATDL 408D723F
ATWR

408D723F is the coordinators SL.

For Point To Point - One Router and One Coordinator only

Coordinator Config Commands
+++
ATRE
ATWR

ATID 2001
ATDH 0013A200
ATDL 409D723F
ATWR

Note : 409D723F is SL for Router

Router Config Commands
+++
ATRE
ATWR

ATID 2001
ATDH 0013A200
ATDL 408D723F
ATWR

Note : 408D723F is the coordinators SL.

Addressing

There are multiple parameters that need to be configured correctly for two modules to talk to each other (although with the default settings, all modules should be able to talk to each other). They need to be on the same network, as set by the ID parameter (see "Configuration" below for more details on the parameters). The modules need to be on the same channel, as set by the CH parameter. Finally, a module's destination address (DH and DL parameters) determine which modules on its network and channel will receive the data it transmits. This can happen in a few ways:

If a module's DH is 0 and its DL is less than 0xFFFF (i.e. 16 bits), data transmitted by that module will be received by any module whose 16-bit address MY parameter equals DL.
If DH is 0 and DL equals 0xFFFF, the module's transmissions will be received by all modules.
If DH is non-zero or DL is greater than 0xFFFF, the transmission will only be received by the module whose serial number equals the transmitting module's destination address (i.e. whose SH equals the transmitting module's DH and whose SL equals its DL).

Again, this address matching will only happen between modules on the same network and channel. If two modules are on different networks or channels, they can't communicate regardless of their addresses.

For the "Series 2" modules you must chose which firmware put on the module to give it Coordinator, Router or End Device functionality. Series 2 use only serial low (SL) and serial high (SH) for addressing.

Read
http://arduino.cc/en/Main/ArduinoWirelessShield
http://www.digi.com/support/kbase/kbaseresultdetl?id=2191

Hope this resolves your query

3

sanketss84:
Assumptions
Your Co-ordinator and Router 1 seem to communicate properly but no connection with rest of the Routers

I am assuming you are having a problem with broadcasting

Thanks for your reply sanketss84. I am trying to poll rather than broadcast. I didn't find anything in the references you included to indicate I can not poll the devices by changing the coordinator's DL (if the DH's are the same).

4

@Zarac, I use API mode myself, but I would think that what you describe should work. The fact that ATND only returns one other device is a concern. Do the shields have "associate" LEDs on them? It sure sounds like they're not joined to the network for some reason. I'm not clear whether the routers can all talk to the coordinator, i.e. is the problem in one direction or two (or unknown)?

The channel (CH) parameter does not need to be explicitly set, it will take care of itself, recommend not messing with it. For that matter, if it's the only XBee network around, PAN ID does not even need to be set, the default of zero will work. But I do like to set PAN ID myself because the zero PAN ID will let any device join.

I'd try reloading the Router AT firmware on the modules that aren't talking. Set the PAN ID and nothing else, and that should do it. Leaving DH and DL set to the default values of zero on the Routers is also fine, this is a special value that causes traffic from the Router to go to the Coordinator, I do this a lot.

If that doesn't help, let me know and I can try it here when I get some time.

5

Jack, thanks for some food for thought. I am trying to accomplish a system similar to your simple sensor network, the difference being the routers wait for the coordinator to ask for light and temperature data. I enjoyed your web site.

With 1 coordinator and 3 routers, all indicate association, slow blink on coordinator, fast on routers. I could not talk to any until I unpowered 2 routers for some period of time, then I was able to reconnect with the remaining router after reconfiguring and unjoining. I was able to do this with different routers after unpowering the others and waiting. I repowered the routers and all showed association and I could still communicate with the first. I could not communicate with the other routers by changing the coordinator DL and at some point, lost communication with the first even after changing the coordinators DL back. I did not find DH & DL of 0 helped, although I was fooled for part of the time by a bad association LED.

I changed my Arduino code to send unsolicited data on setup in addition to responding to poll questions. I found I would see the setup message only after resetting an Arduino that was already responding to poll questions.

My conclusion is my plan will not work, but it'd be interesting to see if you get the same result if you want to try it. I'm assuming the 'complicated' API mode can be no more difficult than the 'easy' AT mode, so will try that next.

6

Zarac,

I tried a three-node AT network with two routers and one coordinator. Loaded the firmware fresh on all nodes, and it works as expected. By changing the coordinator's DH/DL it can send data to either router. No Arduinos were involved, the XBees were just plugged into adapters (I use Adafruit's) and connected via FTDI to three copies of X-CTU running on the PC. So your plan should work.

A couple things to watch for. First, "association" does not guarantee the ability to communicate! A router can be associated to a network, then the entire rest of the network can be taken down, and the router will still be associated and the LED will still blink. Check the Operating PAN ID (OP) and Operating 16-bit PAN ID (OI). All nodes should have the same OP, and all nodes should also have the same OI (OP and OI do not have the same values, but if ID > 0, then OP will equal ID). If this is not the case, force the module to disassociate with an ATDA command.

Secondly, I do get the occasional bad firmware load, which is why I suggested reloading firmware earlier. I've never figured out why this happens, it could well be a personal problem but I just don't know. In fact, when testing the three node setup earlier, I had one router that appeared not to associate in that the LED did not blink, but in checking the OP and OI parameters, it looked OK, and it would in fact communicate but only in one direction! It took about three tries reloading firmware before I got it right. So take that with a grain of salt, YMMV, but it might be worth a try.

Let me know what happens.