Spreading Factor, a key characteristic in LoRaWAN that can make or break your IoT solution. Finding the right Spreading Factor is crucial for realizing long-term performance of a LoRaWAN device. This article explains how to find the right balance between battery performance and long-range communication.
Spreading Factor (SF) decides on how many chirps, the carrier of the data, are sent per second. The network decides the spreading factor (graded between 7-12) based on the environmental conditions between the communication device and the gateway. This assumes that the Adaptive Data Rate functionality is switched on, which is recommended for all but the continuously moving devices.
Lower SF means more chirps are sent per second; hence, you can encode more data per second. Higher SF implies fewer chirps per second; hence, there are fewer data to encode per second. Compared to lower SF, sending the same amount of data with higher SF needs more transmission time, known as airtime. More airtime means that the modem is up and running longer and consuming more energy.
The benefit of high SF is that more extended airtime gives the receiver more opportunities to sample the signal power which results in better sensitivity. Better sensitivity means that you can receive the signal further away, so you get better coverage. Theoretically, each step up in SF doubles the time to transmit the same amount of data, see fig 1. Each step up in SF correlates to about 2.5dB extra link budget.
Fig.1 Relationship between spreading factor and airtime for LoRa modulation.
The theory is all great, but how does the airtime and battery life look like in practice?
To get a sense of this, we used two tools:
1. Airtime calculator from LoRaTools
2. Otii to measure energy consumption profiles for SF7 and SF12
In this test, we measured a LoRaWAN device from Bintel which uses Semtech's SX1276 chipset. Our set-up was an indoor-outdoor scenario, i.e. device was measured in an office, at a developer’s table, with a gateway outside on one of the buildings nearby. Hence, it was not the normal use scenario for this device, that is meant for waste bins, outdoors. We measured the energy consumption of the first transmission and total activity cycle with a payload of 19 bytes and a bandwidth of 125 kHz.
Fig. 2. Bintel LoRaWAN device for waste management.
In the measurement, the activity cycle comprised of a transmit and a listen period with a confirmed message, an acknowledgment (ack), see fig 3.
Fig.3. Measured energy consumption for transmission at SF12 (in blue) and SF7 (in green), with acknowledgement (ack) from the gateway.
Table I. Measured and calculated transmission time and measured energy consumed for SF12 and SF7.
The measurement shows that it takes approximately 25 times longer and 25 times more energy to transmit in SF12 compared to SF7. Airtime calculator shows the same result.
The number 25 is, however, not set in stone. It depends on the payload size and the headers assigned for the transmission. If you play with different sizes of the payload, you can see different multiples.
Note that the above calculation is for the transmit time only, and not for the whole activity cycle. The ratio of energy consumption per activity cycle is 20 times more energy for SF12 than SF7, in this specific measurement (energy stats showing 55.1 uWh vs. 2.78 uWh, see Fig.4). It is good to note that the energy consumption for the activity cycle depends on what Class the device is. If it is a Class A device, it has only two receive opportunities, as seen in the Fig. 5 (red trace), meaning the receiver is not awake more than for those two opportunities. Another configuration can be, for example, that the device keeps listening continuously, which increases the energy consumption drastically. In that case, the SF number doesn't matter.
Fig 4. Marked energy consumption for transmission at SF12 (in blue) and SF7 (in green), for the full activity cycle including uplink and downlink.
Fig 5. Measured energy consumption for transmission at SF12 (in red) and SF7 (in yellow), with no acknowledgement from the gateway.
It's difficult to draw more conclusions as each application is unique, but we want to highlight that the optimal spreading factor that will yield the lowest energy consumption is not necessarily the highest or the lowest one, but most likely somewhere in between. If there are excessive retries, due to the need for confirmed messages, the energy savings of a shorter transmission will rapidly get lost due to retransmissions. The important thing to remember is that the total energy consumption is never optimized with one parameter only.
To check out the energy measurements for different SFs presented, download .otii file below (and open it in Otii application that you can download here for free).
Do you want to learn more about optimizing the power consumption of your LoRaWAN deployment and meet the Qoitech experts in person? Join 2000 LoRaWAN professionals at The Things Conference on January 30 and 31, 2020 in Amsterdam; the world’s largest LoRaWAN conference.
GET YOUR TICKETS NOW
10% discount code: FRIEND-OF-QOITECH
Qoitech Team
You can download .otii file of the above measurements HERE
For more information about LoRa, LoRaWAN or The Things Network, have a look at one of the links below
- LoRa CHIRP
- LoRa crash course
- Decoding the LoRa PHY