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

nRF51 power management for energy harvesting applications

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.

Parents
  • I'd stick with the nrf51, but you might try skipping the softdevice entirely and just build the packet manually and write it out to the radio. I think there is a github project of someone trying to do a opensource BLE stack for the nrf51. I'd imagine they got far enough along to advertise.

    If you are only advertising then you most likely don't need the external crystal (you don't need to stay in sync with the connected central).

    I started working on a sensors + BLE + energy harvesting project (tiny solarcell + linear tech energy harvesting chip). For that application it wanted to collect data all the time and only turn on the radio when it had energy to spare. It never got past the design document stage because for it to be useful it really needed a mesh network not BLE.

Reply
  • I'd stick with the nrf51, but you might try skipping the softdevice entirely and just build the packet manually and write it out to the radio. I think there is a github project of someone trying to do a opensource BLE stack for the nrf51. I'd imagine they got far enough along to advertise.

    If you are only advertising then you most likely don't need the external crystal (you don't need to stay in sync with the connected central).

    I started working on a sensors + BLE + energy harvesting project (tiny solarcell + linear tech energy harvesting chip). For that application it wanted to collect data all the time and only turn on the radio when it had energy to spare. It never got past the design document stage because for it to be useful it really needed a mesh network not BLE.

Children
No Data
Related