Thingy:91 and current consumption

RE: Thingy:91 and current consumption

Achim Kraus — Sat, 12 Nov 2022 07:26:24 GMT

> I'm not entirely sure what consumes this extra current on the 3.3V domain, but yes, it could be the GNSS PA.

I compared the schematics of 1.5.0 vs. 1.6.0. From the changelog:

> Power optimization, added circuitry to turn off RF switches when not used

v1.6.0 adds a "RF frontend power switch" (TCK106AG), which seems to doe the job without switching off the 3.3V.

RE: Thingy:91 and current consumption

Achim Kraus — Wed, 26 Oct 2022 08:16:19 GMT

You're welcome.

RE: Thingy:91 and current consumption

ArmNewbie — Wed, 26 Oct 2022 08:01:17 GMT

Thanks Achim Kraus , this works as a charm!

Switching off the 3.3v during LTE sleep removes the excessive ~150uA seen on the v1.4 Thingy!

RE: Thingy:91 and current consumption

Achim Kraus — Tue, 25 Oct 2022 12:47:19 GMT

There are callbacks on modem events.

in prj.con add

CONFIG_LTE_LC_MODEM_SLEEP_NOTIFICATIONS=y
in the code:
static void lte_handler(const struct lte_lc_evt *const evt)
 switch (evt->type) {
      case LTE_LC_EVT_MODEM_SLEEP_ENTER:
         lte_power_management_3v3 = false;
         // switch off
         break;
      case LTE_LC_EVT_MODEM_SLEEP_EXIT:
         lte_power_management_3v3 = true;
         // switch on
         break;
}
...

 lte_lc_modem_events_enable();
 err = lte_lc_connect_async(lte_handler);
switch off/on must be implemented.
Hope, the snippet helps.

RE: Thingy:91 and current consumption

ArmNewbie — Tue, 25 Oct 2022 08:32:23 GMT

Thanks Achim and Stian, I'm now able to control the 3.3v from the ADP536 via I2C. Nice!

But where to "hook in" when the nRF9160 is going in/out of sleep?

RE: Thingy:91 and current consumption

Achim Kraus — Mon, 17 Oct 2022 11:20:21 GMT

> #define ADP536X_I2C_DEV_NAME DT_LABEL(DT_NODELABEL(i2c2))

Unfortunately, NCS 2.1.0 breaks that API of NCS 2.0.0, see NCS-2.1.0 - CONFIG_ADP536X_BUS_NAME not longer valid?

It's now "DEVICE_DT_GET(DT_NODELABEL(i2c2))" and not longer configurable via Kconfig.

If a Thingy:91 is used, the "adp536x_init(ADP536X_I2C_DEV_NAME);" is not required, it's called during the boot.

RE: Thingy:91 and current consumption

Achim Kraus — Mon, 17 Oct 2022 10:08:27 GMT

> Of course, some of the sensors which are powered from the 3.3V domain will not work

Especially the LEDs will not work.

I switch 3.3V only off in the quiet-phase. In order the reduce the on-flank, I also adapted the Soft Start Time to 512ms. It looks like the LEDs "dim on".

If switching off 3.3V for newer Thingy:91 is not required, is there a API to check the board-revisions?

RE: Thingy:91 and current consumption

Stian Røed Hafskjold — Mon, 17 Oct 2022 09:56:19 GMT

Hi,

I check the difference between version 1.6.0 and 1.0.0, and I see the same thing.

I tried turning off the 3.3V regulator, as Achim suggested, and the current on 1.0.0 now matches the current on 1.6.0. I'm not entirely sure what consumes this extra current on the 3.3V domain, but yes, it could be the GNSS PA. I will investigate a little bit more to be sure, and let you know.

If someone is wondering; the 3.3V output on the ADP536 can be turned off through the I2C interface, which is already wired to the nRF91.

Add the following to main.c:

#include <adp536x.h>
#define ADP536X_I2C_DEV_NAME    DT_LABEL(DT_NODELABEL(i2c2))

void main(void){
    adp536x_init(ADP536X_I2C_DEV_NAME);
    adp536x_buckbst_enable(false);
    
    .....
    
}

The i2c2 interface should already be configured with the right pins if you compile for the thingy91 board.

Of course, some of the sensors which are powered from the 3.3V domain will not work

RE: Thingy:91 and current consumption

Achim Kraus — Wed, 12 Oct 2022 07:23:22 GMT

Just to mention:

I run Thingy:91s from 1.0.0 to 1.5.0. Disabling the 3.3V on a 1.0.0 results for me in ~40uA. With enabled 3.3V I get also the ~200uA.

In the meantime, I switch the 3.3V on, when the Thingy:91 is active, and off, when it sleeps.

From the schematics, the 3.3V are also used for GNSS, but I don't use and the GNSS has anyway it's own consumption which requires to limit that ontime as well.

RE: Thingy:91 and current consumption

ArmNewbie — Tue, 11 Oct 2022 09:09:51 GMT

Hi Stian, and thanks for good and informative hints!

I've done some "research" against our sim provider, and we are now successfully running PSM (against Telenor).
The 640ms spikes we saw earlier was due to eDRX as you assumed.

Reading some of the other answers as you suggested, and are now running without logging via UART, and we now see an idle current of 20-40uA running the asset_tracker_v2 on the Thingy 1.6.
Which is good!

However, we also have a couple of Thingys of version 1.4.0, and those show and idle current of ~200uA running the exact same FW.
Is it expected that the v1.4 has so much higher idle current than the v1.6, and what might be the cause of that?

Thanks!

-Alf

RE: Thingy:91 and current consumption

Stian Røed Hafskjold — Tue, 04 Oct 2022 08:57:20 GMT

Hi, the 600 uA base current is probably because of the logging module which uses UART. Please have a look at my answer in this thread, which explains how to turn off the UART in the LwM2M sample. It should be similar in the asset tracker sample.

The ~630 ms (which I believe should be 640 ms) spikes could be DRX paging. I'm thinking that the modem does not enter PSM mode, and continues in RRC idle mode, aka. eDRX, iDRX, etc. In the online power profiler you can simulate this by turning off PSM, and set the iDRX interval to 0.64. Of course this assumes that you are getting these spikes after a successful connection to the network. Is that correct?

Please have a look at this guide for more information regarding how to check if the network supports PSM or not: Getting started with current measurements on the nRF9160

The guide suggests using either the UDP example, or AT commands directly to check the network status.

A quick note about the UDP sample; it has UART logging disabled by default in order to demonstrate a power optimized application, and to fit the numbers in the online power profiler. In order to see the network connection status log output, you need to turn on the serial module by changing CONFIG_SERIAL to =y in the prj.conf file. Now you will also see that the current consumption increases by around 600 uA, which matches your initial measurements of the asset tracker application.

Best regards,
Stian