API and Transparent Mode Confusion

XBee & XBee Gateway XCTU
1

I have the drop in networking professional development kit: ConnectportX2, 2xRS232 interface boards and 1xUSB interface board, all with XBEE Znet2.5 router/end device AT firmware 1241. All interface boards are each connected to a separate PC. My problem is understanding where API and AT mode come into the picture. I understand the difference, but how do you use it?

Is API and Transparrent mode only used when configuring the modems? Since my modems currently have AT firmware on them, i ran a few tests such as the “helloworld” program that uses sockets and it works ok. Communicating between two modems via the terminal tab in XCTU works fine too. My understanding is that i’ve been doing all this in AT mode since that’s the type of firmware loaded onto the modems, right?

When i change the firmware to XBEE Znet2.5 router/end device API, enable API in PC settings, and try the same thing, it doesnt work as well as before. For example, when running the “hello world” program again, nothing happens. When i try communicating from one pc to the other via the terminal tab, i get these funny characters and each letter is displayed on a new line after the same set of funny characters.

So, can someone please help me understand how this API and AT commands/operation is used. I have read thru the manual numerous times but i cant seem to understand how to go about using this. It only kinda explains the difference between them. It does explain how to use it in a way, but i dont get how it fits into the picture. How does it fit into a picture where you have a python script running? Are they both independant of each other? If i create a program using python and upload it to the gateway, how does API and AT affect my program??

I am very sorry for the basic questions, i am fairly new to this and am trying to use Zigbee/Xbee for a project i have to work on. The aim of my project is to eventually run network where the Xbee modems would eventually be integrated with moisture sensors and communicate that data to a local host (which i’m assuming is my ConnectportX2 Gateway) in a mesh network. I thought i’d test the communication of these modems by using them to talk between different PC’s first to explore how they work before i use them with my moisture sensors. Any help would be greatly appreciated!!!

Thank you in advance

MTM

2

AT command mode is called transparent mode, because it should be just that, transparent. What is meant by transparent is that what is sent by one radio, will be received by the others (as addressed) exactly the same way it was sent, no bytes added no bytes taken away. Thus, if you send “hello world” from radio A to radio B, you should see “hello world” show up on the other side. This mode also allows the radios to respond to the AT command set by first enetring command mode through the use of the “+++” command string, then sending AT(and the command etc.) AT command mode is user friendly, buy not very efficient when being controlled by a host embedded system or computer program.

The API is different in that once the radio is loaded with API firmware, everything that is sent to the UART or passed out of the UART of the radio in API mode will be formatted in the API data frame outlined by the data structure in the product manual.

The one exception to the API structure is the gateway device. The modules in the gateway are runing the API, but Digi has placed hooks into the python code to interpret and compose the API frames in the code, such that the correct frames are sent to the radio.

Here is an exaple of how the API could be leveraged. Let’s say for example, that there is a radio on each of your sensors. Each sensor is a temperature sensor. The sensor itself is simple and merely sends out a reading of the current temperature once every few seconds or so. If each sensor only sends out its reading of 72 degrees, when a message reaches te gateway, all you will see is a bunch of readings of 72 degrees. Because the API gives you greater access to additional information sent along with the packet (including the source address of where the messsage originated, you will have enough infomration to parse out the payload of 72 degrees, and parse out the source address to tell you which sensor reported the reading.

If a node is being controlled by a host program, like say a host micro controller running some embeded code like python for instance, you can use the API data structure to quickly send messages to many different destinations without the need to enter command mode, change the parameter value, exit command mode, and send your data. by composing one packet, the host controller can send a message to a specific address on a packet by packet basis.

These are only a few qualities of the API mode. Obviously it is more complicated to start because you need to program your host controller to compose and interpret API packets, but it is faster and gives you more control. Of course if that isn’t necessary, the transparent AT mode will be tranparent to your existing protocol and allow the protocol you already have developed take care of addressing and the like.