Boron - One Year Battery Life Project


Thank you for pointing out very interesting. My devices are in parks and many don’t have great signal so I suspect I will need a much bigger battery than a coin cell. Still, the idea of connecting directly to the 3.3V rail is interesting.


I was just doing the back of the envelope calculations for an CAT M1 battery deployment. The killer is how long the Boron may take to connect to the LTE network. In my experience this is anywhere between 15 to 25 seconds. Average current is around 250mA but it’s usually very spiky. Surprising when you see it plotted out. See below:

That means you’re using about 1.388mAh (20sec/60/60*250mA) of energy every time you publish. As @rickkas7 points out in his calculations depending on the data that will dictate time spent with the modem on.

Multiply that number by 16 * 365 and the gets us to 8105.92 mAh. That’s a conservative number too. When you start factoring environmental (the colder it is, the less capacity) you could need upwards of 10Ah. You could go with a Li-MnO2 cell. They have similar self discharge capabilities but don’t need any extra super caps to augment the high internal resistance of the Li-SOCl2. Li-SOCl2 are tough for LTE deployments because you’re right at the cusp of the cell not being able to handle the transmission current.

Connecting to the 3.3V rail only works for the Xenon. The Boron has two rails so you’d need to run the battery through the onboard power management no matter what.

1 Like

@chipmc, here is a link to another post that originally started off related to battery powered long term deployment of Borons and optimization of their cellular usage, but also included some great testing related to the power usage as a result of the optimizations: Boron - High Cellular Usage. Please note that this stragety was being developed before Particle rolled our their sleep functionalities.



@jaredwolff, a strategy that the community helped develop was pulling up the cellular connection and not executing the Particle.connect() function. It appears that the Particle.connect() is where a lot of the 15-25 seconds is spent. This strategy inherently means that the device does not check in with the cloud, but there was talk of developing a flag system that would allow the system to do one cloud check-in per day to check to see if the user is trying to grab it for an update, etc.

As cellular time is the vastly more power consuming task, I usually think of it as in how many connections can be achieved with a setup.

Yes, it would take a lot of saved uA’s by cutting off at the LiPo (VSYS needed) instead of using Enable pin, to extend operating time with just one more connection.

Great discovery. Reduced online time is really effective in prolonging operating time (or number of connections), and for most longterm scenarios.

@chipmc, I’ve discussed a 1 year of run-time @ a 2 hour publish schedule for a Boron LTE using the EN pin, AA batteries, in this post/thread. The actual Stress Test concluded at 10,000 Wake & Publish Cycles using (3) AA Batteries. The Cycle time was 12-14 seconds for the 10,000 Events.

Summary: A power budget for my location would be calculated using any publish schedule (1 mWh each publish) and the Quiescent current of 7.5 mWh per day. Note: The 1 mWh per Startup/Publish Event will likely be reduced if not Connecting to the Particle Cloud each cycle, by pushing data directly to your backend service (as @Backpacker87 did with Ubidots to minimize Cellular Data on each Event).

As far as I know, you just need your carrier board to store the Count from your motion sensor, and cleared after each Boron Wake Cycle/Publish.

Trial #1 in the same thread used a 0.5W Solar Panel, that only cost a few dollars. It’s smaller than the breadboard that Particles ship with (for a physical size reference). That was 1 year ago (and several firmware versions), but the Boron still re-charged the LiPo while Shutdown via EN Pin. I haven’t confirmed that for 1.4.0.

Depending on the # of Motion Sensor Events that actually occur in a day at your locations, a simplified version (no carrier board) might be applicable with a small panel. The Motion sensor can trigger the TPL to wake the Boron and report each Event directly (simple test here), especially considering the Cellular Data Reduction that @Backpacker87 reported.

Side Note: In my opinion, it makes more sense to track the mWh, not mAh.
In Low-Powered Applications, we are dealing with the entire voltage range of the battery source.
The mA change drastically across this voltage range, the power (mW) doesn’t.

For this kind of simple design, I have been wondering lately what would be the cheapest HW option external to the Boron to store a cycle count (0-255) in a low power design, preferably a chip you need anyway.

There is another thread proposing an ATTINY85 as the external low power device - it has 4 I/O. One could count Motion pulses, one could wake up the boron, on a count threshold or even a timer, via EN or via a mosfet to turn the Boron off between reporting cycles. The boron could turn itself off via a third Input I/O on the ATTINY85 (DONE pin). Sort of a WD and I/O pre processor combo that you could put into sleep mode and achieve much greater power economy



That is a great idea. One way to accomplish this would be to share the FRAM memory between the ATTINY and the Boron. I have done this on another board and the “multi-master” approach worked surprisingly well.

The ATTINY would wake and store the count and timestamp in FRAM. Then, it could wake the BORON who would take the data out of the FRAM and sent it via Webhook.


+1 to above.
@chipmc is a man that can make this happen :crossed_fingers:
He’s already proven it in the past with his Boron Carrier Board :smirk:

OK, so let’s just start with a baseline. Over the next week, I will monitor a Boron with the following characteristics:

  1. Naps 16 hours a day (System.sleep(intPin, RISING, wakeInSeconds))

  2. Sleeps for 8 hours a night ( System.sleep(SLEEP_MODE_DEEP,wakeInSeconds))

  3. Wakes for counting events. (checks for debounce, counts and writes to FRAM)

  4. Reports using a webhook every hour. Payload:

  "hourly": "{{hourly}}",
  "daily": "{{daily}}",
  "battery": "{{battery}}",
  "temp": "{{temp}}",
  "resets": "{{resets}}",
  "alerts": "{{alerts}}",
  "maxmin": "{{maxmin}}"
  1. Suffers from not very great cellular coverage ( LTE: Signal Strength :40%, Signal Quality:12%)

Sound like a reasonable way to refine the rough assumptions that @rickkas7 has in his estimation tool?

After a few days, we should have a better idea of what a reasonable battery capacity should look like.

Comments / Suggestions welcome.



No suggestions here. The best way to gauge your battery life is to test it in the real world! :slight_smile: Our fake numbers always beat the real ones. Especially if you have the coulomb counter in place.

1 Like

That is what I would do, knowing that the system will behave differently near low bat, depending on the type.

Next experiment could be to send data directly to the end server every hour, skipping the Particle cloud except once per 24h.

1 Like

Update - I have been running the coulumb counter for a few days now and have some initial results.

One change, since I did not yet implement the external real time clock on the Boron carrier board (that is another thread) I am only using the System.sleep(intPin, RISING, wakeInSeconds); command and am reporting every hour 24 hours a day.

So, how did we do?

Running for 68 hours, we used 159mAH of battery or 2.33mAH per hour. If we were to run at this rate for a year, we would need a battery with 20,500mAH of capacity. Given the “D” sized LiSOCL2 battery from Tadiran has 19k mAH capacity, costs $20 in qty 1 and can support a pulse current of 500mA, putting two of these in parallel seems like it could work.

There are a few extra factors to consider.

  • There is a lot more I can do to improve power consumption (deeper sleep with a RTC, turning off LEDs, Reporting for less than 24 hours in a day…)
  • Temperature effects. These batteries have a large operating window -55 ºC to +85 ºC but, the voltage drops with temperature so a 100mA current draw at 0ºC will reduce the voltage to 3.0V which is below the recommended LiPO voltage for the Boron. So, I will next insert an efficient boost converter to ensure we always meet the devices expectations. I am thinking about using this one from Pololu and setting the output to 4.0V. The small delta between Vin and Vout means we will get about 85% efficiency.
  • If I put the boost converter in line with the batteries, I will need to add an analog line to the input to sense the battery voltage under load. I have an application note from Tadiran showing how this can be done but I need to get their permission to share. The discharge curve for these batteries is very flat so, this indication will be “hey, you have less than 10% of battery power remaining - switch out battery in the next couple weeks or else” variety.
  • I am also thinking about a low power data collector that would service the sensor interrupts and store data in a shared FRAM chip. Then, the external device would wake the Boron from deep sleep to send the data. Want to see if I can get there without additional hardware first however.

So, the bottom line is that there is a solution that looks promising, two Tadiran “D” cells in parallel, connected to a boost converter and with a low voltage analog sensor. The issue here is that the batteries are large and there is a $40/year battery cost. I would like to see if I can get this down to only needing one cell for cost and size reasons.

To be clear, there is a lot more testing to do here. At this point, I am just trying to get a feel for the viability of the approach. I will share more as this moves forward. Also, as it gets cooler in Raleigh, I plan to move these tests outdoors.

Please let me know what you think and give me your thoughts on this approach.




This thread is great, I am trying to get my head around this low power stuff. Although I am stuck with 3G for now :frowning:

For reading the voltage over the boost, I settled on a voltage divider with a FET. I am curios how Tadiran implemented it. (if allowed to share of course) The FET allows the divider to be “disabled” when sleeping to stop it from leaking power.

Also if looking for a buck/boost to embed, I had some success with the tps610995. Most of my problems came from a bad layout, but after a few bodge wires I was getting 200uA-300uA deep sleeps with an electron. (some of that was my board)

here’s an approximate schematic

^ very limited testing on this

Wow, thank you for that. I have some experience with the TI switchers and your circuit looks like a great approach. I just looked at the Datasheet for the Boron and realized that none of the pins are 5V tolerant so your suggestion for a voltage divider is a very good one.

I do find the TI QFN with powerpad somewhat painful to solder so I am open to other options. But, this chip seems perfect so I will layout a board once I validate the approach with the Pololu module.

As for the stuck with 3G part, have you tried the Electron LTE?



Exactly, I wanted to be able to run it off the lipo for testing (why burn primaries when testing) as the electron’s ADC top end is 3.3V. I can’t find it explicitly in the boron datasheet but I think it’s a safe assumption that it’s the same for the boron. Although assumptions can make an ass out of me and you :slight_smile:

Ya it is a tiny little guy to solder. A stencil and hot air seemed to help a bit.
But definitely let us know if you find a different boost!

I’m a small fish, with a few prototypes deployed, I doubt I count in the “existing product” category. But now that the boron works in Canada it is looking very enticing.

My project have the same problems with possible theft and therefore we decided to keep both the battery (2000mA) and the solar panel as small as possible to make theft not worthwhile. I read sensors every hour and send the data to the server once a day and my battery life is 4 months without an solar panel. Afterwards we added a 25 mA / 5 Volt solar panel (25 mm X 45mm) that is about 10 times stronger that we needed but we could not find an smaller one. We have a few units installed and some of them is even installed under tree canopies and the batteries stays full 100%. We theoretically therefore never have to visit an installation again. We also decided to keep the solar panel stronger than needed cause solar panels degrade over time and this will help a lot to counter it. I use Electron’s for my project.



Thanks for sharing your approach. I like your approach to collect hourly and send daily, this could be a very significant savings in power.

I have recently looked at the process to collect data frequently and report in-frequently and wrote a sample sketch for the folks at Colorado State University here.

In my approach, I stored the data payload as an object in EEPROM each 15 minutes and then sent the data each hour. As this was my fist attempt at this, I figure there may well be a better way. Any advice or tips you might be able to give on how to manage this process?

I am especially concerned that the daily send would be a big payload and I would hate to loose a day’s data if the payload is corrupted, does not go through or there is a system outage that prevents a connection for the backend.



1 Like

I seem to be working in a similar area as this, here’s a few bits and pieces that might come in handy:

  • Boost converter: I found these guys to be very efficient even when I have a sensor that uses a lot of current for a short period of time. Datasheet lists it as 6.5uA quiescent.
  • Might think about using alatching circuit for your secondary microcontroller/counter system if it can fit in to your design requirements. This would allow you to be drawing next to nothing, trigger off your (PIR?) and only keep the (ATTiny85?) powered for a very short time while it adjusts your counts/writes to memory/de-powers itself. There are some ICs for this as well if you don’t need the flexibility and have limited board space.
  • This is a decentRTC with alarm function, biggest downside is ~130uA current draw in standby. But if you can use it to remove power from the boron between checks…
  • These are great for a ‘oops I drained the battery, start cutting power to anything I don’t absolutely need’ option. Several of my sensors are active with useful sleep modes, and if anything goes wrong or the batteries are seeing their end of life it’s more helpful to have the boron start sending help messages than to just have it die.
1 Like