Achieving long battery life with LoRa sensors

LoRa is a radio communication technology that LoraWAN uses for transmission of messages.  It can be thought of as the physical layer in the OSI Network Stack.

LoRa is known for it’s long range and low power usage.  In fact, LoRa stands for “Long-Range”.  The exact details of LoRa modulation are proprietary and the property of Semtech Corporation but it uses a technique called chirp spread spectrum to travel long (multiple kilometer) distances with relatively low transmission power.  By comparison, other modulation technologies such as frequency shift keying (FSK) would either cover much shorter distances or require much higher transmission power.

Despite all this, a device running off a small, cheap battery will only last months or years by spending the vast majority of it’s time powered down.

Some of this is down to the manufacturer of the devices you are using, they need to have done a good job of designing their device and writing the software for it so that it goes into as low a power state as possible  when it is not doing anything.

The rest is down to the data being sent and the radio signal strength between the device and the nearest gateway.  The data format might be fixed by the device manufacturer, or you might be able to design this yourself.

Making the battery last a long time

  • Send small amounts of data:

The smaller the data payload the device is sending, the less time the device needs to be powered up.  Even with the low power usage LoRa gives you, transmitting data uses power.

Most LoRa sensor devices will have a LoRa radio chip and a separate micro-controller which both use power.  The less data being sent, the less time it takes to send so the less power is used.

Data is sent in bytes and you want to send the minimum amount possible.  You can achieve this by being a bit clever about how you encode your data.  As an example, lets say you have a sensor reading ambient temperature, here are some ways you could encode that data:

“Temperature: 21.26” as text encoded into ASCII ends up as 54656d70657261747572653a2032312e3236 which is 18 bytes long.

If you shorten this to “2126” and then convert to a readable format in your application, this data in ASCII hexadecimal is 32313236 which is 4 bytes long so less than a quarter.

If you actually convert the number 2126 to hexadecimal you get 084e.  So now only 2 bytes.

You should always avoid sending text.

  • Send messages less frequently:

If you send messages less frequently, the device is in it’s low power sleeping mode for a longer percentage of time so the battery will naturally last longer.  As tempting as it can be to make your sensor send data back every minute or so, it’s hardly ever necessary.

For example, a sensor taking readings of soil moisture to control an irrigation system.  Soil moisture isn’t going to change rapidly, taking a reading once every hour will most likely be suitable, taking a reading every five minutes is a waste of energy.  Potentially your battery will last 12 times as long which could be the difference between changing it every 2 months or every 2 years.  This is an over-simplification but useful enough for this example.

Even for things like temperature, humidity or CO² metering inside buildings, these factors only significantly change over the course of hours rather than minutes so having per-minute accuracy isn’t necessary.  Something like every 15 minutes would be ample.

  • Keep LoRa Spreading Factor as low as possible:

the spreading factor in LoRa relates to the length of the “chirps” sent over the air when transmitting data.  Longer “chirps” (which equate to a higher spreading factor) take a longer amount of time to transmit but will be successfully received over a longer distance.  Spreading factor numbers go from 7 to 12, for each step up the transmit time doubles.

This screenshot is taken from the Things Network console showing several LoRa messages received by a gateway using various spreading factors:

Note the column headed data rate and the values given for “SF”.  Then note the corresponding values under the air time headed column.  You’ll see several messages at SF7 with an air time of around 40-60 milliseconds depending on the size of the data.  There is one message at SF9 with an air time of over 164mS and lastly one message at SF12 (the highest factor) which has an air time of 1482mS, or nearly one and a half seconds!  That’s about 25 times the amount of time needed to send the same message at SF7.

It’s clear that higher spreading factors will have a huge effect on battery life, potentially 25 times less if using SF12 in comparison to SF7 in this example (which is showing some real data).

So you want to use the lowest spreading factor as possible.  LoRaWAN does this using an “adaptive data rate” mechanism.  Exactly how it works is dependant on implementation of the network server.  But for example (at the time of writing this), The Things Network’s server will wait until it has received 20 messages from a device, then if the signal strength is very good, it will instruct the device to reduce it’s SF.  There is an acknowledgement mechanism used after this to allow a device to ensure it’s data is still received.

For more information on how ADR works with TheThingsNetwork, see this page.

This screenshot from the ThingsNetwork console shows ADR in action:

Here you can see the network server adding commands to a downlink message to tell the device to change it’s data rate (where you see “link-adr” in the screenshot).

Using lower spreading factors relies on network coverage.  Using higher factors will allow messages to travel further and still be received when interfering factors are in play such as buildings between the device and the gateway.

Ultimately you might only be able to use lower spreading factors by adding more gateways to your network but at least this is possible with LoRa.   Unlike for example if you have a poor mobile phone signal then your only real option is to move somewhere else with better signal.