I’m having an issue where all of the sudden my receiving Xbee will stop receiving frames after I take it out of range and back in again. I think I was able to recreate the problem by closing and re-opening my serial terminal in XCTU. I didn’t realize what was happening until I opened the frame filter tool and included “invalid frames” I saw then that I was indeed receiving frames (the Rx frame counter was still going up), but that all the frames were “invalid” and my data was scrambled. To break it down further:
• Going out of range or receiving through certain non-line-of-sight conditions result in some packet loss.
• Sometimes after packet loss, no more packets are received unless I change the data contents of the packetized AT transmission.
• In XCTU, the receiving Xbee shows invalid frames after closing and reopening the serial connection.
• The invalid frames appear similar to expected data, but are somehow out of sync
• Changing the transmitted data does not work in XCTU. The invalid frames show up looking like the changed frames, but scrambled as before.
• If I repeatedly disconnect and reconnect the serial connection in XCTU, I see good frames after a few tries.
• My good strings are supposed to look like this: 0$ 0.24156* • Whereas the invalid frame data is showing up like this: }33$
0$ 0.24156* (Line return) £
And to elaborate on my settings and methods:
• Remote device is in AT mode, hardware serial. Packet sizes range from 3 to 13 and sometimes more
• I’m using API mode on the receiving side because I sometimes have to call a remote AT command to wake my remote arduino.
• I’m using cyclic sleep on the remote Xbee, and keeping it awake at all times by continually sending data except when I put the remote arduino to sleep.
• Between sleep cycles, the remote xbee sends a packet containing D0 high or low. D0 is not connected to anything. This serves as a sleep indicator.
• My send loop takes about 21ms to iterate.