• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 54 subscribers
  • Views 1422 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.

Timing issues in Multicast and Broadcast

Mario Braun
Intellectual 435 points
Other Parts Discussed in Thread: Z-STACK

Hey everyone!

I have a problem with the minimum idle time between ZLL-commands in Multi- and Broadcast.

We are developing an App for an Android device to control our ZLL-Lamps. If the user changes (e.g.) the level with the corresponding slider, a command is send every 100ms to change the level of the selected group.

The problem: After a few transferred commands the lamp stops to change the level for a short time, but then the lamp reacts normal. This behavior is repeated, until no commands are sent.

If we change the idle time to about 350ms everything is working perfect, but there is a to big time offset between the App-Level (nominal value) and the Lamp-Level (actual value). We want to reduce this idle time to 150-200ms, because it does not look good.

Thanks in advance!

best regards

Mario

  • 0
    TI__Genius 9180 points

    Mario,

        Can you provide a packet trace? I am interested in if this is unicast or broadcast, if APS counter is incrementing correctly, ZCL command ID used (Move, MoveTo, Step etc), ZCL level transition time, if the delay coincides with a LinkStatus message, or if there is other nwk work messages causing high BW.

    Sending a level command every 100ms, should be possible, but could cause lots of nwk traffic if multiple apps are controlling multiple Lights. It would also be a very bad thing to do using groups (broadcast) messages. You could consider a slower rate (350ms) using a transition time of 350ms.

    Tony.

  • 0 in reply to TopCat
    Intellectual 435 points

    Thanks for the quick answer!

    I recorded the behavior of the ZLL-Lamp (Address 3) and the control (Address 1) in unicast and broadcast.

    The control is sending a Move-To-Level command every 200ms.

    Unicast:

    You can see the response from the ZLL-Lamp after every command.

    Broadcast:

    In Broadcast the ZLL-Lamp stops to send a response after a few messages, but then the lamps reacts normal.

    There is only one app controling the lights and i am using Z-Stack Lighting 1.0.1.

    best regards

    Mario

  • 0 in reply to Mario Braun
    TI__Genius 9180 points

    Mario,

        Unfortunately your packet sniffer could not decode the nwk traffic, and I would like to see this level of information. Please uncomment the below line in zll.h and rebuild the Light and Controller (I assume you are using the ZLL Remote as a controller, if you are using a HA controller please let me know).

    #define ZLL_DEV_FIXED_NWK_KEY { 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc,\
    0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc }

    It looks like you are using Ubiqua if you are then you can go to Tools->Options go to security tab and click add. Add a ZigBee Network Key and set the key to all CC:CC:CC:CC:CC:CC:CC:CC:CC:CC:CC:CC:CC:CC:CC:CC.

    You will then be able to decode the traffic. Please resend the trace with the nwk payload decoded (preferably by attaching it to this thread).

    Regards, TC.

  • 0 in reply to TopCat
    Intellectual 435 points

    Here is the traffic trace with the decoded ZCL-Packets in Broadcast.

    It looks like the APS counter is incrementing correctly and it is a valid ZCL-Command.

    What am I doing wrong?

    best regards

    Mario

  • 0 in reply to Mario Braun
    Prodigy 240 points

    Hi Mario,

    Looks like your broadcast transaction table is filling up to me. The sets of 9 broadcasts before they start to get dropped is a give away.

    From memory there is a NIB value that controls how long entries stay in the BTT, and a define setting it's size, but beware playing with these, as you cant rely on other manufacturers to have done the same.

    Again from memory, the numbers work out to a limit of 9 broadcasts in 9 seconds before commands get dropped, so i would look at using less commands or going unicast.

    Hope that helps,

    Mark

  • 0 in reply to MarkV
    Intellectual 435 points

    Hi Mark,

    Thanks for the answer, but the manipulation in the NIB of the Lamp is no option for us. Is there no other way to solve this problem on the side of the bridge?

    best regards

    Mario

  • 0 in reply to Mario Braun
    Prodigy 240 points

    Hi Mario,

    I don't know of any solution to this, its a property of ZigBee Pro...

    The only options i know of are to change to unicast, or to limit the average rate of broadcasts.

    Good luck,

    Mark

  • 0 in reply to MarkV
    TI__Genius 9180 points

     

    Mario,

        Sorry for not responding to this, it slipped through my email filter (it would be good to put ZLL or Lighting in the subject to make sure you get my attention). Mark, thank you for stepping in and spotting the broadcast table was filling up.

    This is why I was asking for the trace, there is a limit in ZigBee-Pro to the amount of BCast you can send in a given time. You should not see this happening in unicast, but let me know if you do.

    You can change this behavior without changing the NIB. There are parameters exposed in build time defines. Please look at the define "MAX_BCAST" in the doc "Application-Level Tuning of Z-Stack.pdf". Unfortunately it looks like this document was missed from the Document set in ZStack Lighting 1.0.2, so you will need to get it from the ZStack Home-1.2.0 installer from http://www.ti.com/tool/z-stack.

    Regards, Tony.

  • 0 in reply to TopCat
    Intellectual 435 points

    Yes it only happening in multicast or broadcast.

    Thanks for the help!

    best regards

    Mario