I have a microprocessor communicating with an XBee over the SPI bus. On startup it communicates fine for a few seconds, and then it stops transmitting. The XBee’s Extended Transmit Status (0x8B) is returned for the messages. Initially, while the messages were getting through, the Delivery status was “0x00 = Success”. After the messages stopped getting through, the Delivery status was “0x25 = Route not found”.
After the messages stop getting through, if I reset the XBee radio, the messages get through for a few seconds before stopping again as described. If I slowed the number of messages sent to the XBee, all messages will be transmitted successfully, and it continues working without stopping.
I gather from this that I am writing messages to the XBee too fast. But shouldn’t the XBee return an error that states this instead of “Route not found”? What is the proper way to ensure that I am not writing to the XBee faster than it can handle?
Thanks @mvut. I get the 0x25 as a response after I have attempted to send the message. Is there a way for me to check if I need to wait before attempting to send the message?
I was able to find a solution, though I’m not completely sure why. I noted in the datasheet “If the SPI is the serial port, no hardware flow control is available. It is your responsibility to ensure that the receive buffer does not overflow. One reliable strategy is to wait for a TX_STATUS response after each frame sent to ensure that the device has had time to process it.” I am using the SPI port, so I followed this instructions and did not send any packets until I got the response from the XBee on the previous packet. After that, the problems went away (although I’m now sending packets slower than I wish).
Here’s my guess at why I was getting the 0x25 code back: If I overrun the buffer, every once in a while (maybe 1 out of 256 times) a garbled packet made it through because the checksum happened to be correct. However, the address might be corrupted, so there would not be a route to that address. Thus the 0x25 error. That’s my best stab in the dark.
TLDR: on the SPI bus, I must wait for a response from the XBee for a packet before sending the next packet.
@mvut thank you for your help so far. I have a follow up question. In my application, I am sending a lot of small packets of data - only 32 bytes of data in the packet including the overhead from the XBee protocol. On average I get a response from the XBee after 66ms. Because of the problem above, I cannot send another packet until I get a success message back from the XBee on the last packet. At this rate, I am only able to send 15 packets of data per second. This translates to 480 bytes per second or 3.8kbps. Clearly this is a far cry from the 250kbps that my modules are set for, so I am obviously doing something wrong.
Out of curiosity, I changed my modules’ bitrate to 10kbps. At that setting, it took an average of 905ms for the XBee to reply with a successful send response after sending a transmit request API frame.
After doing some more reading, it looks like part of the problem is that I am sending to the broadcast address. When I changed the address to a specific XBee module, the XBee response time dropped to ~18ms. A large improvement, but still only 14kbps, so it seems there are other things I’m still doing wrong…