1
\$\begingroup\$

I am working on Xbee in API mode and i am writing a small program in C to receive API frames and process them, but to start with this, i simply wanted to check that how does these frames look like and is API communication is really happening or not.

I have Radio A and Radio B

Radio A - Transmitter 
64 bit address - 0013A20040BB1716


Radio B - Receiver 
64 bit address - 013A20040BCDE18

I added them both via Xbee USB shield to KDE and started minicom for both. They both are replying to the AT command pretty well. I set APi mode by using

ATAP = 1 or ATAP = 2

and then ATWR and ATCN and checked API mode again by issuing ATAP and get 1 or 2 as reply, that means i am in API mode now.

I used this link to frame API frames to be send from Radio A to Radio B, and this is the frame which i got

`7E 00 10 10 01 00 13 A2 00 40 BC DE 18 00 00 00 00 AE DA BF`

when i send it from Radio A to Radio B, i didn't get anything on Radio B serial on minicom. What am i missing? I had already attached antenna. I also considered this link but instead of using XCTU, i had simply used minicom.

\$\endgroup\$
  • \$\begingroup\$ How are you sending the packet in Minicom? I don't use it but that hex has to be sent as binary, for example 7E would be the ~ character and some others are non-ASCII so if you're just trying to paste in the hex string as text it won't work. \$\endgroup\$ – PeterJ Aug 15 '15 at 9:46
  • \$\begingroup\$ @PeterJ : I am simply trying to send the hex string. I think that is why it is not working. I tried to install XCTU on linux but it didn't worked because i wasn't able to create symlink between ttyUSB and COM port. Is there any alternate? \$\endgroup\$ – srj0408 Aug 15 '15 at 15:13
2
\$\begingroup\$

When sending those packets they have to be in binary rather than sent as a hex string and Minicom doesn't appear to support binary data. However from a Stack Overflow answer the following page contains details on adding the ability to send a binary file:

Sending binary files via minicom

You could get your packet into a binary file using a command like the following:

echo -ne '\x7E\x00\x10\x10\x01\x00\x13\xA2\x00\x40\xBC\xDE\x18\x00\x00\x00\x00\xAE\xDA\xBF' > packet.bin

Another alternative would be to use the RealTerm program that allows sending of binary files and also will allow you to see the packets received in hex which may be difficult with Minicom. I use it under Windows but according to the support page it has been successfully tested under Wine.

\$\endgroup\$
  • \$\begingroup\$ I got success in sending the same by using a separate WINDOWS machine. I was successfully able to send the API packet to another radio. But i faced one problem. On the other side, i am having a microcontroller and i am receiving char instead of hex. Like for 7 i am getting ~. Or will i always get char on the other side? \$\endgroup\$ – srj0408 Aug 21 '15 at 9:45
  • \$\begingroup\$ Everything you receive will be in binary as well. Hex is only used in the documentation to explain it in a human-readable form, for example values below 0x20 and above 0x7F aren't printable characters. So it's best to think of everything as a byte with a value of 0 to 255, maybe this ASCII chart would help you understand why certain values show a certain way if you treat them as characters and display them: asciitable.com \$\endgroup\$ – PeterJ Aug 21 '15 at 9:55
  • \$\begingroup\$ so on the AVR side, it is best to store everything in a frame and convert it to HEX using some binary_to_hex convertor program and then compare it with the frame type? \$\endgroup\$ – srj0408 Aug 21 '15 at 10:14
  • \$\begingroup\$ Yes I'd normally store it as bytes and then display as hex for debugging, but for using the data internally don't forget you probably won't need to convert it you can use things like if (my_rx_byte == 0x40) to check if that byte contains 40 in hex. \$\endgroup\$ – PeterJ Aug 21 '15 at 10:19
  • \$\begingroup\$ I don't know whether to extend this here or not. But i am simply using frame[index++] = ch; to store the binary in a buffer frame[100];. Most of the bytes are unreadable has spaces etc. Generally, if i will get hex, i can easily find out the length of the frame, which type it is, what is the destination address, data, checksum but how will i deal with binary bytes without storing and converting them to hex. I need to check what is the frame type and size of frame. \$\endgroup\$ – srj0408 Aug 21 '15 at 10:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.