• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 55 subscribers
  • Views 657 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.

the delay existes when the hub sending out commands

Ada_Cheng
Prodigy 60 points

Other Parts Discussed in Thread: CC2538

Hi TI guys

our product is based MT6732 main chip, and included the zigbee chip CC2538.

now we are sending simple on/off commands to a LAMP and a Wall Plug, one command each second.

sometimes these commands are not sent to the devices for about  5-6 seconds, then suddenly these commands are sent out again.

the CC2538 always reply OK to our MT6732  main chip when we send the commands(response status is success), also when the CC2538 doesn't send the commands to the devices.

  • 0
    Guru 735695 points
    I suggest you to use Ubiqua Packet Analyzer to check over the air messages first.
  • 0 in reply to YiKai Chen
    Prodigy 60 points

    hi YiKai, thank you for your quick answer.

    here is sniffer test and analyse from my colleague Davide:

    - test: send on/off every 1/2/5 seconds to lamp and plug, alternatively or together
    - result: sometimes we experience unexpected wait time between "command ok" from SPI of cc2538 and activation/deactivation of lamp/plug
    I sniffed zigbee protocol on air to check what happens and the result is:
    1) the delay is due to cc2538 not sending the command frame on air (sometimes I have seen 10s+ delays)
    2) any incoming frame seems to unlock this situation almost immediately.
    I see this happening 100% of the times with for example broadcast link status frame from device and ias zone device
    check the images, if this "sleep" time occurred, these incoming frame unlocked situation and cc2538 starts to send the commands in air again
    Immagine incorporata 2
    There seems to be:
    1) possible bug that locks the zstack for some reason
    2) some sleep mode activated
    100% of the times it seems to be unlocked by incoming frame.
  • 0 in reply to Ada_Cheng
    Guru 735695 points
    According to your sniffer screen shot, your coordinator keeps sending command in several milliseconds interval and that's cause the problem.
  • 0 in reply to YiKai Chen
    Prodigy 60 points
    yes, indeed our zigbee chip sends out 2 commands in 100ms for on and off, one to switch on/off and one to request status
    we want to know which is the property timeout between two commands we send out?
    and why when the cc2538 receives link status frame and starts to send frames again?
  • 0 in reply to Ada_Cheng
    Guru 735695 points
    lots of your commands are sent within 20 ms and this is too fast. I would suggest not to send command with interval less than 100 ms.
  • 0 in reply to YiKai Chen
    Prodigy 60 points
    as you can see from the picture, after the frame 33, the one that wakes up after 11s the cc2538. the frame are sent fast by the cc2538 ittself as they are inside his message queue.
    we don't send from our code frames with < 100ms timeout in this test
  • 0 in reply to Ada_Cheng
    Guru 735695 points
    If you have a look on packets before no.33, the interval is still very small.