Hi all, long time.
How big is the FIFO buffer on the XBee that holds
packets until I’m ready for them?
The document: XBee/XBeePRO OEM RF Modules ‐ 802.15.4 ‐ v1.xAx [2007.05.031]
on page 11 reads:
When RF data is received, the data enters the DO buffer and is sent out the serial port to a host
device. Once the DO Buffer reaches capacity, any additional incoming RF data is lost.
Hardware Flow Control (RTS). If RTS is enabled for flow control (D6 (DIO6 Configuration)
Parameter = 1), data will not be sent out the DO Buffer as long as RTS (pin 16) is de-asserted.
Yet, I cannot find the size of the DO buffer stated anywhere in this document.
How big is it? Will it hold a couple status packets and an ACK packet?
On a related note:
It appears that the firmware engineers on the XBee project are exercising their First Amendment right
to be totally awesome.
Thanks for the firmware updates!
David
I held off on answering this, because anyone else’s informed opinions would be better than my speculation.
Presumably, though, the DO buffer must be at least big enough to hold the maximum sized incoming packet, which I believe would be an RX packet with the maximum payload of 100 bytes.
So that would be:
3 bytes for packet header and length
1 byte for packet type
8 bytes for source address (or 2, but 8 is worst case)
1 byte for RSSI value
1 options byte
100 data bytes
1 byte for checksum
which I make to be 115 bytes (YMMV :-).
So to the specific question of whether it would hold “a couple of status packets and an ACK packet” my guess would be “yes, easily”.
If you want reliable information though, you’d probably do best to send this question directly to Digi support. And then if you wouldn’t mind posting the answer here, we can all benefit.
I suppose there is another way, which is to experiment. Enable RTS, and de-assert it while sending a few packets and then re-assert it. See how big the packets can be before something gets lost. Against that approach, though: (a) it’s time-consuming, and (b) it wouldn’t reveal cases such as “it depends on the firmware/hardware revision”.
Incidentally, and in support of your case, I’ve been through that product manual quite a lot now and I too am convinced that the answer isn’t in there.
Thank you for the answer. Which leads me to another question:
Is the 802.14.5 ACK process influenced by a full UART DO buffer?
The document: XBee®/XBee‐PRO® OEM RF Modules ‐ 802.15.4 ‐ v1.xCx [2008.09.04]
on page 11 reads: Once the DO Buffer reaches capacity, any additional incoming RF data is lost.
OK, so I’ve got a full buffer on my coordinator. An end device sends a packet to this coordinator. Does the coordinator reply to the end device with an ACK packet? Or does it think: “Hey, my DO is full. I’m gonna drop this packet on the floor anyway…NO ACK FOR YOU!” (Think Seinfeld.)
Can I assume that no partial, incomplete packets will be inserted into the DO buffer by XBee?
Basically, what I’m getting at is this. If an end device sends a packet to a coordinator and receives an ACK, can it assume that said packet made it into the DO buffer in its entirety?
Cheers,
cesium
PS, From the recent firmware updates, it appears that the engineers on the XBee project have gotten ahold of a giant family-size package of kick-butt… and opened it.
The product manual referenced in the first post of this thread was outdated, but a new version was posted last week. Does the following manual have the correct information?