Quiescent current seems to depend on VBAT (v5)

AchimKraus

I did some current measurements, but the quiescent current was changing and changing. I considered a lot, but finally, my experiments shows, it depends a lot from the battery voltage. Are you aware of that? Using the PPKII as power source it’s quite easy to verify that.

3.50V => 25µA
3.60V => 19µA
3.85V => 17µA
4.00V => 21µA
4.06V => 36µA
4.14V => 70µA

jaredwolff

Hey AchimKraus, the current will vary for sure. It also depends on the usage of your board and what you’re doing at that time. What are you running as firmware? Anything beyond NCS 1.9.x is untested/unverified.

AchimKraus

Hi Jared,

the current will vary for sure.

But I would not assume, that it varies with the same “sleeping” software, but at slightly different voltage levels. At least not in that range.

I setup a second box to run your tools and projects closest possible.
I use https://github.com/circuitdojo/nrf9160-feather-examples-and-drivers.git in version 1.9.1 , I build the “sample/active_sleep” (the patch seems not longer matching nor required for v2.7.99-ncs1-1).
Using the Nordic PPK II in power source mode (GND and VBAT), I get different results (I guess, the sample is not completely up to date with ncs 1.9.1):

3.6 V => 200µA
4.0V => 200µA
4.1V => 470µA

Also a test with my own app (using ncs 2.1.2) results in a similar behavior (values of my first comment). It seems to have a “significant consumption step”, if 4.1V is reached and exceeded.

jaredwolff

Let me double check on my end and I’ll get back to you.

jaredwolff

Doing a quick test this is what I got withactive_sleep on both 1.9.x and 2.2.x. I’ve only tested at the lipo voltage range (3.6v typ).

While the >= 4V is a bummer, it’s working as expected at the typical operation ranges. AFAIK it seems to be a limitation of the switching regulator. Unfortunately not much I can do about that other than provide an ideal < 4V to the regulator.

AchimKraus

Just to check, because my “active_sleep” build is far away from your numbers, is a pre-compiled bin available?

(I found some precompiled samples in https://docs.jaredwolff.com/files/nfed_v1.7.x_e946e5c.zip , but these are too old. The github docu-repository also doesn’t contain newer ones.)

jaredwolff

Hey AchimKraus

Yes, the samples do get built with CI. Here’s the latest one that passed: (go to the very bottom for assets)

https://github.com/circuitdojo/nrf9160-feather-examples-and-drivers/actions/runs/3914555142

Here’s a download of what I was working with. Should be very close if not the same.

https://community.jaredwolff.com/assets/files/2023-01-19/1674147599-123728-v19x-g4067430.zip

AchimKraus

Thanks, using the “merged.hex” and jlink, I still get values of about170µA, measured using GND and BAT to source the device.
Anyway, thanks.
(The app, I want to use, reaches lower numbers, so it’s OK for me).

jaredwolff

Interesting. Is your board standalone or does it have something connected to it?

AchimKraus

Standalone, no external components. Just the PPK II on GND + BAT.
Using a different app, it goes now down to 12µA/3.6V,
modem in psm,
uart, lis2dh => suspended,
i2c, spi => active
mcu in k_sleep().

(3x times less than I reached with the Thingy:91.)