nRF51 power management for energy harvesting applications

[mnhs]

Hi,

as a university project, I am currently developing a ultra-low-power temperature and barometer sensor powered just by RF and laser-beam energy. Please see this link to read more about the whole system and how it works: hackaday.io/.../6243-rf-and-laser-beam-harvesting-for-future-sensors

I use TI BQ25570 as a harvesting chip. The amount of energy which I can harvest to the storage capacitor is tiny, the average current flowing to the capacitor is about 50 microamps - 470uF cap gets charged to 4.5 volts in about half a minute. The BQ25570 includes a buck converter which generates stable voltage for uC from the storage capacitor. Unfortunately, I can't connect the nRF51 directly to this supply, because it consumes a few mA's during start-up and init and discharges the cap very quickly.

What I need is to read one temperature and barometer sample using I2C and broadcast it using BLE non-advertising packets.

My idea is to design a simple nanopower supply management as following:

• the power managament will be powered directly from storage capcaitor with a maximum standby power consumption of microamp or two.
• at around 1.5 volts, the low-voltage comparator with reference and load switch will start working and start monitoring the storage capacitor voltage
• after the storage capacitor voltage is over let's say 4 volts (will be properly calculated afterwards), turn on the load switch and use the energy which is in the capacitor to init the nRF51 and broadcast a few packets
• if the storage capacitor voltage is under around 2.2 volts, turn off the load switch.

My questions are following:

• how to minimize the start-up duration of the chip and S110 stack? I use rev3 chips and internal RC 32kHz oscillator (I read in one post that the external 32kHz crystal may take up to one second to start) ? I won't be powering the nRF51822 at the lowest possible voltage - 1.8V, but with a bit higher, about 2.2 volts to avoid the delays in initialization.

• when I am thinking about it, maybe I could save some time by not using the stack at all. It is possible to send non advertising BLE packets using nRF24L01 chip:

dmitry.gr/index.php

This implementation would take a lot less time than the initialization of the stack, initialization of BLE broadcast etc, right? I am not targeting for certification, it is only an explorative project to prove the concept.

• I would welcome any other suggestions if I missed something.

Thank you in advance, Marek.

[Nenik]

Well, your bq25570 already does decent power management for you, it has an independent "battery voltage" comparator (vbat_ok) that you could use for your control needs. Then, with 470uf and limits of 4.7V VBAT_OV and builtin 2V VBAT_UV, you have over 1.2mC of charge available for your startup. And you can go even slightly higher with VBAT_OV

Perhaps if you structured your app to:

• Set really high VBAT_OK (4.5V)
• Upon power-up (boot after loss of power), immediately go to sleep and wait for interrupt from VBAT_OK connected to GPIO - this way, you'd build some headroom
• Preinitialize the LFCLK yourself, so even if it takes long, you're in a low power mode in between
• Then, wait for energy replenish again, sleeping in low power.
• Only when having all this energy, use it to initialize the soft device.

With the bq25570 dc/dc, 1.2mC at 4.7->2.2V would give you over 1.5mAs at 2V (milliAmpSeconds), that is, 1.5s runtime at 1mA, or 250ms at 6mA And once you're behind the initialization, you just sleep most of the time. 1.2mC is plenty of energy for sending few packets so you only need to moderate your off-time to avoid cold-boot.

LFCLK startup time might be up to 1s, but the consumption is small, so as long as you're able to preinitialize the LFCLK this way, you should be good to go.

Is my math wrong? Did I miss something?

[mnhs]

Thanks for this tip, I will make some more tests. I set the VBAT_OK to 3 volts, maybe it is just too low. When I tried to run the nRF51 going to sleep immediately after start-up, I had problems with high rise time of VDD from 0 to 2V - about 400ms, which probably negatively affected the start-up procedure.

I will return back in a few hours after testing higher VBAT_OK.