Long-lasting battery solution


I’m building a humidity sensor that I’d like to report humidity/temperature every 2 hours or so. I’d like it to be small and run on battery - the battery shield is one option but I don’t like the shape of it and am looking for something smaller. If I use deep sleep, what kind of battery life can I realistically expect, and what kind of batteries would be best to use?


Battery life really depends on what type of battery you are using. 2AA batteries won’t last as long as a 20.000mAh battery pack for example.
By using a power bank, you can exclude the battery shield altogether. Actually, if you’ve got one of those, try that for testing, and then calculate the values you would get with an alternative solution. This way, you can check out the performance, before having to buy a battery shield ‘thing’.


@digitalex, the amount of battery life you get is very dependent on many factors. In deep sleep, the core uses less than 1ma of current but the power for your sensors need to be factored in. The core can consume 250ma when wifi/cloud is connecting. @BDub did some greate work looking at battery life in deep sleep mode on another topic. I agree with @Moors7 that a power pack may be better but you will need to experiment to see what kind of results you get. :smile:

UPDATE: The battery life work was actually by the amazing @wgbartley here:


I will assume that the sensor is outside or far from a power source?

How about a solar panel? I picked up one of these kits for $20 yesterday http://www.seeedstudio.com/depot/Seeeduino-Stalker-Waterproof-Solar-Kit-p-911.html


@paulscott56, good point! You can use a LiPo battery, a solar panel and Seedstudio’s LiPo Rider Pro to give a full power solution! :smile:


Thanks all. What exactly do you mean by “power bank” @Moors7? I was thinking a 2000mAh Lithium Ion battery like this one from sparkfun might provide enough power to run for a while. If you’re right about the 1mAh deep sleep consumption that would last long enough.

@peekay123 you say “the power for your sensors need to be factored in” - does that mean the sensor will still draw power from the spark core even when the spark is in deep sleep? If so, can I prevent that simply or do I need to do that ‘manually’ by using a transistor for instance?

@paulscott56 in my case the sensor will live inside a guitar case, which is why I’d like a battery that I don’t need to change/charge too often.


@digitalex, what @Moors7 means by power bank is one of those USB rechargeable power “cubes” for use with phones and such. As for the sensors, unless their current draw is small, you will need to manage them with a transistor as you mentioned.


Aha, yes that kind of power bank. I think I have one somewhere deep in a closet. I’ll try to test with that, good idea.


The power bank option does have some downsides: the ones I’ve seen have internal power consumption that can’t be turned off externally. Once the power bank is turned on, it slowly drains the battery even with nothing connected.

I’ve had good run times using either a lipo wired directly to the core, or better with just two AA alkaline batteries. Connect the sensor to a digital pin so you can turn off the sensor power when not needed (assuming it’s a 3.3v low power sensor). The deep sleep function can drop to less then 1ma (even less if you bypass the on board regulator).

digitalex presents some good data. Although I’m still experimenting, I’ve had a temp logger sending remote data for about 2 mouths on a single set of AA batteries. I’m sending every 15 minutes, so your app should do better. The key is switching off sensor power, using deep sleep as digitalalex explains, and sending data as quickly as possible since the most pwer is consumed during the wifi send.


@tbitson Has anyone provided schematics of how they were able to bypass the board regulator? Does this involve a different regulator, a capacitor, or an unregulated input voltage?

I’m also wondering if spark has provided the deep sleep draw for the photon. Thanks!


In my case I removed the regulator by unsoldering it, and then used the 3.3 volt input to power the core. Unfortunately, I did not measure the current before removing the regulator, so I can’t provide information if it really helps much. I made the assumption that there will be some current back flowing through the regulator.


That’s a good solution for a limited number of cores. Simple and smart. I’d really like to bypass that regulator without having to unsolder it, though. Also, for reference, there was another thread quite a while ago with some other folk’s measurements https://community.spark.io/t/findings-sleep-modes/2471/5

I also think that it may be helpful for others in the situation of needing long-life battery solutions to see a footnote at http://docs.spark.io/firmware/ that “In deep sleep mode, the Core current consumption is around: 3.2 μA” is true if you unsolder the voltage regulator. I have measured 180 μA when in deep sleep when powered by 3 AAs through the voltage regulator.

@zach can you please shed some light on the voltage regulator and configuration that will be used in the photon? I’d love to see a way to get a lower current draw from it without unsoldering (i.e. close to the published deep sleep current draw on the core). Thanks in advance!


Hey @mashandburn - if you’re interested in looking into how the Photon is configured, check out the Github design files:

The most significant differences to the Core are that we’re using a switching power supply and that the WAKEUP pin is exposed which will allow for much better low-power configurations.


I think Zach probably meant to say we are exposing the VBAT pin, which is more notable for low power systems than the WKUP pin, and in addition to that we will have a SMPS regulator with an exposed shutdown pin. The regulator will consume less than 0.1uA in shutdown mode, but the pull up resistor that will be on the Enable pin is likely to consume 5-50uA when the regulator is in shutdown mode. This enable input is not likely to be exposed on the header pins, but via an internal pad that you can solder to. The pull up resistor could be removed as well for really low power configurations that involve a hard switch, latching relay or other type of circuitry.


I am working with a new Photon trying to design a very low power battery operated system. Basically it should work like a door sensor where when the door opens, it should “wake up”, connect to wifi, wait for a second input, call a web service to send a message, then turn itself off. It will have long periods of inactivity so I really want to fully disconnect it to preserve battery. Also I have really tight physical constraints so a mechanical latching relay isn’t feasible. I have been fighting with a latching circuit using transistors to switch power to the Vin, then using D0 to break the latch. The problem is that sometime during the boot-up process(likely when the wifi turns on), the current draw spikes, and the voltage to Vin drops too far and the Photon restarts itself.

Occasionally (1 in 10 attempts???), it will get past that startup spike and enable wifi. Then setting D0 low breaks the latch and the circuit works. Unfortunately it will occasionally shut itself down before the second input -I can’t tell why. I think it simply is susceptible to RF, or random noise and I need a more robust approach.

So my question is - first, how would you recommend connecting a circuit to both turn on and turn off power to the Photon, and second, assuming you would use the SMPS enable pin, where physically on the Photon is the enable pad that you have referenced?

Here is the circuit I am trying:

where instead of switching a relay, I am switching Vin to the Photon and pin D0 on th ePhoton is connected between the base of T1 and ground(in the latch circuit). Input power is provided by 4 AA batteries although I would like to use 3 AAA batteries to save space.


You might want to take a look at this power switch by Pololu. You can add an external switch (door opening??) that turns power on to the Photon. Then you can turn it off, ready for the next cycle, using a Photon GPIO pin. Pololu also have a number of high efficiency boost power modules, allowing you to use 2 X AA, and still deliver a true 5V to Photon’s VIN.


Cutting power totally from a device and powering it only on external input is generally not ideal; this significantly reduces the functionality of a connected device, which then cannot check in on a regular schedule (so you know it’s still there, its battery is OK, and nobody has stolen it).

The Photon itself is a bit limited in that sense (1mA typical sleep current, ie 5mW), for a few reasons:

  • The RT8008 is a cheap PWM mode converter; it doesn’t have a light-load PFM mode (50uA even when not switching)
  • The VBAT input is not exposed, so you can’t run the always-on sections of the STM32 independently (eg coin cell)
  • The BCM43362 power is not gated, and this burns ~40uA even when wifi is off (6x that of the MCU!)

Mainly, this is due to the RT8008. If you pull that (so it doesn’t leak) and feed 3.3v from a better DCDC like the TPS62172 (3.3-17v input range) then you’ll likely be down to around ~70uA - almost 15x lower.

As a comparison, the electric imp, which has the same CPU and WiFi chip but a more power-aware design, takes <6uA when sleeping (RTC on, 4k SRAM preserved), which translates to ~25uA @ 5v with a TPS62172. A lower maximum voltage buck can get you down to well below 5uA @ 5v, depending on how much you’re willing to spend on power supplies.

Even lower sleep currents are possible from 2xAA if you use a boost converter which feeds Vin to Vout when disabled. You need to turn this on when you want to fire up wifi, and ensure your flash timings are set appropriately so that you wake from the 2xAA voltage (~1.8v). This gets you sleeping at ~6-7uA.

The electric imp Nora design (see https://www.electricimp.com/docs/hardware/resources/reference-designs/nora/ ) has some good circuit ideas for this including UVLO for the battery, the controllable boost converter, etc) - the design is open so feel free to crib bits of it as required. With an imp this gets ~2.5 years from 2xAA batteries when connecting every 15 minutes (YMMV depending on how long each wake is - that’s based on ~1.2s wake-associate-dhcp-dns-secure connect-exchange data-sleep cycles).


I just wanted to point out that while this was true for the Core it is not true for Photon.


Ah, ok - I was going by the Photon datasheet, which shows VBAT being directly fed by the RT8008 - see https://docs.particle.io/datasheets/photon-datasheet/ (first block diagram, bottom right).

External VBAT can help depending on your use case, but you need VCC up if you’re going to wake from the VBAT-powered RTC :smile:


Sure, that is a very “conceptualized” schematic. On the real schematic, VBAT goes to the VBAT pin with 0.1uF and 10uF caps to ground.

I think folks looking to deploy (rather than prototype) extremely low-power products should be steered toward P0/P1 modules on their own boards in the Particle universe. You have a variety of nice platforms and reference designs over in your Electric Imp universe (where you are the CEO I believe) too.