LoRa - Is Link Budget Everything? (No, it's not!)

by Jon Adams, N7UV

LoRa's Got a Lot of Knobs

LoRa is a digital mode with technical characteristics that are extremely well documented publicly. To wit, one of the many things many people experimenting with LoRa find are the incredible link margins that LoRa can support. At 433 MHz, a LoRa bandwidth (BW) of 7.81 kHz, a spreading factor (SF) of 12 and a transmit power level of +22 dBm, the link budget is nearly 171 dB. The receiver sensitivity is approaching -149 dBm. Link budget is just transmitter output power - receiver sensitivity. In this case, +22 dBm - (- 149 dBm) = 171 dB. Compare that to the RF path loss at 433 MHz between the Earth and the Moon, 197 dB. Only about 26 dB more than the best-case LoRa link budget using 0 dB gain antennas. That means that with ham moonbounce antennas at both Earth and Moon, the enterprising ham could use 70 cm LoRa to communicate between the Earth and Moon. That's literally out of this world!

Where do I get these numbers? Right here at Semtech's LoRa Calculator site. Check it out!

But with such incredible link budget and receiver sensitivity comes a hit to power consumption. Why? The above LoRa settings provide an effective bit rate of about 11.5 bits per second. Comparing that to Morse code, 11.5 bits per second is equal to approximately 14 words per minute! At BW 7.81 kHz and SF12, and assuming an 8-byte packet length, the LoRa transmitter will be on for 19 seconds just to send that 8 bytes of data. Even if it's only 4 bytes of data, that's still nearly 15 seconds transmit time (frame overhead, etc.). That consumes a fair amount of energy to transmit that one short message. That energy has to come from somewhere! Soon, we'll look at real-world examples where that matters. A lot.

Another important note. If the sending device is transmitting for 15 seconds, that means any other similar field device that has data to transmit must somehow know to wait until that packet is successfully received at the far end. Less than 4 data transmissions (or messages) per minute can be successfully received at the other end, there's 1440 minutes in a 24-hour day, so if everything is perfect, that's <4 transmissions/minute x 1440 minutes/day which means a potential for around 5500-5600 8-byte messages per day. That may sound like a lot, but we'll get into some use cases a little later and investigate the value of that message rate.

With LoRa, doubling the BW decreases the link budget and receiver sensitivity by 3 dB. Holding the BW constant and moving from SF12 to SF11 is a 2.5 dB decrease (any single-SF change results in a 2.5 dB change to link margin). Right there, those two knobs provide a hint as to how LoRa RF performance can be changed. Nonetheless, link budgets that generous mean that the obstacles between the sending and receiving devices can be significant and variable and still afford a good data connection.

At the opposite end of the LoRa performance spectrum, running BW 500 kHz SF5 at +22 dBm transmit output reduces the link budget to 133 dB, and the receiver sensitivity is -111 dBm. However, the data rate is now 62.5 kbps and that same 8-byte packet takes just 2.7 milliseconds (ms) to transmit, which is an energy savings and on-the-air time improvement of over 6600x! Suddenly, instead of only 5760 messages per day, it's over 30 million messages per day. LoRa can support a huge range of communications performance at a variety of energy costs. This is one of the really cool features that LoRa brings, the number of knobs and the range of settings that can be optimized for a given situation. It also makes for a daunting technical challenge on knowing what's best for the situation, and that the situation for one person or group of persons isn't the same as for others.

(As a side note, our now over 4500 sq mi / 12000 sq km 70 cm LoRa APRS network here in Phoenix Arizona is currently running BW125 SF7 for an effective over-the-air data rate of about 4560 bps, a link budget of 146 dB, and a receiver sensitivity of -124 dBm. The time on air for an 8 byte packet would be less than 40 ms. We're also running a much smaller "experimental" network at BW125 SF6 CR8 which is about 5800 bps OTA. LoRa APRS just works.)

Why Did They Create LoRa, Anyway? (Besides to make money %^)

According to Semtech's own website:

"LoRa is the de facto wireless platform of Internet of Things (IoT). Semtech's LoRa chipsets connect sensors to the Cloud and enable real-time communication of data and analytics that can be utilized to enhance efficiency and productivity. LoRa devices enable smart IoT applications that solve some of the biggest challenges facing our planet: energy management, natural resource reduction, pollution control, and infrastructure efficiency."

In subsequent web pages and white papers, Semtech outlines how LoRa can enable "smart" everything, it seems. No toasters or toilets, yet.

Case Study: The Ubiquitous Utility Meter

Remember, LoRa was designed for the "Internet of Things". That's a pretty big universe, but a very real example is the lowly (but extremely important) electric, water, or gas utility meter. Before wireless, the only way the meter value was collected was by a human walking around and copying down the number shown on the meter. I never met a meter-reader person, but I can't imagine that they'd get to more than 15-30 meters per hour. Adding short-range wireless connectivity to the meter could mean that one person could just drive slowly through the neighborhood, slowly enough that every meter along the route (assuming the meters transmitted frequently enough and had reasonable range) would be heard at least once a billing cycle. Or, with a longer-range wireless technology, instead of the person driving around the neighborhood, each meter could communicate directly to a data aggregator device mounted on a power pole. That would require no one to manually collect the meter readings!

LoRa brings the ability to establish very low power, using primary battery or scavenged power, communications between things like utility meters and the utilities themselves. A water meter is often below ground in a concrete box mounted flush to the ground, and the radio path between that LoRa-equipped water meter and the neighborhood aggregator might be upwards of a half mile (~1 km). The water meter doesn't have much to say, perhaps once or twice a day it transmits the meter reading along with the meter ID. No more having some person driving around lifting the box lid and hand-writing the meter reading, or even driving the neighborhood and hearing the meters transmit.

That water meter isn't intended to be serviced except on the order of decades (the meter in front of my house is going on 50 years old, now), mostly when it malfunctions or a leak develops. Adding the LoRa radio to it saves the data collection effort, but incurs the expense of someone going out and replacing the battery on that meter every 5 to 10 years. That effort might take 10 minutes, once the technician arrives at the meter location. Open the lid, sweep the nasty spider webs and other creepy crawler infestations away, maybe the occasional snake (I live in the desert!), remove the depleted battery, install the fresh battery, then close things up. Heck, given the complexity of field-swapping a battery, it's generally easier and less problematic to swap the entire LoRa unit, battery and all! Newer LoRa transceivers are even more energy efficient.

One might think, that's no big deal. 10 minutes? But what happens when the utility is a moderate to big one, like Phoenix Arizona's Salt River Project or the City of Phoenix (5th most populous in the USA)? Suddenly, there's potentially hundreds of thousands of meters, and if the battery life is 10 years that's still tens of thousands of batteries that need replacement every year. At 10 minutes per meter, and a few minutes to drive to the next meter, call it 15 minutes per meter total. That means in an 8 hour day the tech can get to 32 meters. In a 5-day workweek, and 52 weeks per year, that's a little over 8,000 meters serviced per year. All that's assuming that the meters are close to one another! For a moderate to large utility, just swapping meter batteries or integrated radio/battery units can be a full-time job for dozens of techs. Compare that to the rare failure or need to service a traditional water meter. As well, the typical battery used in an install like this is an expensive lithium primary (non-rechargeable) cell, and their lifetime is impacted by heat and cold. As with all things, there are tradeoffs that must be considered to find the optimal solution. Keeping power demands as low as practical is important for long battery life! Reducing on-the-air time increases network capacity!

LoRa Link Budget as a Metric

The thing with LoRa link budget is that to get any particular link budget means changing BW and SF. While that doesn't sound particularly difficult, what is does change is the required transceiver frequency accuracy, the allowed local clock drift before waking, the amount of time a receiver must be active (not asleep or in standby), and most importantly the amount of time the transmitter must be active. TX-on duration has a significant impact on battery life. So, while the range of link budgets sounds alluring, taking advantage of them comes at a systems cost of channel capacity, energy consumption, and increased maintenance. In the end, preferring high link budget settings can kill the meter battery very quickly, which causes that technician to have to replace even more batteries. Preferring high link budgets can clog up the network, forcing more granular costly infrastructure. Selecting a reasonable link budget is a systems tradeoff. Factors that inform on appropriate link budgets include desired channel availability, simultaneous number of users and typical message size, power/energy consumption, and worst-case (in design) RF path loss. That last one is important: of the many water meters the utility may have, perhaps there are a few water meters that are really difficult to connect to, and would require the most extreme LoRa link budget to connect. In that case, the utility may get connectivity to that one meter in a different way. Don't degrade the overall network performance to meet the needs of a few outliers. Design for the future.

Hams, LoRa, and APRS

Hams really started experimenting with LoRa around a decade ago. There are plenty of accounts of using LoRa for ham radio purposes, perhaps the most notable being "the guy with the Swiss accent" on YouTube. Nearly if not all hams (at least the ones who wrote or videoed about it) who picked it up were intrigued by the high link budget. That caused them to be stuck in low-bit-rate muck. Even now, popular LoRa radio firmware has a default setting that equates to about 300 to 1200 bps. Yeesh - here we are, 50 years after 300 baud modems were obsolete, and 40 years since 1200 baud was on display at the museum, and the default settings for one of the most innovative digital radio technologies around is stuck in 1980.

So what should a good LoRa APRS network be? As I suggest above, it should at least represent a generational advance on traditional AX.25 1200-baud AFSK FM APRS radios. In the US, any significant region with even a moderate number of APRS-active hams rapidly overwhelms the channel carrying capacity. I'd imagine the same is true around the world. Carrying capacity must expand. Throughput must increase. Utility must advance. Robustness of infrastructure must improve. Hams need to find it useful and fun! LoRa can do it!

--Cheers and 73 - Jon N7UV