• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 57 subscribers
  • Views 765 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2530 Route Request issue

EthanChen
Intellectual 550 points

Other Parts Discussed in Thread: Z-STACK, AES-128

Hi all,

We have test TI latest Z-Stack Home 1.2.2 and have some problem occur and description at below

This test enable NV_RESTORE and security.

ZigBee NWK Key: 22222222222222222222222222222222
(AES-128 Encryption, 32-bit Integrity Protection)

Network topology just 3 node for this test

ZC <------> ZR1(0xa1f5) <------> ZR2(0xe1f9)

ZC and ZR2 is far enough away, so ZR2 must associate through ZR1.

Test method:

  1. ZC and ZR1 power on.
  2. After ZR1 assoicate and can tranciver data success with ZC then ZR2 power on.
  3. ZR2 successful associate with ZR1 and can tranciver data to ZC via ZR1,record take time, then re-power on ZR1 and ZR2 to reapeat this activity serveral time.

The detail wireshark log at attachment,"wireshark_bad_log" is to intercept packets from "wireshark_complete_log" problem occurred.

The questions is,

1. Most of the Route Request ZR2 has been ZR1 forward to ZC,
But sometimes still occur ZR2 been sent Route Request,but ZR1 no help forward it, such as "wireshark_bad_log"
2. Before wireshark_bad_log frame #51 the ZR1's link status still have ZR2, but suddenly there is no link status with ZR2 after frame #51 that ZR2 Route Request will fail and dat can't transmitter to ZC success.

Can you help explain what status this route request will fail and what method can avoid it?

Ethan Chen

Best Regards,ZigBee wireshark log.zip

  • 0
    TI__Expert 3050 points
    Hi Ethan,

    From the log you send, I suspect that ZR2 was actually too far even from ZR1. Also the sniffer itself is possibly too far from ZR2, as some Link Status messages are missing. If this is the case, this would explain why ZR1 did not hear some route requests from ZR1, and thus would not forward them (your observation #1). Also, it would suggest that some Link Status messages from ZR2 did not reach ZR1, which caused ZR1 to mark ZR2 link as bad. When a device fails to hear a neighbor's Link Status message for 3 times in a row, it marks that neighbor as invalid - this can explain your observation #2.

    I'm assuming that the during the period captured in the 'bad_log', the devices were ON the whole time (and not turned off/on).

    From the log it seems you set the link status period to 30 seconds (the default is 15 seconds - see NWK_LINK_STATUS_PERIOD in Nwk_globals.h). Is there any specific reason you changed this?

    Would it be possible for you to retry this setup, using the default stack configuration (including NWK_LINK_STATUS_PERIOD set to 15), placing the sniffer adjacent to ZR1, and making ZR2 and the coordinator in equal distances and opposite sides from ZR1? Please keep ZR2 and the coordinator relatively close to ZR1, to rule out bad/weak RF connection between each of them and ZR1.

    Please use TI SmartRF Protocol Sniffer (available at www.ti.com/.../packet-sniffer) to capture the traffic log, and export the sniffer log in PSD format. This format is more portable and allows us to open the capture in commercial protocol analyzer software like Ubiqua.

    Best regards,
    OD
  • 0 in reply to OD
    Prodigy 170 points

    The link status period is change to 30 sec because we have over 100 nodes in the future. We're afraid it will increase the traffic in a PAN and cause our requesting data from coordinator to router cannot be received. BTW, we'll try to modify it back and test it again.

    CYLin.