LoRaWAN Sensor Battery Drains Too Quickly: Optimising Transmission Interval, Reception Quality and Alarm Traffic

→ Product category: IIot solutions

 

A battery-powered IIoT sensor is expected to operate for several years without maintenance. However, after only a few months, the platform already indicates a significantly reduced battery level. The first suspicion often falls on an undersized battery. In many cases, however, the actual cause lies in the configuration and the radio connection.

With a LoRaWAN sensor, battery life is not determined solely by how often a measured value is recorded. What matters just as much is how often the radio module becomes active, how long a transmission takes, what transmit power is used and whether additional telegrams are generated by alarms, retransmissions or network communication.

Remote measuring points are therefore particularly interesting: a sensor may transmit only a few measured values per hour and still consume a large amount of energy if the radio connection is poor. Conversely, a sensor can measure frequently, store the values locally and transmit them compactly only at longer intervals.

IIoT components for corresponding applications can be found under IIoT Solutions. Solutions specifically for wireless remote monitoring of levels are grouped under IIoT Level Monitoring.

Where does a LoRaWAN sensor consume energy?

Ideally, a battery-powered IIoT sensor spends most of its time in a very low-power sleep state. For a measurement, the sensor electronics are activated, the measured value is recorded and processed if necessary. The device can then return to sleep mode.

Significantly more energy is usually required as soon as the radio module becomes active. It is not only the actual transmit power that matters. The duration of the telegram “on air” and any additional communication processes that follow are equally important.

Battery life therefore depends on several factors that must be considered together: measuring frequency, transmission frequency, data rate, radio quality, telegram size and the number of additional communication processes.

The simple assumption that “one measurement equals one radio transmission” is therefore unnecessarily inefficient for many IIoT applications.

Distinguishing between measuring interval and transmission interval

The measuring interval and transmission interval serve different purposes.

The measuring interval determines how finely a process is monitored over time. A level, for example, can be measured every five minutes so that rapid changes are detected locally.

However, this does not mean that a LoRaWAN telegram is also required every five minutes. If one value per hour is sufficient for central monitoring, several measured values can be processed or collected locally and transmitted far less frequently, provided that the device supports this operating mode.

This is often where considerable energy savings can be achieved. For a slowly changing tank level, for example, a transmission every one to six hours is often much more sensible than transmitting every minute.

At the same time, event-based logic can ensure that critical changes are still reported immediately. The sensor can therefore operate with a long regular transmission interval but additionally send a message when a defined high or low alarm occurs.

The optimum configuration is therefore not:

measure as rarely as possible

but rather:

measure as often as necessary for process monitoring and transmit only as often as the application actually requires.

Why does radio quality affect battery life?

LoRaWAN is designed for long range and low energy consumption. However, long range does not mean that every measuring point has the same radio conditions regardless of its installation environment.

Sensors installed inside or directly behind large metal structures are particularly unfavourable. Steel tanks, control cabinets, machinery, reinforced concrete and underground shafts can significantly impair the radio connection.

A sensor that communicates reliably with a gateway in an open area may therefore experience significantly poorer conditions only a few metres away behind a large tank.

Poor radio reception can make more robust LoRa transmission parameters necessary. The transmission then requires more airtime. Depending on the network and device configuration, additional transmissions may also be required.

Poor reception quality is therefore not merely a range problem. It can directly affect the energy design of the sensor.

Correctly using ADR, Spreading Factor and transmit power

LoRaWAN uses different data rates. In simplified terms, a robust transmission under difficult radio conditions takes longer than a fast transmission with a good connection.

The Spreading Factor is an important parameter in this context. A higher Spreading Factor improves transmission robustness and range, but increases the required airtime.

Adaptive Data Rate – ADR – is therefore particularly useful for stationary sensors. It allows the network to optimise the radio parameters based on the actual observed connection. Depending on the LoRaWAN version and configuration, these parameters include data rate, transmit power and transmission behaviour.

A sensor close to an easily accessible gateway may be able to use a high data rate with correspondingly short airtime. A remote sensor behind several obstacles, on the other hand, may require more robust radio parameters.

However, ADR cannot completely compensate for poor system planning. If a sensor is installed in an almost completely shielded metal shaft, improving the gateway or antenna position is often far more effective than permanently using an extremely robust radio configuration.

When do additional transmissions occur?

An important distinction must be made between confirmed and unconfirmed uplinks.

With an unconfirmed telegram, the network does not necessarily have to acknowledge every measured value. This reduces communication overhead and is suitable for many regularly recurring measurements.

A confirmed uplink, on the other hand, expects an acknowledgement. If this acknowledgement is not received and multiple transmission attempts are configured, the telegram can be sent again.

Even with unconfirmed telegrams, LoRaWAN can transmit the same frame multiple times depending on the network configuration. Therefore, if battery life is unexpectedly short, it should not automatically be assumed that every packet not received by the gateway is retransmitted. The actual device and network configuration is decisive.

For regularly transmitted temperature, pressure or level values, it is often unnecessary to acknowledge every individual measurement. If one cyclic telegram is lost, the next up-to-date measured value will usually follow shortly afterwards anyway.

The situation may be different for a rare critical event. In that case, a confirmed transmission can be useful if the application must ensure that the alarm has actually been accepted by the network.

Improving gateway coverage instead of increasing battery size

If several sensors in the same plant area simultaneously show poor radio quality, the network coverage should be examined first.

An additional or better-positioned gateway can be far more effective from an energy perspective than larger batteries in many individual sensors. Even moving a device by only a few metres can help if this prevents a massive steel wall or large tank from being located directly between the sensor and gateway.

The antenna position is particularly important. A sensor should not be installed unnecessarily deep behind pipework, metal cladding or steel structures. Where external antennas are used, the antennas, cables and installation conditions specified by the manufacturer must also be observed.

Radio planning should ideally be carried out under actual plant conditions. A measuring point that works during installation with control cabinet doors open can have completely different radio quality once the enclosure is closed.

Limiting alarm traffic sensibly

Event-based transmission is an excellent way to combine battery life with up-to-date information. However, it can itself become a problem if alarm thresholds are poorly configured.

A typical example is a level fluctuating directly around an alarm threshold. Without hysteresis, the sensor may send “Alarm”, “Normal”, “Alarm” and then “Normal” again within a short period of time.

The same applies to pressure or temperature. Small process fluctuations, measurement noise or wave movement in a tank can generate a large number of additional radio telegrams.

Suitable hysteresis or time-based debounce prevents this effect. An alarm should not be retransmitted every time the threshold is exceeded by a minimal amount.

The repetition rate of an active alarm must also be chosen deliberately. A low tank level that has already been active for twelve hours does not necessarily need to be retransmitted every minute as the same alarm. An immediate initial message followed by significantly longer reminder intervals is often sufficient.

Optimising payload and data packets

The amount of transmitted data also influences airtime. A telegram should therefore contain the information actually required by the application without being unnecessarily inflated.

For a simple level sensor, the measured value, status and battery condition may already be sufficient. Long plain-text information or permanently repeated static device data is rarely useful.

Several measured variables can, where appropriate, be transmitted in a single telegram. This avoids triggering a separate radio transmission for every individual value.

However, a compact payload only reduces one part of the total energy consumption. A poorly accessible sensor with an extremely short transmission interval will not become a ten-year solution simply by removing a few bytes from the telegram.

Offline buffer and communication failures

For remote measuring points, it should also be defined what happens during an extended network outage.

If the device supports local storage, measured values can initially be buffered and transmitted later. However, care should be taken to prevent thousands of historical individual telegrams from being transmitted immediately once the connection is restored, unnecessarily draining the battery.

For many monitoring applications, intelligent aggregation is more useful. For example, minimum, maximum and average values can be stored during a communication outage, provided that the device supports this function and the application does not require a complete time series.

Repeated join or reconnection attempts can also become relevant during extended periods without network coverage. A device should therefore not continuously attempt to restore a non-existent connection at very short intervals.

Considering temperature and battery behaviour

The achieved battery life does not depend solely on the radio protocol. Ambient conditions also influence the available energy and battery behaviour.

Outdoor measuring points in particular can become significantly colder in winter than originally assumed during planning. At the same time, a sensor may become very warm during the day due to direct sunlight.

The design should therefore not be based solely on theoretical battery life at room temperature. The specified temperature range of the radio unit and battery as well as the actual temperature profile at the measuring point are decisive.

For very remote measuring points, an additional reserve is advisable. A battery theoretically sized to last exactly until the next scheduled maintenance visit offers little margin if radio conditions, alarm frequency or ambient temperature change later.

Systematic optimisation

Observation	Possible Cause	Suitable Measure
Battery drains quickly despite only a few measured values	Radio transmission too frequent	Separate measuring interval from transmission interval
Only individual sensors have short battery life	Local radio shielding	Check installation position and gateway reception
Sensor permanently operates with robust radio parameters	Poor connection to the gateway	Investigate ADR, gateway position and antenna location
Very many telegrams in the event log	Alarm oscillates around a threshold	Optimise hysteresis and alarm delay
Many confirmed messages	Every measured value requires acknowledgement	Use confirmation only where technically necessary
Energy consumption increases after a network outage	Repeated communication or retransmission of buffered data	Check reconnect strategy and offline buffer
Battery problem mainly occurs in winter	Low ambient temperature	Check temperature range and battery reserve

The most important information is often not the current battery level but the communication log. The number of uplinks, data rate used, radio quality, alarm frequency and any retransmissions show much more clearly where the energy is actually being consumed.

Practical example of a remote tank measuring point

At an industrial site, the level of a tank is monitored using a battery-powered LoRaWAN sensor. The level normally changes only slowly. Nevertheless, both the measuring and transmission intervals were initially configured to five minutes during commissioning.

This results in 288 regular transmission events per day. In addition, the tank is located between two large steel vessels. The radio connection to the gateway in the administration building is poor.

After several months, it becomes apparent that the predicted battery life is being significantly undercut.

The process requirement is therefore reassessed. For logistics planning, one current level value every two hours is sufficient. A faster update is only required when the tank reaches a critical minimum level.

The internal measurement can therefore remain at a shorter interval, while the regular transmission interval is significantly extended. At the same time, an event-based alarm with suitable hysteresis is configured.

The gateway is also moved to a more favourable position so that the direct radio path is no longer completely shielded by the steel tanks.

Parameter	Before Optimisation	After Optimisation
Regular transmission interval	5 minutes	2 hours
Regular transmissions per day	288	12
Critical alarm	Within normal cycle	Event-based
Gateway situation	Strongly shielded by metal	Radio path improved
Process information	Far more frequent than required	Adjusted to actual requirements

This eliminates two causes at the same time: unnecessarily frequent regular transmissions and an unfavourable radio connection.

The example also shows why a larger battery should not be the first measure. It would merely have prolonged the symptoms without eliminating the inefficient configuration.

Planning battery replacement

Long battery life does not mean that the battery should be operated until complete failure.

In larger IIoT installations, the battery condition should be monitored together with the normal measured values. This allows replacement to be combined with already scheduled maintenance work.

A trend is particularly useful. If the battery status of one sensor falls significantly faster than that of comparable measuring points, the battery should not simply be replaced immediately. First, it should be checked whether this sensor transmits more frequently, generates more alarms or has poorer radio conditions.

The battery itself thus becomes a diagnostic indicator for the quality of the entire IIoT installation.

Which IIoT products are suitable?

WIKA NETRIS 1

The WIKA NETRIS 1 is a universal radio unit for standard sensors and is particularly suitable for retrofit and remote monitoring applications. It can connect, among other things, measuring instruments with 4 … 20 mA, 0 … 10 V as well as Pt100 or Pt1000 sensors.

Depending on the version, LPWAN technologies such as LoRaWAN and mioty are available for radio transmission, as well as Bluetooth for local communication. The radio unit can be battery-powered or externally supplied. Configurable measuring and transmission control allows the communication behaviour to be adapted to the respective application.

WIKA NETRIS 2

The NETRIS 2 is designed for applications in hazardous areas and has two intrinsically safe analogue 4 … 20 mA inputs. Existing process instruments can therefore be integrated into a battery-powered LoRaWAN infrastructure.

This is particularly useful for pressure, level or other process measuring points where retrofitting fixed wiring would be very complex.

WIKA NETRIS 3

The NETRIS 3 is a LoRaWAN radio unit for compatible WIKA measuring instruments and is also intended for hazardous areas. The measured data is digitally transferred from the connected WIKA instrument and then transmitted wirelessly.

A specific example from level measurement is the WIKA FLRU reed level transmitter in combination with the NETRIS 3. This allows liquid level measurement to be integrated into web-based remote monitoring.

Depending on the device version, configuration and operating conditions, WIKA specifies battery lifetimes of up to ten years for NETRIS radio units. However, such a figure should always be understood as the result of a defined operating profile and not as a guaranteed lifetime independent of the transmission interval.

Under IIoT Solutions, you will find corresponding radio modules and measuring systems. Suitable solutions for tank and vessel applications are available under IIoT Level Monitoring.

ICS Schneider Messtechnik provides support in selecting sensors, radio units and measuring principles as well as in configuring measuring intervals, data transmission and suitable IIoT infrastructure.

Conclusion

Short battery life in LoRaWAN sensors is not automatically a battery problem. It is often the result of overly short transmission intervals, poor radio coverage and unnecessary communication traffic.

The most important approach is to separate the measuring interval from the transmission interval. A process can be monitored frequently without transmitting every single measured value immediately.

For slowly changing variables such as tank level, pressure or ambient temperature, longer regular transmission intervals combined with event-based alarms are often far more efficient.

Good gateway coverage is equally important. An unfavourable installation behind metal structures can require more robust and therefore longer radio transmissions. ADR helps adapt the radio parameters to the actual connection, but it cannot replace technically sound radio planning.

Confirmed telegrams should be used selectively. Not every cyclic measured value necessarily requires an individual acknowledgement. Critical events, on the other hand, can be handled differently from regularly recurring status values.

Alarm hysteresis, payload, offline behaviour and ambient temperature should also be included in the battery-life assessment.

Long battery life is therefore not achieved by adjusting a single parameter. It is the result of a coordinated system consisting of sensor technology, data model, radio connection, gateway infrastructure and maintenance strategy.

Frequently asked questions about LoRaWAN battery life

Why does the battery of my LoRaWAN sensor drain so quickly?

Common causes include a very short transmission interval, poor radio conditions, frequent alarm telegrams, additional transmission attempts or a combination of these factors.

Is the measuring interval the same as the transmission interval?

Not necessarily. A sensor can, for example, measure every five minutes but transmit only once per hour or send aggregated data, provided that the device supports this configuration.

Does LoRaWAN consume more battery when reception is poor?

This can be the case. Under unfavourable radio conditions, more robust radio parameters with longer airtime may be required. Depending on the configuration, additional transmissions may also occur.

What does ADR do?

Adaptive Data Rate allows the LoRaWAN network to adapt transmission parameters such as data rate and transmit power to the radio conditions of a device. This can optimise airtime and energy consumption, particularly for stationary devices.

Is a high Spreading Factor bad?

A higher Spreading Factor is not inherently wrong. It enables more robust communication under difficult radio conditions. However, the transmission requires more airtime, so an unnecessarily high value should not be used permanently.

Is every lost LoRaWAN packet automatically retransmitted?

No. Transmission behaviour depends, among other things, on the message type and network parameters. The actual device configuration should therefore be checked when diagnosing battery consumption.

Should I send all measured values as Confirmed Uplinks?

For regularly recurring measured values, this is often unnecessary. An acknowledgement generates additional communication. Critical events, on the other hand, may justify a confirmed transmission.

How can I improve a sensor installed behind a metal tank?

The sensor or antenna position and the gateway location should be investigated first. Better radio geometry is often more effective than increasing battery capacity.

What is important when configuring alarms?

Hysteresis and, where appropriate, a time delay should prevent a measured value directly at the threshold from constantly switching between normal and alarm states and thereby generating many additional telegrams.

Is ten years of LoRaWAN battery life realistic?

Such lifetimes are possible with appropriately designed devices and favourable operating profiles. However, they depend significantly on the transmission interval, radio conditions, alarm traffic, ambient temperature and the specific device configuration.