What is the current consumption between advertisements on the nRF51422 and nRF52832

[raphael]

According to the product specification of the nRF51422 the current between the advertisements is:

i_sleep = I_on + I_rtc + I_x32k

16k Ram enabled: = 2,6 µA + 0,1 µA + 0,25 µA = 3,1 µA

32k Ram enabled: = 3,8 µA + 0,1 µA + 0,25 µA = 4,3 µA

for nRF52832 this is:

i_sleep = I_on + I_rtc + I_x32k + RAM_rentention

i_sleep = 1,2 µA + 0,1 µA + 0,25 µA + 0,32 µA = 1.87 µA

In our own measurements with an amperemeter we got the following results (performed as described in devzone.nordicsemi.com/.../ and devzone.nordicsemi.com/.../) :

nRF51422: 3,78 µA

nRF52632: 12,5 µA

While nrf51 seems to be roughly in the range from the datasheet, the measurements of the nrf52 are far of the values from the datasheet. On the other side in devzone.nordicsemi.com/.../ a current of 14,25 uA is measured, what confirms the measurements we took.

This results in the following questions:

• Why are nordics and our measurements so far of the values from the datasheet?

• Has the nRF52 a such higher current consumption then the nRF51?

[Stian Røed Hafskjold]

The first thing you describe is the System ON IDLE current, and as you say this is between the advertisement packets. 3-4uA for the nRF51 and ~1.8uA for the nRF52 is correct. You can see from the plot in the tutorial that the System ON IDLE current on the nRF52 was measured to be 1.75 uA.

Im not sure where you get the 14.25 uA current from, but if you are referring to the 14.3 uA current in the tutorial, this is including an advertisement packet every 1000ms (@2V). Not only the IDLE current.

So to answer your questions:

• The numbers in the tutorial should be close to what is specified in the datasheet. If not please let me know which numbers you mean are wrong. If your measurements are wrong I suspect that you are picking up current from the advertisement packets. Or maybe you have some DC leakage currents somewhere. A nice way to check if you don't have any leakage currents and to see if the measurement setup is correct, is to put the chip in system OFF mode. (NRF_POWER->SYSTEMOFF = 1)You should then see some hundred nanoamps.

• The nRF52 has generally lower current consumption than the nRF51

EDIT 20.05.16

So the s132 v1.0.0 has included a few workarounds because of HW erratas from chip revision A. The v1.0.0 was released before revision B came out. Please see the compatibility matrix to see which chip goes to which SD/SDK.

The workarounds included in the softdevice involved always keeping RAM on in System ON IDLE, because of this erratum. And to keep power to the TIMER0 module in System ON IDLE, because of this erratum.

Please try with Softdevice s132 v2.0.0 if you have revision B (QFAABA) of the chip. It requires new softdevice header files, and a good place to start is with the newest SDK v11. (Alternatively you could try with just disabling the TIMER0 fix, as suggested in the erratum)

[raphael]

You are totally right, I missunderstood the 14.3 µA.

To make sure the advertising packets are not influencing the measurement we took a advertising interval of 8s. In this case we can clearly see the difference between sleep phase and advertising phase on the amperemeter. Also we cheked for leakcurrents by the method you mentioned. As expected the current is as low as 0.25µA with NRF_POWER->SYSTEMOFF = 1.

Anyways the measurement still shows 12.5 µA as sleep current which is far off the expected 1.75 µA.

[Stian Røed Hafskjold]

May I ask which chip revision you have? RevA: QFAAAA, RevB: QFAABA, RevC: QFAABB or Rev1: QFAAB0? In the first two engineering versions of the chip, A and B, a few errata caused the chip to consume more current in system on idle. As described in the tutorial posts you linked to. The production version of the chip does consume current as specified in the datasheet.

[raphael]

Yeah you are right, we use the nRF52 DK (nRF52832 QFAABA) in the Engineering Revision B. But in the Tutorial the same version is used. So I dont expect this to be the reason.

As Softdevice we use the s132 1.0.0-3.

And in the Software we disable the DCDC, since of the issues of the RevB:

sd_power_dcdc_mode_set(NRF_POWER_DCDC_DISABLE);

the softdevice initialization is done with:

SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_XTAL_20_PPM, NULL);

and the sleep state is started with:

static void power_manage(void)
{
    uint32_t err_code = sd_app_evt_wait();
    APP_ERROR_CHECK(err_code);
}

Maybe there is something wrong with the initialisation code. If needed i can post also the complete code.

[Stian Røed Hafskjold]

Please see the updated answer