This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Understanding the power consumption of nrf9160 and Thingy:91

Using a multimeter and a Thingy:91 I've measured the current to

Environment

  • SIM-card: iBasis
  • Firmware on the nrf52840 is the one from the Thingy homepage.
  • Firmware on the nrf9160 is an app that goes into a long k_sleep's for 60s, then registers GPIO 26 with a edge-triggered ISR then k_sleep again (UART disbled and modem not initiated)

The nrf52840 only draws a very few uA - great!


The nrf9160 draws 35uA at first, but when GPIO gets registered it draws 115uA (GPIO triggering adds 80uA - a big percentage increase)
Question: Is there anything that can be done to lower power consumption when waiting for external input (the signal I'm waiting for is high for around 2 seconds).

Total consumption to Thingy:91 is 200uA first and 280uA when GPIO is registered.
Question: What is taking the 165 uA (200-35) ? SIM-card, MCU or some sensor that is enabled by default?

An observation: Starting the board without the nrf52840 increases the total power draw to around 400uA - IMHO indicating it disables some electronic components or performs some magic

Question: Is it possible to disable (preferrably via FW) everything except the nrf9160 and SIM?

  • Hi,

    What is taking the 165 uA (200-35) ? SIM-card, MCU or some sensor that is enabled by default?

    I think most of this is sensors. SIM card current is typically around 30µA when not in PSM mode.

    Is it possible to disable (preferrably via FW) everything except the nrf9160 and SIM?

    There are some configurations you can set to reduce the power.In prj_nrf9160_pca20035ns.conf,e.g. set

    CONFIG_POWER_OPTIMIZATION_ENABLE=y

    You can also try to replace the sensor configs with this in order to use simulated values.

    CONFIG_ACCEL_USE_SIM=y
    CONFIG_TEMP_USE_SIM=y

    You can also disable the light sensor with

    CONFIG_LIGHT_SENSOR=n

    and the UI module with

    CONFIG_USE_UI_MODULE=n

  • Thanks for your reply!

    Those settings however seem to be for the asset application only (I'm testing on a super bare bone FW).

    Can the sensors be disabled from the nrf9160 FW or do they need to be disabled from the nrf52840 FW?

    Regarding the SIM-card current, is it powered through the nrf9160? (I mean; is it accounted for when I'm measuring the nrf9160 current?)

    If a SIM-card takes ~30uA, how much would an eSIM circuit consume?

  • Hi,

    Is there any reason you set these 26 GPIOs as input in the "super bare bone FW" ?

    Since you are not using the modem here, did you set CONFIG_BSD_LIBRARY=n in prj.conf for the nRF9160 project ? (If set to n, SIM card should then not be enabled)

    Have you seen this block diagram ? The nRF52840 is not controlling the sensors.

    Jesper Tiberg said:
    Regarding the SIM-card current, is it powered through the nrf9160? (I mean; is it accounted for when I'm measuring the nrf9160 current?)

    It’s powered from the nRF9160(from the SIM_1V8 pin on the nRF9160), and it's accounted for. Have you seen the PCB schematics ? It can be download at this page. (Hardware description files)

    Jesper Tiberg said:
    If a SIM-card takes ~30uA, how much would an eSIM circuit consume?

    We typically see eSIM current consumption between 2-15 X the PSM floor current, i.e. between 5.5-40uA, depending on the eSIM used. 

  • Hi,

    Sorry for the confusion, I wrote GPIO 26 like in "GPIO index 26 which equals the button on the Thingy:91".

    I'm testing power consumption with this stripped down FW to get some sort of "basline" reading with different things (like GPIO) when disabled and enabled.

    In the actual project, a couple of GPIOs will be used and the modem will be in PSM but woken up a couple of times a day.

    A stand-by current of 30uA (without GPIO with modem off or in PSM) seem great.
    The question about the 80uA increase when enabling GPIO, if this can be lowered, remains... any suggestions?

  • Hi,

    Jesper Tiberg said:
    The question about the 80uA increase when enabling GPIO, if this can be lowered, remains... any suggestions?

     That seems high. Could you post the code you used to configure the GPIO?

    If you configure it to use level-triggering instead, what do you measure then ?

Related