Xbee API mode firmware

Question

Hi

I am trying to write a code in C which can send API frame as well as receive API frame, parse it, get the data and process it. I wanted to understand one thing, do Xbee firmware itself is programmed that if a API frame is received with AT command, it will reply back with the response of AT command or we have to program our MCU, that after receiving the API frame, search which type of API frame it it, depending on the frame type, do a query with the Xbee module and then send back the response in the API frame.

Thanks

Answer 1

Hi, The radio will handle the AT command for you if it has to configure anything. You will receive on your MCU a feedback frame for each command send locally or remotely. All you have to do is send a frame of bytes to the radio.

Comments

Still i am a bit confused. Module will handle the AT command for us. But API frame which module will received will be forwarded to MCU via serial. Once MCU get the frame, it has to find out which kind of frame it is and then act accordingly. Assume that Xbee module get AT command frame. It will forward it to MCU via serial. MCU will parse the frame, get to know which kind of frame it is, enter the Command mode with Xbee by issuing +++ and fire AT command, get response and frame AT command response frame in API, send it to the destination via Xbee. AM i right? Or it will happen like this that Xbee will receive the frame and will reply back without passing it to the MCU? If some one has to write a library for API mode, what all he has to take caere of?

---

You have to imagine that in API mode radios talk between each other and provide feedback of their actions.
You give them orders and they will execute it in the network.
You will have to parse incoming messages if :
1- you have sensors or inputs,
2- you want to process feedback messages
3- if you send text from one radio to another.
You do not use anymore +++ as the radio is only expecting frames (commands). If you want to send a text message, there is a frame for that. The remote radio will receive it into a frame 0x91.
If a MCU requests a remote radio to activate a pin. It will send a frame to his radio requesting that the radio B has to activate the pin. MCU's radio send the request in the network and radio B acts. Radio B will reply back job done if so. In this example, the MCU behind the remote radio will not see anything! If your application doesn't care, you can cancel the feedback.
Which language will you use?

---

As you said i have a question, how does the radio A find out to which radio B we have to send message or even AT command. For that we have to provide address. Right? So what i asked, let me frame it once more. We have to supply a API frame like "7E0011900012A20040522BAA7D84015278446174612E" to the radio which contain every relevant information like address of Radio B to which this frame need to send, frame type - 0x90 means receive packet  and the data in hex format "527844617461".  Where i am confused is if we supply only At command, how does the address of "To" radio B come into action.

---

I am using C for coding. I had done the part to receive any frame from the module, parse it , find out which type of frame it is. I am still writing the part to make a API frame taking input  of radio address and data to be send by the user.

---

The frame you supplied has a mistake length should 0x12 not 0x11. Checksum change also : 7E 00 12 90 00 12 A2 00 40 52 2B AA 7D 84 01 52 78 44 61 74 61 0E
This is a frame 0x90 which means it is a received packet. This is where you were misled. You don't send a frame like this. A radio would not know what do about it.
Your frame means :
Radio A (64 bits address 00 12 A2 00 40 52 2B AA and 16 bits address 7D 84) sent you a message "RxData". Radio B knows thank to the byte 01 that this message was already acknoledged to radio A.

If the MCU behind radio B wants to send a message back "hello world" to radio A, he will send a 0x10 frame to his radio:

7E 00 1C 10 01 00 12 A2 00 40 52 2B AA 07 84 00 01 48 65 6C 6C 6F 20 77 6F 72 6C 64 21 0D 0A D3

In case of an outgoing message you have starting on the 6th byte up to  0x10 the address where the message will be delivered.
Hope this is clear...

---

Also i am trying to communicate between two modules in API mode. I set them using ATAP=1. Now i had attached them to minicom using a USB cable.

My Radio A had address 0013A20040BB1716 and i want a message to send to this Radio from Radio B. For that I went to http://ftp1.digi.com/support/utilities/digi_apiframes2.htm and selected 0x10 frame, put the address of Radio A and selected 16 BIt address as broadcast message (0xFFFF), when i did build frame, i get the frame
7E 00 11 10 01 00 00 00 00 00 00 0F FF F0 FF FF 00 01 AE DA 69 and i when i put this on Radio B minicom, i didn't received anything on Radio A minicom. I don't know what i missed. Can you help me in that.

---

Yes, that is clear now. So this was what i wanted to understand that we have to supply frame to the radio. Just like mine radio is Radio B and the other radio is Radio A. When radio A send data to me, my radio provide me the frame "7E 00 12 90 00 12 A2 00 40 52 2B AA 7D 84 01 52 78 44 61 74 61 0E" in which 0x90 means receive frame and 01 means that a "acknowledgement" message is being send by my radio. All i get is the frame which i would have to parse and get the data out. Similarly, if i had to send data to a radio A, i would have to use frame 0x10 to send a message in which i have to add the 64 bit and 16 bit address of the other radio in my case which is Radio A.

Well thanks a lot for this. It was making me mad, just to understand. I will try today to transfer packet between two radios using minicom .

---

Hi.
First, I do appreciate the "Well thanks a lot for this". I do not belong to Digi.

This frame is a 0x10. It means a radio wants to send a message, option = 1 (you will to receive a 0B message with transmission status). On 0x8B message, a 0 on the 9th byte means OK otherwise error.
If your sender is reading this message, it means it is properly talking with his radio.

Next step, for a big relief (transmission!), is to address the frame properly.
7E 00 11 10 01 *(DL)00 00 00 00*/*(DH) 00 00 0F FF*/*(MY) F0 FF*/*(broadcast option, I always leave 0 there) FF* 00 01 AE DA 69

The 64 bits address is 8 bytes and the 16 bits address is 2 bytes. Addressing takes therefore 10 bytes.


Case one: a radios want to send a broadcast message. All the radios in the network will receive it. You would address as:
00 00 00 00 (DH = 0) FF FF FF FF (DL = 0xFFFF) FF FY (MY for broadcast)
Case two: a radio wants to send a frame to a specific recipient. Only the recipient will receive it. You would address it as:
00 12 A2 00 (DH) 40 52 2B AA (DL) xx yy (insert the latest MY. caution it changes)
Case 3: a radio wants to send a message to the coordinator. Only the coordinator will receive it. You would address it as:
00 00 00 00 (DH) 00 00 00 00 (DL) 00 00 (it never changes!)

You can use the 3 rd option to set your network as a star. Everyone is talking to a master, easy addressing for remotes !
The master (coordinator) can send himself send a ND network discovery command ('07 00 04 08 01 4E 44 64'). Radios will reply back with their 64 bits and latest 16 bits address, NI... and other options if you configure them.
 
I suggest you use XCTU. Under the console tab, you has first to connect the console. Then on the bottom part, there is an editor that helps greatly to write and understand frames. You can send those frames right away and see exactly what is going on. It helped me a lot to understand how this thing works!

Have fun!

From arduino.cc (https://www.arduino.cc/en/Main/ArduinoXbeeShield):
Your radios 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.

---

Hi, fortunately, using windows and XCTU i was able to send the packet from XCTU to the other Xbee module connected to AVR board and get acknowledgement. Why i was not able to communicate using minicom is answered in this link "http://electronics.stackexchange.com/questions/185813/communicating-between-2-xbee-in-api-mode-using-minicom/185894#185894".

Next to it when i get data on AVR side, i get binary data with "7" equivalent to "~" and so on and some data is not human readable. How can i convert the same in hex or decimal?

And i do get that you are not from Digi.

Thanks

---

Hello,
I do not use much minicom. I prefer python.
You are reading in your terminal the ascii symbol http://www.asciitable.com/ that corresponds to the byte of information received on your board which range from 0 to 255 or 0xFF.
ascii codes up to 20 are not human readable.
In short, convert each received char into hex byte. You will be able to read the full frame on the screen. It starts with 0x7E which is ~.
Remember that if you send a 0x10 frame on one hand, you will receive a 0x91 frame on the other hand. Your information in ASCII will be from 21st byte. Keep that in char.
I recommend that you find the xbee documentation. You will find a good definition for each frame as well as AT commands.
Good luck!