nRF9160 sleep current to high

RE: nRF9160 sleep current to high

Étienne Castanié — Thu, 28 Feb 2019 13:56:10 GMT

Hi Bjørn, I'll do that right away thank you.

RE: nRF9160 sleep current to high

Bjørn Kvaale — Thu, 28 Feb 2019 13:18:56 GMT

Hi Étienne,

Could you please open a new devzone case?

RE: nRF9160 sleep current to high

Étienne Castanié — Tue, 26 Feb 2019 10:14:20 GMT

Hi Bjørn,

Thank you for this code. When we use it on our nrf9160 DK we hit 23 uA (uart disabled in secure boot).

This level of current consumption is pretty good, now we would like to test a mode where the device wakes up from this deep sleep mode (on a timer or a button push for test purposes) then send data over LTE-M in PSM mode then goes back to sleep (with the 23 uA consumption after sending the data).

Is there a working example of this kind of behavior available?

Thank you very much.

Best,

Étienne

RE: nRF9160 sleep current to high

Eric Gross — Wed, 30 Jan 2019 22:46:29 GMT

Hi,

I have tracked down a few leads by adding things back in:

-CONFIG_BSD_LIBRARY_TRACE_ENABLED=n is critical to getting low power on an "empty" application that just calls k_cpu_idle(). This is apparently not the default.

-Adding back in LTE connection (but nothing using it) shows very low uA-level power consumption when using eDRX mode. If I use PSM mode, it seems to idle at 1-2mA and never drops, even when timer should have long expired. I'm not sure how to interpret the power numbers listed in the link you sent regarding SIM on/off, etc. I don't seem to have control over any of this.

-After creating a TCP socket and connect()'ing it, power consumption increases significantly to the couple hundred uA level, even with no traffic and CPU asleep.This does not go away even after the socket has been closed. It is not clear to me how the socket offloading mechanism works, but maybe this is activating some feature that prevents the CPU from going to sleep. This is preventing low power consumption in anything using TCP. Note that UDP-based traffic (like performing a DNS lookup) did not appear to cause this continuous power draw after thr activity has stopped.

Eric

RE: nRF9160 sleep current to high

Bjørn Kvaale — Wed, 30 Jan 2019 11:55:52 GMT

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.

RE: nRF9160 sleep current to high

Eric Gross — Wed, 30 Jan 2019 00:04:17 GMT

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

RE: nRF9160 sleep current to high

jrubis — Tue, 29 Jan 2019 15:25:59 GMT

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.

RE: nRF9160 sleep current to high

Bjørn Kvaale — Tue, 29 Jan 2019 14:30:10 GMT

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:

devzone.nordicsemi.com/.../power_5F00_measurements.zip

RE: nRF9160 sleep current to high

Eric Gross — Fri, 25 Jan 2019 15:45:23 GMT

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

RE: nRF9160 sleep current to high

Karst van der Veen — Fri, 25 Jan 2019 11:33:27 GMT

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.

RE: nRF9160 sleep current to high

Eric Gross — Thu, 24 Jan 2019 21:53:30 GMT

Ok, I think I may have been a bit hasty in my original response. It was just user error that my serial port wasn't showing up, though definitely I get no output anymore since presumably the UART is disconnected.

The issue I was seeing with the socket(AF_LTE) call seemingly hanging appears to just be oddities with the step function in the debugger (since I was trying to validate what was going on without serial output)

One mismatch I am seeing with the instructions is that for the secure bootloader example, the UART items in the config simply don't exist. They do exist in the other application example and I did disable them, but see no change in power usage. Any idea why I am not seeing options to disable the UARTs in the secure_boot example?

Thanks,
Eric

RE: nRF9160 sleep current to high

Eric Gross — Thu, 24 Jan 2019 19:23:11 GMT

Hi Bjorn,

I have been following this as I have noticed the exact same issue as the original poster, with very similar idle power measurements.

I tried to follow your instructions. When I do, I see that the virtual JLink COM port for the console no longer shows up. I assume this means I can't have serial console output for debugging without it consuming 1mA of standby power?

Even this limitation aside, it appears to me that it just doesn't work. Calls to "socket(AF_LTE, 0, NPROTO_AT);" just hang now without the UART pieces enabled.

Am I missing something?

Thanks,

Eric Gross

RE: nRF9160 sleep current to high

Bjørn Kvaale — Thu, 24 Jan 2019 09:56:00 GMT

@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.

RE: nRF9160 sleep current to high

Bjørn Kvaale — Thu, 24 Jan 2019 09:52:14 GMT

We tested with another customer & were able to get the secure boot with an application down to 5 uA of current consumption in sleep mode.

It seems that the secure boot in the current implementation turns on UART & UART remains on when switching from secure boot to the application. What you can do is try to configure the secure boot & your example application to not use uart to see if that lowers the consumption. Still keep the PSM mode on naturally!

First, in the secure boot example, go to Build -> Configure nRF Connect SDK Project ... at the bottom. Then, open up Device Drivers -> Serial Drivers -> & uncheck everything related to UART:

Under console drivers, I would also uncheck "Use UART for console".

I would then do the same for your application. Then, erase the nRF91 board (nrfjprog -f nrf91 --eraseall), compile both examples & program them to the board.

Then, you should be able to see lower current consumption.

We have noticed a few issues with the Project Configuration settings in SES, so if that did not work, I would try disabling UART via menuconfig instead.

RE: nRF9160 sleep current to high

kalslebub — Wed, 23 Jan 2019 22:30:40 GMT

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.

RE: nRF9160 sleep current to high

Karst van der Veen — Wed, 23 Jan 2019 09:06:33 GMT

We have tried everything you said here, but we cant get the current consumption low enough.

What is the lowest current you can get if in sleep? We are, with the asset tracker sample, at lowest drops about 1mA or higher. We also tried to put the device to sleep ourselves where we got about 700uA which is still to high.

We hope to get the consumption lower then 20 uA, if possible.

I hope you can help us out.

RE: nRF9160 sleep current to high

Bjørn Kvaale — Tue, 22 Jan 2019 14:41:21 GMT

Did you notice a change in the current consumption with that?

Have you taken a look at the power optimization chapter here & implemented the eDRX or Power Saving Mode?

I would start with Power Saving Mode, as it seems eDRX may work depending on the carrier you are using.

It seems you can set the PSM either via the code itself (see here), or via AT commands (see here & here). If you want to do it via the AT commands, I would suggest to either run the AT Client example or include the AT client example functionality in the asset tracker example.

Please note that there is an active time after connection before we can enter PSM sleep, i.e. power consumption stays on the “idle DRX” level before we move to “PSM level”.

You may need to wait a few minutes until the nRF91 reaches PSM current level. You can see the value for this timer with the negotiated PSM parameters. Use the AT+CEREG=5 command to "subscribe to unsolicited network state notifications". Take a look at the AT Commands PDF for more info.

If you ask me, it seems easiest to set the PSM in the code directly in the asset tracker example. Then, I would measure the current consumption after a few minutes when the PSM mode kicks in.

Otherwise, you could also run the at_client example, set the PSM via the link monitor application & the at commands & then measure the current of the at_client example.

Also, make sure to keep in mind that the debugger prevents the modem from entering deep sleep. At the moment, you cannot check the sleep level of the modem from the application side.

Hope that helps!

RE: nRF9160 sleep current to high

Karst van der Veen — Mon, 21 Jan 2019 14:27:45 GMT

Thank you for your reply, I have tried this, but unfortunately without luck.

Could it be that some functions stay active when put to deep sleep mode?

RE: nRF9160 sleep current to high

Bjørn Kvaale — Mon, 21 Jan 2019 12:13:07 GMT

I believe this case could be helpful.