XBee3已经推出有一段时间了，在许多项目上可以直接替换。但在一些特别的应用场景，仍可能存在一些尚未解决的兼容性bug。尽管由于zigbee 3.0协议的升级，一些兼容性的功能只能通过专用参数或在特定的参数组合下实现，Digi仍然会致力于让XBee3能完全取代和替换S2C，而不需要对传统使用S2C的产品作出修改。
最新发现的一个bug是在开启APS加密的情况下出现。XBee模块在开启EE后，网络包已经是加密了，但由于许多早期用户对ZigBee了解不深，在产品中还额外开启了APS加密。APS加密实际上是在加密网络包内对任意两点的应用层的payload再做进一步加密，意义不大，工业场景很少被使用。在XBee API模式中有个transmit option字段，默认为0x00，中石油不少RTU和传感器的早期用户就在XBee中采用了transmit option=0x60这种方式进行通讯. 本次测试所用固件：100D和4061。
一、XBee3作为协调器, S2C作为路由器
方向：S2C –> XB3
刚开始时通讯正常，大约过5分钟后， S2C发不成功，错误代码：21 (Network ACK Failure)
如果对S2C进行reset，仍不能修复，但错误代码变成：24 (Address not found)
使用00作为协调器16位地址，结果仍一样。
方向：XB3 –> S2C
刚开始时通讯正常，大约过5分钟后，发不成功，错误代码：24 (Address not found)
使用真实的16bit地址而不用FFFE，结果仍一样。
把S2C的EO改为和XBee3一样的0x2，看看结果
要让双向通讯恢复，只有S2C发ATNR退网才行。
二、XBee3作为路由器，S2C作为协调器
奇怪的是，如果S2C作为协调器，XBee3作为路由器，并不会有这个bug。
初步结论：
这是一个不常用的bug，只有当XBee3作为协调器时，S2C作为路由器时，并且API帧中的发送选项开启了APS加密（0x20或0x60），才会出现。
解决思路：
是否能在XBee3的配置中解决？很可能是NK或trust center的因素，需要测试以下几种临时解决方案：
1. 设置XBee3 的EO＝0
这个设置会导致地址0不能代表XBee3作为协调器了，S2C发XBee3只能用FFFE或是真实的16位短地址。如果用0作为短地址发不通，并且会阻塞后续的发送（除非退网）
2. 固定NK的值
实验表明，NK即使双方配置成一样的默认值，这个bug也依然存在。
这个bug的解决要等Digi发布新版的XBee3固件。对于混合组网的设备产家来说，在程序中不盲目采用部分厂家的0x60发送选项的设备制造商，在S2C到XBee3换代升级过程中受到的影响最小。
