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

Low latency message sending from coordinator to enddevice

Fox36631
Intellectual 280 points
Other Parts Discussed in Thread: Z-STACK

I have a question regarding data transmission from the ZigBee coordinator to an EndDevice.

 The network that i have is operating under non-beacon mode. My understanding is this, in this mode the coordinator buffers any data that might need to be sent to the enddevice untill it receives a data request command from the enddevice. Now, what do i do if there is an "urgent message" that needs to be sent to the enddevice immediately? I cant possibly wait for a data request command since it means increasing the latency of the "urgent message".

Also i am operating under a constraint whereby i cant reduce the data request poll period.

Can i make my coordinator do a broadcast of the "urgent message"? i believe for broadcasts the coordinator does not have to wait for data requests from the end device. But in this case the enddevice should keep its receiver always ON. Is this the default behaviour of the end device.

Btw, i am using ZStack ver 1.4.3-1.2.1 with CC2430DB/EB

 

 

  • TI__Guru*** 130875 points

    Hi Fox,

    I hope the following couple points help.

    The default expected behaviour is the polling model.  Ie  End Device sleeps, wakes up at regular intervals to poll messages, and sleeps again.  In the mode there is really no way to tell it 'important message coming, break the pattern'.   Ie you simply have to wait for the poll.

    Look for this option in f8wConfig.cfg

    -DRFD_RCVC_ALWAYS_ON=FALSE

    You can keep an end device always on.  In this case, more power will be consumed, however you will not have to wait for a poll and your message should get right through.

    Also note that I do not beleive broadcast messages are stored for future forwarding upon a poll.

    Hope this helps,

    Yoda

  • in reply to Lisa TI
    Intellectual 280 points

    Thanks Yoda, 

    I made the EndDevice's receiver to be always on by means of -DRFD_RCVC_ALWAYS_ON=TRUE. The ED no longer polls the coordinator for data, meaning no more Data Requests from the ED. The coordinator now is able to send unicast messages to the ED immediately without waiting for any DR poll. Now the question is:


    1. How did the coordinator know that the ED is having its receiver always on? Is the coordinator also using the -DRFD_RCVC_ALWAYS_ON flag?. But it is specifically mentioned that this flag is only for EDs? So what gives?

    2. Is this behaviour specific to Z-Stack? What about other ZigBee stacks, will the coordinator be able to figure out that the ED has been configured to keep its receiver always on and threby send unicast messages anytime?

    3. Is this behaviour even compliant with the ZigBee standard? I mean, i cant find anything in the protocol saying that EDs can always keep thier RX on and coordinators can send unicast  messages anytime.

     

    One more thing:

    Regarding Orphan notifivations, i changed the MAX_RESUME_RETRY to 3 from the default value of 2. I did this so that my ED could attempt multiple orphan notifications. I have only 1 channel enabled, so orphan scans are done on a single channel. What i noticed is this, the time period between successive orphan notifications is about 700ms(i can see this in the sniffer). How can i reduce this time period? i tried to make the 'delay' variable in ZDApp_NetworkInit  0, this reduces the orphan notification period to about 500ms only. But I want about 250ms.

     

    Regarding your comment, Also note that I do not beleive broadcast messages are stored for future forwarding upon a poll.

    Actually broadcast messages do get stored and get transmitted again via unicast upon receiving a data request from a ED. I noticed this in the sniffer.

     

     

  • in reply to Fox36631
    TI__Guru*** 130875 points

    Hello Fox,

    All this should also be in the f8wConfig.cfg.

    I would recommend setting all the POLL rates to 0.  

    Regarding the timeout this you can try modifying this line

    -DNWK_INDIRECT_MSG_TIMEOUT=7

    Hope this helps.

    Cheers,

    Yoda