I was testing two xbee modules that I have (xbee pro) , with both configured to send and receive to each other. I had one module (lets call this X1) continuously write and read messages in a for loop (using the win32serial library). The other module (X2) was receiving but I would trigger the transmission (using x-ctu).
So the problem is that some packets are not being acknowledged by X1 and this is being shown on ACK error counter of X2. It happens like 1 out of 10 times which is too high.
If have X1 only receiving then I dont lose any packet. Its only when X1 is both sending and receiving that it misses some packets.
I dont understand the hardware (Not an EE student) but is there any literature or site where I can learn more about this problem?.
Since there are a few different variations of the XBee Pro hardware and Firmware please post the Firmware Version as reported by X-CTU from the Test/Query button. Then we’ll know which Document to use.
Save the Profile from the Modem Settings tab and post. Then we can look at the XBee parameter settings that you are using.
In addition: What is the Baud rates you are using?
And how much data are you trying to send?
Depending on Firmware version, is Retransmit enabled?
For more info on XBees look through the threads in this forum (Wireless/RF) for ones with links to other sites about XBee. Also Digi Int has a User’s Forum that may be helpful.
Baud rate is 57600. there is no feature of setting number of retries in this firmware.
Firmware as I understand is like the OS… so If I load a firmware (10A4) which has the feature of Retry number will it work on this hardware? hardware version is 1742
Ok, the current Firmware is 0x1084, which ID’s the module as a Series 1 running the 802.14.5 Protocol. The latest Firmware is 0x10E6.
The AT command RR (10E6 firmware) “is used set/read the maximum number of retries the module will execute in addition to the 3 retries provided by the 802.15.4 MAC. For each XBee retry, the 802.15.4 MAC can execute up to 3 retries.” Using the newest firmware and increasing the # of retries may or may not help.
Your problem may be interference from other 2.4GHz devices like an 802.11 wireless router. Do you have 802.11 running near by? If so you maybe change the RF channel the XBee’s are using.
So the problem is that some packets are not being acknowledged by X1 and this is being shown on ACK error counter of X2. It happens like 1 out of 10 times which is too high.
D
The ACK error counter- I presume you mean the AT register. This counts MAC layer ACK failures. With the ACK required option enabled, each non-broadcast (unicast) MAC layer frame sent shall get an ACK response from the destination within a couple of hundred microseconds of the end of the outgoing frame. If not, the sending side retransmits n times before declaring an error.
A certain percentage of MAC layer ACK errors are inevitable in any wireless data system. The causes are ususally either weak signal or excessive/persistent interference. The RSSI issues are obvious: antennas, path length, path obstructions, etc., as indicated by the RSSI/LQI value for each received packet. The interference issue: First order is if there are analog signals near the 2MHz wide channel you have chosen. These can be wireless video cameras, old cordless phones, etc. Cure: change channels- large step. The other key interference would be 802.11, but only if there is a very, very heavy stream of 802.11 packets leaving too little open air time for the 802.15.4 packets. Both 802.11 and 802.15.4 use “listen before transmitting” (CCA or CSMA/CA). Again, changing channels is the cure.
None the less, uncorrectable transmission errors will occur, say, 1% of the time in any system with a decent margin in the transmission link budget. So your application may need error detection and correction, e.g., by numbering messages, etc. The XBee binary API does have an error notification so you can know that the frame did not get ACKed and you can do whatever if anything to cope.
@Steve: Can we use a higher level language like python to read the AT register?. IN the terminal I just type +++ and it enter command mode. but it does not seem to work when I try to write “+++” to the com port through python.
Anyway is it practical to read the AT register through com port ? I am getting messages from other sources so how would I know which byte is from AT register.
dheer1um:
I got the api mode working with Python. Is it advisable to handle all communications in api mode? I will be sending extra bytes through the api frame.
API mode is needed for other than (1) Digi's wireless serial port extension mode; (2) Digi's wireless virtual I/O bits and A/D. For a simple peer to peer 802.15.4 network where any node (in range) can talk with any other node, without the mess of a PAN coordinator, and if you don't need meshing, then yes, the API mode is needed so you can easily handle addressing each packet sent, and, conversely, you can learn who sent each incoming packet.
This is all assuming you have Series 1. I think Series 2 products are ZigBee-only.
dheer1um:
I got the api mode working with Python. Is it advisable to handle all communications in api mode? I will be sending extra bytes through the api frame.
API mode is needed for other than (1) Digi's wireless serial port extension mode; (2) Digi's wireless virtual I/O bits and A/D. For a simple peer to peer 802.15.4 network where any node (in range) can talk with any other node, without the mess of a PAN coordinator, and if you don't need meshing, then yes, the API mode is needed so you can easily handle addressing each packet sent, and, conversely, you can learn who sent each incoming packet.
This is all assuming you have Series 1. I think Series 2 products are ZigBee-only.
I understand that the API mode will help me retransmit packets which have not been acknowledged, as I get a transmit status message from the module after each transmission. But I am using python which reads the buffer of the virual com port, this buffer would store the other incoming messages from RF module and the transmit status msg.
So the transmit status message would be read after some incoming messages right?.
So error detection and correction without using the API would need your application to do the work. Such as encapsulating up to 90 bytes in a packet of your design. Each would have a sequence number or some such. The far end would send an application layer message saying “I got #n”, i.e., an application layer ACK.
stevech:
So error detection and correction without using the API would need your application to do the work. Such as encapsulating up to 90 bytes in a packet of your design. Each would have a sequence number or some such. The far end would send an application layer message saying “I got #n”, i.e., an application layer ACK.
Probably easier to use the API mode.
Yes, the API mode is definitely better, Now I am able to retransmit the packets that failed. Thanks Steve and others.
I just want to know how this acknowledgement works, the rf module sends the transmit status frame back to the host, how does the module know that the reciepient has got the message?. If I was waiting for an application layer ACK then it could also get corrupted and basically it becomes a chicken and egg problem.
Yep, that can be a problem with ACK/NAK protocols. Should the ACK get ACKed so the the receiving end knows the transmitting end received the ACK. That can spin your head.
There is always a possibility that data gets corrupted or lost in any data transfer protocol. That is why code should be written to handle data exceptions. Wrapping another layer around your data, as Steve pointed out, can help. But especially with an RF link data loose is always a real possibility.
stevech:
I just want to know how this acknowledgement works, the rf module sends the transmit status frame back to the host, how does the module know that the reciepient has got the message?. If I was waiting for an application layer ACK then it could also get corrupted and basically it becomes a chicken and egg problem.
The API returns the transmit status after sending the packet and getting a MAC layer ACK or a timeout for that ACK. The timeout is per the IEEE standard and is about 200 microseconds.
So if your transmitted packet had the ACK-Required bit set in the API packet and you get no MAC ACK timeout error, then the packet was received and acknowledged by the destination XBee.
PS: Humor us: Please don’t use the term “ZigBee” as in the title of this thread to refer to 802.15.4 transmissions where you aren’t using ZigBee as in the Series 2 XBees. I preach: ZigBee is not 802.15.4 and vice-versa, as TCP/IP is not 802.3/Ethernet.