Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

  • State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 56 subscribers
  • Views 1105 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Problems with binding and lost packets

Ryan Press
Prodigy 145 points
Other Parts Discussed in Thread: CC2530, Z-STACK

I have an end device (battery powered) using Z-Stack Home 1.2.2 on CC2530.  It supports binding on out clusters 0x0006 and 0x0008 for on/off and level.  My problem is that sometimes the command is lost, especially when there are two different devices bound to one endpoint.  Here is a packet capture so you can see what I mean.  In this case I press the On button, and it sends on command to two different devices.  Z-Stack handles this all on it's own because it's a binding.

Device 0x1549 is not made by me, it is from Centralite.  It seems that 0x1549 needs to do a route request, but then once it gets the route reply it does not send the packet on to 0x4908.  Only the second packet to 0x821B gets through.  Is this a problem with my device or something wrong with 0x1549?  Do I need to wait for the default response to the first command before sending the second?  How could I even do this using Z-Stack and how it handles bindings?  Should I listen for the default response for all bindings and if I don't see them in time I resend? (This will use more battery)

Thanks for any insight!

  • 0
    Guru 735535 points

    It looks like ON/OFF command sender lost its routing path to this Centralite (0x1549) device so it starts route request. When this happens, the command won't be delivered and it won't resend the command automatically. You should enable AF_ACK_REQUEST when sending command and check for ack in your application. If there is no ack, application can resend the command.

  • 0 in reply to YiKai Chen
    Prodigy 145 points
    Thanks for your reply!

    The way I read it, is that the On/Off sender 0x0979 next hop is 0x1549; the final destination is 0x4908. Then 0x1549 (the Centralite) lost the path to 0x4908 so 0x1549 did a route request and my packet was lost here. Why did it not send the packet after it received the route request? Is this normal ZigBee behavior? Is it because the On/Off sender sent another packet too soon?

    If I enable AF_ACK_REQUEST it will take more battery because I have to listen for the reply. And in this case it seems silly because the packet was not lost due to signal strength. Then because the binding sends multiple On/Off commands I have to keep track of what request goes with what ACK. I don't know, it seems to me like it should work without AF_ACK_REQUEST, because why even allow that option to be off if it's so unreliable?
  • 0 in reply to Ryan Press
    Guru 735535 points
    1. It is normal ZigBee behavior that it doesn't resent application packets automatically.
    2. According to my experiences, we don't wait ON/OFF command ack on sender side because user would press the button to resend ON/OFF command if they find switch or light is on turned on or off. If you have to guarantee delivery, you need to wait ack.
  • 0 in reply to YiKai Chen
    Prodigy 145 points

    I am reading the ZigBee Specification 3.6.3.3.  It talks about discarding the frame here:

    If the discover route sub-field has a value of 0, the NIB attribute nwkUseTreeRouting has a value of FALSE, and there is no routing table corresponding to the routing destination of the frame, the frame shall be discarded and the NLDE shall issue the NLDE-DATA.confirm primitive with a status value of ROUTE_ERROR.

    However in my case the discover route sub-field is set to 1, so it should discover the route and then send the packet; not discard it.  Maybe it's "normal" that this could cause dropped packets but I don't think it is according to specification.

    I have worked around this issue by sending a dummy frame to the destination device, waiting 60 ms, and then sending the real command.  This allows the router to discover the route before the command is sent through.  However now it seems to me like I am working around a bug in the Centralite device, which is triggered by sending packets too close together.

  • 0 in reply to Ryan Press
    Guru 735535 points
    Your workaround might not work because sending a single dummy frame to the destination device might not fix routing path. I still suggest you to use APS ack.
  • 0 in reply to YiKai Chen
    Prodigy 145 points

    Like your device you mentioned earlier, my device is a light switch so the user could just push the button again.  But it was very unreliable before, about 1 in 5 times it would fail.

    Using APS ACK is really not desired...  It's harvesting indoor solar energy, it needs to keep consumption very low.

    I think I have found a working solution now.  I am using group multicast, which solves the one packet right after another problem.  With this approach I have seen no failures.

    Thanks for your ideas.

  • 0 in reply to Ryan Press
    Guru 735535 points
    It's a good to use multicast when a single switch wants to send a single command to control several lights. Anyway, it's good to know it works now.
  • 0
    Expert 1405 points

    FWIW, I have had the same issue with Z-Stack Lighting (Core stack 2.6.1, so two point releases older than yours). Getting end-devices to find routings smoothly is not reliably possible in anything but the most trivial network (i.e. a single router and end device). I'm not sure if it's a Z-Stack issue or not and I never got answers from TI about this. I too switched to using multicast to work around the routing issue, and it works fine.

  • 0 in reply to Sjef de Krijger
    Guru 735535 points
    As I replied , I always use APS ack to guarantee delivery in my application.