Unfortunately the version 200C suffers the same problem. As we have 200 devices in production already I did not have many options, so I had to diagnose the problem deeper myself. The issue points to retry parameter RR>0 in XBee3 modules only. We normally use RR=3 in XB/XBP24 and all modules work reliably. When RR=3 on XBee3 transmitting side the receiving XBee3 gets stuck for some reason and needs reboot. Setting RR to 0 helps to resolve the problem, however makes communication reliability worse, so not much win here
I am providing a simple table below explaining how XBee3 behave in networks with mixed XBee1 and XBee3 when RR=3.
Our devices use Xbee1/3 modules, I name them Device A and Device B:
Device A | Device B | functionality
XBee1 | Xbee1 | OK
XBee1 | Xbee3 | OK
XBee3 | Xbee1 | OK
XBee3 | Xbee3 | FAILS !!!
Device A sends the remote command 'D7 go low' to wake-up DEVICE B (we do not use CTS# in flow control).
This repeats couple of times within SP period until device B responds or this process times out. XBee module in device B wakes up regularly in 5 seconds intervals SP = 5000ms, ST= 1100ms, SM = 5. Does not matter what C8 value is. As mentioned above with RR=3 XBee3 fails in Device B and needs reboot.
I hope this helps others to resolve the same or similar problem.
I would appreciate Digi fixed the problem asap.