nRF9160 sleep current to high

[Karst van der Veen]

Hi there,

I have been testing with the nrf9160 DK for a while now and I cant figure out how to get the device to sleep properly. I have been working with the asset_tracker example and made some modifications to send data to myself and left out any unused parts.

The lowest current draw is around 500 uA, measured on the nrf current measurement pins, which, is way to high. The datasheet shows that it is possible to get around 1~2 uA, which is what I need.

The device needs to be able to sleep for long periods of time, and only wake op on an external interrupt or RTC timer. Does anyone know how to get here? At this moment I am kind of stuck.

Thanks in advance.

Karst

[Bjørn Kvaale]

I believe this case could be helpful.

[kalslebub]

I appear to be having the same issue as the original post with similar amounts of "more current then expected", even with SB44 cut. I cut SB45 after that in an attempt to entirely remove SW10 from the equation. I can make my own post if it's more appropriate for the dev forums or contact you guys directly, but I figure more attention on a shared issue may be better for getting a response.

What I've done so far:

I have two devkits, both are exhibiting the same behavior, though I did not cut SB45 or SW10 on the second board. I have enabled power optimization in the project settings, and have also removed all init and processes from the asset_tracking example except for the modem_configure, and I added a lte_lc_psm_req(true) that always goes off once after 30 seconds or so. I have a graphing power meter and can watch the initial power on TAU/connect and the subsequent eDRX pulses that show up until an RRC disconnect happens and the PSM should be taking over, but to no avail.

I have a graphing current meter and can clearly see the eDRX pulses and the RRC release that should signal entry into PSM. I call k_cpu_idle() a could minutes into the example and then just let the program run. This doesn't seem to have made any real difference when compared to the current consumption between eDRX pulses, which seems a little odd to me. I've probed the SIM card power lines and clock during this PSM time and both are off for further confirmation I'm really in PSM mode.

I'm powering the devkit off an external power supply connected to the +/- terminals of connector P24 as your link suggests, and I have nothing else plugged in during testing. 

[Bjørn Kvaale]

@kalslebub I believe it would be better to post this in a new devzone post. If you want, you can comment on your reply here linking to your new case. That way, people with the same issues may take a look at your related case too.

[Karst van der Veen]

Thank you for all your reply's.

Unfortunately the power consumption somehow stays the same. 

At this point I have done about the same as Kalsebub and I also cant get any lower consumption's.

Could it be that the deepsleep state isn't implemented in the nrf91? Because I saw this under General Kernel Options -> Power Management Control -> Low power state and Deep sleep state. These are unchecked but when i check them, it wont compile. 

Could this have anything to do with the power consumption?

Let me know.

[Eric Gross]

Karst van der Veen I dug into that too. I'm pretty new to Zephyr, so maybe I am analyzing things wrong, but it does seem like some power management is missing for the nrf91 soc.

Note that under the power management config, there are two possible opens: PM_CONTROL_APP and PM_CONTROL_OS. Setting it to the default of _APP expects the user to provide a sys_soc_suspend() hook function. If you set it to _OS, then it expects the SoC support code to provide an "soc_power.h" header with a few functions to allow the OS to suspend as needed. The nrf52 SoC support code provides this header while the nrf91 currently does not.

I would seem to concur that the kernel does seem to properly support low power operation on the CPU.

Eric

[Bjørn Kvaale]

I believe the issue is the secure boot application. Could you please try to disable the serial drivers in the secure_boot application like explained here. The link does say that the application FW code is not fully customized for low power yet. We are working to make the examples as low power as possible.

Then, erase the nRF91, program the secure boot example first & then the application code.

If that does not work, I can recommend trying out this application code instead. This has been tested to give a current consumption of around 5 uA:

power_measurements.zip

[jrubis]

I am measuing around ~12uA after disabling the UART in secure boot and running the power_measurements application that you have attached. The Asset Tracker is consuming a few mA with PSM enabled. As you mention, I suspect that example is not optimizaed/working for low power at this time. 

[Eric Gross]

Thanks Bjorn,

I can confirm that with disabling serial completely in secure_boot and then running your attached example, I can hit a very low power consumption.

However, I have not been able to replicate the low power consumption when using the LTE modem in my own application. I have a few observations:

-When PSM is enabled, I see power consumption bouncing to 2mA every few seconds. It does not appear to work as expected. This is across a wide range of PSM timer values.

-When eDRX mode is enabled, I see power consumption drop significantly when idle (as compared to PSM mode). I am not hitting the same low value as your example which doesn't use the modem, but I see my power draw doesn't change much even if I turn the modem off. I suspect there is some unrelated CONFIG differences between enabled devices in my app and your example. I will dig into this further.

 Eric

[Bjørn Kvaale]

Hi Eric,

It seems that the 2 mA PSM power consumption could be the connected DRX (320 ms) mode that can be found in the PSM subsection in this link. Yes, please keep us updated if you manage to hit lower current numbers!

Also, I could recommend using the example I sent as a base & add functionality to that example. Every now & then, I would measure the current. That way, you are hopefully able to debug what is leading to the sub-optimal current consumption.