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

How to set a ideal value to POLL_RATE?

Flavio Bianchi1
Prodigy 70 points

Other Parts Discussed in Thread: CC2530, Z-STACK

Hi,

I´m designing a network using several radio modems based on CC2530 + ZStack 2.5.1a. They link one HMI to five PLCs using Modbus protocol. For the modems I develop a custom software based on SerialApp, which spread all the messages send by any product (uses broadcast address).
 
When I use a low query rate (5 to 8 seconds/query), all works fine. But when I try to poll the PLCs faster, the error rate increases a lot. Many messages are lost inside the network. For test, all the products are in a small room, so there´s no RF problems.
 
I think that it can be optimized through the compiler directives or parameters. Is it correct? Or is it a intrinsic limitation of the Zigbee structure? The document "Application level tuning of Z-Stack" describes a little the meaning of the parameters, but I don´t understand how to optimize them. For example, how to set a ideal value to POLL_RATE?
 
Thanks for any comment or help!
  • 0
    Guru 735705 points

    1. How many devices are in your system?

    2.Do you have router in your system.

    I would suggest you to use unicast to instead of broadcast. I think this the root cause of message drop and nothing to do with the polling rate if your device number is not very large.

  • 0 in reply to YiKai Chen
    Prodigy 70 points
    YiKai,
     
    Our system have six devices - one ZC and five ZEDs, no router in this application.
     
    About the option unicast X broadcast, I chose to use broadcast because I don´t know which address I must set for each communication operation. The coordinator sets random shortaddresses to the ZEDs and when the HMI calls a PLC, I know only the Modbus address, not the Zigbee shortaddress of the destination... 
    Is there a way to solve this problem? Or, is there a way to preconfigure in each ZED firmware the shortaddress that will be assigned by ZC?
     
    And for last, is the broadcast method intrinsically unsafe on Z-Stack?
     
    Thanks,
     
  • 0 in reply to Flavio Bianchi1
    Guru 735705 points

    Since ZED uses polling to get the data for it, it might miss broadcast message when it is not polling. I would suggest to to use unicast in your case. When ZED joins ZC, ZC should receive end node announcement which will give the short address of ZED. You should keep it and use it for unicast in your application.

  • 0 in reply to YiKai Chen
    Prodigy 70 points
    I changed the format from broadcast to unicast and the communication became actually much more reliable.
    But this approach created a new problem. Whenever a station wants to do a reading in another, it needs to know its ShortAddress. Configure it when the system is being installed is easy, but if I have to change one board (for maintenance), this will receive a new (different) random ShortAddress, which will require me to reconfigure the system.
    How can I force the setup of the ShortAddress (on ZED or ZC) to a known desired value, bypassing the generation of random ShortAddress?

    Thanks!
  • 0 in reply to Flavio Bianchi1
    Guru 735705 points

    As I know, you can't force the setup of the ShortAddress.

  • 0 in reply to YiKai Chen
    Prodigy 70 points
     Another alternative to solve the problem: Can I send a unicast message using AF_DataRequest (), specifying the target by its extended address (setting GP1500Z_TxAddr.addrMode = afAddr16Bit;)?
    The documentation available in Z-Stack API.pdf is not clear about this, but inspecting the code of the function it seems to be possible. Does anyone know this?
  • 0 in reply to Flavio Bianchi1
    Guru 735705 points

    No idea about this.