I have set up communications between an XBee PRO 900 DigiMesh and an XBee PRO USB Adapter DigiMesh 900 with both running AP=1 and FW 8044 and 8444, respectively. I am noticing slower throughputs than I would like, and I have traced at least part of the problem down to the fact that Transmit Status API frames are being sent out the UART on both sides whenever a Transmit Request API frame is sent to the XBee.
I tried setting bit 0 in the Transmit Options byte of the frame at the zero-based index of 16, which is where the documentation says it is located in the frame, to 1, and I even went so far as to hard code it to make sure it was being set. One problem: it doesn’t seem to work. Whether I hard code 0x01 or 0x03 on either XBee, I still get Transmit Status API frames, which I then have to fully receive before I can dump them and try to read the next frame on the UART.
Support told me to open a case on the support website, so I did. I am waiting to hear back.
Has anyone else had this issue, and if so, how did you work around it or resolve it?
I did find a solution though, and quite by accident.
I ran across another post on a Google search after typing in the correct combination of search terms that made mention of a DigiMesh Java API where setting the Frame ID to zero caused the Transmit Status frame to not be sent:
I have yet to hear back from Digi on my support case, but I expect that they will either fail to reproduce the behavior or come to the same conclusion that I have, which is that the documentation is obviously wrong.
I had noticed this behavior last week, but it was still very early in my development process. As a result, I wasn’t sure if the module was correctly sending out the data frame, since the other side did not receive it anyway. It appears that bit 0 has no effect on whether the Transmit Status frame is sent out the UART, but using a Frame ID of 0 does, in fact, disable it as the documentation says setting bit 0 of the Transmit Options byte should.