XBees in use: XBP24-AWI-001
All XBees are using firmware 10ED and configured as End-Devices with AP=1. All XBees have a unique 16bit MY address
I am running into a problem where an XBEE is randomly(?) generating TxStatus messages when it is not ever being told to even transmit anything.
One XBEE is connected to my computer via digi's X-BIB-R board.
A number of other XBees are attached to microcontrollers.
The XBees on the microcontroller send an Tx16 API message to address 65535 with lets say a "W" as the payload.
When the XBee on my computer sees the "W" it performs a Tx16 API message to the exact 16bit MY address from the microcontroller XBee.
That is the only time the XBee attached to my computer transmits anything.
The XBees on the microcontroller then proceed to send pieces of data via API Tx16 using the 16bit address of the XBee attached to my computer.
The problem comes from that the XBee attached to my computer will sometimes dump ACK FAILURE TxStatuses down the UART at me. The same status message actually as the frame number always points to the same frame that was sent in the past.
I have even tried disconnecting the XBee attached to my computer (unplugged it from power, removed x-bib) and then re-attaching it. It will STILL send those random ACK FAILUREs. It appears to "remember" what is transmitted in the past through a power cycle.
With more checking I am getting the transmission success status for the frames I send out and then later on i receive the ack failure statuses for that same frame.
Is there any way to stop this? That ACK FAILURE disrupts the data flow causing a wait time in data recieved from the microcontroller XBees.
Think Host and Satellites. The "satellites" send a message to 65535 asking if a "host" is out there. The "host" responds affirmative and then the "satellites" send messages directly to the "host". For some reason the "host" keeps telling me it failed to send data even when it is not sending any.
So it hasnt solved my issue 100%, *BUT* it seems that the default settings for I/O sampling and sending is ENABLED. And it will try to send the results as an API packet to DH/DL address. Which for me was 0 (zero) and thus was failing and sending me some transmission failed messages. It also reused the SAME frameID over and over again, which was what i was seeing.
I think more research into this will help solve the problem.