基于cc2530的协议栈怎么提高传输速度

你的时间是通过什么方式算出来的？是指单次发送呢，还是发送一次到收到ACK为止。

协议栈里面是有一个调度系统的，需要调度到的时候才会发出去。

我通过抓包工具看到的，是发送方发出到接收方收到时间。   请问一下协议栈里面的调度系统怎么能提速？跟f8wConfig.cfg中的-DRESPONSE_POLL_RATE=100，-DREJOIN_POLL_RATE=440，-DQUEUED_POLL_RATE=100 这三个参数有关系吗？

通过抓包看到的时间，是你的发送端到抓包工具接收的时间，你能否把你的抓包log用附件上传下。

上面这些参数可以提速，但是这些数据已经很小了，应该不会有很大影响，不建议自己修改参数。

通过我最近的观察发现耗时基本在

AF_DataRequest( &SampleApp_Periodic_DstAddr,
(endPointDesc_t *)&SampleApp_epDesc,
id,
len, buf,
&SampleApp_TransID,
//AF_DISCV_ROUTE,
AF_DISCV_ROUTE,
60 )

这个函数里面。因为我收到广播命令后如果马上发送一条广播命令他耗时570ms,如果发送两条广播命令耗时1127ms.我附件里有抓包资料，你可以对比一下。看看能不能帮我找到在哪里设置相关参数缩短这个函数的执行时间。万分感谢！如果可以的话希望能加下你qq,或者你加下我qq:421181705.

附件是发送一条广播信息的抓包资料

AF_DataRequest这个函数的起的作用，是应用把数据通过这个函数发送出去，但是这个函数并不是把数据直接通过射频发送出去，而是把数据从上层到下层封装好，然后丢给发送的队列，但是什么时候能够发送出去取决于系统的任务调度，信道的占用情况，其实从你的抓包来看，当收到一条广播的时候，到发送第一广播的话也只有7ms的样子。

那个7ms是协调器广播出来，下面一个路由器收到此广播再把它广播一遍的时间，它是直接在底层实现的。接下来程序里要再发出另外一个广播信息耗时就570ms(两个广播信息耗时1127ms)。那这个系统任务调度时间怎么去调整呢？

你好，

第二条发送广播的时候，你是从应用层往下数据封装，最后才发送出去的。

你可以尝试 改下

在f8wConfig.cfg文件中

/* The number of items in the broadcast table */
-DMAX_BCAST=9

把这个数字改大点，可以把发送广播收的时间缩短。

我试过把那个数变成18没效果，变成2也没效果。耗时老样子。朋友能qq吗方便一些421181705？

从第一条广播数据发出去，到发送第二条广播数据，即调用到AF的时间，

发送第二条广播数据到发送成功的时间，执行AF并发出去，

以上两段时间加起来是570ms，具体时间花在哪一段？能确定吗？

你可以连续发送多跳广播数据观察下，观察每条广播数据之间的间隔。

我试过只要从应用层执行成功发送一个广播命令他耗时570ms,如果两条的话会在应用层积累起来再到底层发送（发送出这两条的第一条发送成功要大概570*2ms）。三条的话要成功发送出这三条中的第一条耗时大概是570*3ms.问题应该在系统机制上。我现在就是对这个系统的整个机制不太清楚

你好，你这里提到的两条和三条，是指顺序执行了两个AF_Datarequest函数，对吧。

如果是这样的话，那可以解释的通，因为AF_Datarequest函数只是把数据帧封装放到了底层的发送队列里面，但不会立即发出去，因为还有其他任务，所以你连续执行两个发送函数，从效果上来看是一起发出去的。

能否用I/O的高低电平，在示波器上看下波形，把具体时间测出来，你在调用AF函数前把I/O拉高，然后发送完数据把I/O拉低，这样比用抓包软件测要准确很多

从你给出的psd文件来看，两个广播包之间的时间差为570ms,　数据的传递方式是A发广播,B收到广播后广播。这个570ms可能是由于B设备得到数据延迟或者nwk发发缓存造成的。如果0x4C7B(抓包文件中第二次广播的节点)，是End, 这部分时间可能是它Poll到数据的延迟，要验证这个猜测，需要使用两个FFD来测试，广播地址使用0xFFFC。　再一个，B设备的发送缓存造成，由于前一次广播的数据B设备接收到A的广播消息以后，仍然要进行一次广播，这一次广播与它后面要发送的广播之间出现时间差的原因可能是底层将两个广播排队，这个是没有办法的。

ANY WAY,　尽量不要在ZigBee网络内使用broadcast通信。

vv,你好，你用的是什么软件，我哪里可以下到？？

在网上搜 Ubiqua

好的，谢谢VV大神！！