ZIgBee信标工作模式

但是我把另一个关于IO口的功能任务清掉了，只保留了一个任务来对无线数据监听和网络状态改变的事件进行监控。而且，我用工具检测功耗时，终端节点是空载的，没有外接任何IO设备，这样的情况下，平均功耗在200多ua，（每分钟有半分钟的600ua左右），所以说觉得有可能是终端节点和协调器通信所导致的，所以说想询问一下这个时间是不是可以更改

还有就是天线功耗我给调到了最大值

保留了一个任务来对无线数据监听和网络状态改变的事件进行监控

這個任务多久作一次，如果把這個任务停調的功耗如何？

通常低功耗不会你这么高，估计你在PM2或者你的IO有漏电，至于poll 你可以在config文件中修改。

就是下面这个任务，如果协调器发命令或者网络状态发生变化，这个任务应该不会工作的吧？

uint16 GenericApp_ProcessEvent( byte task_id, UINT16 events )
{
afIncomingMSGPacket_t *MSGpkt;
if ( events & SYS_EVENT_MSG )
{
MSGpkt = (afIncomingMSGPacket_t *)osal_msg_receive( GenericApp_TaskID );
while ( MSGpkt )
{
switch ( MSGpkt->hdr.event )
{
case AF_INCOMING_MSG_CMD: //无线消息事件处理
//HalLedSet(HAL_LED_2,HAL_LED_MODE_TOGGLE);
//HalLedBlink(HAL_LED_2,10,50,500);
SendShortAddrToCoor();
//GenericApp_MessageMSGCB(MSGpkt);
break;
case ZDO_STATE_CHANGE: //建立网络后，设置事件
GenericApp_NwkState = (devStates_t)(MSGpkt->hdr.status);
if(GenericApp_NwkState == DEV_END_DEVICE)
{
SendShortAddrToCoor();//联网成功把自己的ID发给协调器
}
break;
default:
break;
}
osal_msg_deallocate( (uint8 *)MSGpkt );
MSGpkt = (afIncomingMSGPacket_t *)osal_msg_receive( GenericApp_TaskID );
}
return (events ^ SYS_EVENT_MSG);
}
return 0;
}

poll在config哪个地方可以设置？还有这个天线的频率选择对于功耗有影响吗？
/* Default channel is Channel 11 - 0x0B */
// Channels are defined in the following:
// 0 : 868 MHz 0x00000001
// 1 - 10 : 915 MHz 0x000007FE
// 11 - 26 : 2.4 GHz 0x07FFF800

没有的,默认为11信道.

/****************************************
* The following are for End Devices only
***************************************/

-DRFD_RCVC_ALWAYS_ON=FALSE

/* The number of milliseconds to wait between data request polls to the coordinator. */
-DPOLL_RATE=1000

/* This is used after receiving a data indication to poll immediately
* for queued messages...in milliseconds.

你是說你定期會去執行GenericApp_ProcessEvent？

没有，那个触发的，只有当有事件过去了它才会去执行，我是这么认为的

這樣看來估計是你的IO有漏电

如果我的设备用在一个办公环境里，对数据的传输速率没什么要求反正很低，但要求设备的穿墙能力要强，要比较稳定，是不是868MHz的比2.4GHz的要好一些

是的

但是IO口漏电不可能是周期性的啊，现在它的功耗曲线是一个周期性的。比如说10分钟的平均功耗是250ua左右，但是它每分钟都有半分钟的时间功耗在500ua左右，另外半分钟无限趋近于0；就这样周期性的工作，所以说觉得有可能是终端节点在向协调器发类似于心跳似的东西，想改一下这个时间

但是我看配置文件里面，好像没有868MHz的信道选择啊？还有868MHz的通信距离和2.4GHz的通信距离差距大不大啊？

你對功耗的描述這樣聽來很粗略，建議你用power analyzer 或是scope仔細量測細部的耗電，我們在來討論；TI Z-Stack 沒有支持sub GHz

我使用的UI Meter，也可以测试功率的。现在查看曲线图，发现好像是终端节点有一个任务在跑似的，就是那种一分钟内有半分钟好像是在和协调器通讯，耗量在600ua左右，剩下的半分钟稳定在100ua左右，就这样工作下去

你都不會看到有上mA的功耗？

mA的功耗少，只会偶尔出个峰值会达到mA

這樣不大對，GenericApp每秒會polling一次，所以至少每秒你會看到一次衝高到mA的功耗，如果沒有要嗎你的軟件有問題，要嗎你的量測方式有問題

应该是对的，我记得之前我好像对这个值进行修改过，，，polling一次应该要不到1ma

CC2530 tx/rx隨便都超過1 ma怎麼會polling一次应该要不到1ma

电压: 平均=3.8214 V 最大=3.8216 V 最小=3.8207 V
电流: 平均=0.0003 A 最大=0.0037 A 最小=0.0000 A
温度: 平均=23.0 ℃ 最大=23.0 ℃ 最小=23.0 ℃

上面是我软件分析得来的结果，它这个polling的时间应该是可以设置的吧。好像从图中看确实是半分钟稳定在100ua左右，另外半分钟稳定在500ua左右

这个不能，只能说看到个大概的曲线图和一个平均值，，，，，就是那种勉强可以凑活着测试功率。。。。。

这樣看不到細節的

-DRFD_RCVC_ALWAYS_ON=FALSE

/* The number of milliseconds to wait between data request polls to the coordinator. */
//尝试修改，原有值3000
-DPOLL_RATE=5000

/* This is used after receiving a data indication to poll immediately
* for queued messages...in milliseconds.
*/
//尝试修改，原有值100
-DQUEUED_POLL_RATE=100

/* This is used after receiving a data confirmation to poll immediately
* for response messages...in milliseconds
*/
//尝试修改，原有值100
-DRESPONSE_POLL_RATE=100

/* This is used as an alternate response poll rate only for rejoin request.
* This rate is determined by the response time of the parent that the device
* is trying to join.
*/
//尝试修改，原有值440
-DREJOIN_POLL_RATE=440

这上面是那个config文件里的信息，这几个值具体的含义是什么啊？这几个值对于终端节点实时接收协调器的消息并发送回去这一功能点有多大影响？改变这些值，功耗是不是可以适当的降低？

我测试好像也确实是这个影响比较大，当大于1000ms时，响应的实时性就不行了，但是功耗在200ua左右，小于1000ms时，实时性确实很好，但是500ms时的功耗在400ua左右。这个功耗应该是比较大的吧，正常情况下，DPOLL_RATE设置为1000ms轮询一次，功耗大概为多少啊？

我沒有用你類似的儀器量過這樣的平均功耗，不過看來你的1000ms轮询一次功耗在200ua左右聽起來蠻正常的

但是我的协调器又没有说是1000ms发送一次数据啊，从头到尾好像都没有发送数据；终端节点1000ms轮询一次，只是开了一个用户任务监听强制事件，200ua是正常的吗？因为我也是刚毕业之前也没有研究过，请不吝指教

你不是說了终端节点1000ms轮询一次，這樣看來你终端节点有200ua可能是正常的，如果你把终端节点轮询時間拉長應該就可以省功耗

但是我的终端节点就只是在监听协调器信息，1000ms轮询一次这样都200ua了，那如果我再跑其它定时任务比如说一分钟一次这样子的，再加几个外设，功耗估计就会在800ua左右了。。。。

/* The number of milliseconds to wait between data request polls to the coordinator. */
-DPOLL_RATE=1000
这样设置是不是就是我说的那种终端节点1000ms轮询一次啊？

那有没有可能通过代码的优化，宏定义的更改，在不影响实时性的情况下，再次降低功耗呢？如果有的话，能不能给个思路，或者指点一个方向，谢谢了

沒有了、