LoRa (Part 1)

Where Does This Featherweight Fit In?

In this new article series, Bob discusses LoRa—the Long Range spread spectrum modulation technique that promises to solve a number of the key issues in fulfilling the wireless IoT requirements. In Part 1, Bob starts with an introduction to LoRa, looking at what it is, what are its limitations and how those limitations affect how we use this technology.

I had several friends who wrestled in high school. One friend in particular was a little wiry guy who weighed about 120 pounds. As some of you may know, high school wrestlers compete in as many as 14 weight classes. Each weight class covers a 6- or 7-pound range. My friend was always trying to get to the lowest possible class. To facilitate this, before the weigh-in, he would fast and binge on Ex-Lax. It always seemed to defeat the advantage of the lighter class by coming into the match weakened by those actions.

This begins a new article series on LoRa—the Long Range spread spectrum modulation technique that promises to solve a number of the key issues in fulfilling the wireless Internet-Of-Things (IoT) hype—especially low power and long range (Figure 1). For purposes of this article series, I will be talking about LoRa devices communicating on a LoRaWAN (LoRa Wide Area Network). In this series, I won’t make a distinction and I’ll just call them both LoRa. Jeff Bachiochi laid a great foundation for understanding LoRa in two articles in his June 2017 (Circuit Cellar 323) [1] and July 2017 (Circuit Cellar 324) [2] articles. In part 1, Jeff provided some of the technical details about chirp spread spectrum and how the data packets are formed in the RF cloud. In particular, he discussed how LoRa achieves such range. If you want to dig even deeper into “LoRa Modulation Basics,” check out the Semtech Application Note by the same name [3].

At the end of part 1 and in part 2, Jeff went into the details of creating a peer-to-peer test module for verifying the range using a single wire for an antenna. I will try to not cover ground already covered by Jeff, but rather start at a high level and work down into more details as the series progress. In particular this month, I want to ask the question: “Is LoRa like my high school buddy? Is it trimmed down so much that it has lost its ability to fulfill the objectives we require to create wireless IoT devices?” So, this month, we will briefly look at what LoRa is. Then we will look at the practical limitations to achieve these amazing distances at such low power. Finally, we will look at the kind of applications for which this very low bandwidth will be ideally suited.

WHAT IS LoRa?
The LoRa technology was patented by a French company and later acquired by Semtech. The proprietary nature of this Long Range and Low Power technology affects the costs of LoRa chipsets when compared to LTE Cat M1 and other competing wireless technologies. We have done bill-of-materials for competing designs, and the LoRa chipsets are more expensive. We will talk more about this in a later article. Unlike Bluetooth Mesh which achieves long range through a mesh network, LoRa achieves its range in a star of stars type network. Many devices that connect to one gateway and many gateways connecting to the cloud (Figure 2). And the range specifications are impressive (more than 10 km in rural areas). In my tests, as well as in the tests documented by Jeff in Part 2 of his Circuit Cellar article, the real-world numbers—though not being close to the rural area numbers—are still impressive. Again, more on that in a later article.

LoRa uses sub-gigahertz license free radio frequency bands: the 868 MHz band in Europe, 915 MHz in North America and 433 MHz for Asia. This means that when you design your LoRa devices and your LoRa gateway, you will need to select the radios for your target area. It also means that you cannot have one device that will work in all regions.

Although LoRa devices could be used in a peer-to-peer network, the primary intent of the creators was for the LoRa devices to have a means of communicating to the cloud. For LoRa devices to communicate to the cloud, the LoRaWAN protocol was specified and is used by a number of cloud-based LoRa networks. There are three approaches to getting the data from your LoRa devices to the cloud: a private network that you create as part of your system design with your own LoRa gateways; a commercial network like MachineQ being deployed by Comcast, which gives you access to their gateways for which you pay for a data plan like you do a mobile data plan; and a community and open-source network like The Things Network (TTN), which provides free access to local gateways. We will explore these options in a later article.

Finally, there are three classes of traffic defined for LoRa [4]: Class A which is used for applications like those in Smart City devices that send data just a few times a day and the devices do not listen except after a transmission (Figure 3); Class B which is used for applications like irrigation that require the cloud to turn valves on or off with minimal latency—typically powered by batteries (Figure 4); and Class C which is used in applications like Smart Lighting where the LoRa device is constantly listening for pings to facility low latency actuation and is typically powered by the power grid (Figure 5).

RANGE AND BANDWIDTH
A term that is used to help us understand the theoretical limits of the range is the concept of the link budget, which is used in both wired and wireless communication systems. A link budget provides a means to take into account all of the gains and losses from the transmitter to the receiver. A very simplified equation for a link budget is to add all of the gains (in decibels) in the system to the transmitted power and subtracting all of the losses (in dB). There are some very good link budget calculators on the web [5]. From this you can see the theoretical distances that can be achieved with LoRa, which starts with a link budget of 154 dB. In comparison, the link budget for Cat M1 is 146 dB. Play around with the calculator and see how various factors like rainfall and elevation of the antenna affect the range. When you add cable attenuation and walls and trees and building attenuation you can get a much more realistic value for the maximum distance.

One of the questions that we should ask is: How does LoRa achieve such long range using such low power transmitters? Have they invented the IoT equivalent of the free lunch? No! LoRa achieves the long distances by using a very low bandwidth. The bandwidth for a Cat M1 device is 20 MHz. The maximum bandwidth of a LoRa device is configurable at 125 kHz, 250 kHz and 500 kHz. Another way to look at it is that the maximum data rate for a Cat M1 device is of the order of 10 Mbps. For LoRa in North America, the raw maximum data rate is 27 kbps. With this reduced data rate comes smaller payload sizes as well.

Practical concerns can become legal concerns, which further reduce the practical band-width. In Europe, devices using the LoRa frequencies are only allowed to transmit 1% of the time. This significantly reduces your data rate by a factor of 100. Practically—since LoRa uses the same frequencies to send and receive—it is not just the legal concerns that reduce the data rate, you need your LoRa devices to leave a lot of dead air.

Once you choose the network you will use to connect to the cloud, you will be limited by their rules and guidelines. For example, if you use TTN, it is recommended that you only transmit 10 downlink messages a day (including uplink ACKs!). Further reductions happen due to the recommended maximum payload of 12 bytes. This translates to a downlink data rate of 0.001 bps!

PRACTICAL USE CASES FOR LoRa
At the end of June, 2019, the Wikipedia article on LoRa stated the following:

“Semtech’s LoRa devices and wireless radio frequency technology (LoRa Technology) is a long range, low power wireless chipset that has become the de facto technology for Internet of Things (IoT) networks worldwide” [6].

The de facto technology for IoT networks worldwide? This is not even close to being true. I complained and Wikipedia removed this statement [7]. Don’t get me wrong. I was very impressed with the Long Range and the Low Power of LoRa in my test setup. LoRa does have a bright future for certain IoT networks. But LoRa is far from the “de facto technology for IoT networks worldwide.” And the reason is that most IoT devices cannot live with the data rates allowed.

Using TNN as representative of a public network, where do these limitations affect us in the real world? According to TTN’s Fair Access Policy, you should limit your air time to 30 seconds per day. For the maximum range Spread Factor, this amounts to 200 bytes per day for sending data up to the cloud. The Fair Access Policy will limit the amount of data you can send down to your device to less than 50 bytes per day.

Let’s assume that your application can tolerate this data budget. (At our company, we have yet to create an IoT device that could get by with so little data). But this leaves you with a much bigger problem. How do you handle Over-The-Air (OTA) software updates? An article in the IEEE Communications magazine for January 2017 documented some of the limitations of LoRa [8]. It is a useful article and I recommend it for determining the payload limitations of LoRa. But it didn’t address the need for OTA software updates. How do you perform an OTA software update when you are limited to 50 bytes per day? A small 16k program would take almost a year to update.

Just recently, we worked with a company that was looking to create a Smart City application. Their device was fairly simple. It was detecting only one thing. It really only needed an uplink. They would typically deploy about 500 of them in city of 200,000 people. The city they were targeting already had a TTN network and they really wanted to leverage this existing network. They wanted to send 24 packets of 10 bytes every day. This is close to the TTN’s policy and their specification could be tweaked to meet the policy. However, sending the raw sensor data to the cloud would far exceed 10 bytes. The project assumed that the device would perform a complicated, sophisticated and proprietary algorithm on the sensor data. I was not convinced that this algorithm could be perfected at the time of roll out to preclude requiring an OTA software update over the life of the product. And as we mentioned, OTA software updates are DOA with LoRa—at least on TTN.

If the sensors and actuators in your device are simple and the algorithms are in the cloud, I think you could take a chance on never having to update the software. And there are plenty of IoT examples where this is the case. Even if you design your own private gateway, to be able to do OTA software updates you would need to significantly reduce the range (by reducing the Spread Factor—more on that in a future article) and reduce the number of devices going to the gateway. The economics of scale begin to take their toll when we do that. Where I think LoRa works best is very low data rate projects with such simple software that you can guarantee that you will never need to do an OTA software update—or you have another means of doing software updates.

CONCLUSIONS
LoRa technology provides some amazing long-range wireless data transmissions at amazingly low power. But like my friend in high school, trimming down comes at a cost. As embedded system designers, we need to be aware of the costs up front. In my opinion, the future is not smaller and smaller programs that can be verified and expect to never be updated. The future is larger and more complex software packages that have flaws lurking in them. Often with sensors we cannot push the processing off to the cloud. We know that the IoT application has to be pretty simple for us to deploy without OTA software updates. And few are small enough to use LoRa’s range at the expense of OTA software updates.

There still is an important place for LoRa in our IoT tool box. And so next month we will delve deeper into LoRa and how it can be used in your IoT project. But, of course, only in thin slices. 

Read “LoRa (Part 2)” Here

RESOURCES

References:
[1] Circuit Cellar June 2017 Issue 323 Long Range, Low-Power Wireless Communications (Part 1) Trading Throughput for Distance
[2] Circuit Cellar July 2017 Issue 324 Long Range, Low-Power Wireless Communications (Part 2) Putting LoRa to Work
[3] https://www.semtech.com/uploads/documents/an1200.22.pdf
[4] Smart City our customer / our design victorstanley.com
Irrigation photo –  (stock image) no attribution
Smart Lighting  https://pxhere.com/en/photo/1379760 no attribution
[5] http://en.jirous.com/calculation-wifi This includes factors like elevation, rainfall as well as antenna, amplifier and transmitter gains.
[6] https://en.wikipedia.org/wiki/LoRa on July 1, 2019
[7] Note: The LoRa page on July 1, 2019 had the following disclaimer: “A major contributor to this article appears to have a close connection with its subject. It may require cleanup to comply with Wikipedia’s content policies, particularly neutral point of view. “
[8] Understanding the Limits of LoRaWAN https://arxiv.org/pdf/1607.08011.pdf

Semtech | www.semtech.com

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • OCTOBER 2019 #351 – Get a PDF of the issue

Sponsor this Article