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

Power modes

Necdet
Intellectual 890 points
Other Parts Discussed in Thread: Z-STACK, CC2530

Hi,

I'm trying to add power modes to my application. I read the power management pdf. I have routers that broadcast a message per 5 seconds. I want my end devices to wake up when they hear from router. I'm playing with the poll rates, but I don't know how to acknowledge that my device is in the power mode or polls for data. How can I examine the power mode 2 on my hardware?

Best Regards,

Necdet

  • 0
    Guru 31280 points

    Hi Necdet,

     

    1. OSAL managing device's power modes by itself. Of course if it's allowed to.
      Again, I'm not sure what is going on in earlier versions of Z-stack, but It's working in v2.3.0,
      v2.3.1, v2.4.0 and v2.5.0.
    2. While in PM2 or PM3 cc253x (in your case the End Device - ED) won't be waken up from "hearing"
      a router, or any other packet destined to this end device. Instead, different variations of Poll Rates
      should be applied/enabled in order to "extract" different types of messages from ED's parent.
    3. Regarding the poll rates, in "power management document" there are 3 different types of polls,
      as a start point, set those three to 100, in other words for every 100mSec.
      These poll rates should be managed by the application in some way. In the bottom line, you've
      deigned your project to act in some way and you familiar with your system, thus you should know
      when and how long your ED have to poll for data, ACKs and other messages.
    4. You can examine different power modes (maybe except the PM3) by connecting your PCB to power
      source trough current meter (DVM-Fluke). Ensure that no peripherals are working and all the IO
      pins configured in a way where no possible leakage of current through internal pull-up/pull-down
      resistors is expected. When SoC configured in the "right" way and you have no other parts/devices
      on your PCB that could draw extra current, you should be measuring ~1uA while in PM2 and
      something like 1mA in PM1... refer to current consumption table in cc2530 datasheet.

    Hope this helps

  • 0 in reply to Igor Sherer
    Intellectual 890 points

    Thanks Igor,

    I tried to change the poll rate to 4 seconds with NLME_SetPollRate(). I make LED1 blink when it receives a data packet. I suppose, it must take at least 4 seconds to receive another data packet. Sometimes it takes around 2 secs. What might be wrong?I use broadcast addressing, does that cause any problem with data polling?

    Best Regards,

    Necdet

  • 0 in reply to Necdet
    Guru 31280 points

    Hi Necdet,

     

    Well, try to change these poll rates altogether and see what happpens.

    I suggest you to check this with a packet sniffer, it is much much easier to

    analyze what's going on once you have an observation of the OTA traffic.

    Regarding the broadcasts, shouldn't be a problem as long as the broadcasting

    address is 0xFFFF (FYI 0xFFFC or 0xFFFD won't be delivered to end devices).

     

  • 0 in reply to Igor Sherer
    Intellectual 890 points

    Hi Igor ,

    I changed all the poll rates to 100000 msec and it reads data per 20 secs. I'm sending broadcast per 5 secs. It's interesting. What should I look for in the packet sniffer in order to understand polling : Sent data requests from the end device?

    Also, in the packet sniffer I see three broadcast messages per 5 secs instead of 1 . For example ; at 5 ,5.5 and 6 I see broadcast message, and at 10,10.5 and 11 other messages come. Is it normal?

    Best Regards,

    Necdet

  • 0 in reply to Necdet
    Guru 31280 points

    Hi Nected,

     

    I think 100000 is too much and eventually will be wrapped, since the parameter for the poll functions is a 16 bit variable,

    thus the max passed number can be 0xFFFF (other values will be wrapped).

    In the packet sniffer you should look for the data request transmitted by the end device and then the parent should feed

    the end device with data (of course if it has data for that specific end device).

    As for the broadcasts, I lost you here a little bit, what types of broadcasts you see exactly??

    By the way a good way to explore the polls and its meaning is by enabling once at a time and see what happens OTA,

    I agree that the documentation has a little of information regarding these polls, but you can investigate it, successfully,

    by yourself. To tell you the truth, sometimes, I myself getting a little bit confused on that one.

  • 0 in reply to Igor Sherer
    Guru 31280 points

    Hi again,

     

    Did you managed to understand the whole thing with polling rates?

  • 0 in reply to Igor Sherer
    Intellectual 890 points

    Hi Igor,

    No, the problem still continues. The polling occurs always around 1 / (2.7) times the poll rate I entered. (For example, PollRate = 10 secs ; device polls for data per 10 / 2. 7 secs.) I checked with the packet sniffer. Also, it has some irregularities with its polling behaviour. It sometimes polls earlier.

    The broadcast thing is about the packet sniffer and does not  cause any problem with the data flow so I stop worrying about it.

    Thanks,

    Necdet

  • 0 in reply to Necdet
    Guru 31280 points

    Hi, 

     

    Well, the problem is I'm not familiar with Z-stack 1.4.3 and may be what you seeing 

    is a known bug or may be now.

    But, let's say, once you have enabled only the "Queued Data Polling" to be carried

    out every 5 seconds (NLME_SetQueuedPollRate(5000); ) you should be seeing a

    clear pattern of polls sent every 5 seconds (of course +-delta of several uSeconds).