Mixing API and transparent modes

Is it possible to mix transparent mode XBee-ZBs and API mode XBee-ZBs on the same PAN?

I have a number of sensors (many, many, sensors in fact), that communicate via SPI. When an ASCII string is sent to the device, it gives a short ASCII reply. I would like the coordinator, however, to use API mode. Can I have my end devices send and receive transparent data to an API controller? I really need a controller that takes advantage of the feature set of the API. With the number of sensors I’m using, using a small microcontroller to wrap the ASCII data in an API frame on each device would be extremely costly, both chronologically and monetarily.

If that isn’t possible, is there a way to send/receive SPI data over the digital I/O pins?


Hi Oren,

It is possible and very simple to mix transparent and API devices on the same PAN. After starting the API coordinator, AT (transparent) and/or API routers and end devices can then join the PAN and communicate with the API coordinator. There is no special configuration required to make this work.


Hi There,

I’m having same problem here. I want to mix both API (as Coord) and AT (as an End Node).
I’m doing some trial, using 2 XBee Modules. First one is functioning as a Coordinator (API mode, Firmware 2164), and second one is functioning as an End Device (AT mode, Firmware 2864). I connect the End Device with PC and Coordinator also connected to PC (another PC). I’m using Development Board (XBIB-R) to connect the modules to the PCs.
When I send data from End Device (AT) to Coordinator, the data is being received successfully and correctly by Coordinator, displayed perfectly in X-CTU Terminal tab. But when I want to send data from Coordinator (API) to End Device, the End Node didn’t receive any of the data.
I have trying to send it broadcast from Coordinator by sending frame 7E 00 0E 10 01 00 00 00 00 00 00 FF FF FF FE 00 31 C2 (ASCII 1) but it won’t work.
Tried to send the data to designated 64-bit address also by sending 7E 00 0E 10 01 00 13 A2 00 40 3C C7 23 BF CD 00 31 16 (ASCII 1), also won’t work.

How to send data from API Coordinator to AT End Device? Is there any special frame format to be used to send data from API to AT?

Your help is very appreciated …

Are you getting ZigBee Transmit Status Frame? Is your check sum of the packet is correct?

Both can communicate without any issue. The API or Transparent reflash in the serial/ UART communication only. The internal stack of xbee takes care.

I hope your check sum is wrong.

Already answered by DiGi. There is no issue in sending data from AT to API. But the problem is API could not send data to AT. Is there anyone suceeded sending data from API to AT?

Yeah… It is possible your end node is sleeping


I tried same conditions, and succeed it.
I use XBee’s firmware version 2xA0.
Please, try new firmware version.

I used 2xA0 also, 21A0 for Coordinator and 28A0 for End Node. I’ve set sleep mode to 1 (pin hibernate) and i connect sleep_pin to GND (which is always active). So, the device is considered as active. There are some command which can be used, indeed, like ND command (Node Discovery). But for sending data (frame type 0x10, Transmit Request) from API Coord to AT End Node, can not be done.
Sending data from AT to API can be done, correct. But not by sending it from API to AT. For you who succeeded, is there any special frame type that need to be used?

Exactly,i configured sleep mode was SM=4, it is no problem, but SM=1 is something wrong.
When power cycle occur and then Sleep_RQ was set 1,the xbee end device did not find available PAN.

> is there any special frame type that need to be used?

no,it’s same your frame.


sorry, my mistake. i did something wrong in frame format, and did something wrong in binding socket also :smiley:
I’m using python also to communicate with Coordinator ;p
problem is solved. thx all for the kind attention :slight_smile:

Possibly I found the phenomenon.

I am usually using CP2104 of Silicon Laboratories for a setup and experiment of xbee.
It seems that CP2014 changes the state of a DTR terminal about 7 times at a power supply start-up.

Although it does not know that it is detailed, possibly, this may become a cause and may make unstable starting of END DEVICE set to SM=1.