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

SerialApp with the option 'POWER_SAVING'

Naoki Fujiwara
Prodigy 80 points

I'm developing with CC2530ZDK.

 

I want to use the functions: Zigbee, UART, POWER_SAVING.

I need the low power consumption in the system that I just develop. But I don't need speed of connection.

 

At first, I use TI's sample 'SerialApp'. I configured two CC2530EB, one for Cordinator and the other for End-Device.

They worked fine with the default setting. 

 

I configured the End-Device with a compile-option 'POWER_SAVING'. But they didn't work well.

The way from Cordinator to End-Device was OK. Although the reverse way was NG.

 

Question:

- Can I use POWER_SAVING with SerialApp ?

- (If not,) Which part do I need to modify?  I think the callback of UART is the part. But I'm not sure.

 

Regards.

  • 0
    Guru 31280 points

    Hi,

     

    I have no immediate answer for question, but I have several suggestions:

    1. Have you tried to debug and see where the problem happens?
    2. Do you have any packet sniffer trace?
    3. Have you tried to increase the POLL_RATE to, let's say 500 instead of 1000
      (open f8wConfig.cfg and search for -DPOLL_RATE=1000)

    When ZED compiled with POWER_SAVING the TX will be off during sleep

    period, hence it won't be able to receive packets.

  • 0 in reply to Igor Sherer
    Prodigy 80 points

    Thank you for your advice, Igor.

    I followed your suggestions.

    Igor Sherer said:
    1. Have you tried to debug and see where the problem happens?
    2. Do you have any packet sniffer trace?
    3. Have you tried to increase the POLL_RATE to, let's say 500 instead of 1000
      (open f8wConfig.cfg and search for -DPOLL_RATE=1000)

    The result are below:

    1. I debugged and found the problem seemed wrong with UART-callback function.
       Even there are some data in UART-Input, callback function only sometimes is called.
       So the data is sometimes lost.

    2. I tried to use packet sniffer. But it's beyond my knowledge. I can't use the tool effectively.

    3. I changed the POLL_RATE to 500. But nothing changed. 

     

    Your below comment inspired me.

    Igor Sherer said:

    When ZED compiled with POWER_SAVING the TX will be off during sleep

    period, hence it won't be able to receive packets.

    I think 'POWER_SAVING' mode isn't suitable for my purpose.

    Actually, I want to reduce the power consumption during there isn't any transferring data.
    And we know both the timing of the period with data transfer and the timing of no-transfer beforehand.

    So I notice that I compile my project WITHOUT 'POWER_SAVING' and I use 'halSleep()' function when the period of no-transfer.
    I made a new project with the moving like above. It seemed good for me.

    Now I solve my problem. Thank you for your advice. 

     

  • 0 in reply to Naoki Fujiwara
    Guru 31280 points

    Hi,

     

    Naoki Fujiwara said:
    2. I tried to use packet sniffer. But it's beyond my knowledge. I can't use the tool effectively.

    I strongly suggest you to go over the packet sniffer user's guide. Debugging

    wireless network behavior without actually seeing an over-the-air traffic is

    sometimes impossible. It will make you guess and assume very wrong and

    misleading assumptions. Spare a hour or two to understand the very basic

    of it. (still, it's just a suggestion) :)

     

    Naoki Fujiwara said:
    So I notice that I compile my project WITHOUT 'POWER_SAVING' and I use 'halSleep()' function when the period of no-transfer.
    I made a new project with the moving like above. It seemed good for me.

    using/calling halSleep() out of normal order can cause serious problems

    and unexplained behavior, use it with extreme caution and full understanding.

     

    I can suggest you an alternative scenario:

    1. Compile your end device with "POWER_SAVING" option.
    2. Force your ED to stay "awake" while transmitting or receiving of serial data
      by calling osal_pwrmgr_task_state(My_App_TaskID, PWRMGR_HOLD);
    3. When RX/TX ends, allow to your ED to enter sleep mode again by calling
      osal_pwrmgr_task_state(My_App_TaskID, PWRMGR_CONSERVE);

     

    By the way, once ED is in one of the power saving modes (PM2, or PM3) how exactly it

    is notified of incoming serial transmission (from the serial port, not the RF)?

  • 0 in reply to Igor Sherer
    Prodigy 80 points

    Hi,

    Igor Sherer said:

    I can suggest you an alternative scenario:

    1. Compile your end device with "POWER_SAVING" option.
    2. Force your ED to stay "awake" while transmitting or receiving of serial data
      by calling osal_pwrmgr_task_state(My_App_TaskID, PWRMGR_HOLD);
    3. When RX/TX ends, allow to your ED to enter sleep mode again by calling
      osal_pwrmgr_task_state(My_App_TaskID, PWRMGR_CONSERVE);

    Your suggestion is great! Thank you so much.

    I use 'osal_pwrmgr_task_state()' as your scenario, it works very well for me.

    The power consumption is small while its state is 'PWRMGR_CONSERVE'.

     

    Now I solve my problem completely. Thanks.