Home/Support/Support Forum/Compatibility of two XBEE modules

Compatibility of two XBEE modules

0 votes
Hi all,

I have two XBEE modules, one is XBEE S2 (product code: XB24-Z7WIT-004) and one XBEE SMT (XB24CZ7UIS-004) and I need to know if it is possible to have the SMT to act as coordinator for the S2 and have communication between the two?

Thanks
asked Jun 5, 2014 in ZigBee Smart Energy Profile 1.1 by mhmani21 New to the Community (0 points)

Please log in or register to answer this question.

1 Answer

0 votes
Yes, they certainly can. Have a look in the manual here:

http://ftp1.digi.com/support/documentation/90002002_M.pdf

Page 37 has the details for how you would do that.

Easiest way is to plug it into your Dev Kit, program it up with XCTU and away you go.
answered Jun 5, 2014 by NicholasWilson Veteran of the Digi Community (1,001 points)
Thanks Nicholas.

My issue is that I don't have a Dev Kit, I have two XBEE SMTs that I have included in my own PCB designs on two different boards. They both connect to the XCTU and I can program them, but they never managed to establish communication. I have set the PAN ID on both to be the same, SC is the same as well but the client still doesn't join the network. I also tried both broadcasting and direct addressing and I still couldn't get the communication between them. What I did was, by mistake at first, set the coordinator destination address to itself and sent data which was received on the coordinator itself. I did the same thing with the other board but there was nothing so I assumed the chip might be faulty. But since I have managed to get comms running with XBEE S2 without a problem, I was wondering if I could get my SMT to act as coordinator for S2 end devices. I did a quick try yesterday but it didn't work so I figured it's best if I do a quick check to make sure they are compatible.

There is no special setting for two versions to work together is there? I couldn't find anything on the link you sent me, so they should work as normal?
They are part of the same family so very much should work as normal. [url=http://www.digi.com/pdf/chart_xbee_rf_features.pdf]http://www.digi.com/pdf/chart_xbee_rf_features.pdf[/url]

Here is a screen shot of where you would change it in the XTCU if you had a dev kit :(  [url=http://imgur.com/VPmHXTi]http://imgur.com/VPmHXTi[/url]

The manual also highlights some complications on page 34


[size=1] [i] By default, the module operates as a router in transparent mode. To select coordinator operation, set CE to 1.
To select end device operation, set SM to a non-zero value. To select router operation, both CE and SM must be
0.
One complication is that if a device is a coordinator and it needs to be changed into an end device, CE must be
set back to 0 first. If not, the SM configuration will conflict with the CE configuration. Likewise, to change an
end device into a coordinator, it must be changed into a router first.
Another complication is that default parameters for a router build don't always work very well for a coordinator
build. For example:
DH/DL is 0 by default, which allows routers and end devices to send data to the coordinator when they first
come up. If DH/DL is not changed from the default value when the device is changed to a coordinator, then the
device will send data to itself, causing characters to be echoed back to the screen as they are typed. Since this
is probably not the desired operation, DH/DL should be set to the broadcast address or some specific unicast
address when the device is changed to a coordinator.
Another example is EO for smart energy builds. This value should be 08 for routers and end devices and it
should be 02 for the coordinator to designate it as the trust center. Therefore, if using authentication, which is
the normal case for Smart Energy builds, EO should be changed from 02 to 08 when CE is set to 1.
In general, when changing device types, it is the user's responsibility to ensure that parameters are set to be
compatible with the new device type. [/i] [/size]


Perhaps someone more technical with this particular product on the forum can point you in the right direction.

As always, the standard support paths are also available.
Thanks again. I went and checked to make sure the settings are right. The old S2's firmware is set to end device with sleep mode on cyclic. The new SMT model is set to be a coordinator (CE to 1) and SM = 0 to make sure it's set as a router before CE. There is no security enabled either. They still don't communicate.
The thing is, although I've set the DH and DL on the coordinator to 0 to sent the data to the coordinator, when I run the ATDL and ATDH in command mode (still using the XCTU software) I get something completely different:
+++OK
ATDL
40B63323
ATDH
13A200
I can't set the ATDH on the coordinator to 0 either, it keeps going back to 13A200!
It's the same for ATOP. I mean ATID is 12345 but when I run the ATOP it's 0 and the channel (ATCH) is 0 as well.

On the coordinator, though, ATOP is same as ATID, 12345, and ATCH is 18. This is really confusing me that the ATID and ATOP on the coordinator (regardless of the new module or old one) are not the same. And I assume that's why they're not communicating to each other, they're not on the same PAN and/or channel. And I really don't know why that is!
Set the SC on the SMT module to match the through hole module and then issue a local network reset on each node. You will find that they will then associate on the same channel and communicate.
The SC is the same for both; I tried the local reset (ATNR0) and it still won't connect to the coordinator or change the channel
Try reloading the firmware on the module with the always update firmware enabled.  Make sure that you upload it using the default settings. Then issue an ATRE, NR1 starting at the End devices with all other nodes powered off.  Power on one at a time and issue the commands.  Once all of the nodes have been reset, power back on the desired coordinator first. Set the SC and nothing else so that it will match the routers and End devices.  Then power on the routers and End devices one at a time.  They should all associate with the coordinator and you should be able to verify communications one at a time.
...