It can be pretty useful to know how LoRa parameters influence data rate and range, for example when configuring your RNode. In this post I'll go over the basic concepts needed to understand the different LoRa parameters, and how they affect range and data rate.
If you just want to know what your on-air bitrate will be for a certain set of parameters, you can use the following calculator to input the parameters, and see the resulting on-air bitrate. If you want to understand how and why the parameters affect the modulation, read on!
When setting up a LoRa transceiver, you will not only need to know what frequency it should transmit on, and what the output power should be, but also three other parameters, that will drastically change how the transceiver operates. These parameters are:
- Spreading Factor
- Coding Rate
LoRa is a very flexible modulation scheme, that can provide relatively fast data transfers up to 253 kbit/s. Conversely, the parameters can be configured in a way that will result in a very low data rate, all the way down to a mere 11 bits per second. This will in turn result in a large processing gain for the receiver, and therefore much longer range of the transmission.
In this post I will focus on how the parameters affect data rate, and not go into the specific processing gain calculations for various LoRa configurations. As a rule of thumb, you can expect the range to increase as the data rate is lowered.
LoRa modulation can be configured to use variety of different radio frequency bandwidths. Most commonly, a modulation scheme will occupy a more or less set bandwidth of radio spectrum, which is a result of the modulation technique used, and the rate at which information is transferred.
Since LoRa is a chirp spread spectrum modulation scheme, it intentionally spreads out the signal over a wider bandwidth than would strictly be necessary to transmit the information. The technique offers better noise immunity in the frequency domain, and is especially useful when transmitting with low output power.
LoRa can be configured to use bandwidths in pre-determined steps from 7.8 KHz to 500 KHz in the sub-gigahertz bands, and from 250 KHz to 1.6 MHz in the 2.4 GHz band. Generally speaking, choosing a narrower bandwidth will result in a slower transfer rate, but improved range. Choosing a wider bandwidth will result in an increased data rate, but a shorter range.
The chirp spread spectrum scheme employed by LoRa spreads out each bit of payload data over multiple symbols. This can improve noise immunity in the time-domain, and also incurs a processing gain for the receiver. The LoRa spreading factor is the parameter that controls how spread out in time each data bit is. If a higher spreading factor is selected, each payload data bit will be spread out over more symbols. LoRa can be configured for spreading factors between 5 and 12, although only 6 through 12 are accessible in the sub-gigahertz band, and 6 often requires a TXCO to be stable.
Where the bandwidth and spreading factor controls physical parameters of the modulation scheme, and thus can result in significant processing gains and range improvements, the LoRa coding rate essentially controls the amount of Forward Error Correction that is added to the payload data. As such, a higher coding rate will not increase range, but will make a link more reliable if interference is present. As one would expect, it also comes at the cost of decreasing the data rate. LoRa can be configured for four different coding rates.
The coding rate describes the ratio of actual data to error-correcting data added. In choosing the LoRa coding rate, it is important to consider whether it's necessary to permanently employ a high coding rate, with subsequent loss of data rate, or whether it is more efficient over-all to allow for the occasional dropped packet due to interference.
Since the coding rate does not modify the physical parameters of the modulation, two (or more) LoRa transceivers configured with different coding rates can still decode each others signals. This might be useful if a receiver is located in an area with high amounts of interference, but the other end of the link is not. In such a case, the two transceivers can be configured with asymmetric coding rates, such that optimal transfer rates can be achieved, even though interference levels vary at the different sites.
7 thoughts on “LoRa bitrate calculator and understanding LoRa parameters”
Thanks, it clarifies a lot.
Can you add a cell to show the RF sensitivity
That’s a great idea. Will add this shortly.
Any updates to the reticulum project?
Very exciting project.
I recently released the first beta of Reticulum, which now comes with decent documentation. All the info is available on the github repository: https://github.com/markqvist/reticulum
You could also take a look at the Nomad Network LXMF client: https://github.com/markqvist/nomadnet
If I understand this, and I want to build a general purpose passive packet sniffer, I would need a separate receiver for each frequency, SF, and bandwidth? Or some sort of scanner, but with the low duty cycles, that would probably not work.
Sounds like one would need a Software Defined Radio to look at the whole band?
Yes, to reliably monitor a large portion of a band, you would need a number of separate receivers, or an SDR with a very high bandwidth, and some serious processing power on the host end to concurrently demodulate all the different combinations of frequencies, bandwidths and spreading factors. To my knowledge no such demodulator software exists currently (but probably will at some point in the future).
The next major release of the RNode firmware will support monitoring many different frequencies and modes at the same time (and offer WireShark compatibility as well), but naturally this will come at the cost of possibly missing some packets, since it will need to “scan” the different configurations.
The frequency and mode hopping in the RNode is very fast, so a number of frequencies/configurations can be monitored at the same time with a pretty low chance of losing packets. It is basically a function of the LoRa preamble time versus the number of configurations monitored. The largest limitation to this approach is obviously that you can only capture one configuration at a time. If multiple transmitters are active at the same time, only one will be captured. For such situations, you need multiple receivers.