Possible for API mode to talk to Transparent mode?

I am using 2 XBee S1 and XBee S1 Pro all in digimesh mode

X1- - - - - - - - - - - - ->Xpro- - - - - - - - - - - - - - - - - - - - - - - - - ->X3

My set up goes as follows:
X1 (in API mode) is taking ADC readings and sending it to Xpro.

XBee pro (in API mode) is connected to a microcontroller to parse out the packets, read the ADC values and turn it into a meaningful value (ADC to temperature conversion)

I want to send the newly converted ADC to temperature value from Xpro to X3 but I am not receiving anything on X3.

X1’s destination address is Xpro. Xpro’s destination address is X3.

This question pertains to the Xpro in the middle: Is it possible to receive from an Xbee in API mode and send out ASCII strings on the same Xbee? I am not receiving anything on X3. Is what I’m trying to do possible?

Yes and No.

Yes you can inter mix modules that some are using API mode and others are using transparent mode.

So using your information above if X1 who is in API Mode wants to send data to X3 who is in transparent mode, all you need to do is form your TX request packet on X1 to have the SL/SH of X3 and then send the data.

X3 will receive the data and output the (Data) portion of the API frame.

X3 will receive the API frame from X1 if i do it that way, but X3 needs to receive an ASCII string from XPro, not the API frame from X1

BUT! XPro is receiving from X1 in API mode already, is it possible to send out ASCII characters from a microcontroller as well?


API vs AT only affects the UART of that specific node, It has nothing to do with what comes out the UART of the receiving module. What I mean by that is that I could have a Node 1 in API mode and Node 2 in transparent mode. When I send a TX request API frame from Node 1 with the data payload of Hello world, Node 2 which is in transparent mode will only output Hello world. Now when sending data back from the transparent mode or AT command mode node, if I send the data payload of “it has been a good day” the receiving module that is in API mode will output of its UART and Rx Receive API frame with the Hex data conversion of “is has been a good day” along with the reset of the Rx frame.

Thank you, maybe my problem doesnt pertain to API vs AT mode.

I am having trouble receiving anything from Xpro to X3. I am running XCTU for all XBee devices so I can see the output of the com ports.

X1 is sending ADC values to XPro, which I can see on XCTU. I set XPro’s destination address to SL/SH of X3 but on XCTU for X3, it receives nothing.

At XPro is where I interpret the ADC frame and convert it into a meaningful value. I want to send that converted value to X3 but right now XPro is not sending to X3. I think I might need 2 XBees at the XPro node. One for receiving the ADC value, and one for transmitting the newly converted ADC value. But having 2 XBees at one node (one for receiving and one for transmitting) seems totally necessary

This doesnt seem to be agreeing with me in XCTU when I assemble packets.

When 2 devices are in AT mode, they can communicate with eachother when I create type “hello world” using “Assemble Packet”

When the transmitting node is in AT and receiver node is in API, I can see the message using XCTU on the receiver along with the source address.

However, when transmitting in API mode, I do not receive anything on the receiver when the receiver is either in API or AT mode.
So back to my original question: is it possible for a transmitter in API mode to send data to a receiver?


The transparent serial connection created by an AT mode XBee simply transmits data bytes using a particular hard-coded Endpoint/Profile/Cluster combination.

If you have an AT mode XBee transmitting to an API mode XBee you will see 0x91 - ZigBee Explicit Rx Indicator frames on the API side. Parse addressing fields from that frame to figure out the Endpoint/Profile/Cluster needed to setup a 0x11 - Explicit Addressing ZigBee Command Frame in order to transmit from API mode to AT mode.

That is incorrect. A standard Tx request packet is all that is needed. That is providing they are using API mode 1. If you are having issues it is most likely the result of a faulty assembled API frame. Try using the XCTU NG software and its Assemble packet option.