Spark Battery Life Testing

Social Project Share
1

I have been testing running Spark Cores on battery power to get a feel for its real-world, 100% untethered potential.

The test battery is a 3.7V 600mAh LiPo battery. I have actually been running a few Cores simultaneously on their own batteries, so each battery may not be exactly 600 mAh, but I think they’re all reasonably close. Testing is still on-going, but I think I have enough results for people to take interest. All Cores are u.Fl antenna unless otherwise noted. There are no additional peripherals attached.

The test code uses TCPClient to make an HTTP request to my server. The server then records the timestamp of when each test connects. I have put a sample of the Spark firmware in this gist. Note in the firmware that I have put a delay(5000); before the TCPClient HTTP request. It seems like much less of a delay causes the client to just hang and never make a server connection. I did not have this problem in the Cores that did not go into deep sleep mode.

I will update this post as I get more results.

Test 1: No sleep. 60-second update interval.
Average real interval: 63 seconds
Total approximate uptime: 2 hours, 33 minutes, 28 seconds

Test 2: No sleep. RGB LED disabled. 60-second update interval.
Average real interval: 63 seconds
Total approximate uptime: 2 hours, 24 minutes, 52 seconds

Test 3: Deep sleep. 60-second update interval.
Average real interval: 81 seconds
Total approximate uptime: 10 hours, 50 minutes, 40 seconds

Test 4: Deep sleep. 60-second update interval. Chip antenna
Average real interval: 78 seconds
Total approximate uptime: 11 hours, 52 minutes, 59 seconds

Test 5: Deep sleep. 120-second (2 minutes) update interval.
Average real interval: 141 seconds
Total approximate uptime: 19 hours, 48 minutes, 4 seconds

Test 6: Deep sleep. 300-second (5 minutes) update interval.
Average real interval: 320 seconds
Total approximate uptime: 1 day, 22 hours, 17 minutes, 51 seconds

Test 7: Deep sleep. 600-second (10 minutes) update interval.
Average real interval: 698 seconds
Total approximate uptime: 4 days, 1 hour, 20 minutes, 37 seconds

Test 8: Deep sleep. 900-second (15 minutes) update interval.
Average real interval: 922 seconds
Total approximate uptime: 1 week, 1 day, 7 hours, 1 minute, 42 seconds

Test 9: Deep sleep. 1800-second (30 minutes) update interval.
Average real interval: 1827 seconds
Total approximate uptime: 1 week, 3 days, 15 hours, 44 minutes, 36 seconds

Test 10: Deep sleep. 3600-second (1 hour) update interval.
To be determined.

A total approximate uptime followed by a + means the test is still ongoing.

As you can see, I have not started the final test yet. I may go beyond 10 tests, but I will not commit nearly as many resources to them. I’d like to use these Cores for other projects!

To view a full breakdown of the current statistics with pretty graphs, check out http://spark.wgb.me/battery-stats. The statistics on that page generate the data from the live log files, so the data is real-time. Thanks goes to @poiju for doing the standard deviation stuffs!

11 Likes
2

@wgbartley, great work! If we can get the core to wake with an even-driven interrupt we could bring that power down a lot I bet. I have also been considering using a small FET power gate for the 3.3V peripherals so that just before the Core goes in deep sleep, all the peripherals are turned off as well. :smile:

1 Like
3

I should also note that there are no peripherals attached so as to not skew the results.

4

@wgbartley, I knew that :wink: I just wanted to highlight that sensors, etc. can drain the battery as well and need to be considered in the final equation :smile:

1 Like
5

great stuff! im actually pleasantly surprised with the performance.
some intelligent sleep scheduling / good interrupt wakeups and we might have a good long term battery based option for certain projects…

1 Like
6

I’m thinking of finding some way to breakout the Vbat on the STM32 given the interest for low power applications?

Sounds good? I can look into the board design!

1 Like
7

As an FYI for the interested, the uptime of a LiPo will be shorter in colder temperatures, so some insulation is never a bad idea.

8

Did a check to see if what i wanted to do was feasible.

Seems like we have not much access with various layers overlaying the Vbat pin and it’s also underneath the CC3000

Att

9

There was some discussion about trying to tap into VBAT a while back. I think @BDub mentioned using power tools at some point. @timb also mentioned bringing out VBAT in the CFOD thread.

CC3000 “deep” control
Bug bounty: Kill the ‘Cyan flash of death’

10

VBAT is pin 1 of the STM32, and it's technically under the CC3000 ... but on the bottom side of the board :slight_smile: So you can very easily just lift the pin with an exacto knife while heating with a soldering iron. Normally when the pin is down it's attached to 3.3V. With the pin lifted, solder a 30awg wirewrap wire to it and strain relief the wire and connection by supergluing the wire to the top of the STM32. Then bring the wire out to wherever you need it.

Ideally this needs to be jumped and broken out to a nice pad on future revisions of hardware... with some other stuff to help make it easy to use. There is another thread that talks about low power stuff where we discussed this before:

1 Like
11

Great work!

Didnt someone on hear build a circuit board for the Spark Core that allows you to hook up a Solar Panel for charging?

12

Interest and great information, thanks for doing these tests. Interesting than Test 8 and 9 lasted way way less than Test 7 which was waking up more often.

13

Those are still on-going. I need to document the "+" after each uptime.

14

@timb is working on a battery/solar shield as we speak :smile:

15

I wound up buying a USB / DC / Solar Lithium Ion/Polymer charger from Adafruit for $17.95 to hold me over until @timb can finish up his shield. I’m hoping @timb’s version will be cheaper!

16

Thanks for the clarification :blush:

17

I don’t know if anyone else has noticed it, but as the sleep durations get longer, the average real interval (actual averaged time between updates) gets closer to the intended sleep duration. But with the 1800-second sleep duration, I’m getting a shorter real interval. Is there a sort of cap on this sleep? Would it be better to do back-to-back Spark.sleep(SLEEP_MODE_DEEP, 900) instead of Spark.sleep(SLEEP_MODE_DEEP, 1800)? I expect the real interval to be longer since it has to wake up, establish wifi connection, establish cloud connection, delay(5000) and finally post the data. I don’t imagine that process would get any faster or more efficient with longer sleep durations.

I just re-read the Spark.sleep() docs, and it restarts my user code from the beginning, so it’s actually a delay(5000) in setup() and another delay(5000) in my httpGetRequest() function. If I took out that extra delay, I could probably squeeze even more time out of it. I don’t even want to think about starting all of this over from test #3. :cry:

EDIT: I just realized that you can’t do back-to-back deep sleeps since it restarts the user code from the beginning unless I try to keep state in the EEPROM. Hrmm…

1 Like
18

I have been conducting slightly less scientific battery tests for my weather station project:

I pushed some updated code to GitHub over the weekend that reads the sensors once every 15 minutes and puts the core into a deep sleep for everything in between (around 14 minutes sleep time per loop which allows for re-connection after the core reboots and flashing the core if I want to update it). My battery is twice the size (1200mAh) and I disabled the onboard LED to save some extra juice. I also have sensors attached which are drawing extra power.

It just gave up after starting it on Sunday night. My total uptime is 1 day, 10 hours and 30 minutes (34.5 hours) which I am fairly pleased about but are perhaps a little shy of your tests at the moment. I am hoping this should be plenty with the right solar panel.

1 Like
19

For me, the onboard LED power seems negligible. It made a whopping 9 minutes of difference, at least on the no-sleep tests. I expect test #7 (10-minute sleep) will run out of juice today, but it has far exceeded my expectations. I have my solar panel, battery, charge board, etc all lined up to do some solar testing. I plan on deploying it as a semi-production setup since it could be a long, long time before it stops sending updates at expected intervals. I just need to get my sensors all lined up (conflicting I2C addresses, enabling/disabling power to sensors, etc) and an enclosure built.

How do you plan on handling getting sunlight to the lux sensor without super-heating your enclosure and throwing off the temperature? Any plans for isolating the DHT22 away from the Core? Basically, do you have an enclosure idea picked out yet?

1 Like
20

@wgbartley I am amazed at how long you are getting off your battery. This test seems particularly good:

I guess it comes down to differences in code and perhaps the draw of the additional components. In theory I should be able to get around 6 days+ from my battery of twice the size.

I have a few plans for the case. I am planning to recycle an old food tin, spray paint it and create a platform inside for the electronics. This will be attached to a shed and hang on its side via two straps. The DHT22 will be external (under a small lip in the shed roof). The light sensor will be internal but point towards the sky. Any holes drilled into the tin will be sealed with some sugru or glue to weather proof it. Hoping the spray paint will keep the majority of the rust away but may end up having to move to a plastic case when the weather turns again.