This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Best possible strategy for deep sleep and awakening

Hello,

I'm working on NRF9160-DK.
I would like to be able to put the card to sleep in the deepest sleep possible to be able to save as much energy as possible and to wake it up if the state of one of my 3 inputs changes (button press, accelerometer or other). What is the right strategy for falling asleep and waking up? k_sleep () or is there something better?
What orders of magnitude am I supposed to get for my NRF9160-DK in the best solution to sleep card?

Best regards,

Lecozahu

  • Hello,


    I am more interested in the ON system.
    I have the impression that there are several ways to switch to "System ON": k_cpu_idle (), k_sleep (..) and sd_app_evt_wait (), WFE / WFI. Is there one better than the other? I would like to save as much energy as possible and wake up either on a timer or an interruption.
    Moreover, if I understood correctly, he wakes up at the slightest task. Is there a way to know if all the processes are stopped? Do you have an example ?

    Best regards,

  • Hello again,

    I have read several things since this message and I understand that the system ON is activated with WFE () and WFI () but one wakes up on an event or an interrupt and the other only on the interrupt ( WFI). So does WFI wake up on an RTC interrupt? Is the RTC what we see in the screenshot as MCUON1? Do you have an example of use of MCUON1 and wake up with RTC timer ?


    Thank you in advance.

    Best regards,

  • Hello again!

    I see. For the nRF9160 system ON mode is what I recommend! When entering sleep in k_sleep(...) is usually the way to go. When all threads are sleeping the application will enter an idle thread and go to System ON sleep. 

    You can read more about the Zephyr power management module in the documentation. It also contains info about device power management. However, we do not have a specific example showing all of this functionality, but I recommend looking at the customer code in this thread. This demonstrates how System ON mode can be used together with BLE functionality.

    Reach out if you wonder more about this.

    Best regards,
    Carl Richard

  • Hello again !

    I just have one last question, the current consumption indicated in MCUON1 (2.35µA), is well calculated for with k_sleep (I'm sure now) combined with the function lte_lc_offline () or with lte_lc_power_off ().

    I am sorry to insist but I have to be sure for the specification of the product.

    Also, I would like to have the choice between PSM (24h standby) and modem off if PSM is not available. Is there a way to test on the board if the psm is available (depending on the netwok) or should I use: lte_lc_psm_req and see if there is an error?

    Last question, can the power supplier of the NRF5284 go on the NRF9160DK?

    Thanks in advance,

    Best regards,

    Hugo LE COZANNET

  • Hello, Hugo!

    No worries. The current consumption during lte_lc_offline() and lte_lc_power_off() both reflect the power consumption during PSM (~2.7µA). In addition you can call bsdlib_shutdown() to achieve ~2.35µA. Note that when powering of the modem will also save configuration to flash which will consume some power. Starting up again will also consume some power. I recommend sticking to lte_lc_offline() when PSM is unavailable.

    To be clear: you can then expect a total SIP power consumption of ~2.7µA. 

    If your request PSM you can use AT+CEREG afterwards to see if the network granted the desired values. If PSM isn't available the Periodic-TAU will be 11100000 (which means that it's disabled). 

    What do you mean by this? That the nRF9160 should be powered by the nRF52840, or by the same power supply hardware? Anyways, you can expect much higher peak currents from the nRF9160 compared to the nRF52840, meaning that the power supply must be adapted to this. I suggest taking a look at the nRF9160 Hardware Design Guidelines.

    As well as the HW design of the nRF9160 DK.

    Best regards,
    Carl Richard

Related