Hi Guys,
I am facing a problem with the transmit status message coming in a bit late after I send the transmit frame. In the Xbee manual its not clear how long it should take. In some places it is mentioned that if retries are enabled it waits around 200 msec for an ACK. Isnt that too long?.
I am sending and reading over serial in my PIC micro. After each message sent if I dont have a delay of upto 200,000 Tcy (instruction clock cycles) then I miss the ACK and the message is sent again (its programmed to do that).
dheer1um:
Hi Guys,
I am facing a problem with the transmit status message coming in a bit late after I send the transmit frame. In the Xbee manual its not clear how long it should take. In some places it is mentioned that if retries are enabled it waits around 200 msec for an ACK. Isnt that too long?.
I am sending and reading over serial in my PIC micro. After each message sent if I dont have a delay of upto 200,000 Tcy (instruction clock cycles) then I miss the ACK and the message is sent again (its programmed to do that).
Do you mean the IEEE 802.15.4 MAC layer ACK? If so, this is done in the chip, per the IEEE standard. If you mean an ACK due to some application or network layer, then ignore the rest of this post.
The time is just a few hundred microseconds, as I recall. The standard says that the ACK must be received wthin (for 2.4GHz), 192 microseconds of the end of the sent-frame.
In the XBee API mode, you must set a bit in the transmitted frame that says “ACK is required”. The XBee API will pass back, on the serial port, an API frame after the frame is ACKed by the addressee if the frame was unicast. If it isn’t ACKed, you will get a transmit complete status frame with that error noted. You may also get CCA failure status. OF course, if you send to a destination address that is invalid, to to an out-of-range destination, there will be an ACK failure, assuming you have set that ACK Required bit.
There’s also a bit to say that Transmit Complete Status is requested (to be sent via the serial port).
If you don’t set that ACK requested bit, you will still get a transmit complete status, IF you requested it, and it will say no-error, since an ACK wasn’t required.
No ACKs for broadcast address destinations.
Yeah I am talking about the transmit status message that is supposed to be received after I send the transmit request. In my while loop I am just writing to serial and then reading from it.
After each write In the read process I check for the transmit status frame but it appears a bit too late for my liking. I tried setting delays after each write. My intruction cycle is at 5Mhz. I have to set a delay of 100,000 instruction cycles to get the transmit status after each write. Isnt that a bit much?.
thats like 0.02s.
dheer1um:
Yeah I am talking about the transmit status message that is supposed to be received after I send the transmit request. In my while loop I am just writing to serial and then reading from it.
After each write In the read process I check for the transmit status frame but it appears a bit too late for my liking. I tried setting delays after each write. My intruction cycle is at 5Mhz. I have to set a delay of 100,000 instruction cycles to get the transmit status after each write. Isnt that a bit much?.
thats like 0.02s.
Transmit status will come in after a delay that's mostly dependent on the baud rate you have to the XBee. It has to transfer x number of bytes that constitute the transmit status message per se. I run my interface in API mode at 115Kbaud, though I use a fast ARM7 and tight UART interrupt code. So 56K might be better as a general rule.
The transmit status response is 6 bytes as I recall. So at 57.6Kbaud, 8N1, the status takes about 6 x 10 bit-times at that baud rate. That’s a bit over 1,000 microseconds if I did the math right at this hour of the day! Add to this the MAC ACK time which can vary due to CCA and retransmissions. So I’d not use less than 20mSec as a timeout.