TI中文支持网降低协调器串口波特率进行测试，丢包现象依旧没有改善。经过具体测试分析，丢包主要发生在协调器端。
1. 通过串口发数据给协调器，再由协调器通过zigbee网络发送到透传模块，通过抓包器可以发现“20”序号数据包没有发送出去：
2. 通过透传模块发送数据给协调器，根据以下数据分析，透传模块发送出去的“0C”序号数据包，协调器没有进行接收处理：
请问对于这种现象，在协调器端还有什么方法可以进行优化的？谢谢！
Peipei Huang：
协调器通过串口工具发送数据，透传模块收到数据后通过串口发出，中间使用抓包器进行数据抓取分析，发现丢包是发生在协调器端。比如：协调器端串口发送11串数据，而抓包器跟透传模块只收到10串数据。 协调器跟透传模块软件所基于的协议栈为：ZStack-CC2530-2.5.1a （ZigBee-Pro）。
测试示意图：
丢包统计：
miffy：
回复 Peipei Huang:
你先确认你的数据到底有没有从APP发送到COO，先把这个捋清
确认发过去之后，再看COO有没有发出，这个可以抓包看。
Peipei Huang：
回复 miffy:
文章最开始就是抓包工具抓出来的结果，后面是补充整个测试的流程。
VV：
协议栈对广播包会有一定的限制，有用单播包试过吗？
另外最后可以确定AF_DataRequest的返回值是什么？
Gavin Chen1：
回复 VV:
我也试过使用单播的方式进行透传传输，从终端到协调器成功率会高很多（SampleApp_P2P_DstAddr.addr.shortAddr = 0x0000），但是从协调器传输给终端时还是一样丢包（SampleApp_P2P_DstAddr.addr.shortAddr = 0xffff）。
至于AF_DataRequest的返回值，我在等于afStatus_SUCCESS的位置做一个累加数并跟数据包一起发出，从最终的接收/抓包情况看，累加数是有在增加，但是中间有些包却没发出来。
miffy：
回复 Gavin Chen1:
你给的0xFFFF是广播地址，不是节点的地址，广播可能会丢包
节点的地址不能是0x0000，也不能是0xFFFF。
xiaoming huang1：
请问你是使用的是cc2538还是cc2530 我也碰到丢包的问题
e2echina.ti.com/…/148814
Gavin Chen1：
回复 miffy:
我用的是CC2530，使用点对点的方式传输成功率是会高很多。但是协调器给终端点对点发送，通过短地址的方式没有发送成功。地址确认无误，协调器发送出去后终端没收到，抓包器也抓不到数据，现在只有使用Mac地址进行单播发送。请问使用短地址进行点对点传输是否还有需要特别注意的地方？
xiaoming huang1：
回复 Gavin Chen1:
我用CC2530 短地址发送没问题，你看看AssociatedDevList[]中有这个短地址的信息吗？没有发出的包的AF_DataRequest的返回值串口打印一下看看是不是success
miffy：
回复 Gavin Chen1:
如果抓包没抓到数据的话，很可能是没发出来，查查coordinator出了什么问题
PS：建议用Ubiqua的抓包工具，别用sniffer分析不方便
