ZigBee模块频频重新入网原因

没有，我是根据它每次发送消息给协调器，数据包里面的rssi来检查它的信号强度的

正常-45dbm 也不会掉线的, “ 但是-57dbm的模块却频频重新入网“ 是你控制leave的还是主动leave的。

没有，关于入网的这个地方，我只动了一个连接的次数，其它的没动也没法动啊，已经被你们封装起来了，就是容易重新入网？想问一下，你们是如何判断这个设备无法连接协调器，然后将设备踢下去的

您的意思是设备发射封包后会等待一个ack回应，这个ack回应是协调器发出的吗？但是我没有发射包，应该是设备底层会有心跳包是吧，能不能更改这个心跳包的一个间隔时间？还有如何避免这个情况发生呢？

协议栈版本？
你发送一个包，对方需要回复一下ack。 只有在 1.22a 以及3.0以上版本有child aging。
当然你的你应该有poll rate 当3次poll 没有收到ack 就会判定掉线。
poll rate在
/* This is used after receiving a data indication to poll immediately
* for queued messages...in milliseconds.
*/
-DQUEUED_POLL_RATE=100

如果设备自行判断无法连接，那是父节点发送请求请它离网，还是说它自己请求离网？有没有什么方式可以优化，让设备至少在10m之内，不会离网。还有，就是判断设备从断网到入网的时间和连接次数，是不是从这开始算起来的：

if ( events & ZDO_NETWORK_INIT )
{
//新加加网次数统计
//static uint8 initFailCounter = 0;
// Initialize apps and start the network
devState = DEV_INIT;
osal_set_event( ZDAppTaskID, ZDO_STATE_CHANGE_EVT );
//新加 连接一定次数之后，连接时间变长
/*if(initFailCounter++ >= NWK_INIT_fAIL_MAX )
{
osal_start_timerEx( ZDAppTaskID, ZDO_NETWORK_INIT, 60000 );
initFailCounter = 0;
return(events ^ ZDO_NETWORK_INIT);
}*/
Timer1_Init();
network_count ++;
ZDO_StartDevice( (uint8)ZDO_Config_Node_Descriptor.LogicalType, devStartMode,
DEFAULT_BEACON_ORDER, DEFAULT_SUPERFRAME_ORDER );

// Return unprocessed events
return (events ^ ZDO_NETWORK_INIT);
}

只要是單播就會有mac ack，设备底层沒有心跳包，至少據我所知Z-Stack沒有，你貼上你的抓包檔來看看問題吧

/* This is used after receiving a data indication to poll immediately
* for queued messages...in milliseconds.
*/
-DQUEUED_POLL_RATE=100
这个就是终端节点在底层向协调器发送心跳的时间吗？能不能更改这个时间呢？可以更改的范围是多少？更改后会有什么影响呢？还有我的版本是ZStack-2.5.1a，希望大佬不吝赐教

这个不是终端节点在底层向协调器发送心跳的时间,QUEUED_POLL_RATE指的是如果父節點上面有給终端节点的資料，终端节点下次polling的時間，建議是不要更改

终端节点是不是要定时发送MAC地址请求啊？这个定时时间可以更改吗？还有就是您说的那个mac ack次数可以更改吗？
// Transmission retries numbers
#if !defined ( MAX_POLL_FAILURE_RETRIES )
#define MAX_POLL_FAILURE_RETRIES 1
#endif
#if !defined ( MAX_DATA_RETRIES )
#define MAX_DATA_RETRIES 2
#endif

这里面更改MAX_POLL_FAILURE_RETRIES和更改MAX_DATA_RETRIES会有什么影响吗？

你不能控制mac request ，你只能修改poll rate。

关于上面的参数请参考

下面这个图，可以便于你理解关于ZigBee协议栈里面的MAC ACK和APS ACK的区别。

哦哦，看到了，mac ack是物理层上面的，不能去控制更改，只能稍微更改一下我自己的数据的一个ack，您看是不是我这么理解的，#define MAX_DATA_RETRIES 2这个应该是我的数据的一个重发次数，#define MAX_POLL_FAILURE_RETRIES 1这个应该是设备mac的重发次数，对吧。

哦哦，看到了，mac ack是物理层上面的，不能去控制更改，只能稍微更改一下我自己的数据的一个ack，您看是不是我这么理解的，#define MAX_DATA_RETRIES 2这个应该是我的数据的一个重发次数，#define MAX_POLL_FAILURE_RETRIES 1这个应该是设备mac的重发次数，对吧。

嗯，那我的理解应该是对的，MAX_POLL_FAILURE_RETRIES是设备polling后没有收到mac ack要重发的次数，这个是mac层的，最好不要动还有那个polling的时间也是mac层的，这个可不可以动啊？或者说小幅度改动会有影响吗？MAX_DATA_RETRIES 这个是设备单播app消息的重发次数，无论是协调器和终端节点都适用，可以更改

polling的时间可以动沒有問題，

这个polling只是查询mac ack的一个轮询时间，请教一下，如果网络差的情况下，mac ack大概会多长时间接收到？
/* 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
DRESPONSE_POLL_RATE这个是mac ack的轮询时间吗？这个轮询时间是不是只要设置不比mac请求的周期时间大就可以了是吧。那消息ack的轮询时间是哪一个呢？

其实，我最想解决的问题，最想保证的是我的终端设备可以在我的协调器10mi范围内连接很稳定，现在我的设备离协调器8、9米就很不稳定了，所以说想询问一下，有没有什么好的解决方案

1. 通常都很快，10ms以內吧，mac ack最多就是等到~19msec
2. RESPONSE_POLL_RATE不是mac ack的轮询时间吗？

设备离协调器8、9米就很不稳定，通常是硬體RF有問題

软件会不会造成这种情况发生呢?如果会的话，会是哪方面容易造成这种情况？能不能再不更改硬件的情况下，改善这个情况

依我的經驗软件不会造成这种情况发生

如果是在办公环境下，一般来说这个稳定的通信距离是多少呢？还有就是
/* The number of milliseconds to wait between data request polls to the coordinator. */
//尝试修改，原有值3000
-DPOLL_RATE=800
我更改了终端节点这个轮询值，NWK_AUTO_POLL又加了这个宏，对与整个网络架构以及稳定性没有影响吧。
如果有，该如何优化呢？

还有就是zigbee的通信速率可以更改吗？如果可以更改，将之改小，通信质量会不会有所改善？

CC2530 跑Z-Stack 基本上距離30米內應該都要正常、建議你先查一下是不是RF硬件問題

那跟我更改的那两个地方有关系吗？还有就是这个空中通信速率可以降低吗？

我認為沒有多大关系，你也可以改大點試試。
另外，空中通信速率可以降低

空中速率如何降低呢？降低的话，这个通信距离和质量肯定会好的吧

我是不是誤會你空中速率的意思，如果你指的是250kbps的data rate，這個是沒辦法降低的

。。。那您说的降低空中速率是指什么速率？如何降低，降低的话会有什么影响（好的方面）

我指的是降低poll rate還有設備發射訊息的頻率

poll rate发射讯息的频率？是发送mac请求的一个频率吗？

还有i想请教一下您，就是TI官方有没有卖cc2530模块，如果有能不能发一下链接？如果没有的话，能不能发一下您认为或者您使用过的比较好的cc2530模块的链接

poll rate发射讯息的频率定義在f8wconfig.cfg的-DPOLL_RATE=1000，TI官方没有卖cc2530模块，我們的模块是自己設計的，沒辦法发认为或者使用过的比较好的cc2530模块的链接給您

我改过这个，因为当时我发现当我将它改成很大的时候，终端节点无法及时响应协调器发出的app消息，所以我最后将它改为了800.话说这个就是终端节点和协调器之间的一个mac请求周期是吗？周期时间越小，响应越快是吗？

是的

从我的经验看， 这个问题应该不会出现。 你这里说的不稳定是重新入网吗？ -57dbm信号没问题的。

建议怀疑硬件问题

-DPOLL_RATE=800 这个值我给改成了800，并且我起了一个事件，每分钟往协调器发送一次信息，每包数据20个字节。然后，我将7个zigbee终端节点放在一张桌子上，协调器放在离终端节点有10米远的地方进行通信质量的测试。我从上午10点测试到下午2点，最后发现，除了一个设备是重连了2次，其它的居然都重连了300多次。。。这是什么情况啊？

还有一个问题，就是其是每包数据有19个字节，我放在一个19个字节的数组中，发送时按20个字节发，有人说会内存溢出？会内存溢出吗？

從終端發封包出來不應該會導致協調器内存溢出

他的意思是我终端节点会内存溢出，但我觉得不会。其实我觉得有可能会有两种情况导致的，1、就是我把7根天线靠的太近，但我觉得协议栈应该会考虑到这种情况，这种假设应该错误；2、就是我的发送频率的问题，每个设备每分钟都会发一次app数据，而且每800ms还会请求一次，会不会是这种情况导致的；3、第三种情况，会不会是我的模块天线前面有一个东西挡住，导致的？而且还是在办公环境下测试的。

你可以提供抓包檔嗎？

抓包档？

就是用Ubiqua protocol analyzer抓封包的檔案

没有软件，也没有工具，。。。

那還真不知道要怎樣幫忙...

请教一下，这个抓包工具有什么作用？是和Packet Sniffer一样的作用？只是说它能抓到局域网内所有的设备通信是吗？

基本上作用差不多，但是功能強大很多，信號強弱也可以比較清楚的抓到，也能解譯加密過以及zdo/ZCL相關的封包