I was reading about escape mode, AP=2. I was confused about this though, because Digi mentions multiple times that a packet malformed over the air could could the XBee (or receiving device connected to the XBee?) to lose sync to the data because the data length would not be correct if bytes were dropped.
I’m not sure if this is true, but it has some concerning implications if it is.
-
The XBee frames going into the TX side XBee have a checksum, and in API mode, ACK packets are used to confirm reception. Does this imply that even if a packet is seen by the RX side XBee with a bad checksum, an ACK will still be generated?
-
This implies that the RXing XBee will still pass a packet out of its serial DOUT even if it knows for sure that the packet is bad.
Hypothetical situation:
-
Let’s say that we have two XBees in AP=2. these XBees are in an environment where there is a magic box transmitter which has the ability to corrupt RF packets in flight such that that bytes are dropped, whatever it takes for that to happen. For the sake of simplicity, the magic box ignores ACK packets or any other mesh overhead.
-
Let’s say that the TX XBee transmits a packet with 100 bytes of payload. 1 byte is knocked out by the magic box
-
In this situation, would the RX XBee send out it’s serial port a corrupted frame which includes an incorrect payload count as well as failed checksum? Would the RX XBee generate an ACK?
FWIW I’m using XBee PRO SX radios.
Thanks!
Chris