Thingy:91X - quiescent current

[Achim Kraus]

Thingy:91X rev 1.0.0

NCS 2.6.2 own custom application

Quiescent current measured with PPK II and extension board:

nRF53x   2µA, OK

nRF70x   0µA, OK

nRF91x   17µA, OK

Quiescent current measured with PPK II and power plug/battery:

310µA, that's pretty high.

What else on the Thingy:91X drains the 300µA? Is it possible to switch it off?

[dejans]

Hi,

Quiescent current measured with PPK II and extension board:

nRF53x   2µA, OK

nRF70x   0µA, OK

nRF91x   17µA, OK

Quiescent current measured with PPK II and power plug/battery:

310µA, that's pretty high.

Can you show your measurement setup in each of 2 cases, similar to how it is shown in this ticket?
Which extension board did you use?

NCS 2.6.2 own custom application

Can you provide more information about your application? Is it based on any of our sample applications?

Best regards,
Dejan

[Achim Kraus]

> Can you show your measurement setup

There is nothing special, just use the new daughter board for current measurement of the Thingy:91X. Though those values are in the range expected by me, that should fit.

Then I replaced the battery by a JST 1mm 3pin and powered the complete device with that. My assumption would be slightly more than the sum of the 3 other values, but it's 20x more.

> Can you provide more information about your application? 

Sure, it's my zephyr-coaps-client

Anyway, my feeling is, we may exchange a lot of infos, but the real question is:

- what is the quiescent current of the Thingy:91X overall

- what must be disabled/enabled to get that

From a couple of other tickets around the quiescent current of several nRF91 based device, I would welcome an example, which demonstrates that and documents the numbers to be expected. Please, not the links to the other tickets. I know them. In a couple of cases I even answered them. 

Here it's about the new Thingy:91X and what to do and expect for that.

[dejans]

Hi,

The problem of driving around 300µA from VBAT might be due to improper initialization of BMM350. The fix was introduced here, but it is not part of NCS v2.6.2. You could either turn off ldsw_sensors or add the code shown below and testing if this fixes the issue.

#include <zephyr/device.h>
#include <zephyr/drivers/i2c.h>

#define BMM350_I2C_DEVICE  DEVICE_DT_GET(DT_NODELABEL(i2c2))
#define BMM350_REG_OTP_CMD_REG                      UINT8_C(0x50)
#define BMM350_OTP_CMD_PWR_OFF_OTP                  UINT8_C(0x80)
#define BMM350_START_UP_TIME_FROM_POR 3000

int bmm350_init_minimal(){
  k_sleep(K_USEC(BMM350_START_UP_TIME_FROM_POR));
  uint8_t otp_cmd = BMM350_OTP_CMD_PWR_OFF_OTP;
  i2c_burst_write(BMM350_I2C_DEVICE, 0x14, BMM350_REG_OTP_CMD_REG, &otp_cmd, 1);
  return 0;
}

SYS_INIT(bmm350_init_minimal, POST_KERNEL, CONFIG_SENSOR_INIT_PRIORITY);

As for the total current on the board, it depends on the configuration of the various regulators and peripherals as well as on the firmware running on controllers. Based on our internal testing, estimated current consumption should be around 13µA at 3.7V from VBAT in addition to what is used by MCUs.

Best regards,
Dejan

[Achim Kraus]

Thanks a lot! That's the solution. My app is now at 23µA.