I’m sending API data packets on a Series 1 Xbee, 802.15.4, once every 25ms. The packet transmits successfully and is received by a 2nd Xbee successfully almost all of the time but every minute or so at random intervals, the receiving Xbee doesn’t send the packet out of its uart port.
I have tried different Xbees at both ends, set up with both devices as End Devices, transmitting and receiving with 16-bit addressing, and I’ve tried the transmitter as an End Device, associated with a Coordinator as the receiver, using 64-bit addressing.
I am communicating at a nominal 115200 baud rate and have checked that all uarts are communicating at the real Xbee rate of 111111 baud.
The communication is two way, so that the receiving end returns a packet to the transmitter within the 25ms time slot.All waveforms on a scope look good except for the single random dropouts, when the Rx device fails to transmit the received packet out of its uart.
I have checked that the packet being transmitted is correct when the failure occurs, including packet length bytes and checksum; the packet is <20 bytes long in both directions.
I have tried this both wirelessly and with a wired connection between the two xbee connectors.
Can’t really see where this is going wrong, so is there something I’m missing or any way of diagnosing what’s happening ?
I can’t really run at a much lower baud rate without significantly reducing the packet size. The channel is automatically selected by the coordinator device and it does choose different channels. I am sending broadcast packages.
I installed a wi-fi analyzer on my phone and I’m now convinced that the problem is being caused by multiple strong wi-fi signals in the local area occasionally interrupting the Xbee signal
If you are using 802.15.4, then you do have the ability to change the channel. That is just a matter of changing the CH value or the SC value on the Coordinator.
If you are seeing strong signals, then it could be that you are exceeding the CCA value and that is why you are dropping packets.
I did try reading the CCA value in my code when I got a dropped packet but it always reads zero.
It doesn’t seem to make any difference which channel the coordinator chooses, packets are always dropped, albeit pretty infrequently.
I have monitored the 2.4GHz with a spectrum analyzer and the Xbee always seems to be the dominant signal at about -33dBm, but there are pretty strong signals very close to the Xbee channel.
The packet is being transmitted from End Device to Coordinator at a frequency of 40Hz and I have counter adding up the lost packets. One example count was 40 in 3.5 hours, so a drop rate of 0.0008%.
Data is being returned from Coordinator to End Device within the 25ms time slot of the 40hz cycle and the round trip normally takes around 16ms, so I can’t see why data collisions would occur.
I have a scope plot of a packet being dropped but can’t see any way to attach it to this comment
Data is being sent bak from the
You can’t attach files to the Form. But I can tell you this, ALL forms of communications can and will experience some form of packet loss. Both cabled or wireless. You just need to build in some tolerance for the occasional packet loss. Regardless of the reason. Even if you can’t see the interference or reason.
If that’s the case, that’s fine, I just wanted that confirmation.
I have already built in detection of packet losses at the Rx end that deals with losses. That needs to be the case because this is for real-time control of a servo motor, so sudden jumps in demand are not acceptable.