由于国庆节假期,帖子审批以及工程师回复将会有所延迟,敬请谅解

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

关于Zstack2.5.1 EndDevice或Router自动重发问题

Other Parts Discussed in Thread: Z-STACK

各位大神好!近日我基于Zstack2.5.1的Simple Application Interface例程做了个EndDevice(ZED)定时上报传感器数据的工具。

在测试过程中,用1个coor(ZC),有2个router(ZR),8个ZED,拓扑结构如下:

ZC

|

ZR1,ZED1,ZED2 (直连ZC)

|

ZR2,ZED3 , ZED4 , ZED5 (经ZR1连接ZC)

|

ZED6,ZED7,ZED8 (先经ZR2,在经ZR1连接ZC)

并且ZED设定每隔60s上报一次数据,发现下面问题,请帮忙解答一下,谢谢!

1. ZC偶尔会收到连续2条或3条间隔约10-30ms的重复数据(ZED1~8都有出现过,但似乎经Router会频繁点),经分析是z-stack自动重发的数据,而非AF_DataRequest被重复调用所致。

请问这种重发,是正常现象吗?是Router还是ZED产生的?通过调整哪些参数控制其次数和间隔?

2. 与问题1类似,但重发间隔变为约6s左右,经分析同样也是z-stack自动重发。

请问这种重发,是正常现象吗?是Router还是ZED产生的?通过调整哪些参数控制其次数和间隔?

3. ZR1与ZR2有时会自动交换位置,是什么原因造成的?

//===========下面是f8wConfig.cfg的参数================

/*
* f8wConfig.cfg
*
* Compiler command-line options used to define a TI Z-Stack ZigBee device.
* To move an option from here to the project file, comment out or delete the
* option from this file and enter it into the "Define Symbols" box under the
* Preprocessor tab of the C/C++ Compiler Project Options. New user defined
* options may be added to this file, as necessary.
*
* Each macro is prefixed with '-D'. The entries are to be constructed as if
* they are to be on the compiler command line invocation (which they are).
*
* NOTE: The RHS (Right-Hand-Side) must be quoted if there are embedded blanks.
* See the DEFAULT_KEY definition for an example.
*/

/* Enable ZigBee-Pro */
-DZIGBEEPRO

/* Set to 0 for no security, otherwise non-0 */
-DSECURE=0
-DZG_SECURE_DYNAMIC=0

/* Enable the Reflector */
-DREFLECTOR

/* 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
//
//-DMAX_CHANNELS_868MHZ 0x00000001
//-DMAX_CHANNELS_915MHZ 0x000007FE
//-DMAX_CHANNELS_24GHZ 0x07FFF800
-DDEFAULT_CHANLIST=0x04000000 // 26 - 0x1A
//-DDEFAULT_CHANLIST=0x02000000 // 25 - 0x19
//-DDEFAULT_CHANLIST=0x01000000 // 24 - 0x18
//-DDEFAULT_CHANLIST=0x00800000 // 23 - 0x17
//-DDEFAULT_CHANLIST=0x00400000 // 22 - 0x16
//-DDEFAULT_CHANLIST=0x00200000 // 21 - 0x15
//-DDEFAULT_CHANLIST=0x00100000 // 20 - 0x14
//-DDEFAULT_CHANLIST=0x00080000 // 19 - 0x13
//-DDEFAULT_CHANLIST=0x00040000 // 18 - 0x12
//-DDEFAULT_CHANLIST=0x00020000 // 17 - 0x11
//-DDEFAULT_CHANLIST=0x00010000 // 16 - 0x10
//-DDEFAULT_CHANLIST=0x00008000 // 15 - 0x0F
//-DDEFAULT_CHANLIST=0x00004000 // 14 - 0x0E
//-DDEFAULT_CHANLIST=0x00002000 // 13 - 0x0D
//-DDEFAULT_CHANLIST=0x00001000 // 12 - 0x0C
//-DDEFAULT_CHANLIST=0x00000800 // 11 - 0x0B

/* Define the default PAN ID.
*
* Setting this to a value other than 0xFFFF causes
* ZDO_COORD to use this value as its PAN ID and
* Routers and end devices to join PAN with this ID
*/
-DZDAPP_CONFIG_PAN_ID=0xFFFF
//-DZDAPP_CONFIG_PAN_ID=0x111F
/* Minimum number of milliseconds to hold off the start of the device
* in the network and the minimum delay between joining cycles.
*/
-DNWK_START_DELAY=100

/* Mask for the random joining delay. This value is masked with
* the return from osal_rand() to get a random delay time for
* each joining cycle. This random value is added to NWK_START_DELAY.
* For example, a value of 0x007F will be a joining delay of 0 to 127
* milliseconds.
*/
-DEXTENDED_JOINING_RANDOM_MASK=0x007F

/* Minimum number of milliseconds to delay between each beacon request
* in a joining cycle.
*/
-DBEACON_REQUEST_DELAY=3500//1000

/* Mask for the random beacon request delay. This value is masked with the
* return from osal_rand() to get a random delay time for each joining cycle.
* This random value is added to DBEACON_REQUEST_DELAY. For example, a value
* of 0x00FF will be a beacon request delay of 0 to 255 milliseconds.
*/
-DBEACON_REQ_DELAY_MASK=0x00FF

/* Jitter mask for the link status report timer. This value is masked with the
* return from osal_rand() to add a random delay to _NIB.nwkLinkStatusPeriod.
* For example, a value of 0x007F allows a jitter between 0-127 milliseconds.
*/
-DLINK_STATUS_JITTER_MASK=0x007F

/* in seconds; set to 0 to turn off route expiry */
-DROUTE_EXPIRY_TIME=30

/* This number is used by polled devices, since the spec'd formula
* doesn't work for sleeping end devices. For non-polled devices,
* a formula is used. Value is in 2 milliseconds periods
*/
-DAPSC_ACK_WAIT_DURATION_POLLED=3000

/* Default indirect message holding timeout value:
* 1-65535 (0 -> 65536) X CNT_RTG_TIMER X RTG_TIMER_INTERVAL
*/
-DNWK_INDIRECT_MSG_TIMEOUT=7

/* The number of simultaneous route discoveries in network */
-DMAX_RREQ_ENTRIES=8

/* The maximum number of retries allowed after a transmission failure */
-DAPSC_MAX_FRAME_RETRIES=3

/* Max number of times retry looking for the next hop address of a message */
-DNWK_MAX_DATA_RETRIES=2

/* Number of times retry to poll parent before indicating loss of synchronization
* with parent. Note that larger value will cause longer delay for the child to
* rejoin the network.
*/
-DMAX_POLL_FAILURE_RETRIES=2

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

/* The maximum number of groups in the groups table */
-DAPS_MAX_GROUPS=16

/* Number of entries in the regular routing table plus additional
* entries for route repair
*/
-DMAX_RTG_ENTRIES=40

/* Maximum number of entries in the Binding table. */
-DNWK_MAX_BINDING_ENTRIES=4

/* Maximum number of cluster IDs for each binding table entry.
* Note that any value other than the default value may cause a
* compilation warning but Device Binding will function correctly.
*/
-DMAX_BINDING_CLUSTER_IDS=4

/* Default security key. */
-DDEFAULT_KEY="{0x01, 0x03, 0x05, 0x07, 0x09, 0x0B, 0x0D, 0x0F, 0x00, 0x02, 0x04, 0x06, 0x08, 0x0A, 0x0C, 0x0D}"

/* Reset when ASSERT occurs, otherwise flash LEDs */
//-DASSERT_RESET

/* Set the MAC MAX Frame Size (802.15.4 default is 102) */
-DMAC_MAX_FRAME_SIZE=116

/* Minimum transmissions attempted for Channel Interference detection,
* Frequency Agility can be disabled by setting this parameter to zero.
*/
-DZDNWKMGR_MIN_TRANSMISSIONS=20

/* Compiler keywords */
-DCONST="const __code"
-DGENERIC=__generic

/****************************************
* 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=5000

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

/* This is used after receiving a data confirmation to poll immediately
* for response messages...in milliseconds
*/
-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.
*/
-DREJOIN_POLL_RATE=440

  • 1&2、网络不好,导致数据发送不成功【对方没有回复ACK】,协议栈会进行重发
    3、还是怀疑网络不好,路由重新入网了吧?
  • 建議抓包先分析一下狀況
  • 是的,我也同意是信号不好,但测试时ZC,ZR,ZED上电后就不再移动,有时24小时都不会有一次重发,通常一天就那么几次,是被干扰了吗?

    另外,我的客人担心ZED过多重发会影响其待机时间,所以请问能否调整重发的间隔和次数?如何测试?

    最后,对於2 我是最困惑的,原则上重发很快会发生,但为何会等了6s才重发呢?有没哪个底层参数是影响这个间隔的?谢谢!
  • 有沒有抓包檔可以分析?
  • 有的,刚抓了一堆WireShark+TiWsPc的数据,由于数据庞大,并且没有Ubiqua的那么直观,稍等我整理一下发出来
  • 下面附上最新的抓包数据,抓了20小时,抓到一个6s重发,详见下面压缩数据说明。

    另外,数据用Wireshark打开后,时间平移设定09:28:12。problem.zip

  • 数据已上传,有空帮忙看看,谢谢!
    e2echina.ti.com/.../problem.zip
  • 你附上的抓包数据我打開只看到650個封包数据,跟你截圖上有有很大的差距,請你用你附上的抓包內容說明問題發生的時間點,我才能夠看發生什麼事
  • 是的,我截取的就是出现重发附近时刻的数据,并且以下图ZED (0x5ae6)为说明对象的,发生重发是10:58:31和10:58:37.

  • 我Wireshark看到的packet no.跟time,看起來跟你的不一樣,所以不知道要查哪些封包

  • 是的,wireshark要设置一下。

    麻烦按下面截图操作,应该就可以了,谢谢!

  • 試過時間平移了,沒辦法看到跟你一樣的時間軸
  • 你可能漏了设置“时间显示格式”,或者参考下面视频设置,应该会变成与我一样的时间轴。

    通过详细分析数据,连接在路由0x8822下的两个ZED(0x0b4c 和 0x5ae6)在10:58分内均出现6s重发现象,

    其中0xb4c重发了2次:

    1.384 10:58:28.214087 0x0b4c 0x0000 ZigBee 132 ZCL: Read Attributes, Seq: 215

    2.434 10:58:34.219978 0x0b4c 0x0000 ZigBee 132 ZCL: Read Attributes, Seq: 215

    3.474 10:58:40.225495 0x0b4c 0x0000 ZigBee 132 ZCL: Read Attributes, Seq: 215

    0x5ae6重发了1次:

    408 10:58:32.128926 0x5ae6 0x0000 ZigBee 151 ZCL: Read Attributes, Seq: 216

    458 10:58:38.137017 0x5ae6 0x0000 ZigBee 151 ZCL: Read Attributes, Seq: 216

    我还发现,重发时,Seq:是一样的。

    另外,还看到No.318 10:58:07.347245 0x5ae6 0x8622 IEEE 802.15.4 72 Data Request, Bad FCS ,0x5ae6向0x8622设备发送数据请求,但实际是没0x8622的,难道是发送错误?

  • 你這個是因為這個ZCL read request有要APS ACK但是沒收到,所以重發了,而且你這個ZCL read attributes好像都是私有格式,你確定協調器有支持這些私有格式attributes?
  • 谢谢帮忙分析!

    “因APS ACK没收到,于是重发”,请问在哪里修改这个重发时间?为何有些重发间隔是毫秒级,而这个重发是6s呢?

    我用AF函数发送的是自定义格式数据,至于“ZCL read attributes”我不懂为何抓到这个包?

    我从目前数据中看到的规律是,如果发送时刻抓到的包是”ZCL Device Temperature Configuration“,则是正常的
    213 10:57:32.090356 0x5ae6 0x0000 ZigBee 151 ZCL Device Temperature Configuration:
    214 10:57:32.093652 IEEE 802.15.4 65 Ack
    215 10:57:32.099856 0x5ae6 0x0000 ZigBee 151 ZCL Device Temperature Configuration:
    216 10:57:32.103152 IEEE 802.15.4 65 Ack
    而如果抓到"Read Attributes, Seq: xxx",则会在6s后重发
    408 10:58:32.128926 0x5ae6 0x0000 ZigBee 151 ZCL: Read Attributes, Seq: 216
    409 10:58:32.132222 IEEE 802.15.4 65 Ack
    410 10:58:32.138751 0x5ae6 0x0000 ZigBee 151 ZCL: Read Attributes, Seq: 216
    411 10:58:32.142047 IEEE 802.15.4 65 Ack
    请问有没一些zigbee抓包数据分析的教程?
  • In f8wconfig.cfg, APSC_MAX_FRAME_RETRIES is the number of retries the APS layer will send the message if it doesn’t receive an APS ACK before giving up. APSC_ACK_WAIT_DURATION_POLLED is the time between retries.
  • 明白,目前的设定如下:
    -DAPSC_ACK_WAIT_DURATION_POLLED=3000
    /* The maximum number of retries allowed after a transmission failure */
    -DAPSC_MAX_FRAME_RETRIES=3
    但困惑的是,按这个设定理应是每隔3s重发,为何实际却是6s重发?
  • 看不大出來為什麼你log里會6s重发,如果你試著改變APSC_MAX_FRAME_RETRIES/APSC_ACK_WAIT_DURATION_POLLED,比如說APSC_MAX_FRAME_RETRIES設置為0,那還會看到重发?
  • 对的,我之前有将测试的8个ZED配置下面参数:

        DAPSC_MAX_FRAME_RETRIES=0

        DNWK_MAX_DATA_RETRIES=1

        maxFrameRetries = 0

    结果在ZC还是看到6s重发,接着怀疑是router重发,于是将2个router的那三个参数改成与ZED一样,结果还是有6s重发,并且更多,明显比默认参数差了。

    =====================

    在分析前面抓包数据时,还遇到一些问题,如下图:

    下面是出现重发的帧:

    下面是重发的最后一帧,是否又在收到APS,所以停止重发了?

    问题:

    1.ZED无收到APS引起重发,但究竟是Router受到干扰,还是ZED受到干扰,还是ZC呢?

    2.通过上面抓包数据如何分析出来?

    3.是软件问题?还是硬件问题?从哪方面入手解决?还是这本来就是一个正常现象?谢谢!

  • 你截圖看來是routing path改變了,所以要重建routing path,這應該跟干扰無關
  • 谢谢回复,离真相又近了一步,“routing path改變了”是与什么有关?是否正常现象?
    我目前与路由相关参数设置如下:
    -DMAX_RTG_ENTRIES=40
    -DROUTE_EXPIRY_TIME=30
    -DMAX_RREQ_ENTRIES=8
  • 可能跟你設備重新入網或有关是你調整了設備的位置,或是有干擾可能都會讓routing path改變
  • -DROUTE_EXPIRY_TIME=30
    路由表为已经建立连接路径的节点维护路径记录。如果在一定的时间周期内,没有数据通过沿着这条路径发送,这条路径将被表示为期满。期满的路径一直保留到它所占用的空间要被使用为止。这样,路径在绝对不使用之前不会被删除掉的。在配置文件f8wConfig.cfg文件中配置自动路径期满时间。设置ROUTE_EXPIRY_TIME为期满时间。

    而我这边ZED 设定为60s发一次数,而ROUTE_EXPIRY_TIME设置为30s,会否发送间隔>ROUTE_EXPIRY_TIME,所以有时会“routing path改變了”?ROUTE_EXPIRY_TIME应如何设定较为合适?
  • 沒有設備重新入網或是你調整了設備的位置,或是有干擾,基本上routing path不會變啊,不用去改這些參數
  • 自己回答一下,是因为:
    /* This number is used by polled devices, since the spec'd formula
    * doesn't work for sleeping end devices. For non-polled devices,
    * a formula is used. Value is in 2 milliseconds periods
    */
    -DAPSC_ACK_WAIT_DURATION_POLLED=3000

    “Value is in 2 milliseconds periods” ,so 3000*2ms = 6000ms = 6s