Battery Life - what impacts it and how to optimize and estimate it

There is a lot that can be said about battery life and how important it is in the field of IoT. One could go as far as to say that it would be even more important than the actual set of functionalities of a device.

If a device is limited in measurement metrics, or is is not designed well, or not easy to operate, this might make things less than ideal and the information you obtain from it might be less than what you would like. If your batteries die in the field a couple of months after deploying the sensor you have a dead device, PERIOD. You get no data, nada.

There is no perfect product, however any good product needs to have solid battery life and there are a number of things we would like to discuss in order to make sure you have the right understanding and tools to make your battery life as long as possible.

Design matters, but it is only the base

Unless a device is designed well, it will not have a good battery life, this is true. The following need to be in order:

• Low power consumption, especially in the sleep cycle.

• Large enough and of a good quality batteries

• Is possible some type of energy harvesting (solar, vibration, heat, etc.) to extend the operational time.

We at MClimate have invested a great deal of resources and time to make sure that our Devices operate in an efficient and stable manner. WE utilize high quality batteries of sufficient capacity and can ascertain that under nominal conditions (test report at the link), our devices can operate 10+ years.

This is our gift to you, however you need to do your part too. Let us discuss what you can and must do it order to make sure that your LoRaWAN devices stay operational as long as possible. Here as a list of the most important things to consider, that will each be discussed in a chapter throughout this document:

• Keep-alive period and how it impacts battery life

• Spreading Factor (SF) and its impact on battery life

• Range, position of gateways and how they limit device longevity

• Offline devices, reconnecting and does it kill batteries faster than normal operation?

Keep-alive period and how it impacts battery life

Battery powered LoRaWAN devices generally work as Class A nodes, which means that they sleep most of the time and wake up to perform measurements, which they than transmit as a message. This message we call the Keep-alive and it is periodic in nature. As you might have guessed the shorter the period between these messages, the more often the device wakes up and is active, drawing more from the battery.

It is an inevitable tradeoff, either you increase the granularity of the data, transmitting more often, but you sacrifice battery life, or you transmit less often to gain longevity, but your measurement data points are further apart.

Spreading Factor (SF) and its impact on battery life

This is tied with the keep-alive as far as impact on battery life goes as it directly impacts power consumption.

Put simply the higher the spreading factor the more time it takes for the device to transmit a message, thus it remain in active mode longer, consuming more power.

All other things being equal the decrease in battery life is significant between SF7 and SF12.

Range, position of gateways and how they limit device longevity

This ties to the previous point as it directly relates to the SF. We are not going to go into details here as it is not the purpose of the article, but LoRaWAN devices utilize something called Adaptive Data Rate (ADR) which allows them to change the SF, based on how strong the received signal is.

In a network with poor range the signal level will be low and the devices will move to a higher SF (closer to SF12 or SF12). This will reduce battery life in order to extend the effective range and allow the message to actually be received and not lost.

Thus, you need to have a good network coverage, where devices can work on SF7-8 predominantly, so they are power efficient. Examine your network and if need be install more gateways (over deployment of gateways has no negative impact on the network, except increasing its monetary cost).

Offline devices, reconnecting and does it kill batteries faster than normal operation?

There is some concern that a device that tries to join frequently because of network instability/outage would case the battery life to be negatively impacted to a certain degree. This is true, up to a point. Yes, battery life is negatively impacted if the device tries to rejoin frequently, however in no realistic case will it be doing so very often.

We are going to give sufficient examples in the following paragraphs where one can see that join-requests do not significantly impact battery life (long term). MClimate devices have a built-in mechanic that in the event of a device not being able to connect for a certain period, the interval between the join-requests is increased. Thus, the longer the device can't connect the less often it tries to do so. This lets it preserve its battery life and at the same try does no completely stop trying to rejoin.

Overall it is a very efficient process that balances connectivity and battery life.

Utilizing Enterprise as a Battery Estimation tool

Now that we have covered the theoretical basics we can move to a more practical scenario. Luckily MClimate offers two very effective ways to predict your device's battery life

• Online LoRaWAN Battery Calculator

• Device Dashboard Battery Estimation

The first one while is a very good estimator in ideal operating conditions (never the case in real deployment). It can give you a rough estimate on what to expect, it is more of a rule of thumb than exact science tool.

Estimation via the Online Calculator

Let us look at a few examples for a Vicki working under what we consider average workload (based on the communication interval, heating season duration and daily motor steps, which you can see in the images below) that is operating under 3 different network conditions resulting in different SF. The Battery data is for the Energizer L91 batteries, we ship the device with (top of the line quality and battery life).

At SF 7 we have:

• Average daily consumption - 0.316 mAh

• Expected battery life - >12 years

Now lets compare with the same use case but at a much worse SF (poor network coverage)

At SF11 we have:

• Average daily consumption - 1.159 mAh

• Expected battery life - 6.6 years

As you can see this practically halves your battery life. Lets worsen conditions even more to that is considered the lowest possible network quality.

AT SF12 we have:

• Average daily consumption - 2.167 mAh

• Expected battery life - 3.5 years

The battery life is almost halved, yet again.

We believe the tool is quite useful (even if not precise) and gives you good insight into how different parameters can affect your battery life. We encourage you to play with it and try to modify the values to best represent your use case scenario in order to obtain as close an estimation as possible.

Direct Estimation via Enterprise Metrics

We believe this is the best way to predict your battery life, as it is based on measurement data rather than estimation based purely theoretical calculations.

Every device that you have onboarded in Enterprise can take benefit of this Energy Consumption Model, assuming it has operated long enough for it to gather sufficient data.

The values shown are not simulated, or based on statistical modeling, but the result of direct measurement. We take the metadata from every uplink packet and analyze it, taking into account SF, packet size / transmission time, motor consumption per actuation, battery degradation, etc.

The average consumption is calculated and a prediction is made for the projected battery life (assuming there is no radical change in the operation of the device) which is as close as you will get to the real one.

Let us look at 3 examples in order to better understand what the benefits of the model are an gain insights into how best to operate your devices.

Use-case 1

Our first test case Vicki has the following parameters:

Keep-alive period: 10 minutes

Overall Consumption: 257.63mAh

Projected battery life: >12 years

Calculations are based on: 490 days

The above are shown when you open the Battery estimation tab. If you want a bit more details you can point to an area on the pie chart.

For example lets look at how much the Motor consumption was over the 490 days (image below).

The 101.58 mAh is how much of the battery went for movement of the motor and adjusting the openness of the TRV.

Now lets take a look at the Communication consumption.

Communication took out 99.58 mAh from the battery. This would be how much power was required to assemble da data packet and transmit it. It is to be noted that this value is optimal as the device communicated mostly on SF7 (as should be the case in any good deployment). This can be seen below the pie chart where the total number of packets on different SF are displayed, in our case we have SF7: 76875, there are just a few on SF12 (this is normal as they are used when joining to the network for a better range / chance to join).

This leaves us with a consumption of 101.58+99.58=201.16 mAh, the rest is re-joining the network (rare, but still happening due to power outages for example of gateways being down) and idle consumption.

As you can see the majority of the energy goes towards adjusting the TRV and communicating information to the Enterprise cloud.

Lets compare this to another scenario, so we can start to better understand how parameters impact battery life.

Use-case 2

The only difference with the use-case 1 is the Keep-alive period being shorter.

Keep-alive period: 6 minutes

Overall Consumption: 393.93 mAh

Projected battery life: >9.5 years

Calculations are based on: 490 days

Lets break it down once more. Motor consumption cost 129.12 mAh. This is similar to the last use-case as can be expected as they are both over the same time period in the same building, thus the adjustments to the TRV openness while somewhat different were quite similar.

The device consumed 209.77 mAh in order to communicate with the Server, which is roughly 2.1 times more for the same period of time. Again this is to be expected as the keep-alive interval is close to half of the previous one, meaning that on average twice as many packets are transmitted and the device remains active for twice as long.

The combine consumption for the Motor + Communication is 129.12+209.77=338.89 mAh. This is about 1.7 times the consumption of the first use-case. If we look at the total consumption it is 1.53 times that of the first use-case.

Thus, the second device has consumed 53% more of the battery for the same period of time, which is not a small amount considering that the periods is less than 2 years and the motor consumptions is more or less the same.

If we look at it another way:

Use-case 1 - 38.7% of all the current drawn was for Communication

Use-case 2 - 53.3% of all the current drawn was for Communication

The concluding, under similar conditions decreasing the keep-alive time significantly reduces battery life, so take care to account for this. If you need frequent updates be prepared to pay the price in longevity of your battery.

Use-case 3

Let's examine one last use-case.

Keep-alive period: 6 minutes

Overall Consumption: 113.49 mAh

Projected battery life: >12 years

Calculations are based on: 310 days

This one is for a shorter period, just 310 days, so it is expected for the Overall consumption to be lower. What is interesting though is that the period is 38% shorted, but the power consumption is 56% less, which means it is a lot more efficient.

The device is still a Vicki, the SF7 predominantly, the keep-alive 10 minute, so there is no difference there, what is different is the operational time. If you check the pie chart you can see there are 495 messages on SF12. While these consume more power they are a lot less than the SF7 ones, which are 32760 so it should not make a notable difference. However they are an indication that there might have been a lot of rejoining the network (we know this for a fact).

This was a test device that was simply off (batteries removed) for a lot of the test period, so it was power cycled a lot and while this consumes a lot of power, it was depowered long enough that not much of the batteries was used. It was simply not operational for a prolonged period.

The reduces consumption is also visible from the pie chart, Communication took just 49.06 mAh, there was simply not much Communication.

The point we are trying to make with this last example is that the keep-alive period makes a huge difference in battery life and while the Motor consumption is not something that you can influence (it is an automated response to the heating requirements) you can adjust the keep-alive time to a reasonable interval where you have a good balance between battery life and data granularity.

You can even compensate poorer network coverage (higher SF drawing more current) with a longer keep-alive period. Your device might take longer to transmit, but you can make it transmit less often to balance things out.

In the end the Battery Estimator is your best tool to predict what the operational cycle of the device will be and gives you insights into optimizing it. We would advice you take a look at this data at least 2 times a year (assuming there are no major issues as the network being down frequently, the device being offline, the SF being high, etc.) to see if the predicted battery life is what you are aiming for and if need be adjust one or more of the operational parameters of your device.